[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Key bindings proposal
Re: Key bindings proposal
Sat, 31 Jul 2010 14:07:47 +0000
Good afternoon, Uday!
On Sat, Jul 31, 2010 at 11:04:50AM +0100, Uday S Reddy wrote:
> 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.)
How often do users want to do a massive rebinding of keys? Approximately
never is the answer.
> 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.
Oh come on, get real! Many, possibly most, commands are unusable by
typing M-x plus <command name>. Not all commands have keybindings, not
by a long shot. The scenario you've pictured is ludicrous.
> 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.
You're turning into something like a conspiracy theorist here. It is
simply the case that typing a key sequence is easier and faster than M-x
+ name. There is no policy involved such as you've sketched.
> 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.
Your (a), (b) and (c) aren't problems to anybody bar yourself.
> 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.
Well, for deity's sake stop flooding this mailing list with long screeds
and start hacking out a solution. If you think you can show something is
a good idea, and expect "Somebody" (tm) to code it up for you, you're
mistaken. That's not the way development groups work, at least not this
one. If you really believe you've identified problems, fix them!
> (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!)
Design and code up that architecture. Post a patch on this mailing list.
Then, and only then, will your ideas get taken seriously.
> 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.
OK, I will instead. Yes, it takes time to learn to use Emacs's info
pages, but once you've learned how they work, they are a joy to use. A
bit like Emacs itself.
> 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.
Well YOU start taking it seriously. Or have you done so already?
> 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.
Contribute such a sorting.
> 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.
All, or nearly all, of the mouse ambages have keyboard equivalents. What
I think you mean is that they are not all displayed in the menu. I agree
with you that they probably should be, but I can't be bothered any more
than you can about implementing this; I don't even use menus in Emacs.
> 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.
Read the elips page on bindings. The key bindings C-c C-<letter> are
allocated to major modes. C-c <letter> are allocated to users. Other
C-c bindings are allocated to minor modes. Mode developers tend to stay
within these strictures.
> 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
Then get hacking, and sort this "problem" out! I honestly can't see what
all the big fuss is about. Your solution will involve an immense amount
of work amending Info pages and doc strings, for questionable benefit.
Just because Emacs is very configurable, it doesn't follow that extreme
customisation should be made very easy, at the cost of who knows what.
I've only seen one other person wanting this, his name's Xah Lee, and
he's forked Emacs to do this. Search for "ergoemacs" to find it.
Alan Mackenzie (Nuremberg, Germany).
Re: Key bindings proposal, Uday S Reddy, 2010/07/29
coding guidelines? (was Re: Key bindings proposal), Joe Brenner, 2010/07/29
Re: Key bindings proposal [Was: Emacs learning curve], Noah Lavine, 2010/07/28