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

["Drew Adams" <drew.adams@oracle.com>]

> > On the surface this seems wrong and overly complicated (to 
> > me). "Eminently meaningful" it no doubt is, but it seems
> > somehow bass ackwards. ;-)
> 
> Do you still think that, after reading my explanations?

No, your explanations clarify things.

I think you still have not given a good reason for swapping the arrow keys in an
R2L para. But I have no problem with the behavior you describe, personally.

> It does seem wrong.  Which is why Emacs doesn't do that.  Do you
> agree, after reading my explanations?

Yes, see above.

> > Why would it be wrong for `right' (right arrow) to always 
> > represent movement toward the right, regardless of R2L/L2R?
> 
> It is not wrong, which is why Emacs behaves precisely like that.
> 
> The only exception is when R2L text is embedded in a L2R paragraph
> (i.e. in otherwise mostly L2R text).  Since arrow keys still move in
> logical order, the direction is reversed while we are traversing R2L
> text; it returns to its usual sense when point is back inside L2R
> text.

And that's true also for C-f/C-b, IIUC.  And it sounds good to me.

> Having the right arrow always go right (i.e. in the visual order)
> means that users will be unable to press the Shift key and have the
> text they traverse be marked correctly.  That is why we have only the
> logical-order movement for now -- because it is indispensable.  While
> I don't object to have a visual-order movement mode, I think it is
> much less useful, and it must be a separate mode in any case.

Sounds good.

> In general, I believe the visual-mode movement is useful only to
> people who don't really read the bidirectional text they traverse with
> the cursor-motion keys.  Any person who actually reads and understand
> the text will need the logical-order motion first and foremost, and
> the fact that direction is sometimes switched for a short period of
> time is expected and understood by users of bidirectional scripts.  It
> is a necessary complication, and one that is not hard to become used
> to -- because the cursor moves in the reading order, the same order
> our eyes move when we scan text.
> 
> At stake here is a very fundamental issue: the reading order is still
> from character position 1 to position 2 to 3 and so forth.  The order
> on the screen does not change this fundamental fact.  If you break
> this fundamental relation between the buffer order and the reading
> order, users will throw Emacs out the window.

I think I was trying to say the same thing (but with less understanding).

The meaning of "forward" in most command names should stay as it is, which is
the logical (buffer) order.  You've confirmed that that will be the case.

> > Just which things really need to be flipped/mirrored?
> 
> We need to break the one-to-one relation between buffer's logical
> order and the left/right direction.  This is what bidirectional text
> support is all about: "leftmost" no longer means "the first", because
> screen direction and screen sides no longer correspond to buffer
> order, in general.

That's fine.

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

I expressed myself wrong here. What I meant to say was "toward buffer end", as I
stated more clearly in other places. That was my concern: "forward" commands
should move in the direction of point-min toward point-max: buffer order.

And you've confirmed that that is the case. (For both C-f/C-b and arrows - the
only question being which arrow moves which way.)

> > Maybe you'll say that at least `C-d' and `backspace' need 
> > to flip direction (forward/backward)
> 
> They don't, and shouldn't, IMO.  C-d always deletes the character at
> point, and Backspace always deletes the character before point.  The
> basic Emacs notions of "before point" and "after point" are not
> changed by the bidi support, because doing that would mean that
> everything in Emacs would stop working.

Again, very good to hear. In general, what you've done fits what I would expect
naively.

> In general, the basic design of the bidi support changes only the
> display features. It changes nothing in how buffer text is processed
> and accessed.  This is done on purpose: I strongly believe that
> bidirectional text is a display-only feature.  It must not change
> anything else.

Music to my ignorant ears.  Just what I wanted to hear.

> There's no "left" and "right" in the buffer.  Insertion doesn't move
> point to the left, it moves point farther from the beginning of the
> buffer, i.e. it increases its buffer position.

Sehr gut.

> Whether this is right or left on the screen depends on the
> surrounding bidirectional context.
> 
> > If nothing else, perhaps the naive questions expressed here 
> > will help you document the bidi stuff for other naive users - HTH.
> 
> Naive users who read bidirectional scripts do not need this to be
> explained: they expect this behavior by default.

Maybe. Still, your explanation helped this naive user who does _not_ read bidi
to understand the feature. Something similar in the Elisp manual (a concise
statement from your first mail today) would help Emacs users generally, whether
or not they actually use bidi.

> > Perhaps something analogous to node `(elisp) Not Intervals' would be
> > helpful for this, explaining the logic behind the design choices.
> 
> We don't explain design choices in the manuals.  There're plenty of
> comments in the code to explain these decisions; if you or someone
> else can point out where more commentary is in order, I'd be more than
> happy to add whatever is missing, being a documentation maniac.

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.