From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: `C-b' is backward-char, `left' is left-char - why? Date: Thu, 02 Jun 2011 20:43:13 +0300 Message-ID: <83boygf7ta.fsf@gnu.org> References: <6F4054004B154CFB8E2753172D316C13@us.oracle.com> <4DE4F8D0.7010800@lanl.gov> <82y61l16bg.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1307036796 28015 80.91.229.12 (2 Jun 2011 17:46:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Jun 2011 17:46:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 02 19:46:31 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 1QSByX-0006uc-Gu for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 19:46:29 +0200 Original-Received: from localhost ([::1]:47101 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSByW-0001bM-Ju for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 13:46:28 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:56649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBvH-0000yB-08 for emacs-devel@gnu.org; Thu, 02 Jun 2011 13:43:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QSBvF-0005af-EC for emacs-devel@gnu.org; Thu, 02 Jun 2011 13:43:06 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:58744) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QSBvE-0005aK-Uz for emacs-devel@gnu.org; Thu, 02 Jun 2011 13:43:05 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LM600L00BU3J600@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 02 Jun 2011 20:43:02 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.223.140]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LM600LJIBVP5G40@a-mtaout22.012.net.il>; Thu, 02 Jun 2011 20:43:02 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:140083 Archived-At: > From: Andy Moreton > Date: Thu, 02 Jun 2011 17:23:01 +0100 > > > 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 ? Yes, definitely. Those expectations are the primary reason why I wrote right-char and left-char (and also right-word and left-word), and why I bound the arrow keys to them. > 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. Correct. Btw, this has always been like that, even in the Emacs 23 unidirectional display. Emacs never assumed that moving N characters forward means the cursor should move N characters to the right on the screen. It always computed where to draw the cursor, it's just that the unidirectional code which computed that assumed that character positions increase linearly with screen positions. > > 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 :-) Well, maybe if you look at the body of right-char, you will see the light: (if (eq (current-bidi-paragraph-direction) 'left-to-right) (forward-char n) (backward-char n))) That's all there is to it: it does either forward-char or backward-char, depending on the base direction of the current paragraph. And we've already established that forward-char and backward-char can move to the left or to the right according to the text across which they move. The paragraph direction determines how the paragraph is displayed: in a left-to-right paragraph, lines begin at the left margin of the window, while in the right-to-left paragraph they begin at the right margin. > 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 ? No, see the body of right-char above. IOW, both forward-char and right-char move in the buffer order, it's just that they sometimes move in the same direction of buffer positions and sometimes in the opposite ones. (It is actually impossible to do what you say, because right-char must be able to work even when the display is not up to date, e.g. if one leans on the key and has a fast auto-repeat rate, or if some complex Lisp program calls it. By contrast, "screen display" is not defined unless Emacs succeeded to catch up with user keystrokes, and brought the display in sync with the buffer.)