emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Drew Adams
Subject: RE: arrow keys vs. C-f/b/n/p
Date: Fri, 11 Jun 2010 15:46:18 -0700

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

Forward and end wrt what?

What I'm suggesting is that we might want to keep the "what" to be the buffer,
in general. And forward in the buffer means farther from the beginning
(point-min) and closer to the end (point-max).

That's really the question. What are "forward" and "end" relative to, and for
which commands? Is a command such as `forward-char' about moving forward in the
buffer or about moving forward within the immediately surrounding text (which
might be R2L)?

> I also think "forward" and "end" should be correlated because nobody
> wants to go forward to the beginning!

Same question. If the current sentence is R2L then moving forward in the buffer,
i.e. toward the end (of the buffer), also means moving backward in the sentence,
i.e. toward the beginning (of the sentence).

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

Well, that's why I rephrased "right" as forward-in-the-buffer, to make clearer
what is the real question (that I raised).

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

And if we go with a preconceived idea that C-f should change directions
depending on the text surrounding the cursor (R2L vs L2R), then we are also
likely to go wrong.  Consistency, OK, but which?

Assuming we don't change anything that affects someone who never uses R2L, I
won't complain for myself, as it won't really affect me.

But I raised the question because I get the impression we might be marching off
into the swamp.  And also because I would like the doc to explain these things
clearly, in the end.

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

Certainly we will need various commands and offer flexibility.

I think this is about (a) the default bindings and (b) the behavior in general
of `forward-'* commands. 

IIUC, the "coupling" question is part of (a): Should the default bindings be
different for `right' (`<right>') and `C-f'? Should one of them DTRT for R2L but
the other not?

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

It might, if the sentence text is written "backwards" wrt the buffer direction.

Again, that's the question. Does `forward-char' respect the directionality of
the buffer or the directionality of the text surrounding point?

BTW, what do we do when point is at a boundary (R2L/L2R or L2R/R2L)?  Which way
is forward?  Should that depend on the previous cursor movement (where we're
coming from)? Surely, that way lies madness. ;-)

I imagine that these questions are not new for R2L folks. Hasn't some sort of
standard behavior been worked out for buffers/documents that combine R2L and L2R
text? If so, how does that conventional behavior fit with Emacs?

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

We can't say anything about every user.
We do have to decide something about the default behavior, however.

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

You're speaking only about key bindings, I think. I'm asking also about commands
and command names.  Should most `forward-'* commands reverse direction when the
text around point is R2L?

Will `forward-char' be DWIMed to fit R2L (as opposed to some other command being
defined for that)?  How would that affect Lisp code and keyboard macros?

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

I don't imagine that anyone is suggesting to change `beginning-of-buffer' so it
goes to eob.  My question is about the behavior and notion of "forward" in
general.

At any rate, I've admitted that I know _nothing_ about R2L, and you've said that
you too are not an R2L user. So what we two have to say about this is perhaps
not so important, and I'll stop here. Eventually someone who knows better will
chime in and set things straight. ;-)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]