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 00:26:59 +0100
>
>>  - forward-char moves forward one character in the buffer, which in
>>    right-to-left text moves backward one position on the screen.
>
> Not "backward", but to the left.  "Forward" and "backward" are not
> well-defined on the screen in bidirectional context.  For someone who
> reads the bidirectional text, C-f always moves forward, i.e. in the
> reading direction, the direction in which we scan characters while
> reading the text.

Explaining motion in terms of buffer position (forward and backward),
reading direction (l2r/r2l) and screen position (left and right) may
help to disambiguate things as long as those terms are used consistently
and explained broefly in the doc string.

>>  - right-char moves forward one position on the screen, which in
>>    right-to-left text moves backward one character in the buffer.
>
> This is misleading.  "Forward one position on the screen" is not well-
> defined, so using it will confuse the reader.  Using "to the right"
> instead is well-defined, but only _mostly_ correct, because there's no
> pure right-to-left or left-to-right text.  Almost always there's some
> left-to-right text (e.g., digits) embedded in predominantly
> right-to-left text and vice versa.  (That's why the thing is called
> "bidirectional".)  When you use right-char to move over left-to-right
> characters embedded in otherwise right-to-left text, the cursor will
> move to the left.  And that's even before we consider further
> complications such as directional overrides (the RLE, RLO,
> etc. control characters).

I realised that this was a simplification, but it may make the overall
scheme clearer if the simple version is presented first and then the
additional complications explained.

> It would be more precise to tell that right-char will advance in the
> buffer when used in a paragraph whose direction is left-to-right, but
> will move backward in the buffer when used in a paragraph with
> right-to-left direction.  But I'm not sure such a description will do
> a better job, because explaining a simple idea such as cursor motion
> via a much more complex issue of bidi-paragraph-direction doesn't
> sound right.  By analogy, if you ask about laws wrt to traffic lights,
> you will not be amused to first get a lecture about special relativity
> theory that could potentially make the red light look green due to
> Doppler effect.

While overly complex descriptions are not useful, the doc strings do
need to convey whether the simple motion is relative to the buffer or
the screen position for each command.

>> (forward-char &optional N)
>> 
>> Move point N characters forward (backward if N is negative).
>> On reaching end or beginning of buffer, stop and signal error.
>> 
>> Movement on the screen depends on the bidirectional context. Moving
>> forward over left-to-right text moves to the right on the screen, but
>> moving forward over right-to-left text moves _backward_ on the screen.
>                                                ^^^^^^^^^^^
> Should be "_to_the_left_"
Agreed.

>> This is in contrast with right-char, which see.
>
> I'm okay with this if it helps to make the issue less vague, but you
> should realize that it is also inaccurate, because "left-to-right
> text" is not well-defined.  There are "weak" and "neutral" characters
> whose directionality is defined by surrounding strong directional
> characters.  There are directional override control characters that
> can override the intrinsic properties of the following characters.
> Etc., etc. -- all these can invalidate the simple description above.

I understand that there additional complications - I was trying to write
something that would explain the simpler cases so that the behaviour in
more complex cases could be inferred from the simpler ones.

So for forward-char, movement of point is always N characters forward in
the buffer. The effect on the screen position must be considered as a
sequence of single character movements in the buffer, each of which may
move the screen position left or right (depending on the bidirectional
context).

Is that more accurate ?

Thnaks for the patient explanations,

   AndyM