emacs-devel
[Top][All Lists]
Advanced

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

RE: Key bindings proposal


From: Drew Adams
Subject: RE: Key bindings proposal
Date: Sat, 31 Jul 2010 11:17:21 -0700

I really do not want to go down the rat hole of this thread.  But I will make a
couple of comments.  Suffice it to say, beyond these comments, that I agree with
those old diehards ;-) who have been trying to say that this thread is misguided
in general.

> 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

In many or most cases, the mode's specialized version of a command does not
simply replace that command in all situations or for all purposes.

That is the case here, for example.  You might well want to use the general
command `isearch' (e.g. `C-s') in a Dired buffer, in addition to wanting (for
other purposes) to use the more specialized command `dired-isearch-filenames'
(bound to `M-s f C-s').  The latter does not simply replace the former for
everything when in Dired.

You are wrong in assuming that a subtype/subclass analogy holds in general for
this kind of thing.  `dired-isearch-filenames' is not `isearch', and both can be
useful in Dired mode.

Not to mention `dired-do-isearch', which is the command that you mentioned.
That command is for searching within the marked files themselves.  It has
nothing to do with searching within the Dired buffer (`isearch').

(Did you notice the similarity: `M-s f C-s', `M-s a C-s'?  There is a
key-binding logic here.  You might prefer a different logic, but there is one.)

> To get to C-s a M-s in the dired-mode's doc string, I had
> to do some 12 page-downs!

Obviously, in a mode as rich as Dired, you should not expect to use `C-h m' as
your primary means of discovery of what is possible in Dired.

Menus.  Menus.  Menus.  Menus are your friend.  Menus are an excellent way to
_discover_ features, including command names and key bindings.

The menu for a mode tells you about its main features, organizes them in some
logical or pedagogical way, and gives you the keyboard shortcuts for the menu
items.

Menus are _organized_, and that is one of their main advantages for discovery
and memory (infrequent access).  What was that command/key that let me do
such-and-such?  You can try `apropos' and `C-h b', but you can also explore
menus to take advantage of their logical organization.  If you're not doing
this, then I suggest you're missing the boat.

Yes, Emacs menus are not always as good as they could be, partly because the
Emacs developers who add a feature have already discovered it. ;-)

In Dired, the `Operate' menu (the one for operating on marked files), has these
menu items:

 Isearch Files...                    M-s a C-s
 Isearch Regexp Files...             M-s a C-M-s

And the `Immediate' menu has these:

 Isearch in File Names...            M-s f C-s
 Isearch Regexp in File Names-...    M-s f C-M-s

[Personally (dired+.el), I put the latter items on the `Subdir' menu, not on the
`Immediate' menu - they are not actions that apply to a single file.  (And I
rename `Immediate' to `Single', `Operate' to `Multiple', and `Subdir' to
`Dir'.)]

Perhaps these same search items should also appear on the `Search' menu (under
`Edit').

But the point is that you should, like newbies everywhere (and we are all
newbies in some contexts) use _menus_, not just `C-h m' or `C-h b', to discover.
To discover, use menus, use the fine manual, and use `apropos'.

Wrt the key bindings for these commands: Again, there is a logic there - a logic
that facilitates discovery and memory.  And you can easily use your own,
personally superior, alternative bindings.

And you need not use any binding if you prefer to use a command or menu.  It is
trivial in Emacs to get the command name from the menu item (here, but not
always - e.g. easymenu): `C-h k'.  And it is trivial to provide a shorter
command name (alias) if you want to use `M-x my-foo' instead of `M-x
the-long-weird-obscure-fooish-command'.

Honestly, I do not know of an application where it is so easy to discover and
access commands as it is in Emacs.

Could discovery be even easier?  Yes, IMO.  Icicles users have the equivalent of
`apropos' available on the fly every time they use the minibuffer for anything.
Could the menus be improved?  Yes.  Could menu access from the keyboard be
improved?  Yes, IMO (though `tmm' is OK) - La Carte, especially together with
Icicles, gives you excellent menu access and menu discovery from the keyboard.

And other improvements are always possible.  But Emacs is _better_, not worse,
than most apps wrt command discovery and access.

The complaints here about weird Emacs keybindings are surprising to me, coming
from you, Uday, who are familiar with Emacs.  They sound like the superficial
comments of a vi'er or someone unfamiliar with Emacs - someone who has the
impression that one is _required_ to use `M-x a C-s' in order to search.  It is
trivial to use `M-x', trivial to use the menu, and trivial to bind a simpler key
to something that you use often.

> I stopped reading mode doc-strings somewhere around Emacs 19, 
> when they started getting longer than Unix man pages.

I'm the opposite.  I like a mode doc string that gives me almost a mini-manual
for the feature (mode).  People are different.  But a doc string is not intended
to _replace_ a manual.  That is why doc strings link to the manual (or they
should more often), as well as to Customize.

> (And, I stopped using Unix when its man pages became
> unreadable too.) 

Wow, that's quite extreme.  With GNU/Linux you can of course help improve the
man pages. ;-)

