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

[Eli Zaretskii <eliz@gnu.org>]

> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Thu, 02 Jun 2011 13:59:48 +0100
> 
> > Maybe the following variant of the 2nd sentence sounds better:
> >
> >   The effect on the screen is to place the cursor on the character N
> >   buffer positions forward, which could be to the left or to the
> >   right, depending on the bidirectional context.
> >
> > That's because Emacs doesn't really move point one character at a
> > time (when N is more than 1).
> 
> I think that is definitely clearer than what we have now.

Thanks, I will make this change.

> (right-char &optional N)
> 
> Move point N characters to the right (to the left if N is negative). On
> reaching beginning or end of buffer, stop and signal error.
> 
> The effect on the buffer is to place the cursor on the character N
> screen positions to the right, which could be forward or backward from
> the current position, depending on the bidirectional context.

Here, as they say, the plot thickens: unlike C-f/C-b that _always_
move forward resp backward in the buffer, <right> and <left> don't
always move to the right resp to the left.  E.g., if you press <right>
in a paragraph whose bidi-paragraph-direction is left-to-right, then
the cursor will actually move to the _left_ when you get to some R2L
text embedded within this paragraph.  You can see an example of this
in etc/HELLO, in the lines that show Arabic and Hebrew welcome
phrases.

So if you invoke (right-char 10) when point is on characters from some
R2L script, the cursor could move to the left!

IOW, the names of <right> and <left> only express the _global_,
"grosso modo" direction of motion.  That generally DTRT (according to
user expectations) assuming that left-to-right paragraphs contain
mostly L2R text and only occasionally short sequences of R2L text; and
vice versa in right-to-left paragraphs.  But if a left-to-right
paragraph is made solely out of R2L text (a very rare and unusual
phenomenon), <right> will almost always move to the _left_, and <left>
to the right!  So in this case, even the large-scale movement is in
the "wrong" direction.

But while we could (for the doc string purposes) quite safely
disregard the use case of paragraph having the "wrong" direction and
disrupting the global movement direction as described above, the doc
string you suggest is wrong even locally, when short sequences of R2L
text are embedded in an otherwise left-to-right paragraph, or vice
versa.  This cannot be disregarded, so we must find a better way of
describing the effect of the arrow keys in mixed bidirectional text.
Ideas are welcome.