[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ordering of command completions
From: |
Óscar Fuentes |
Subject: |
Re: Ordering of command completions |
Date: |
Sun, 07 Dec 2014 19:33:25 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Lars Magne Ingebrigtsen <address@hidden> 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]
- Re: Ordering of command completions, (continued)
- Re: Ordering of command completions, Lars Magne Ingebrigtsen, 2014/12/07
- Re: Ordering of command completions, Lars Magne Ingebrigtsen, 2014/12/07
- Autoload cookies (was: Ordering of command completions), Lars Magne Ingebrigtsen, 2014/12/07
- Re: Autoload cookies, Daniel Colascione, 2014/12/07
- Re: Autoload cookies, Lars Magne Ingebrigtsen, 2014/12/07
- Re: Autoload cookies, Andreas Schwab, 2014/12/07
- Re: Ordering of command completions, Óscar Fuentes, 2014/12/07
- Re: Ordering of command completions, Lars Magne Ingebrigtsen, 2014/12/07
- Re: Ordering of command completions, Artur Malabarba, 2014/12/07
- Re: Ordering of command completions, Artur Malabarba, 2014/12/07
Re: Ordering of command completions,
Óscar Fuentes <=
- RE: Ordering of command completions, Drew Adams, 2014/12/07
- Re: Ordering of command completions, Óscar Fuentes, 2014/12/07
- RE: Ordering of command completions, Drew Adams, 2014/12/07
- Re: Ordering of command completions, Óscar Fuentes, 2014/12/07
- RE: Ordering of command completions, Drew Adams, 2014/12/07
- Re: Ordering of command completions, Óscar Fuentes, 2014/12/07
- RE: Ordering of command completions, Drew Adams, 2014/12/07
Re: Ordering of command completions, Lars Magne Ingebrigtsen, 2014/12/07
Re: Ordering of command completions, Óscar Fuentes, 2014/12/07
Re: Ordering of command completions, Lars Magne Ingebrigtsen, 2014/12/07