Re: `C-b' is backward-char, `left' is left-char - why?

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Date: Sun, 05 Jun 2011 20:26:01 +0200
>> 
>> > The problems with this are not logical, they are with implementing it
>> > (both the movement itself and the resulting selection and highlight).
>> > Patches are welcome.
>> 
>> The resulting selection and highlight appear to do just what is needed
>> already and don't seem to have a problem with visual discontinuity.
>> 
>> So only the movement itself would appear to be an issue.
>
> Only if you accept the way the region is currently highlighted, as
> several disjoint stretches of text.  People who want strict visual
> operations might want something else, like contiguous regions.
>
>> If one has text like
>> 
>> llllllllRRRRRRRRllllll
>
> That's the easy use case.  Try figuring out the more complicated ones
> with embeddings and directional overrides.  UAX#9 allows up to 62
> levels of nested embeddings, with or without directional overrides,
> and Emacs supports them all.  Logical movement through that is clear,
> but visual one... last time I tried my mind boiled.

[...]

>> Actually, I've just tried entering mixed L2R and R2L stuff with the
>> keyboard and bidi-display-reordering set, and I find it quite
>> distracting that the insertion point for "reversed" text (with regard to
>> the current paragraph direction) gets increasingly distant from the
>> cursor itself.
>
> <Shrug> I just did the minimal change in the original redisplay
> design, whereby the cursor is placed on the character _after_ the
> insertion point in the logical order.  Even that required a total
> rewrite of the function that figures out where to draw the cursor.
> Patches are welcome to rewrite it again so as to keep the cursor
> closer to the insertion point.

I have thought about it, and I guess the key point is ambiguity of
cursor display.  The cursor is usually displayed just after the last
inserted character.  Which means to the left in R2L contexts, and to the
right in L2R contexts.  For a vertical cursor between characters, this
means that

LLLL^RRRR

is ambiguous: we are either at the end of the LLLL passage, or at the
end of the RRRR passage.  For a block or underline cursor, the ambiguity
gets worse:

LLL£RRRR

can mean that the cursor is next before last in the L2R passage, or last
in the R2L passage.

I think what is needed in this particular case is a virtual fill
character (perhaps the direction switch glyph, but displayed with a
different face?) at the insertion point when we are inserting in reverse
paragraph direction and the cursor would be displayed on a forward
paragraph character (including newline), not logically adjacent to the
insertion point.  Either that, or generally switch cursor type for
reverse direction insertion, so that one knows whether one has an L2R or
R2L facing cursor.

> Actually, TRT would be to split the cursor in two, because it plays
> two different roles whose correct positions in this case do not
> coincide.

They diverge only on borders between L2R and R2L, and a virtual padding
like described above gives the cursor a buffer that allows it to never
split.

> That would need an even deeper surgery, including in terminal-specific
> parts -- xterm.c, w32term.c, etc.  And what to do on a TTY with its
> hardware cursor?

The virtual padding approach should work on a tty since it requires only
one cursor to display.

-- 
David Kastrup