[Top][All Lists]

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

\\[...] for a mouse-event command - should never show `M-x'

From: Drew Adams
Subject: \\[...] for a mouse-event command - should never show `M-x'
Date: Sat, 23 May 2009 08:39:54 -0700

`C-h v mouse-buffer-menu-mode-mult':

| *Group the buffers by the major mode groups on <C-down-mouse-1>?
| This number which determines (in a hairy way) whether <C-down-mouse-1>
| will split the buffer menu by the major modes (see
| `mouse-buffer-menu-mode-groups') or just by menu length.
| Set to 1 (or even 0!) if you want to group by major mode always, and to
| a large number if you prefer a mixed multitude.  The default is 4.

1. Why the `?' in the first line? Typo?

2. "Mixed multitude"? "This number which determines whether..." - No verb: what
does this number (which determines...) do or mean?
This doesn't seem to be explained very well.

3. General comment -

Suppose a mouse-event command such as `mouse-buffer-menu' is not currently bound
(e.g., some code binds `C-mouse-1' to a different mouse command). Then the doc
string above shows the binding as "M-x mouse-buffer-menu", which is inaccurate
and misleading.

The user doc that explains `M-x' clearly doesn't anticipate its use to introduce
a command, such as `mouse-buffer-menu', that won't work with `M-x'. See

When the command passed (via \\[...]) to `substitute-command-keys' is known, is
there an easy way for `substitute-command-keys' to know whether the
`interactive' spec uses `e'? That wouldn't be failsafe, but it might catch most
such commands. We could then use some other indication, instead of `M-x' -
perhaps (Mouse): `(Mouse) mouse-buffer-menu'.

Or perhaps just use the command name alone: `mouse-buffer-menu'? In any case,
`M-x' is inappropriate for mouse-event commands.

reply via email to

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