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 07:26:53 -0700 Message-ID: <89C16A134A024399A06EFE296DC6916F@us.oracle.com> References: <87d3w2ncqs.fsf_-_@lola.goethe.zz> <87iq5py7xk.fsf@stupidchicken.com> <83eigclgf0.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 1276356406 18728 80.91.229.12 (12 Jun 2010 15:26:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 15:26:46 +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 17:26:45 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 1ONSbb-0004vm-Bs for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 17:26:43 +0200 Original-Received: from localhost ([127.0.0.1]:60275 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONSXb-000894-6L for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 11:22:35 -0400 Original-Received: from [140.186.70.92] (port=42554 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONS78-0000Lb-3a for emacs-devel@gnu.org; Sat, 12 Jun 2010 10:55:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONRgD-0003PM-BK for emacs-devel@gnu.org; Sat, 12 Jun 2010 10:27:26 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:30502) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONRgD-0003PD-50; Sat, 12 Jun 2010 10:27:25 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5CERMfj013682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Jun 2010 14:27:24 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5CERL2k019274; Sat, 12 Jun 2010 14:27:21 GMT Original-Received: from abhmt005.oracle.com by acsmt355.oracle.com with ESMTP id 319838051276352809; Sat, 12 Jun 2010 07:26:49 -0700 Original-Received: from dradamslap1 (/141.144.64.21) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 12 Jun 2010 07:26:49 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83eigclgf0.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsKFg32BqUnnCdVQTqvmzsfAFHFewAIAFTw X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090201.4C13994C.00D2:SCFMA922111,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:125817 Archived-At: > > On the surface this seems wrong and overly complicated (to > > me). "Eminently meaningful" it no doubt is, but it seems > > somehow bass ackwards. ;-) > > Do you still think that, after reading my explanations? No, your explanations clarify things. I think you still have not given a good reason for swapping the arrow keys in an R2L para. But I have no problem with the behavior you describe, personally. > It does seem wrong. Which is why Emacs doesn't do that. Do you > agree, after reading my explanations? Yes, see above. > > Why would it be wrong for `right' (right arrow) to always > > represent movement toward the right, regardless of R2L/L2R? > > It is not wrong, which is why Emacs behaves precisely like that. > > The only exception is when R2L text is embedded in a L2R paragraph > (i.e. in otherwise mostly L2R text). Since arrow keys still move in > logical order, the direction is reversed while we are traversing R2L > text; it returns to its usual sense when point is back inside L2R > text. And that's true also for C-f/C-b, IIUC. And it sounds good to me. > Having the right arrow always go right (i.e. in the visual order) > means that users will be unable to press the Shift key and have the > text they traverse be marked correctly. That is why we have only the > logical-order movement for now -- because it is indispensable. While > I don't object to have a visual-order movement mode, I think it is > much less useful, and it must be a separate mode in any case. Sounds good. > In general, I believe the visual-mode movement is useful only to > people who don't really read the bidirectional text they traverse with > the cursor-motion keys. Any person who actually reads and understand > the text will need the logical-order motion first and foremost, and > the fact that direction is sometimes switched for a short period of > time is expected and understood by users of bidirectional scripts. It > is a necessary complication, and one that is not hard to become used > to -- because the cursor moves in the reading order, the same order > our eyes move when we scan text. > > At stake here is a very fundamental issue: the reading order is still > from character position 1 to position 2 to 3 and so forth. The order > on the screen does not change this fundamental fact. If you break > this fundamental relation between the buffer order and the reading > order, users will throw Emacs out the window. I think I was trying to say the same thing (but with less understanding). The meaning of "forward" in most command names should stay as it is, which is the logical (buffer) order. You've confirmed that that will be the case. > > Just which things really need to be flipped/mirrored? > > We need to break the one-to-one relation between buffer's logical > order and the left/right direction. This is what bidirectional text > support is all about: "leftmost" no longer means "the first", because > screen direction and screen sides no longer correspond to buffer > order, in general. That's fine. > > Why not leave everything as it is wrt "forward" movement, > > and let users understand that "forward" always means toward > > the right (in both L2R and R2L)? I expressed myself wrong here. What I meant to say was "toward buffer end", as I stated more clearly in other places. That was my concern: "forward" commands should move in the direction of point-min toward point-max: buffer order. And you've confirmed that that is the case. (For both C-f/C-b and arrows - the only question being which arrow moves which way.) > > Maybe you'll say that at least `C-d' and `backspace' need > > to flip direction (forward/backward) > > They don't, and shouldn't, IMO. C-d always deletes the character at > point, and Backspace always deletes the character before point. The > basic Emacs notions of "before point" and "after point" are not > changed by the bidi support, because doing that would mean that > everything in Emacs would stop working. Again, very good to hear. In general, what you've done fits what I would expect naively. > In general, the basic design of the bidi support changes only the > display features. It changes nothing in how buffer text is processed > and accessed. This is done on purpose: I strongly believe that > bidirectional text is a display-only feature. It must not change > anything else. Music to my ignorant ears. Just what I wanted to hear. > There's no "left" and "right" in the buffer. Insertion doesn't move > point to the left, it moves point farther from the beginning of the > buffer, i.e. it increases its buffer position. Sehr gut. > Whether this is right or left on the screen depends on the > surrounding bidirectional context. > > > If nothing else, perhaps the naive questions expressed here > > will help you document the bidi stuff for other naive users - HTH. > > Naive users who read bidirectional scripts do not need this to be > explained: they expect this behavior by default. Maybe. Still, your explanation helped this naive user who does _not_ read bidi to understand the feature. Something similar in the Elisp manual (a concise statement from your first mail today) would help Emacs users generally, whether or not they actually use bidi. > > Perhaps something analogous to node `(elisp) Not Intervals' would be > > helpful for this, explaining the logic behind the design choices. > > We don't explain design choices in the manuals. There're plenty of > comments in the code to explain these decisions; if you or someone > else can point out where more commentary is in order, I'd be more than > happy to add whatever is missing, being a documentation maniac. 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.