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: `C-b' is backward-char, `left' is left-char - why? Date: Fri, 27 May 2011 15:08:46 -0700 Message-ID: <392401A7079D400E86B791262598387D@us.oracle.com> References: <6F4054004B154CFB8E2753172D316C13@us.oracle.com> <83tycfc0l0.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 1306534145 11363 80.91.229.12 (27 May 2011 22:09:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 May 2011 22:09:05 +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 May 28 00:08:59 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QQ5DG-0003Uy-Un for ged-emacs-devel@m.gmane.org; Sat, 28 May 2011 00:08:59 +0200 Original-Received: from localhost ([::1]:55597 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQ5DG-00046E-Fr for ged-emacs-devel@m.gmane.org; Fri, 27 May 2011 18:08:58 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43117) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQ5DC-0003zu-Vk for emacs-devel@gnu.org; Fri, 27 May 2011 18:08:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QQ5DB-0004EM-OH for emacs-devel@gnu.org; Fri, 27 May 2011 18:08:54 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:36606) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QQ5DA-0004Dl-9v; Fri, 27 May 2011 18:08:52 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p4RM8ns4006640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 May 2011 22:08:50 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p4RM8mew012484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 May 2011 22:08:48 GMT Original-Received: from abhmt018.oracle.com (abhmt018.oracle.com [141.146.116.27]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p4RM8hKo004151; Fri, 27 May 2011 17:08:43 -0500 Original-Received: from dradamslap1 (/10.159.51.66) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 May 2011 15:08:43 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83tycfc0l0.fsf@gnu.org> Thread-Index: AcwcsmKLzaK8vmk4RoC6uZHZMg8WFwAAUURA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4DE020F3.0013:SCFMA922111,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 148.87.113.121 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:139785 Archived-At: Thanks for the explanation. Essentially, you've said that (a) the world wants bidi and already uses it - which I already acknowledged, and (b) its redefining of default keys _cannot_ be made optional because it needs to do certain things automatically. With my still limited understanding, I do not see the latter requirement, and I do not see that you have demonstrated (explained) it. See below. That Enacs-for-bidi needs to do certain things is one thing. That it needs to be imposed on everyone all the time, in order to be able to do those things when appropriate is not so clear - not in your explanation so far. > Because users of right-to-left scripts expect the current behavior of > the arrow keys. > > > Why not make bidi optional? > > It _is_ optional: you can set bidi-display-reordering to nil. Obviously I meant optional in the sense that I was questioning. How to prevent it from binding default keys in this way? You say it must bind `left' to `left-char' instead of `backward-char'. That obligation does not sound very optional. I will rarely, if ever, use bidi. OK, maybe I'm a minority of one. Still, how can I prevent it from hijacking keys that normally would be bound to the same good-ol' commands? It doesn't help me much that the commands they are now bound to might do the same thing, as I pointed out. Commands are soemtimes used and manipulated by code, in addition to being invoked interactively and individually by users. That's why we have things such as `remap' and `substitute-key-definition'. > > Why not have a minor mode for the bidi stuff > > Bidi cannot be a minor mode, because bidi reordering for display > should happen automatically whenever there are right-to-left > characters in a buffer. Minor modes don't work that way. That it should automatically do things for people who want it I can understand. But for someone who never wants it? More importantly, what prevents a minor mode, which could even be enabled by default for all I care, from doing just what you said: automatically...? Turn on the mode and you get what you've provided - everything. Turn it off and you get what Emacs has provided for years, limited as it might be. I don't see how using a minor mode would prevent you from doing anything at all that you want or need to do. Can you please explain that? At least having a mode for this would give users a way to turn all of its effects off (hopefully - at least the key hijacking I'm referring to). IOW, if your `left-char' command makes sense only when bidi minor mode is turned on, then it would not be made to hijack `left' except when that mode is on. Minor modes can have their own keymaps, and if need be they can also be made to change/restore other bindings (i.e. in different maps) when you turn them on/off. > Besides, the rest of the world does bidi automatically; it's high time > Emacs does, too. I have nothing against that. I would like a way (if possible) for an individual user to turn off its automatic sensitivity, rebinding of keys, etc. That's all. Even if there are few of us users who won't use bidi much, it would be nice to give us the possibility of non-bidiness. No one is trying to prevent bidi users from bidying (to coin a word). Please do not turn things around - I am not trying to prevent any bidiness among consenting adults. I'm all in favor of Emacs becoming bidi-enabled. I only hope that its bidification doesn't impose changes on people who don't need or want to take advantage of bidi. Enabling (or disabling) as an option - is that impossible? > Emacs should behave exactly the same as it does without bidi when the > text doesn't include any right-to-left characters. Anything else is a > bug. See what I said in my first message. Even if command `left-char' behaves the same as command `backward-char' when the text doesn't include any..., that does not help with code that remaps commands etc. Many tests involving commands check only their symbols, not their definitions, so even if these symbols had the _exact same_ function definition things would break. Think `substitute-key-definition'. > And another reason: if `left' sometimes moves _forward_ in the buffer, > binding it to a command called `backward-char' is a lie. So create an alias. This is really not the point. It would be good for a user to optionally be able to have the traditional behavior of having `C-b' and `left' bound by default to the _same_ command (same symbol), whether it is `froblorph' or `backward-char' or `left-char'. In addition, if possible it would be good for a user to optionally have that same command be what it has been since the big bang: `backward-char'. Any code expecting that default binding or command name would then have a better chance of behaving as expected. If, as you suggest, but haven't yet backed up, you simply _cannot_ put this stuff in a minor mode for some reason - even turning the mode on by default if you want, then so be it. I don't see that restriction yet, and would like to hear the `why'. But if it is truly a hard and fast limit for some reason, then so be it. On n'arrete pas le progres.