Re: Caret

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Thu, 15 Nov 2012 20:51:56 +0100

Yes, and I admitted it. This is still an editor design choice about how to
map the commands. But commands are in fact less important than showing to
the user in which state he is currently in order to allow him to perform
the correct action using these commands.
Two carets anyway are not a requirement because the editor may simply
choose to always diaply only one visual position which is "usually" in the
forward direction, i.e. in the direction indicated by the UBA resolution of
the last unbreakable grapheme cluster before the insertion point: pressing
the END command to go to the end of line for example may go to a position
in the middle of the line, with characters displayed on both sides of the
displayed caret.

There will be no ambiguity as long as the caret displays the UBA-resolved
direction of the last grapheme cluster, e.g. with a small arrow head.
attached to it, as long as the user is trained to understand the convention
used in the editor (and displaying the second visual position of the end of
line may not always help better the user, in addition to the difficulty to
display this second position in the same view).

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

> > From: Philippe Verdy <verdy_p_at_wanadoo.fr>
> > Date: Thu, 15 Nov 2012 19:27:37 +0100
> > Cc: Martin Dürst <duerst_at_it.aoyama.ac.jp>,
> > Jeff Senn <senn_at_maya.com>, Unicode Mailing List <
> unicode_at_unicode.org>
> >
> > So what do you mean by "will not arrive at the place where they are
> > expected" ?
>
> That issuing a forward-char command N times at position P will get me
> to any position that is not P+N.
>
> > Either Emacs has a command for moving the logicial position in
> > the backward (CTRL+D) or forward (CTRL+F) direction, then it will do
> that,
> > but the caret will of course not move always in the same visual
> direction.
>
> Your example showed that to move 1 logical position, one must
> sometimes type Ctrl-F twice. This is not acceptable.
>
Received on Thu Nov 15 2012 - 13:53:41 CST

This archive was generated by hypermail 2.2.0 : Thu Nov 15 2012 - 13:53:41 CST