all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: help-gnu-emacs@gnu.org
Subject: Re: emacs 24's forward-char vs right-char behavior
Date: Wed, 25 Apr 2012 09:07:04 +0300	[thread overview]
Message-ID: <83ipgofipj.fsf@gnu.org> (raw)
In-Reply-To: <379c8837-79c2-4692-8103-0bfa473f221e@wp13g2000pbb.googlegroups.com>

> From: Xah Lee <xahlee@gmail.com>
> 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.




  parent reply	other threads:[~2012-04-25  6:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-24 22:19 emacs 24's forward-char vs right-char behavior Xah Lee
2012-04-24 23:07 ` Joost Kremers
2012-04-25  6:07 ` Eli Zaretskii [this message]
     [not found] ` <mailman.610.1335334014.751.help-gnu-emacs@gnu.org>
2012-04-25  7:43   ` Xah Lee
2012-04-25  8:21     ` Eli Zaretskii
2012-04-25  8:32     ` Joost Kremers
2012-04-25  8:50       ` Eli Zaretskii
     [not found]       ` <mailman.614.1335343852.751.help-gnu-emacs@gnu.org>
2012-04-25 12:48         ` Joost Kremers
2012-04-26 11:17           ` Eli Zaretskii
     [not found]           ` <mailman.81.1335439086.855.help-gnu-emacs@gnu.org>
2012-04-26 18:19             ` Joost Kremers
2012-04-26 20:15               ` Eli Zaretskii
2012-04-27  1:58         ` Jason Rumney
     [not found]     ` <mailman.613.1335342081.751.help-gnu-emacs@gnu.org>
2012-04-26 14:24       ` Xah Lee
2012-04-26 15:00         ` Eli Zaretskii
2012-04-25  8:16   ` Joost Kremers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ipgofipj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.