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 11:38:12 +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 1307011137 23477 80.91.229.12 (2 Jun 2011 10:38:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Jun 2011 10:38:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 02 12:38:53 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 1QS5Ii-0004Uc-SJ for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 12:38:53 +0200 Original-Received: from localhost ([::1]:56703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS5Ih-0004EP-Sh for ged-emacs-devel@m.gmane.org; Thu, 02 Jun 2011 06:38:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:38815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS5IK-0004Df-Av for emacs-devel@gnu.org; Thu, 02 Jun 2011 06:38:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QS5IG-0002km-5V for emacs-devel@gnu.org; Thu, 02 Jun 2011 06:38:28 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QS5IF-0002kM-Ht for emacs-devel@gnu.org; Thu, 02 Jun 2011 06:38:23 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QS5IC-0004Gc-W1 for emacs-devel@gnu.org; Thu, 02 Jun 2011 12:38:21 +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 12:38:20 +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 12:38:20 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 90 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:TejoikgCgYEfrhLmyvozcacBcZA= 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:140055 Archived-At: On Thu 02 Jun 2011, Eli Zaretskii wrote: >> From: Andy Moreton >> Date: Thu, 02 Jun 2011 00:26:59 +0100 > >> - 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. Explaining motion in terms of buffer position (forward and backward), reading direction (l2r/r2l) and screen position (left and right) may help to disambiguate things as long as those terms are used consistently and explained broefly in the doc string. >> - 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). I realised that this was a simplification, but it may make the overall scheme clearer if the simple version is presented first and then the additional complications explained. > 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. While overly complex descriptions are not useful, the doc strings do need to convey whether the simple motion is relative to the buffer or the screen position for each command. >> (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_" Agreed. >> 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. I understand that there additional complications - I was trying to write something that would explain the simpler cases so that the behaviour in more complex cases could be inferred from the simpler ones. So for forward-char, movement of point is always N characters forward in the buffer. The effect on the screen position must be considered as a sequence of single character movements in the buffer, each of which may move the screen position left or right (depending on the bidirectional context). Is that more accurate ? Thnaks for the patient explanations, AndyM