emacs-devel
[Top][All Lists]
Advanced

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

Re: Ordering of command completions


From: Lars Magne Ingebrigtsen
Subject: Re: Ordering of command completions
Date: Sun, 07 Dec 2014 17:28:12 +0100
User-agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux)

Tom <address@hidden> writes:

> Just a quick thought: various modes have lots of keybindings and
> often I use M-x to invoke commands of unfamiliar or rarely used
> modes, because I don't always know the relevant keybindings. Of
> course, I can use the prefix of the mode when completing, but I
> may not know it and it may not be obvious depending on the
> mode. It occured to me that M-x, when showing completions, could
> list command matches from the current major mode first, then from
> the minor modes and then the rest of the commands.

By looking at the commands bound in the active keymaps?  Yes, that would
help.

We discussed the opposite problem a while ago -- excluding commands that
only make sense in a specific mode from turning up when doing command
completion.  For instance, if you're in the *scratch* buffer, you never
want the `message-send-and-exit' command.

During the last discussion, we touched on introducing a new form that
would explicitly say what mode a commands belongs to.  (Some commands
are applicable generally; most are related to a specific mode.)  So
something like

(defun message-send-and-exit ()
  "Doc string."
  (command message-mode "P")
  ...)

where `command' is just like `interactive', only that it takes a mode
name (or a list of mode names) that says "where it belongs".

The main problem with that approach is that it wouldn't really work for
out-of-tree packages, since introducing something like that requires
Emacs Lisp engine level changes, I think.

But if we had this mechanism, then `M-x m<TAB>' would only complete to
things that are potentially useful in the current buffer (or globally),
which would be very nice.

Other, less intrusive approaches (that is, that could be used out of
tree by including legacy macros) would be

(defcommand message-send-and-exit ()
  "Doc string."
  (command message-mode "P")
  ...)

where out-of-tree `defcommand' would be a macro that just transforms
`command' into `interactive'.

Or even more ugly, but even less intrusive for out-of-tree use, by using
a special comment cookie that would just the appropriate modes:

;;;##!message-mode
(defun message-send-and-exit ()
  "Doc string."
  (interactive "P")
  ...)

And probably other approaches...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



reply via email to

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