Re: Caret

> From: Philippe Verdy <verdy_p_at_wanadoo.fr>
> Date: Thu, 15 Nov 2012 08:09:51 +0100
> Cc: Eli Zaretskii <eliz_at_gnu.org>, Jeff Senn <senn_at_maya.com>,
> Unicode Mailing List <unicode_at_unicode.org>
>
> One of the issues caused by the two carets is that sometmes you won"t be
> able to have them BOTH visible at the same time in the screen area. This
> adds another complecity : how do you locate the second caret if it's not
> visible ?

That's indeed an issue, but perhaps a similar case with highlighted
selection could serve as an example of a reasonable solution.

> * at this point it reaches the point where the direction will change. Two
> caret positions are possible for the same logical position. However as you
> have just pressed the RIGHT key, the editors knows that you are going
> foreward, and should show the BEFORE context (the before context is still
> in latin which is RTL, so the caret will be positioned immediately to the
> right of the Latin text, showing the LTR direction on arrow head of the
> caret glyph, the display will be:
> latin_CIBARA
> * if you press the RIGHT key a second time, the editor knows that you are
> already showing the BEFORE context, so it switch to display the AFTER
> context and the caret is positioned to the right of the ARABIC word and it
> displays the caret at the new position with the caret glyph showing an
> arrow head reversed to the LEFT direction (the logical insertion point has
> NOT changed, the encoded text has also NOT changed):
> latinCIBARA^

As you yourself point out in another mail, this scheme has a serious
drawback in that some RIGHT keypresses don't move the logical-order
position of the caret. In a programmable editor such as Emacs this is
unacceptable, because editor macros and commands that use the basic
forward-char command will not arrive at the place where they are
expected.

> This operatinig mode can work in plain-text terminals with a single caret
> (except that arrowheads may possibly not be displayed; but instead the
> caret may still be a half-block positioned at the TOP of the character cell
> oe at the bottom, when the normal caret is a thinner block usually below,
> or a full block. It could work in Emacs.

Plain-text terminals are not an issue in Emacs, because the second
caret can be displayed using an overlay. There are already features
in Emacs that use similar facilities, like the mode which displays a
binary file both as hex dump and as readable characters (similar to
what 'od' shows), and displays a cursor in each of the two panes.

I believe other advanced editors can do similar things on a TTY.
Received on Thu Nov 15 2012 - 12:01:00 CST