From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Key bindings proposal [Was: Emacs learning curve] Date: Tue, 27 Jul 2010 12:17:14 +0900 Message-ID: <87vd81vcjp.fsf@uwakimon.sk.tsukuba.ac.jp> References: <19534.1494.627000.357123@gargle.gargle.HOWL> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1280201762 886 80.91.229.12 (27 Jul 2010 03:36:02 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 27 Jul 2010 03:36:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Uday S Reddy Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 27 05:36:00 2010 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 1OdaxR-0003Ka-7A for ged-emacs-devel@m.gmane.org; Tue, 27 Jul 2010 05:35:58 +0200 Original-Received: from localhost ([127.0.0.1]:38966 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdaxQ-0007SN-Bj for ged-emacs-devel@m.gmane.org; Mon, 26 Jul 2010 23:35:56 -0400 Original-Received: from [140.186.70.92] (port=42105 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OdaxG-0007SI-Un for emacs-devel@gnu.org; Mon, 26 Jul 2010 23:35:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OdaxF-0008Fw-BG for emacs-devel@gnu.org; Mon, 26 Jul 2010 23:35:46 -0400 Original-Received: from mtps02.sk.tsukuba.ac.jp ([130.158.97.224]:46059) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OdaxE-0008Ep-KV for emacs-devel@gnu.org; Mon, 26 Jul 2010 23:35:45 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps02.sk.tsukuba.ac.jp (Postfix) with ESMTP id 979688213; Tue, 27 Jul 2010 12:16:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id ED2AC1A4FA6; Tue, 27 Jul 2010 12:17:14 +0900 (JST) In-Reply-To: <19534.1494.627000.357123@gargle.gargle.HOWL> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:127866 Archived-At: Uday S Reddy writes: > Yidong asked for a specific proposal if there is one. So, here is > mine: This is not a specific proposal. This is waving hands over an enormous cowpie. I'm sorry, but you've managed to get pretty much all of the standard misunderstandings exhibited by the CUA-by-default advocates into a single post. I hope you don't feel too battered when I'm done debunking them. > Stephen J. Turnbull writes: > > > It's trivial to change key bindings. M-x local-set-key RET > > RET and Bob's your uncle. Or maybe > > you want a swap-keys command that would have the UI M-x swap-keys RET > > . I don't have that function on the top of my head, > > but I'm pretty sure it requires at most three lines to express. > > Hi Stephen, I was going to reply to this originally saying that > `local-set-key' and `global-set-key' are destructive change operations > which shouldn't be taken lightly. In context of this thread, that's what was wanted: a permanent change (to CUA by default). I think you're missing the point, or perhaps simply don't understand how keymapping works in Emacs if you think that's an important criticism of my statement. Bringing up broken ruby-related software, well, too bad for the rubes. It's always possible to abuse flexibility, and you know that crap would never get into Emacs as is. If a safe change to the global keymap is wanted, do (defvar saved-global-keymaps nil) (push global-keymap saved-global-keymaps) (setq global-keymap (copy-keymap global-keymap)) (In practice it would be simpler than that, but this shows the most general pattern.) Yes, it would be tedious to do this for a lot of keymaps, but it could be done, and there are only about a half-dozen important ones that more or less *must* be protected. The reason Emacs doesn't do this already is that it's not useful without a concrete proposal ("concrete" is defined below). > If Emacs did take key binding customization seriously, it would have > provided a whole bunch of *declarative* methods for specifying key > bindings, along with rules for how they override each other or not > override, as the need may be. I'm flabbergasted. What do you think a keymap is, if it isn't declarative? What do you think the cascade of keymaps, inheritance, and the like is, if not a set of rules for precedence? > If and when a set of key bindings needs to be installed (e.g., when > a mode is entered), it would go and compile the key bindings from > all the sources, detect conflicts if necessary, and install the > right set. The user would be protected. If you don't think Emacs has this feature already, what's your explanation for the coexistence of CC-mode (in multiple variants!), Gnus, VM, and AUCTeX in the same Emacs process? > The user wouldn't have to mess with mode-hooks or whatever. Configurable commands are a separate problem from changing bindings of keys to commands, although obviously they are closely related in the user's experience. That is out of context (it's about [remap command] specifically, not the problem of keymap conflicts), anyway. > This is not an out-of-the-world idea. Almost all customization > systems out there work this way. What you imply here is nonsense. First, an Emacs keymap has semantics nearly identical to what you claim you want. Second, almost all customization systems deal with very sparse keymaps, which makes collisions relatively unlikely. (BTW, IME none of them work well in practice; I have yet to find a GNOME-compatible WM whose stock bindings don't conflict with some application (usually Emacs :-).) Not so for Emacs, which gave up on "keymap wall-paper" when the wallpaper exceeded the area available on the Great Wall of China, ca. 1986. Look up "whack-a-mole effect" on wikipedia. That, not poor design, is why default Emacs keymappings are hard to change. If you don't need the default bindings at all, you can go wild. Cf. Gnus or viper. > Yidong asked for a specific proposal if there is one. So, here is > mine: > > Redesign Emacs so that key bindings can be designed by end users > or third party customizers and exchanged with each other. Don't you think you really ought to learn how Emacs works before suggesting that a redesign is needed? I'm really tired of hearing that Emacs is poorly designed in this respect. Sure, I disagree with the [remap command] feature, but that's minor, micro, nano, pico. Maybe even femto. > It should be possible to change the entire set of key bindings > in a running Emacs with the click of a button. It is possible. What do you think "M-x gnus" (or "M-x viper") does? The problem is "to what?" The "concrete" part of "concrete proposal" is a request to exhibit a reasonably complete alternative keymap. Without that, the whole exercise is pointless. > If there are conflicts between different sets of key bindings > that users import, there should be clear rules for what to do > in such a case, an analysis of what goes wrong and gentle > feedback given to the users. This is not possible IMSEO. The problem is the whack-a-mole effect. You want to put something on C-x C-s, Emacs comes back with Please, be careful. The old binding to `save-buffer' is very important. If you really want to bind C-x C-s, you should put `save-buffer' on another key sequence. I can do that for you. Choose a key sequence, or type C-g for none [C-x C-# C++ u r k]: _ After getting that warning for about seven commands in succession (the suggested keysequence "C-x C-# C++ u r k" isn't very appetizing :-), the user is not going to feel gently about the process of rebinding commands. And it's about three orders of magnitude worse if you're trying to design a new keymap "for the rest of us", who are hardly a group with homogeneous requirements. Cf. also the wild popularity (not) of http://www.jwz.org/software/xkeycaps. Great program with an excellent interface, but do Gentle Newbies use it? Uh-uh. The problem is that *nothing* goes *wrong*! Keymaps, for all the discussion spent on the colors of their bikesheds, are *arbitrary* (if you start from scratch). Even arbitrary alterations to the traditional full keymap can be correct depending on the user's intent. The whole problem here is specifying what users want, not implementing a set of requirements once you've got them. Specifying the requirements here involves, at a guess, thousands of interrelated decisions. If you want them made, maybe you should get started instead of asking Emacs developers, who would rather do something else, to do it. > If you think that Emacs is alredy capable of doing all of this, > then demonstrate it by implementing a radically different set of > key bindings. Show the users how it can be done. Why should I reinvent the wheel? It's been done, multiple times. CUA, viper, Gnus, and hey, *you* are the maintainer of VM, no? *You* show them radically different keybindings, they're right there at your fingertips. If you want a permutation of the default bindings for fundamental and the other "most common" modes, no, I don't think that's my job. The people who want that should produce it. viper is a fairly good example already, I should think.