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: arrow keys vs. C-f/b/n/p Date: Sat, 12 Jun 2010 12:09:46 +0300 Message-ID: <83ljakliqt.fsf@gnu.org> References: <87d3w2ncqs.fsf_-_@lola.goethe.zz> <87iq5py7xk.fsf@stupidchicken.com> <871vcc4xhf.fsf@catnip.gol.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1276333801 18224 80.91.229.12 (12 Jun 2010 09:10:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 09:10:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 12 11:09:59 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ONMj1-00084A-5s for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 11:09:59 +0200 Original-Received: from localhost ([127.0.0.1]:43800 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONMj0-0007iw-He for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 05:09:58 -0400 Original-Received: from [140.186.70.92] (port=36021 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONMit-0007ir-5x for emacs-devel@gnu.org; Sat, 12 Jun 2010 05:09:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONMir-0006cN-It for emacs-devel@gnu.org; Sat, 12 Jun 2010 05:09:50 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:46703) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONMir-0006cB-5u for emacs-devel@gnu.org; Sat, 12 Jun 2010 05:09:49 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L3W00N0098C0R00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 12 Jun 2010 12:09:47 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.119.36]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L3W00ITL9GA4BC0@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 12 Jun 2010 12:09:47 +0300 (IDT) In-reply-to: <871vcc4xhf.fsf@catnip.gol.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125787 Archived-At: > From: Miles Bader > Date: Sat, 12 Jun 2010 14:43:24 +0900 > Cc: Chong Yidong , David Kastrup , > Eli Zaretskii , emacs-devel@gnu.org > > James Cloos writes: > > Oh, and my personal preference, as a l2r reader who occasionally deals > > with r2l text, is for both C-f/C-b and LEFT/RIGHT to *always* move in > > logical order. The feedback that provides is useful and welcome. > > I agree. This thread is riddled with confusion and misunderstanding, not the least part of which is because many participants do not read any R2L scripts. I will respond to individual messages, but first let me set the stage by defining the terminology and the use-cases. I'm sorry, but this message will necessarily be a longish one. Nevertheless, please read it in its entirety before responding to any further messages. The current Emacs supports two text directions and two paragraph directions. Both can be either left-to-right (L2R) or right-to-left (R2L). Paragraph direction determines whether the text starts at the left window margin or at the right margin. Text direction determines the direction in which text is read. A L2R paragraph can include both L2R text and R2L text. Likewise, a R2L paragraph can include both L2R text and R2L text. In general, a R2L paragraph is supposed to have most of its text R2L, and a L2R paragraph is supposed to have most of its text L2R, but that's not a restriction, and Emacs does not impose that in any way. It's just that a L2R paragraph that has most or all of its text R2L will look awkward; try setting bidi-paragraph-direction to right-to-left in the "*scratch*" buffer, and you'll see what I mean. Here are 2 use-cases I will use throughout the rest of the discussion, and I suggest that everyone else does as well, to avoid confusion. As usual, upper-case letters represent characters from R2L scripts (such as Arabic or Hebrew), while lower-case letters represent characters from L2R scripts, such as the various Latin scripts. Here's how a L2R paragraph which includes mixed L2R and R2L text will be shown on the screen: abcde EDCBA xyz This display corresponds to the following buffer text: abcde ABCDE xyz Here's a R2L paragraph that includes mixed R2L and L2R text. Note that such a paragraph is displayed flushed all the way to the right margin of the window: ZYX abcde EDCBA This display corresponds to the following buffer text: ABCDE abcde XYZ The buffer order of characters is known as the "logical" or "reading" order. The order of characters on the screen is known as the "visual" order. Note that the visual order always goes from left to right, at least in Emacs (and hence in this thread). That is, in the R2L paragraph example above, the first character in the visual order is Z, the second is Y, etc. This thread is about movement keys. In Emacs, these keys always move in the _logical_ order, i.e. in the order of the character positions in the buffer. While visual-mode movement might make sense in some use-cases, it is not yet implemented. Personally, I think it is much less important (see my other messages for why I think so), which is the main reason why they are not yet implemented in Emacs. But I hope everyone will agree that having logical-order motion keys is an absolute must. So let's stop talking about visual-order movement vs logical-order movement, from this point on, in this thread. The _only_ movement mode we have in Emacs is the logical-order one. Both C-f/C-b and the arrow keys move strictly in logical order. C-f always moves forward in the logical order. Thus, in the first example above, it will move like this: a->b->c->d->e->A->B->C->D->E->x->y->z Note that this means the cursor will jump on the screen between e and A and then jump again from E to x. In the second example, of the R2L paragraph, C-f will move cursor like this: Z<-Y<-X<-e<-d<-c<-b<-a<-E<-D<-C<-B<-A Note that again, it will jump from E to a and from e to X. Now please note an important detail: in a L2R paragraph, C-f generally moves cursor _to_the_right_, even though it could sometimes change direction and move to the left, when we are traversing R2L text embedded into a L2R paragraph. Similarly, in a R2L paragraph, C-f generally moves cursor _to_the_left_. In the important special case, when L2R paragraphs include only L2R text and R2L paragraphs include only R2L text, cursor motion with C-f is strictly to the right resp. to the left. This is the reason why the arrow key moves like C-f in a L2R paragraph, and why the arrow key moves like C-f in a R2L paragraph. (And similarly with C-b.) It is so that Emacs behaves as expected in a purely R2L paragraph containing only R2L text. Any other operation would be confusingly counter-intuitive: the key would actually move cursor _to_the_left_! Again, we are talking _only_ about _logical-order_movement_! I hope the issue is more clear now. I will now go and respond to some of the comments posted in this thread.