From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: arrow keys vs. C-f/b/n/p Date: Sat, 12 Jun 2010 10:12:04 -0700 Message-ID: References: <87d3w2ncqs.fsf_-_@lola.goethe.zz> <87iq5py7xk.fsf@stupidchicken.com> <83eigclgf0.fsf@gnu.org> <89C16A134A024399A06EFE296DC6916F@us.oracle.com> <83r5kcjkpp.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1276362848 5344 80.91.229.12 (12 Jun 2010 17:14:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 17:14:08 +0000 (UTC) Cc: emacs-devel@gnu.org To: "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 12 19:14:06 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 1ONUHV-0004uN-VH for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 19:14:06 +0200 Original-Received: from localhost ([127.0.0.1]:53354 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONUHV-0003GQ-1R for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 13:14:05 -0400 Original-Received: from [140.186.70.92] (port=57099 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONUHL-0003Es-V6 for emacs-devel@gnu.org; Sat, 12 Jun 2010 13:13:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONUHK-0002Un-Pa for emacs-devel@gnu.org; Sat, 12 Jun 2010 13:13:55 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:36937) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONUHK-0002UT-JX; Sat, 12 Jun 2010 13:13:54 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5CHDpj4026492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jun 2010 17:13:52 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5C7N1pA029883; Sat, 12 Jun 2010 17:13:50 GMT Original-Received: from abhmt019.oracle.com by acsmt353.oracle.com with ESMTP id 319988201276362719; Sat, 12 Jun 2010 10:11:59 -0700 Original-Received: from dradamslap1 (/141.144.64.21) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jun 2010 10:11:59 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83r5kcjkpp.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsKSea5QqK4YG7lQ9Gx9L7lbbY5PgAAkHQA X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090207.4C13C051.0025:SCFMA4539811,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:125827 Archived-At: > > I think you still have not given a good reason for swapping > > the arrow keys in an R2L para. > > The reason for that is the important special case where the paragraph > is made of R2L text only. In such a paragraph, moving to the left > means moving forward in the buffer. That is why the left arrow does > the same as C-f in a R2L paragraph. I understand. I think that is open for debate, but you'll get no debate on it from me. I'll just say that it's not clear that this arrow reversal and its consequent difference from C-f/C-b is a great idea, especially since it happens only if the entire para is R2L. Sounds like these behavior differences (almost modal) could be confusing. Probably bidi user experience will answer the question of whether it is a good choice. > > Just explain what you explained in your first mail today: > > logical order (whether C-f/C-b or arrows), paragraphs that > > are only R2L or only L2R, etc. You said it very clearly and > > fairly succinctly. I think it probably cleared things up for > > several of us. > > I explained some of that already, in the node "Bidirectional Editing" > in the Emacs user manual. The bidi-aware behavior of the arrow keys > is described in the node "Moving Point". Please see if that's enough. Hm. Well, you try to keep things at a user, as opposed to an implementation/design, level, which is correct for the Emacs manual. From that point of view, saying `"logical" (or "reading") order' is OK. But I think you should also make it clear (clearer) that this "logical" order corresponds to buffer position, even if that might seem more programmer-oriented. Emacs users sooner or later have an understanding of buffer positions, so you might as well anchor the notion of "logical" order as being buffer order. In fact, you might drop "logical" altogether - the word itself doesn't really help here. If you speak about the order of the chars in the buffer (as opposed to how they appear) I think that will be clear. And changing "character position" to "buffer position" would help. The former is ambiguous, or at least it could be read in different ways. It is char position in the buffer that is important. I would suggest emphasizing buffer order/position. (In any case, you do touch on implementation/design anyway, when you speak about display position.) What I got from your mail yesterday, which I think is clear there, is that (a) the buffer text stays put, regardless of how it might be displayed (I already supposed that), and (b) cursor movement always follows buffer order: forward means toward eob; backward means toward bob. It is (b) that is not so clear from the doc. That notion of "logical" movement (movement along the buffer-position gradient) is important to understand. It's one thing to indicate that display order can differ from buffer order. It's another thing to make clear that cursor motion always follows buffer order (until you introduce visual movement to the mix). `forward-foobar' pretty much always implies movement toward eob. This is important to understand, for both interactive use and programming. And I don't think it comes across in the current doc. Admittedly, it can be tricky to talk about these things. But I found your mail yesterday to be clearer than the current doc. In the doc you say things like "the buffer is reordered for display", which is correct but which could also be misunderstood. The chars are not reordered in the buffer - the buffer itself is not reordered. It is just that the displayed order differs from the buffer order (which does not change). Yes, I'm splitting hairs, but it can help to try reading it in as confusing a manner as possible, to see what difficulties others might have. ;-) HTH. BTW, maybe the node should be called Bidirectional Text (or Editing Bidirectional Text) instead of Bidirectional Editing. We've all been doing bidirectional (multidirectional) editing forever.