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 10:12:45 -0700 Message-ID: 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 1276276479 31868 80.91.229.12 (11 Jun 2010 17:14:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Jun 2010 17:14:39 +0000 (UTC) Cc: 'Eli Zaretskii' , 'David Kastrup' , emacs-devel@gnu.org To: "'Stefan Monnier'" , "'Chong Yidong'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 11 19:14:37 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 1ON7oK-0005tt-VV for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 19:14:29 +0200 Original-Received: from localhost ([127.0.0.1]:36330 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON7oK-0001OI-2y for ged-emacs-devel@m.gmane.org; Fri, 11 Jun 2010 13:14:28 -0400 Original-Received: from [140.186.70.92] (port=33349 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON7o3-0001L7-IV for emacs-devel@gnu.org; Fri, 11 Jun 2010 13:14:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ON7o2-0002BK-8R for emacs-devel@gnu.org; Fri, 11 Jun 2010 13:14:11 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:59863) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON7o2-0002Az-3S; Fri, 11 Jun 2010 13:14:10 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5BHE46n027696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Jun 2010 17:14:06 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o5B4vZne012220; Fri, 11 Jun 2010 17:14:03 GMT Original-Received: from abhmt020.oracle.com by acsmt355.oracle.com with ESMTP id 339764961276276367; Fri, 11 Jun 2010 10:12:47 -0700 Original-Received: from dradamslap1 (/141.144.224.37) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 11 Jun 2010 10:12:46 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Thread-Index: AcsJfZJIxyNcSonVTha1bq1lEWqRfgAAIWjQ X-Auth-Type: Internal IP X-Source-IP: rcsinet13.oracle.com [148.87.113.125] X-CT-RefId: str=0001.0A090205.4C126EDE.0157: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:125752 Archived-At: > > (I am still dubious about decoupling the arrow keys and C-f/C-b > > keybindings. Maybe we should provide a separate set of keybindings > > instead.) > > 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. I hesitate to say anything here, since I know _zero_ about R2L. But maybe it will help somehow to expose my naivety in this regard. If not, ignore. Here goes... 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". Why would it be wrong for `right' (right arrow) to always represent movement toward the right, regardless of R2L/L2R? 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). 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? 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"? Just which things really need to be flipped/mirrored? 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? Why would you want `C-f' to move toward the right in one paragraph and then jump to the "beginning" (at the right end) of the "next" paragraph and start moving toward the left - just because it is R2L? Why wouldn't you want `C-f' (and the `right' key and `C-M-f' and `forward-paragraph'...) to always move right, consistently? OK, I understand that there is a mental association of "forward" with the direction that text is inserted, but how important is it that command names reflect that? Will someone be confused or offended if `backward-paragraph' always moves toward the left? Will someone complain that what they think of as "forward" we call "backward"? Maybe, if we kept things consistent wrt forward-means-right then we would also want a new command/key that would jump to the "beginning" of the next paragraph, where that "beginning" position would be a different for R2L and L2R paragraphs. If so, then we could just add that command/key. But once you are in a paragraph, I would think that the ordinary motion etc. commands could work normally. IOW, why not introduce any convenient DWIM transitioning behavior only at R2L/L2R boundaries, and leave the behavior within a piece of R2L or L2R text alone? Maybe you'll say that at least `C-d' and `backspace' need to flip direction (forward/backward), so why not `C-f' also? I have the same naive question for those keys - why not just let R2L flip the _meaning_ of forward/backward instead of the key behavior, so that `C-d' and `backspace' are always rightward and leftward deletion, respectively? Is it important that the keys themselves flip? I can see that self-insertion should move point to the left of the inserted char in R2L. Beyond that, I don't see why all or most key behaviors need to flip. > Now addmitedly, the particular place where the choice between the two > forms of coupling is made is up for discussion: it could be > based on the direction of text underneath point (basically, make > the arrow move visually rather than logically), or based on the > direction of the paragraph (what we now have), or based on user > preferences (default depends on the locale). I don't have a clear > preference, but I think that the current choice is pretty good > compromise between "no need for customization, auto-adjusts to > mixes of L2R and R2L buffers" and "still > move in logical rather than visual order". Why not keep it simple and just have `C-f' and `right' always move toward the right? Likewise for everything that has a "forward" meaning. Why would that be problematic for a R2L user/language? This sounds a bit like trying to redefine "northward" as "southward" when you cross the equator into the southern hemisphere. What's the point? 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. If nothing else, perhaps the naive questions expressed here will help you document the bidi stuff for other naive users - HTH. Perhaps something analogous to node `(elisp) Not Intervals' would be helpful for this, explaining the logic behind the design choices.