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

[Drew Adams]

> >> 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.
> > 
> > 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".
> 
> No, Stefan is not saying 'right' should mean "left"!

When I used `...' quotes for `right', I was referring to the `right' key, aka
<right> aka "right arrow".  The rest of my post also makes this clear, I think.

> He is saying that 'right' moves right, 'left' moves left, 
> 'C-f' moves forward in the text direction and 'C-b' moves
> backward in the text direction. 

And the rest of my post makes clear that I understood that.

> Sometimes the two sets of keys match up one way, and 
> sometimes the other way. Eminently meaningful indeed!
> Whether you want to call this "coupled" or "decoupled"
> is a matter of terminology.

I did not refer to either "coupled" or "decoupled".
I don't care what one calls it.
 
> > 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?
> 
> Only an R2L user can answer that (which I am not).

Well, that's the question.  Why flip the notions of "forward" and "backward" but
not bob and eob?  Why flip `C-f' but not `right' (or vice versa)?

Why should a change in text-insertion direction cause lots of directional
keys/commands to flip (but not all, apparently)?

> However, consistency matters.

Consistency matters.  But which consistency?

> If "forward" doesn't really mean forward in the text,

What about forward in the _buffer_?

Should `forward-char' reflect the R2L/L2R quality of the surrounding chars, or
should it just reflect the buffer directionality (bob -> eob)?

What about beginning of buffer? Should it sometimes become end of buffer? Should
that happen only if the entire buffer is R2L?

Anyone smell a can of worms around here?

> I think you will end up with nonsense in the end, such as "beginning of 
> sentence" moving to the end of sentence.

A sentence, like a defun, has a well-defined start and end. Any display or
editing mode should easily DTRT wrt such things. You could even have a mode
where a sentence is represented as a tree. End-of-sentence would still be
unambiguous, wherever and however it was displayed.

My question is about the "forward" direction. Should it be the traditional,
buffer-oriented direction or should it change depending on the current paragraph
(surrounding text) etc.?

Naively, it seems simpler to have movement from bob toward eob be "forward",
with (1+ (point-min)) being farther "forward" than (point-min), ... and
(point-max) being the farthest "forward".

Of course, anyone and any mode is free to define a custom "forward" direction or
movement.  thingatpt.el offers one way to do that for different kinds of things,
for example. So I'm not arguing that one should not be able to have different
"forward" behaviors or notions.

But for the ordinary cursor movements, I still raise the naive question: Why not
just let "forward" be toward eob?

> That is why I came up with a bunch of questions the other 
> day, which seem all interlinked.