From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Uday S Reddy Newsgroups: gmane.emacs.devel Subject: RE: arrow keys vs. C-f/b/n/p Date: Fri, 11 Jun 2010 22:24:37 +0100 Message-ID: <19474.43413.742000.105784@gargle.gargle.HOWL> References: <87d3w2ncqs.fsf_-_@lola.goethe.zz> <87iq5py7xk.fsf@stupidchicken.com> <6D176B89214E4EE2B2B376B182E5B80F@us.oracle.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 1276291497 18557 80.91.229.12 (11 Jun 2010 21:24:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Jun 2010 21:24:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 11 23:24:54 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 1ONBie-00049T-QO for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 23:24:53 +0200 Original-Received: from localhost ([127.0.0.1]:39543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONBid-0006Hd-Sw for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 17:24:51 -0400 Original-Received: from [140.186.70.92] (port=55733 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ONBiX-0006HV-Dq for emacs-devel@gnu.org; Fri, 11 Jun 2010 17:24:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ONBiV-00012V-UE for emacs-devel@gnu.org; Fri, 11 Jun 2010 17:24:45 -0400 Original-Received: from sun61.bham.ac.uk ([147.188.128.150]:33712) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ONBiV-00012A-PP for emacs-devel@gnu.org; Fri, 11 Jun 2010 17:24:43 -0400 Original-Received: from [147.188.128.127] (helo=bham.ac.uk) by sun61.bham.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1ONBiS-0002Du-PF; Fri, 11 Jun 2010 22:24:40 +0100 Original-Received: from mx1.cs.bham.ac.uk ([147.188.192.53]) by bham.ac.uk with esmtp (Exim 4.43) id 1ONBiS-000411-F4; Fri, 11 Jun 2010 22:24:40 +0100 Original-Received: from acws-0068.cs.bham.ac.uk ([147.188.194.56]) by mx1.cs.bham.ac.uk with esmtp (Exim 4.51) id 1ONBiU-0000cR-6a; Fri, 11 Jun 2010 22:24:42 +0100 In-Reply-To: <6D176B89214E4EE2B2B376B182E5B80F@us.oracle.com> X-Mailer: VM 8.1.90a under 22.2.1 (i386-mingw-nt5.1.2600) 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:125768 Archived-At: Drew Adams writes: > 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. Sorry I misunderstood. Actually, I find most of this discussion hard to understand (as also the line-move-visual discussion earlier). It is best to be as clear as possible. > > 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? The consistency I am asking for is that "forward" should mean the same thing all the time and "end" should mean the same thing all the time. I also think "forward" and "end" should be correlated because nobody wants to go forward to the beginning! On the other hand, there is no need for "forward" and "right" to be correlated. They are independent concepts. --- James Cloos wrote an informative message later, at 5:12pm, where he pointed out that an L2R user that is occasionally using R2L text may have a very different preference from some one that regularly deals with R2L text. So, flexibility is called for. If we go with a preconceived idea that C-f should always mean the same as , then we are likely to go wrong. I might have said this earlier, but key bindings are not a big deal. The users can always bind the keys to their liking. But the *functionality* should be there for them to bind the keys to. If there is only one function called forward-char then C-f and will get coupled, and the flexibility won't be there for the users. If there is a forward-char and a right-char, then James Cloos can bind both C-f and to forward-char. He gets the logical motion that he prefers. Some other user might want to mean right. He might bind to right-char. > 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. Ok, that is nice. But then, will `forward-sentence' move forward over a sentence, while `forward-char' will move back? That might in fact be what some users want. Somebody might have his neurons already wired to correlate C-f with right and C-b with left. But we can't say that every user should follow that choice? > 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". My belief is that many users will want "forward" to be determined by the kind of text they are editing. bob and eob are harder issues. So, I don't think we should let them guide everything else. Rather, they should be postponed to the end, after everything else is decided. In fact, it is not clear to me that when a user does bob or eob, they necessarily want to go to the very beginning or very end of the text. Somewhere close by is good enough. So, if bob and eob don't work perfectly, it doesn't matter all that much. Cheers, Uday