> Fortunately, Emacs has info, which I use regularly.

Amen.

> But my impression is that the vast majority of Emacs users don't 
> use info.

I do not have that impression.  What makes you think that?

> Xah Lee is right that the info manual has begun to read more
> and more like a PhD thesis than a user manual,

I disagree.  I use Emacs 20 often, and I do not see any special trend/change
from Emacs 20 to Emacs 24 that could be so characterized.  And I do not find
either the 20 or 24 manual to be thesis-like.  It is true that some sections are
more difficult to read than others - they are more reference-like.

The Emacs manual is not just a user manual in the sense of an intro,
guide-you-by-the-hand, user guide.  It is that to some extent, but it is also a
_reference_ manual.  Likewise (even more so), the Elisp manual.

> and unfit to look up information quickly unless you
> already know its structure well.

Dunno why you say that.  But there are ways to improve Info as well, and some of
them have recently been added to vanilla Emacs (mostly by Juri).  Virtual books,
history lists, etc. speak directly to the "structure".  If you use Icicles then
you have even more help navigating Info and dealing with its structure.  

> But let me not go into that issue here.

Yes, a separate thread please, if you really want to get into Info.

> Keyboard navigation... hasn't yet been taken seriously in
> Emacs.  The menu entries don't have key strokes associated 
> with them.

See above.  You're wrong on both counts, IMO: keyboard navigation of menus and
presence of keyboard-shortcut indications in menu items.

> 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.

Try Icicles and La Carte.  You can easily sort items on the fly and you can
easily get to any item, no matter where it is in the menu tree.

I'm not trying to pitch Icicles or La Carte here.  I'm trying to say that Emacs
can easily give excellent menu access and provide excellent menu discovery.  Out
of the box it is OK, and it could easily be made even better.

> On second thought, perhaps the menus are not as disorganized 
> as I had imagined. I haven't yet begun to use them seriously.

Please do.  You will thank yourself.  And you will no doubt file menu bugs or
enhancement requests or provide patches for improvements.  Welcome.

I agree that Emacs menus could be improved.  Emacs developers do not always take
them very seriously.  But you do - or will ;-).

> Coming back to the original issue, the over-reliance on key 
> bindings

That is a misconception.  Think of key bindings as an extra, if you like.  Use
commands and menus most of the time, if you like.  Emacs does not require anyone
to use keys all the time or even most of the time.

> the mode developers have used up pretty much all the
> key space there is.

It is trivial to define your own, preferred key bindings.  Think of the existing
bindings as a default, fallback behavior.  Or think of them as only suggestions.
Define your own, if you like.  As others have said here, there is a reason to
Emacs's key-binding madness, but you are free to ignore that organization,
especially in any given context/mode.

> 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.

I think you misunderstand the "key binding culture".  But I won't get into a
discussion about it with you.  I already wrote more than I intended to.  If what
I wrote helps, fine.  If not, ignore.  IMO, this discussion has not been and
will probably not be very fruitful.  But don't let that single opinion stop you.
;-)

And I do hope that you will help concretely to improve Emacs menus and manuals.
Dealing with a concrete problem/improvement is more likely to yield results than
is initiating a general or vague discussion about revamping Emacs.

Of course, for fundamental change we would need fundamental discussion.  But I
don't see that need the way you do.  I think you misunderstand some of the
existing design.  That doesn't mean that your observations can't be helpful.
But I suspect that if you attack more specific targets/needs then everyone will
learn more and there will be more improvement.  Just a suggestion.






reply via email to

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