Re: arrow keys vs. C-f/b/n/p

[Eli Zaretskii]

> From: Lennart Borgman <address@hidden>
> Date: Sat, 12 Jun 2010 20:58:18 +0200
> Cc: address@hidden
> 
> > For users of R2L scripts, what you suggest is a disaster.  If cursor
> > motion is visual by default, one cannot even mark text by holding
> > Shift and moving point with the arrow keys.
> 
> 
> I see no reason for this. The arrow keys will with visual motion move
> just as they do if all the text where just L2R. So the visual part
> will work as before (on the user side, implementation may have to
> change).

It's not just an implementation issue.  Here's an example.  A text in
the buffer is

  abcde ABCDE xyz

It will be displayed as 

  abcde EDCBA xyz

Now, suppose I move cursor in visual order, as you suggest, holding
the Shift key, starting at the first character `a' and ending at `C'.
The underline below shows which characters I traversed:

  abcde EDCBA xyz
  ---------

Now, what characters do you think should be displayed with the region
face?

Now I type "M-w".  What text will that copy to the kill ring?

> Converting the visual region you visually see on the screen to a
> logical range is a bit difficult, but not impossible.

It's impossible.  There's no general algorithm to reverse the
logical-to-visual reordering of text, i.e. produce the original
logical-order text from its visual-order replica on the screen.  Only
relatively simple cases, without embeddings that push the
bidirectional level beyond 2 or 3 (UAX#9 allows up to 60 levels) can
be reversed.

> The difficulty is of course to decide what the range on the screen
> will be if the end points of the visual region happen to disagree
> about the direction.

That's the difficulty; what's your solution?  I don't know of any
solution that would make sense and would not complicate Emacs beyond
any reason.

> The answer to this is as far as I can see that the visual region in
> this case no longer internally corresponds to a single range, but to
> two noncontinuous ranges in the buffer. If I am correct on this, is
> not this then a difficulty that must be handled to finish the bidi
> support?

Do you have _any_ idea what your suggestion means?  Having a region
with several non-contiguous ranges of text blows up so many Emacs
features that I don't even know where to start explaining how wrong
that is.

> > And that's just the tip
> > of the iceberg.  Without logical-order motion keys, Emacs (and every
> > other editor of similar sophistication) is much less useful.
> 
> I think you are referring to the difficulty I suggested above. If not,
> what more problems do you see?

Text properties and overlays all depend on contiguous regions of text
in the logical order.  What you suggest means a complete rewrite of
all of them.  Some "difficulty"!