>>>>> Yuri Khan <yuri.v.khan@gmail.com> writes:

> Emacs already contains a feature that filters out many defined functions
> from M-x. It’s called (interactive). Functions that are not declared
> interactive are not offered as completion candidates, and in fact cannot be
> executed with M-x.

OK Yuri, now you've got me excited. Let's not talk about "filtering M-x";
let's talk about making `interactive' conditional. The former is a UI concern,
while the latter I consider a core API issue.

Right now, functions are interactive if declared with `interactive', and not
otherwise. The suggestion at hand is to allow `interactive' forms to become
conditional -- possibly in multiple ways. I like this concept, and think the
right place for it is indeed in core.

The question is how to declare such conditionality. We can do this rather
easily by accepting new keyword arguments to `interactive':

    (interactive "sDirectory: " [:mode foo-mode] [:when <function>])

This way, all new modes can take advantage of this support as it becomes
available. I've already tested on 24.5, and keyword arguments are silently
ignored by present-day GNU Emacs. This gives us transparent compatibility in
both directions. We could also do it with (declare); I'm open to that too, and
it also gives us such compatibility.

At first, I imagine nothing delivered with Emacs will be conditional, because
it requires annotating packages retroactively. We could alleviate some of that
by writing code to automatically consider every interactive function *without
an autoload token* as being conditional on any modes defined in the same
package (likely determined by prefix matching). The use of such automation
would be configurable and off by default, at least until we believe it's ready
for prime-time.

Thus, proper UI behavior for M-x falls out by design, and we get to make use
of conditionality for other purposes, such as better errors when command
functions are called outside their expected environment.

I'm open to a feature branch implementing such conditionality, as a candidate
for merging to master. As described above, I expect the C code impact to be
fairly minimal, and the changes to `M-x' to also be minor. The automation
logic seems like the trickiest part, as it would have to happen whenever a
feature is loaded.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2