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

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> 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.

> llllllllRRRRRrrrllllll
> lllllllLrrrrrRRRllllll

I find this flipping confusing and unexpected, but if someone wants
this, I don't mind.

> 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.

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.  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?  IOW, if people are queuing up to
improve the bidi display, there's enough work here for several
lifetimes.