RE: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx)

[Drew Adams]

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

Is this supposed to affect `interactive' only for minibuffer
input that is read with completion?  If not then it's no longer
just about filtering completion candidates.

And in that case, just what is conditional?  And what about
interactive uses that do not read input at all?  Does it apply
to those cases also?

Are you perhaps suggesting that a given function would not be
a command (not interactive) when the given conditions are not
satisfied?

If so, does that mean that a predicate such as `commandp' would
also test the given conditions in the current context, i.e.,
generally (no matter how/where that predicate is invoked)?

What kinds of predicates (conditions) would be allowed here?

I guess:

. You've indicated (in effect) testing the current mode, which
  amounts to a predicate that accepts the mode as argument and
  tests with `eq' against the specified `:mode'.

. You've indicated that an arbitrary function could be provided
  (after `:when').  It seems this would thus not be a predicate
  that is applied to an _individual_ completion candidate.  So
  if you wanted to use it to filter candidates then it would
  presumably need to invoke `all-completions' (or equivalent)
  for null input ("") to get all of the initial candidates, and
  then explicitly filter them.

Is that what you are suggesting?  What you describe is not yet
clear, to me at least.

> At first, I imagine nothing delivered with Emacs will be conditional,
> because it requires annotating packages retroactively.

Doesn't it ("just") require changing `interactive' specs
wherever you want this?

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

So you would take the proposal about additional `M-x' filtering
and extend it past `M-x' to all uses of interactive functions?

A priori, the arguments I cited against doing this for `M-x'
would apply a fortiori for such a general treatment.  But it's
all too vague for the moment to guess what the consequences
really might be.

In general, my view is:

. If it gives library authors more control over the behavior,
  not less, then it's likely a good thing.

. If it gives users even more control over the behavior then
  that's likely even better.

. If instead it hard-codes behavior decided ahead of time by
  Emacs Dev then it's likely not such a good thing.

> The use of such automation would be configurable

How?  By whom?  When? (user options? runtime interactively?)

> I'm open to a feature branch implementing such conditionality,

Could you please specify it first, at least in some more
detail than what you've described so far?

I'd start with the question: What is the aim?  What is the
real problem that you want to fix, or the needed missing
feature that you want to provide?  IOW, what's it for? what
good is it?