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

[Drew Adams]

> > (I am still dubious about decoupling the arrow keys and C-f/C-b
> > keybindings.  Maybe we should provide a separate set of keybindings
> > instead.)
> 
> It's actually not really decoupled.
> It just switches between "C-f = right and C-b = left" and
> "C-f = left and C-b = right" based on the paragraph's direction.
> Which seems eminently meaningful since the associating between
> "forward" and "right" is just based on our usual convention of
> writing L2R.

I hesitate to say anything here, since I know _zero_ about R2L. But maybe it
will help somehow to expose my naivety in this regard. If not, ignore. Here
goes...

On the surface this seems wrong and overly complicated (to me). "Eminently
meaningful" it no doubt is, but it seems somehow bass ackwards. ;-) It seems
wrong for `right' to mean "left".

Why would it be wrong for `right' (right arrow) to always represent movement
toward the right, regardless of R2L/L2R?

I suppose that you want to make `C-f' move "forward", which is arguably toward
the left in R2L languages, and you want to keep the association of `C-f' with
`right' (right arrow).

But is it really important that "forward" in a command name move toward the left
in R2L? Why should "forward" necessarily mean "from text beginning toward text
end" rather than just "toward the right"? What is at stake here?

You don't change the meaning of `bobp' to `eobp' for R2L, do you? You don't swap
the meanings of "left" and "right". Why exchange "forward" and "backward" but
not "left" and right"? Just which things really need to be flipped/mirrored?

Why not leave everything as it is wrt "forward" movement, and let users
understand that "forward" always means toward the right (in both L2R and R2L)?
Wouldn't that be just as useful and a lot less confusing overall?

Why would you want `C-f' to move toward the right in one paragraph and then jump
to the "beginning" (at the right end) of the "next" paragraph and start moving
toward the left - just because it is R2L? Why wouldn't you want `C-f' (and the
`right' key and `C-M-f' and `forward-paragraph'...) to always move right,
consistently?

OK, I understand that there is a mental association of "forward" with the
direction that text is inserted, but how important is it that command names
reflect that? Will someone be confused or offended if `backward-paragraph'
always moves toward the left? Will someone complain that what they think of as
"forward" we call "backward"?

Maybe, if we kept things consistent wrt forward-means-right then we would also
want a new command/key that would jump to the "beginning" of the next paragraph,
where that "beginning" position would be a different for R2L and L2R paragraphs.
If so, then we could just add that command/key. But once you are in a paragraph,
I would think that the ordinary motion etc. commands could work normally.

IOW, why not introduce any convenient DWIM transitioning behavior only at
R2L/L2R boundaries, and leave the behavior within a piece of R2L or L2R text
alone?

Maybe you'll say that at least `C-d' and `backspace' need to flip direction
(forward/backward), so why not `C-f' also?

I have the same naive question for those keys - why not just let R2L flip the
_meaning_ of forward/backward instead of the key behavior, so that `C-d' and
`backspace' are always rightward and leftward deletion, respectively? Is it
important that the keys themselves flip?

I can see that self-insertion should move point to the left of the inserted char
in R2L. Beyond that, I don't see why all or most key behaviors need to flip.

> Now addmitedly, the particular place where the choice between the two
> forms of coupling is made is up for discussion: it could be 
> based on the direction of text underneath point (basically, make
> the arrow move visually rather than logically), or based on the
> direction of the paragraph (what we now have), or based on user
> preferences (default depends on the locale).  I don't have a clear
> preference, but I think that the current choice is  pretty good
> compromise between "no need for customization, auto-adjusts to
> mixes of L2R and R2L buffers" and "still
> move in logical rather than visual order".

Why not keep it simple and just have `C-f' and `right' always move toward the
right?  Likewise for everything that has a "forward" meaning.  Why would that be
problematic for a R2L user/language?

This sounds a bit like trying to redefine "northward" as "southward" when you
cross the equator into the southern hemisphere. What's the point?

Again, I know nothing about R2L. I'm sure it's a tough and tricky problem, and
I'm sure you have thought it all out carefully. It just seems wrong and
unnecessarily complicated for this ignoramus who has not thought it all out.

If nothing else, perhaps the naive questions expressed here will help you
document the bidi stuff for other naive users - HTH.  Perhaps something
analogous to node `(elisp) Not Intervals' would be helpful for this, explaining
the logic behind the design choices.