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

[Andy Moreton]

On Thu 02 Jun 2011, Eli Zaretskii wrote:

>> From: Andy Moreton <address@hidden>
>> 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!

I find this to be baffling, but then I'm not the target audience for R2L
languages. Is this motion what users expect to happen for bidi text ?

So C-f/C-b move N characters in the buffer, then work out where that
lives on the screen (which may be to the right or left of the start
position. So far, so good.

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

Now my head hurts :-)

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

OK, I completely misunderstood the semantics here, but your explanation
has again beeen enlightening. 

So is it that right-char means advance forward in screen display order
(which may move to the right or the left) and then work out which
buffer position it corresponds to ?

    AndyM