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

[Eli Zaretskii]

> From: "Drew Adams" <address@hidden>
> Cc: "'Eli Zaretskii'" <address@hidden>, "'David Kastrup'" <address@hidden>,
>         <address@hidden>
> Date: Fri, 11 Jun 2010 10:12:45 -0700
> 
> On the surface this seems wrong and overly complicated (to me). "Eminently
> meaningful" it no doubt is, but it seems somehow bass ackwards. ;-)

Do you still think that, after reading my explanations?

> It seems wrong for `right' to mean "left".

It does seem wrong.  Which is why Emacs doesn't do that.  Do you
agree, after reading my explanations?

> Why would it be wrong for `right' (right arrow) to always represent movement
> toward the right, regardless of R2L/L2R?

It is not wrong, which is why Emacs behaves precisely like that.

The only exception is when R2L text is embedded in a L2R paragraph
(i.e. in otherwise mostly L2R text).  Since arrow keys still move in
logical order, the direction is reversed while we are traversing R2L
text; it returns to its usual sense when point is back inside L2R
text.

Having the right arrow always go right (i.e. in the visual order)
means that users will be unable to press the Shift key and have the
text they traverse be marked correctly.  That is why we have only the
logical-order movement for now -- because it is indispensable.  While
I don't object to have a visual-order movement mode, I think it is
much less useful, and it must be a separate mode in any case.

In general, I believe the visual-mode movement is useful only to
people who don't really read the bidirectional text they traverse with
the cursor-motion keys.  Any person who actually reads and understand
the text will need the logical-order motion first and foremost, and
the fact that direction is sometimes switched for a short period of
time is expected and understood by users of bidirectional scripts.  It
is a necessary complication, and one that is not hard to become used
to -- because the cursor moves in the reading order, the same order
our eyes move when we scan text.

> I suppose that you want to make `C-f' move "forward", which is arguably toward
> the left in R2L languages, and you want to keep the association of `C-f' with
> `right' (right arrow).

Why would I want C-f to be associated with <right> if it actually
moves to the left?  Don't you think it's terribly confusing mentally?

> But is it really important that "forward" in a command name move toward the 
> left
> in R2L? Why should "forward" necessarily mean "from text beginning toward text
> end" rather than just "toward the right"? What is at stake here?

At stake here is a very fundamental issue: the reading order is still
from character position 1 to position 2 to 3 and so forth.  The order
on the screen does not change this fundamental fact.  If you break
this fundamental relation between the buffer order and the reading
order, users will throw Emacs out the window.

> You don't change the meaning of `bobp' to `eobp' for R2L, do you? You don't 
> swap
> the meanings of "left" and "right". Why exchange "forward" and "backward" but
> not "left" and right"?

We didn't change forward and backward.  We did change the relation
between left/right and forward/backward.  That is, "right" is not
always "forward" anymore.

> Just which things really need to be flipped/mirrored?

We need to break the one-to-one relation between buffer's logical
order and the left/right direction.  This is what bidirectional text
support is all about: "leftmost" no longer means "the first", because
screen direction and screen sides no longer correspond to buffer
order, in general.

> Why not leave everything as it is wrt "forward" movement, and let users
> understand that "forward" always means toward the right (in both L2R and R2L)?
> Wouldn't that be just as useful and a lot less confusing overall?

No, it would be terribly confusing.  "Forward" must mean what the word
means, and "left" must also mean what the word says.  Any other way
means placing a terrible mental burden on the user -- and for what?
for convenience of ELisp programmers?

> Maybe you'll say that at least `C-d' and `backspace' need to flip direction
> (forward/backward)

They don't, and shouldn't, IMO.  C-d always deletes the character at
point, and Backspace always deletes the character before point.  The
basic Emacs notions of "before point" and "after point" are not
changed by the bidi support, because doing that would mean that
everything in Emacs would stop working.

In general, the basic design of the bidi support changes only the
display features.  It changes nothing in how buffer text is processed
and accessed.  This is done on purpose: I strongly believe that
bidirectional text is a display-only feature.  It must not change
anything else.

> I can see that self-insertion should move point to the left of the inserted 
> char
> in R2L.

This is a misunderstanding.  There's no "left" and "right" in the
buffer.  Insertion doesn't move point to the left, it moves point
farther from the beginning of the buffer, i.e. it increases its buffer
position.  Whether this is right or left on the screen depends on the
surrounding bidirectional context.  I could even concoct an example
where inserting a single character reorders many characters around the
insertion locus and moves the cursor far away from its previous
position.

> Again, I know nothing about R2L. I'm sure it's a tough and tricky problem, and
> I'm sure you have thought it all out carefully. It just seems wrong and
> unnecessarily complicated for this ignoramus who has not thought it all out.

Complicated, yes.  But also necessary.  Any other solution is simply
wrong, from the user perspective.

> If nothing else, perhaps the naive questions expressed here will help you
> document the bidi stuff for other naive users - HTH.

Naive users who read bidirectional scripts do not need this to be
explained: they expect this behavior by default.

> Perhaps something analogous to node `(elisp) Not Intervals' would be
> helpful for this, explaining the logic behind the design choices.

We don't explain design choices in the manuals.  There're plenty of
comments in the code to explain these decisions; if you or someone
else can point out where more commentary is in order, I'd be more than
happy to add whatever is missing, being a documentation maniac.