Re: Current mode command discovery

[Matt Armstrong]

To your original queston of "should we build a command like this?" I
suspect it just needs to be prototyped to see how it feels.

I have many times totally failed to appreciate how useful a thing could
be *before* I tried it out.

I know that, personally, I have't felt I wanted such a thing so far.
Command name prefixes in M-x do a pretty good job (for me).


Lars Ingebrigtsen <larsi@gnus.org> writes:


[...]

> Hm...  there's two obvious sources if information about what commands
> "belong" to a mode: There's the key bindings, and then there's the new
> mode tagging.  We could perhaps use both in this new command?  I.e., if
> somebody has gone to the trouble to add a command to the keymap of the
> mode, then it's probably pretty useful for that mode?

A third possible signal is the command name prefix.

A fourth signal could be a new 'all mode annotation that means
"generally useful" regardless of mode.

I say "signal" because I'm not sure what you're imagining: a
exploration/discoverability tool or a menu of stuff absolutely known to
work here commands.



[...]

> So: Tagging by mode conveys more information to the system than just
> having predicates, and we can use that.  This also means that
>
>   (declare (modes ...))
>
> should be implemented differently than it is today (which is just
> slapping a predicate onto the symbol-plist).

Declarative programming for the win.

Could the (declare (modes ...)) and the new (interactive ... modes) be
unified?  I understand that they do different things today, but they're
both called "modes" and the difference is pretty subtle.  If they stay
separate, perhaps rename to (declare (completion-modes ...))?