Re: Caret

Highlighted selection is less a problem because this involves separate
actions to mark the start and end of selection. And an explicit move action
or separate clicks : the user chose himself to perform those actions and
knows where he comes from and where he is going to. In addition the
selction is marked as a whole, and is not just two tiny positions.

Yes it is often possible to show different caret forms, even in a TTY
terminal (they typically use a block-type caret, it has to remain
rectangular, but it may still vary in size and poition in the character
cell. But sometimes it will be dependant on the TTY protocol which offers
limit control of their "cursor" and very limited presentation options.

2012/11/15 Eli Zaretskii <eliz_at_gnu.org>

> > 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:05:34 CST