help-gnu-emacs
[Top][All Lists]
Advanced

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

Re: emacs 24's forward-char vs right-char behavior


From: Eli Zaretskii
Subject: Re: emacs 24's forward-char vs right-char behavior
Date: Wed, 25 Apr 2012 09:07:04 +0300

> From: Xah Lee <address@hidden>
> Date: Tue, 24 Apr 2012 15:19:29 -0700 (PDT)
> 
> if it's not too late, i think the semantics of “forward-char” and
> “right-char” should be exchanged (from what it currently is in emacs
> 24).
> 
> “forward-char”'s direction should be context sensitive.

What exactly do you mean by "direction"?  There are 2 "directions"
involved here: the direction of the movement in the buffer (either
forward or backward), and the direction on the screen (either right or
left).  'forward-char' always moves forward in the buffer, but as
result could move either to the right or to the left on the screen,
because with bidirectional languages screen position is no longer
monotonically increasing with buffer position.

> “right-char” should always move to the right.

It mostly does.  It always does move to the right when the surrounding
text is either all made of left-to-right characters (which is what
happens in Latin languages, for example), and also when the
surrounding text is all made of right-to-left characters.  If the
surrounding text is mixed L2R and R2L, then 'right-char' switches its
screen direction, but still generally moves to the right,
i.e. movements to the left are normally short (e.g., when short
sequences of Latin text or numbers are embedded in a generally
right-to-left text).

IOW, Emacs 24 implements the so-called "logical" cursor motion.
Visual cursor motion, the one where 'right-char' would always move to
the right, no matter what the surrounding text, is not implemented.

> At first i thought emacs can't do that because lots elisp code depends
> on “forward-char”'s existing behavior.

That's one reason.  The more important one is that reordering of
bidirectional text in Emacs is a display-only feature.  It was
designed not to affect any buffer-related commands and movements.
Therefore, 'forward-char' must still move in the forward direction,
i.e. in the direction of increasing buffer or string positions.

> But on second thought, am thinking it's probably rare that elisp is
> used to process {Arabic, Persian (Iran), Hebrew} languages.

Emacs 24 includes full support for editing and displaying plain text
in these languages.  And there was no conflict related to
'forward-char' in adding that support that would require a kind of
compromise you are hinting at.

Btw, the cursor movement implemented in Emacs 24 is the same one you
will see in MS products, like Word or Notepad.  Emacs didn't invent
anything in this area, at least from the user POV.

> So, perhaps changing “forward-char”'s behavior isn't too bad?

The behavior of 'forward-char' didn't change at all.  It still moves
forward.




reply via email to

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