User talk:Alex brollo/PersonalButtons

Introduction and preamble

This is the continuance of the posts about Alex brollo's proofreading tools. Until now, the conversations were conducted on either on Alex brollo's it.WS talk page, or on Ineuw's en.WS talk page. I invite anyone with an interest in additional personalized proofreading tools to comment here.

Part of Alex's proofreading kit provide text formatting tools accessible from the sidebar, and user definable toolbar buttons. This is where my main interest lies because of the loss of the legacy mw toolbar and the incomplete implementation of the mw enhanced editor tools.

Alex's toolbar is currently affixed at the lower right corner of the edit window and is activated/managed by a set of three procedures in the user's common.js:

mw.loader.load('https://wikisource.org/w/index.php?title=User:Alex_brollo/Library.js&action=raw&ctype=text/javascript');
mw.loader.load('https://wikisource.org/w/index.php?title=User:Alex_brollo/RMF_tools.js&action=raw&ctype=text/javascript');
mw.loader.load('https://wikisource.org/w/index.php?title=Buttons_tools.js&action=raw&ctype=text/javascript');

The buttons are defined in a .js subpage related to the user and the buttons can be appear in various contexts according to the user's preferences indicated in the code.

The buttons have options to either insert or replace a selected character or text at the cursor, or wikify (encapsulate) a selected text, similar to the previous mw toolbar buttons. The idea is a work in progress and the identified issues are currently under discussion. These are the inability to insert in the header or footer, and the cursor's resting position after completion of an action. — Ineuw talk 08:42, 19 October 2013 (UTC)

A new strategy to work with textfields (input & textarea)

It would be great, that any editing tool could act on any input or textarea - this is particularly wanted when editing nsPage pages with their header, main text, and footer; but the same occurs dealing with multi-field forms. DOM document.activeElement is useless, since as soon a link or a button is clicked, that clicked link or button become current activeElement. :-(

This is a current solution of the issue (WIP), merged into my Library.js:

// a global variable is initialized
activeArea="";

// active area element is saved at .focusin event, so that the last input or textarea is saved:
$("textarea, input").focusin(function(){activeArea=this;} );

// gets selecion from activeArea as a three-string list (pre,selecion,post):
function selezione() {
    var s=[];
	var txt = activeArea.value;
	s[0] = txt.substring(0, activeArea.selectionStart);
	s[1] = txt.substring(activeArea.selectionStart, activeArea.selectionEnd);
	s[2] = txt.substring(activeArea.selectionEnd);
	return s;
}

// puts the content of a three-string list as activeArea value:
function putSelezione (s) {
activeArea.value=s.join("");
activeArea.selectionStart=s[0].length;
activeArea.selectionEnd=s[0].length+s[1].length;
}

The whole stuff seems run; it is used into the new incaps() function, that can replace incapsula() with a new behavior; the replSel() function also uses the new strategy. (the tool works into the last focused textarea or input field, and finally it puts the cursor into it). --Alex brollo (talk) 14:28, 19 October 2013 (UTC)

The solution works fine. The cursor stays where it should. As an aside, your posted code helps me understand and learn a bit of javascript in the context of our work.— Ineuw talk 17:28, 19 October 2013 (UTC)

I find comfortable sometimes to save selection - t.i. to exit with actively selectioned the text, previously selected when clicking the tool. This allows to "nest structures" saving the time for selecting again; the drawback is, that a keystroke replaces all the selectioned text, this effect is so annoying that I discarded it. --Alex brollo (talk) 18:42, 19 October 2013 (UTC)

Simpler, very simpler.... :-(

There's a function insertTags(), normally running into environment and used into editTools, and generated by <charInsert>

It can be called into a newButton():

newButton("//upload.wikimedia.org/wikipedia/commons/2/2f/Ansi_0198.svg","insertTags('Æ','','')","es")

and runs exactly as any editTool .

Parameters are:

1. prefix string, it is added before selection;
2. postfix string, it is added after selection;
3. example text, it is added between prefix and postfix if selection is empty.

It works into any textarea or input field; and.... it runs too in Internet Explorer while previous scripts do not please use them under Firefox or Chrome; Internet Explorer gives unconsistant results.

Important

If needed, use html entities &quot; &apos; &lt; &gt; &amp; for reserved characters " ' < > & into parameters of insertTag().

Solutions previously tried

After loosing the mw toolbar functionality and before trying Alex brollo's toolbar, I installed this Firefox add-on and added this "Insert tool" procedure. Partially managed to modify the code for my purposes, and placed the modified code HERE. The drawback is that while it inserts a character in any textarea, (independent of mw), the button selection closes once it looses focus. I emailed the developer and asked if I could modify his code to display the selections permanently but he never responded. — Ineuw talk 18:18, 19 October 2013 (UTC)

Find & replace tool

There is work in progress on find and replace tool. It's most powerful action is, to remember replacement shot with flagged "Ricorda"; use only if you are sure that it is a commonly needed replacement with no conflict. Such "remembered" replacements are stored into a work-specific cookie (the name of the cookie is the basename of Index page and it is loaded as soon as a page with the same pagename is loaded. Example: I'm working presently on Index:De re metallica (1912).djvu, and the cookie's name is De re metallica.djvu).

Presently the whole set of saved replacements are shot by postOCR tool, but there are serious limitations. The replacements array can't be edited or saved; when a replacement is wrongly saved, there is no mean to fix it and the only fixing way is erase it is to erase the whole cookie content. The cookie length is limited, and the encoding is byte-wasting for encoding issues, so don't presume to be able to save more than 40-50 simple and brief replacements. Nevertheless, its magics really saved lots of time in some cases when scannos are common and similar.

Someday, this cookie-based trick to save replacements should be replaced by something much more user-friendly, editable, and stable.