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

[Uday S Reddy]

Drew Adams writes:

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

Sorry I misunderstood.  Actually, I find most of this discussion hard
to understand (as also the line-move-visual discussion earlier).  It
is best to be as clear as possible.

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

The consistency I am asking for is that "forward" should mean the same
thing all the time and "end" should mean the same thing all the time.
I also think "forward" and "end" should be correlated because nobody
wants to go forward to the beginning!

On the other hand, there is no need for "forward" and "right" to be
correlated.  They are independent concepts.

---

James Cloos wrote an informative message later, at 5:12pm, where he
pointed out that an L2R user that is occasionally using R2L text may
have a very different preference from some one that regularly deals
with R2L text.  So, flexibility is called for.  If we go with a
preconceived idea that C-f should always mean the same as <right>,
then we are likely to go wrong.

I might have said this earlier, but key bindings are not a big deal.
The users can always bind the keys to their liking.  But the
*functionality* should be there for them to bind the keys to.  If
there is only one function called forward-char then C-f and <right>
will get coupled, and the flexibility won't be there for the users.

If there is a forward-char and a right-char, then James Cloos can bind
both C-f and <right> to forward-char.  He gets the logical motion that
he prefers.  Some other user might want <right> to mean right.  He
might bind <right> to right-char.

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

Ok, that is nice.  But then, will `forward-sentence' move forward over
a sentence, while `forward-char' will move back?

That might in fact be what some users want.  Somebody might have his
neurons already wired to correlate C-f with right and C-b with left.
But we can't say that every user should follow that choice?

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

My belief is that many users will want "forward" to be determined by
the kind of text they are editing.  

bob and eob are harder issues.  So, I don't think we should let them
guide everything else.  Rather, they should be postponed to the end,
after everything else is decided.

In fact, it is not clear to me that when a user does bob or eob, they
necessarily want to go to the very beginning or very end of the text.
Somewhere close by is good enough.  So, if bob and eob don't work
perfectly, it doesn't matter all that much.

Cheers,
Uday