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 13:00:03 +0300 Message-ID: <83eigclgf0.fsf@gnu.org> References: <87d3w2ncqs.fsf_-_@lola.goethe.zz> <87iq5py7xk.fsf@stupidchicken.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1276336836 26515 80.91.229.12 (12 Jun 2010 10:00:36 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 12 Jun 2010 10:00:36 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 12 12:00:34 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 1ONNVv-0007AM-VY for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 12:00:32 +0200 Original-Received: from localhost ([127.0.0.1]:47202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONNVu-0001sZ-7A for ged-emacs-devel@m.gmane.org; Sat, 12 Jun 2010 06:00:30 -0400 Original-Received: from [140.186.70.92] (port=33450 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONNVf-0001pw-Qz for emacs-devel@gnu.org; Sat, 12 Jun 2010 06:00:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONNVe-00056C-9J for emacs-devel@gnu.org; Sat, 12 Jun 2010 06:00:15 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:56920) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONNVd-00055k-Qk for emacs-devel@gnu.org; Sat, 12 Jun 2010 06:00:14 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0L3W00100BOVPM00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sat, 12 Jun 2010 13:00:05 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.127.119.36]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0L3W00KFVBS29280@a-mtaout20.012.net.il>; Sat, 12 Jun 2010 13:00:04 +0300 (IDT) In-reply-to: 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:125793 Archived-At: > From: "Drew Adams" > Cc: "'Eli Zaretskii'" , "'David Kastrup'" , > > Date: Fri, 11 Jun 2010 10:12:45 -0700 > > 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? > It seems wrong for `right' to mean "left". It does seem wrong. Which is why Emacs doesn't do that. Do you agree, after reading my explanations? > 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. 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. 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. > I suppose that you want to make `C-f' move "forward", which is arguably toward > the left in R2L languages, and you want to keep the association of `C-f' with > `right' (right arrow). Why would I want C-f to be associated with if it actually moves to the left? Don't you think it's terribly confusing mentally? > But is it really important that "forward" in a command name move toward the left > in R2L? Why should "forward" necessarily mean "from text beginning toward text > end" rather than just "toward the right"? What is at stake here? 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. > You don't change the meaning of `bobp' to `eobp' for R2L, do you? You don't swap > the meanings of "left" and "right". Why exchange "forward" and "backward" but > not "left" and right"? We didn't change forward and backward. We did change the relation between left/right and forward/backward. That is, "right" is not always "forward" anymore. > 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. > 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)? > Wouldn't that be just as useful and a lot less confusing overall? No, it would be terribly confusing. "Forward" must mean what the word means, and "left" must also mean what the word says. Any other way means placing a terrible mental burden on the user -- and for what? for convenience of ELisp programmers? > 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. 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. > I can see that self-insertion should move point to the left of the inserted char > in R2L. This is a misunderstanding. 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. Whether this is right or left on the screen depends on the surrounding bidirectional context. I could even concoct an example where inserting a single character reorders many characters around the insertion locus and moves the cursor far away from its previous position. > Again, I know nothing about R2L. I'm sure it's a tough and tricky problem, and > I'm sure you have thought it all out carefully. It just seems wrong and > unnecessarily complicated for this ignoramus who has not thought it all out. Complicated, yes. But also necessary. Any other solution is simply wrong, from the user perspective. > 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. > 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.