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

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> Date: Thu, 02 Jun 2011 17:23:01 +0100
> 
> > 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 ?

Yes, definitely.  Those expectations are the primary reason why I
wrote right-char and left-char (and also right-word and left-word),
and why I bound the arrow keys to them.

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

Correct.  Btw, this has always been like that, even in the Emacs 23
unidirectional display.  Emacs never assumed that moving N characters
forward means the cursor should move N characters to the right on the
screen.  It always computed where to draw the cursor, it's just that
the unidirectional code which computed that assumed that character
positions increase linearly with screen positions.

> > 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 :-)

Well, maybe if you look at the body of right-char, you will see the
light:

  (if (eq (current-bidi-paragraph-direction) 'left-to-right)
      (forward-char n)
    (backward-char n)))

That's all there is to it: it does either forward-char or
backward-char, depending on the base direction of the current
paragraph.  And we've already established that forward-char and
backward-char can move to the left or to the right according to the
text across which they move.

The paragraph direction determines how the paragraph is displayed: in
a left-to-right paragraph, lines begin at the left margin of the
window, while in the right-to-left paragraph they begin at the right
margin.

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

No, see the body of right-char above.  IOW, both forward-char and
right-char move in the buffer order, it's just that they sometimes
move in the same direction of buffer positions and sometimes in the
opposite ones.

(It is actually impossible to do what you say, because right-char must
be able to work even when the display is not up to date, e.g. if one
leans on the key and has a fast auto-repeat rate, or if some complex
Lisp program calls it.  By contrast, "screen display" is not defined
unless Emacs succeeded to catch up with user keystrokes, and brought
the display in sync with the buffer.)