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 12:19:05 -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> <83k4q4jdce.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 1276370487 27120 80.91.229.12 (12 Jun 2010 19:21:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 19:21:27 +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 21:21:24 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 1ONWGh-0002GT-Cu for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 21:21:23 +0200 Original-Received: from localhost ([127.0.0.1]:40315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONWGD-00058G-QO for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 15:20:53 -0400 Original-Received: from [140.186.70.92] (port=53640 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONWG7-000589-CH for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:20:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONWG6-0003BX-6b for emacs-devel@gnu.org; Sat, 12 Jun 2010 15:20:47 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:59744) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONWG5-0003BP-W8; Sat, 12 Jun 2010 15:20:46 -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 o5CJKhvS006303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jun 2010 19:20:44 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 o5CIYtn7029531; Sat, 12 Jun 2010 19:20:42 GMT Original-Received: from abhmt015.oracle.com by acsmt355.oracle.com with ESMTP id 341432601276370341; Sat, 12 Jun 2010 12:19:01 -0700 Original-Received: from dradamslap1 (/141.144.64.21) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jun 2010 12:19:00 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83k4q4jdce.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsKYB7Lb4dbWhOITo2LUSBQQDqECQAAMnzA X-Auth-Type: Internal IP X-Source-IP: rcsinet15.oracle.com [148.87.113.117] X-CT-RefId: str=0001.0A090206.4C13DE0C.021B: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:125838 Archived-At: > > But I think you should also make it clear (clearer) that > > this "logical" order corresponds to buffer position > > I did: > Emacs stores right-to-left and bidirectional text in > the so-called "logical" (or "reading") order: the buffer > or string position of the first character you read precedes > that of the next character. Good. My point was to make clear also the behavior of movement (e.g. typical `forward-*' commands), not just the order of storage. Forward movement follows the storage order (typically). That's worth saying. > > In fact, you might drop "logical" altogether - the word > > itself doesn't really help here. > > This term is widely used in literature about editing bidirectional > text. I see. Then keep it, for readers familiar with that literature. For those who might not be familiar, "reading" order is perhaps the most helpful. And it helps to point out that this is the same as the buffer (storage) order that you mentioned. > > And changing "character position" to "buffer position" would help. > > See above: the text does talk about buffer positions. That text is not a problem. I was referring to a passage where you spoke of "character position" or character order. That's less clear: character position wrt what? Answer: position in the buffer; position in reading order. > > 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. > > The manual does touch on that: > > Because characters are reordered for display, Emacs > commands that operate in the logical order or on stretches > of buffer positions may produce unusual effects. For > example, `C-f' and `C-b' commands move point in the logical > order, so the cursor will sometimes jump when point > traverses reordered bidirectional text. Similarly, > a highlighted region covering a contiguous range of > character positions may look discontinuous if the region > spans reordered text. This is normal and > similar to behavior of other programs that support > bidirectional text. Yes, I read that. It's fine as far as it goes, but it stresses clearing up some particular behavior (gotcha) that users might find confusing. It mentions `C-f' as a particular _example_, to illustrate the point. But I'm not sure the general point is communicated as such - it might be lost in the detailed description of the gotcha. This is not only about some particular commands that might happen to move point in the logical order. The important point that I think isn't brought out enough is that one's existing notion of "forward" movement, and the typical `forward-*' commands that one is used to, all act the same as does that `C-f' example. They act the same as they always have: forward typically means (continues to mean) _toward eob_, even in a bidi setting. That's not obvious. > > 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). > > I see no "buffer is reordered" in the manual. Hm. That was a direct quote, from GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-06-07 on 3249CTO. Emacs manual, node Bidirectional Editing: "The buffer-local variable `bidi-display-reordering' controls whether text in the buffer is reordered for display." Yes, I admitted I was splitting hairs. Do as you like with the feedback. You are welcome to ignore it. > I see these instead: ... > The buffer-local variable `bidi-display-reordering' > controls whether text in the buffer is reordered for display. So you do `see "buffer is reordered" in the manual', after all. ;-) > > 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. > > I will rename the section, thanks. Thanks for your patience.