[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Key bindings proposal

From: Uday S Reddy
Subject: Re: Key bindings proposal
Date: Sat, 31 Jul 2010 11:04:50 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100713 Thunderbird/3.1.1

On 7/31/2010 8:16 AM, Mathias Dahl wrote:

I just use C-s. In my Emacs the binding you mention does not exist, so it is
probably a quite new invention.

I think we are talking at cross purposes. This whole discussion has been about how to organize the key bindings for local keymaps set up by Emacs modes in such a way that users can modify them easily. Modifying the global bindings is a piece of cake. So, they are not under discussion. (Well, not as far as they don't impinge on local keymaps.)

M-s a C-s is indeed a recent key binding. The ChangeLog.14 file gives a date of 2008-07-28, and grep shows that there are four modes that use it: buff-menu, dired, ibuffer and vc-dir. I was giving this as an example of how Emacs developers feel *compelled* to put functions on keys. The reasons could be (a) they believe that all commands are supposed to be on keys, or (b) they think the users won't use them otherwise, or (c) they think the users won't notice them otherwise.

The problem (a) is a policy issue. I don't know if there is a policy that all commands are supposed to be on keys. But, if there is one, it can be changed easily. So, this is not a big deal.

The problem (b) is a real one. Practically nobody is going to type M-x dired-do-isearch to invoke this function. So, even these twisted key bindings will probably get used by those that need them.

My idea was why can't one type something like "M-x isearch" to get this function, instead of "M-x dired-do-isearch" which is too long-winded and "M-s a C-s" which is too twisted and unmemorable? This requires a new concept for Emacs, bindable command names that can vary across modes. (Stephen Turnbull is going to say that you can already get its effect through some other means. That is all well and good. The discussion right now is really about how to set up an architecture that is functional for the users. Not everything whose effect can be achieved by other means becomes part of the architecture unless we use it appropriately!)

The problem (c) is a real one too. But the solution is self-defeating. Once all the developers start scrambling for the limited keymap space in an effort to attract the users' attention, the keymaps grow and grow and they stop attracting anybody's attention. To get to C-s a M-s in the dired-mode's doc string, I had to do some 12 page-downs! Doubtless my attention has wandered off before then.

I stopped reading mode doc-strings somewhere around Emacs 19, when they started getting longer than Unix man pages. (And, I stopped using Unix when its man pages became unreadable too.) Fortunately, Emacs has info, which I use regularly. But my impression is that the vast majority of Emacs users don't use info. Xah Lee is right that the info manual has begun to read more and more like a PhD thesis than a user manual, and unfit to look up information quickly unless you already know its structure well. But let me not go into that issue here.

Keyboard navigation of the menubar is a potential solution for both the problems (b) and (c). But, as I mentioned earlier, this idea hasn't yet been taken seriously in Emacs. The menu entries don't have key strokes associated with them. At least on Windows, one can get to each menu item by typing the first letter of the item. But this gets tedious if

- there are many menu items starting with the same letter (for example, look under the "Mark" menu in dired) and

- when there is no way to sort the menu items alphabetically.

On second thought, perhaps the menus are not as disorganized as I had imagined. I haven't yet begun to use them seriously. Since you seem to have first-hand experience with their use, I should go by your word that they work well. I would personally prefer if the menu items had key strokes associated with them rather than the default first-letter-selection mechanism. This would also be in line with all the well-designed GUI applications out there.

Coming back to the original issue, the over-reliance on key bindings gets in the way of users trying to move the key bindings around. Even the remapping idea, which is good in concept, is defeated if the mode developers have hard-wired key bindings. And, a lot of the time the mode developers have used up pretty much all the key space there is. So, the remapping idea becomes useless.

To give a concrete example, let us say that a user wants to use i-j-k-m mnemonics for movement instead of p-b-f-n. He can bind C-m to next-line etc at the top-level however hard it might be. But then every mode will probably have some bindings that depend on the p-b-f-n mnemonics. The dired mode had C-n bound to dired-next-line, which has now been changed to [remap next-line]. That helps the user. But dired mode also has `n' bound to dired-next-line. It is not possible to move it to `m' by remapping. In some other modes (e.g., VM summary mode), C-n is not used, but just `n' for the mode-specific movement. Thus the user has to solve the same problem again and again. This is not the whac-a-mole problem because it is the *same* mole that crops up in each mode, not a different one.

So, the more keys the developers bind, the harder it is for the users to move them around. Getting away from the key binding culture will help such users.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]