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

[Drew Adams]

> > I think you still have not given a good reason for swapping 
> > the arrow keys in an R2L para.
> 
> The reason for that is the important special case where the paragraph
> is made of R2L text only.  In such a paragraph, moving to the left
> means moving forward in the buffer.  That is why the left arrow does
> the same as C-f in a R2L paragraph.

I understand. I think that is open for debate, but you'll get no debate on it
from me.

I'll just say that it's not clear that this arrow reversal and its consequent
difference from C-f/C-b is a great idea, especially since it happens only if the
entire para is R2L. Sounds like these behavior differences (almost modal) could
be confusing. Probably bidi user experience will answer the question of whether
it is a good choice.

> > Just explain what you explained in your first mail today: 
> > logical order (whether C-f/C-b or arrows), paragraphs that
> > are only R2L or only L2R, etc. You said it very clearly and
> > fairly succinctly. I think it probably cleared things up for
> > several of us.
> 
> I explained some of that already, in the node "Bidirectional Editing"
> in the Emacs user manual.  The bidi-aware behavior of the arrow keys
> is described in the node "Moving Point".  Please see if that's enough.

Hm.  Well, you try to keep things at a user, as opposed to an
implementation/design, level, which is correct for the Emacs manual.  From that
point of view, saying `"logical" (or "reading") order' is OK.

But I think you should also make it clear (clearer) that this "logical" order
corresponds to buffer position, even if that might seem more
programmer-oriented. Emacs users sooner or later have an understanding of buffer
positions, so you might as well anchor the notion of "logical" order as being
buffer order.

In fact, you might drop "logical" altogether - the word itself doesn't really
help here. If you speak about the order of the chars in the buffer (as opposed
to how they appear) I think that will be clear.

And changing "character position" to "buffer position" would help. The former is
ambiguous, or at least it could be read in different ways. It is char position
in the buffer that is important. I would suggest emphasizing buffer
order/position.

(In any case, you do touch on implementation/design anyway, when you speak about
display position.)

What I got from your mail yesterday, which I think is clear there, is that (a)
the buffer text stays put, regardless of how it might be displayed (I already
supposed that), and (b) cursor movement always follows buffer order: forward
means toward eob; backward means toward bob.

It is (b) that is not so clear from the doc. That notion of "logical" movement
(movement along the buffer-position gradient) is important to understand. 

It's one thing to indicate that display order can differ from buffer order. It's
another thing to make clear that cursor motion always follows buffer order
(until you introduce visual movement to the mix). `forward-foobar' pretty much
always implies movement toward eob. This is important to understand, for both
interactive use and programming. And I don't think it comes across in the
current doc.

Admittedly, it can be tricky to talk about these things. But I found your mail
yesterday to be clearer than the current doc. In the doc you say things like
"the buffer is reordered for display", which is correct but which could also be
misunderstood. The chars are not reordered in the buffer - the buffer itself is
not reordered. It is just that the displayed order differs from the buffer order
(which does not change).

Yes, I'm splitting hairs, but it can help to try reading it in as confusing a
manner as possible, to see what difficulties others might have. ;-)  HTH.

BTW, maybe the node should be called Bidirectional Text (or Editing
Bidirectional Text) instead of Bidirectional Editing. We've all been doing
bidirectional (multidirectional) editing forever.