Re: Ordering of command completions

["Óscar Fuentes" <ofv@wanadoo.es>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

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

That's ok, but it is also very handy to have a global statement saying
"all the definitions on this file are bound to `message-mode' unless
the contrary is explicitly stated."

Consider Gnus, for instance. It has lots of stuff that only makes sense
within a Gnus buffer, but it has just a few "entry points" that are
intended to be used from any context. Having file-level statements would
save a lot of work.

The schema should work for all definitions that target the user, not
just interactive defuns. defcustoms, for instance. Hence, I'm not sure
that the `declare' approach mentioned on other message is appropriate.

A cookie-based approach seems more effective. The cookie affects the
definitions that follow it until a new cookie is found.

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

This is a lesser problem, because the vast majority of noise on M-x
comes from packages distributed with Emacs.

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

Yes, and with the right completing engine M-x comes to be much more
effective on terms of efficiency and discoverability.

BTW, I still volunteer to do the foot job (annotating the files and/or
definitions) if a more knowledgeable hacker implements the feature.
<wink>

[snip]