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 00:37:20 -0400 Message-ID: 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 1306989465 11285 80.91.229.12 (2 Jun 2011 04:37:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Jun 2011 04:37:45 +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 06:37:39 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 1QRzf8-0002K4-JY for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 06:37:38 +0200 Original-Received: from localhost ([::1]:50475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRzf7-0001hI-HL for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 00:37:37 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRzes-0001h9-D4 for emacs-devel@gnu.org; Thu, 02 Jun 2011 00:37:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QRzeq-0002WB-Uz for emacs-devel@gnu.org; Thu, 02 Jun 2011 00:37:22 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]:48821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QRzeq-0002W5-Rm for emacs-devel@gnu.org; Thu, 02 Jun 2011 00:37:20 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1QRzeq-0007Gl-LO; Thu, 02 Jun 2011 00:37:20 -0400 In-reply-to: <82y61l16bg.fsf@gmail.com> (message from Andy Moreton on Thu, 02 Jun 2011 00:26:59 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 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:140049 Archived-At: > From: Andy Moreton > Date: Thu, 02 Jun 2011 00:26:59 +0100 > > Having not looked at these functions previously, I found the doc strings > to be essentially the same for both of them, which was confusing. I can understand the confusion, given the deceptively simple idea of "forward" and "back" in the unidirectional world. > Having looked at the manual, I think the description there of and > does a better job of explaining what happens in bidi enabled > text than the doc strings. Well, we could duplicate the description from the manual in the doc string, if deemed useful. > - forward-char moves forward one character in the buffer, which in > right-to-left text moves backward one position on the screen. Not "backward", but to the left. "Forward" and "backward" are not well-defined on the screen in bidirectional context. For someone who reads the bidirectional text, C-f always moves forward, i.e. in the reading direction, the direction in which we scan characters while reading the text. > - right-char moves forward one position on the screen, which in > right-to-left text moves backward one character in the buffer. This is misleading. "Forward one position on the screen" is not well- defined, so using it will confuse the reader. Using "to the right" instead is well-defined, but only _mostly_ correct, because there's no pure right-to-left or left-to-right text. Almost always there's some left-to-right text (e.g., digits) embedded in predominantly right-to-left text and vice versa. (That's why the thing is called "bidirectional".) When you use right-char to move over left-to-right characters embedded in otherwise right-to-left text, the cursor will move to the left. And that's even before we consider further complications such as directional overrides (the RLE, RLO, etc. control characters). It would be more precise to tell that right-char will advance in the buffer when used in a paragraph whose direction is left-to-right, but will move backward in the buffer when used in a paragraph with right-to-left direction. But I'm not sure such a description will do a better job, because explaining a simple idea such as cursor motion via a much more complex issue of bidi-paragraph-direction doesn't sound right. By analogy, if you ask about laws wrt to traffic lights, you will not be amused to first get a lecture about special relativity theory that could potentially make the red light look green due to Doppler effect. > (forward-char &optional N) > > Move point N characters forward (backward if N is negative). > On reaching end or beginning of buffer, stop and signal error. > > Movement on the screen depends on the bidirectional context. Moving > forward over left-to-right text moves to the right on the screen, but > moving forward over right-to-left text moves _backward_ on the screen. ^^^^^^^^^^^ Should be "_to_the_left_" > This is in contrast with right-char, which see. I'm okay with this if it helps to make the issue less vague, but you should realize that it is also inaccurate, because "left-to-right text" is not well-defined. There are "weak" and "neutral" characters whose directionality is defined by surrounding strong directional characters. There are directional override control characters that can override the intrinsic properties of the following characters. Etc., etc. -- all these can invalidate the simple description above.