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: Fri, 11 Jun 2010 13:16:54 -0700 Message-ID: <6D176B89214E4EE2B2B376B182E5B80F@us.oracle.com> References: <87d3w2ncqs.fsf_-_@lola.goethe.zz><87iq5py7xk.fsf@stupidchicken.com> 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 1276287481 5396 80.91.229.12 (11 Jun 2010 20:18:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Jun 2010 20:18:01 +0000 (UTC) To: "'Uday S Reddy'" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 11 22:17: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 1ONAfv-0002Q0-6o for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 22:17:59 +0200 Original-Received: from localhost ([127.0.0.1]:60868 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONAfu-0002TO-3B for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 16:17:58 -0400 Original-Received: from [140.186.70.92] (port=51818 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONAfi-0002Qj-OK for emacs-devel@gnu.org; Fri, 11 Jun 2010 16:17:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONAfh-0000BZ-7N for emacs-devel@gnu.org; Fri, 11 Jun 2010 16:17:46 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:31601) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONAfg-0000BK-Uo for emacs-devel@gnu.org; Fri, 11 Jun 2010 16:17:45 -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 o5BKHaJR022537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jun 2010 20:17:37 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5BKHZVW020116; Fri, 11 Jun 2010 20:17:35 GMT Original-Received: from abhmt004.oracle.com by acsmt353.oracle.com with ESMTP id 340162121276287414; Fri, 11 Jun 2010 13:16:54 -0700 Original-Received: from dradamslap1 (/141.144.224.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Jun 2010 13:16:54 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsJnTOT6ThQfSmhSV2P52+l/vSIdQAAGl3Q X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090206.4C1299E2.0052: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:125763 Archived-At: > >> It's actually not really decoupled. > >> It just switches between "C-f = right and C-b = left" and > >> "C-f = left and C-b = right" based on the paragraph's direction. > >> Which seems eminently meaningful since the associating between > >> "forward" and "right" is just based on our usual convention of > >> writing L2R. > > > > On the surface this seems wrong and overly complicated (to > > me). "Eminently meaningful" it no doubt is, but it seems > > somehow bass ackwards. ;-) It seems wrong for `right' to > > mean "left". > > No, Stefan is not saying 'right' should mean "left"! When I used `...' quotes for `right', I was referring to the `right' key, aka aka "right arrow". The rest of my post also makes this clear, I think. > He is saying that 'right' moves right, 'left' moves left, > 'C-f' moves forward in the text direction and 'C-b' moves > backward in the text direction. And the rest of my post makes clear that I understood that. > Sometimes the two sets of keys match up one way, and > sometimes the other way. Eminently meaningful indeed! > Whether you want to call this "coupled" or "decoupled" > is a matter of terminology. I did not refer to either "coupled" or "decoupled". I don't care what one calls it. > > 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? > > Only an R2L user can answer that (which I am not). Well, that's the question. Why flip the notions of "forward" and "backward" but not bob and eob? Why flip `C-f' but not `right' (or vice versa)? Why should a change in text-insertion direction cause lots of directional keys/commands to flip (but not all, apparently)? > However, consistency matters. Consistency matters. But which consistency? > If "forward" doesn't really mean forward in the text, What about forward in the _buffer_? Should `forward-char' reflect the R2L/L2R quality of the surrounding chars, or should it just reflect the buffer directionality (bob -> eob)? What about beginning of buffer? Should it sometimes become end of buffer? Should that happen only if the entire buffer is R2L? Anyone smell a can of worms around here? > I think you will end up with nonsense in the end, such as "beginning of > sentence" moving to the end of sentence. A sentence, like a defun, has a well-defined start and end. Any display or editing mode should easily DTRT wrt such things. You could even have a mode where a sentence is represented as a tree. End-of-sentence would still be unambiguous, wherever and however it was displayed. My question is about the "forward" direction. Should it be the traditional, buffer-oriented direction or should it change depending on the current paragraph (surrounding text) etc.? Naively, it seems simpler to have movement from bob toward eob be "forward", with (1+ (point-min)) being farther "forward" than (point-min), ... and (point-max) being the farthest "forward". Of course, anyone and any mode is free to define a custom "forward" direction or movement. thingatpt.el offers one way to do that for different kinds of things, for example. So I'm not arguing that one should not be able to have different "forward" behaviors or notions. But for the ordinary cursor movements, I still raise the naive question: Why not just let "forward" be toward eob? > That is why I came up with a bunch of questions the other > day, which seem all interlinked.