From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: `C-b' is backward-char, `left' is left-char - why? Date: Thu, 02 Jun 2011 17:23:01 +0100 Message-ID: References: <6F4054004B154CFB8E2753172D316C13@us.oracle.com> <4DE4F8D0.7010800@lanl.gov> <82y61l16bg.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1307033711 7846 80.91.229.12 (2 Jun 2011 16:55:11 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Jun 2011 16:55:11 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 02 18:55:06 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QSBAn-0004FX-Oe for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 18:55:06 +0200 Original-Received: from localhost ([::1]:46777 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBAm-0005aL-Px for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 12:55:04 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:36651) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSAg5-0005nR-KR for emacs-devel@gnu.org; Thu, 02 Jun 2011 12:23:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSAg2-0000Qe-34 for emacs-devel@gnu.org; Thu, 02 Jun 2011 12:23:20 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:43050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSAg0-0000Pj-Ev for emacs-devel@gnu.org; Thu, 02 Jun 2011 12:23:17 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QSAfy-0004bC-T9 for emacs-devel@gnu.org; Thu, 02 Jun 2011 18:23:14 +0200 Original-Received: from 193.34.186.16 ([193.34.186.16]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Jun 2011 18:23:14 +0200 Original-Received: from andrewjmoreton by 193.34.186.16 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Jun 2011 18:23:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 75 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 193.34.186.16 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (windows-nt) Cancel-Lock: sha1:MF9yR7ptO+2ngXzdC+9IZZWPoEE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:140075 Archived-At: On Thu 02 Jun 2011, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Thu, 02 Jun 2011 13:59:48 +0100 >> >> > Maybe the following variant of the 2nd sentence sounds better: >> > >> > The effect on the screen is to place the cursor on the character N >> > buffer positions forward, which could be to the left or to the >> > right, depending on the bidirectional context. >> > >> > That's because Emacs doesn't really move point one character at a >> > time (when N is more than 1). >> >> I think that is definitely clearer than what we have now. > > Thanks, I will make this change. > >> (right-char &optional N) >> >> Move point N characters to the right (to the left if N is negative). On >> reaching beginning or end of buffer, stop and signal error. >> >> The effect on the buffer is to place the cursor on the character N >> screen positions to the right, which could be forward or backward from >> the current position, depending on the bidirectional context. > > Here, as they say, the plot thickens: unlike C-f/C-b that _always_ > move forward resp backward in the buffer, and don't > always move to the right resp to the left. E.g., if you press > in a paragraph whose bidi-paragraph-direction is left-to-right, then > the cursor will actually move to the _left_ when you get to some R2L > text embedded within this paragraph. You can see an example of this > in etc/HELLO, in the lines that show Arabic and Hebrew welcome > phrases. > > So if you invoke (right-char 10) when point is on characters from some > R2L script, the cursor could move to the left! I find this to be baffling, but then I'm not the target audience for R2L languages. Is this motion what users expect to happen for bidi text ? So C-f/C-b move N characters in the buffer, then work out where that lives on the screen (which may be to the right or left of the start position. So far, so good. > IOW, the names of and only express the _global_, > "grosso modo" direction of motion. That generally DTRT (according to > user expectations) assuming that left-to-right paragraphs contain > mostly L2R text and only occasionally short sequences of R2L text; and > vice versa in right-to-left paragraphs. But if a left-to-right > paragraph is made solely out of R2L text (a very rare and unusual > phenomenon), will almost always move to the _left_, and > to the right! So in this case, even the large-scale movement is in > the "wrong" direction. Now my head hurts :-) > But while we could (for the doc string purposes) quite safely > disregard the use case of paragraph having the "wrong" direction and > disrupting the global movement direction as described above, the doc > string you suggest is wrong even locally, when short sequences of R2L > text are embedded in an otherwise left-to-right paragraph, or vice > versa. This cannot be disregarded, so we must find a better way of > describing the effect of the arrow keys in mixed bidirectional text. > Ideas are welcome. OK, I completely misunderstood the semantics here, but your explanation has again beeen enlightening. So is it that right-char means advance forward in screen display order (which may move to the right or the left) and then work out which buffer position it corresponds to ? AndyM