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

[Drew Adams <drew.adams@oracle.com>]

> This might be OK if the only reason you every use M-x is to execute a
> command.  But it's not.  People (in particular, me) use it to discover
> Emacs, to find the exact name of a command which has only vaguely
> embedded itself in the memory, to get this name into the kill ring to be
> yanked into another source file or into documentation, and so on.  Try
> M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
> :-)

Precisely.

(It sounds to me like those who now want to remake/cripple
`M-x' might not even be using it to its ordinary potential.)

> What do we gain that would offset this loss?  What is this
> feature for?

Indeed, there has been no spec of what it is for, what
requirement/need it is hoping to satisfy.

> People have suggested filtering by mode, by read-onliness, and so on.
> Somebody (I think it was Artur M.) even suggested removing initial
> checks from commands, on the grounds that M-x filtering would render it
> unneeded.  I don't think that could ever be the case.

Indeed.  It seems like some people do not see why we raise
an argument error in the function body, and not just in the
`interactive' spec.
 
> > 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).
> 
> At which point I see the complexity rapidly increasing, unforeseen Bad
> Things happening, and generally a lot of pain.

Ditto.  And not only because of corner cases or things that
are not obvious.  Mainly because it is a coarse rule - a
hammer, not tweezers or a needle.  One size does not fit all.

> > 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.
> 
> Any chance of an example of such an improvement?  How are we to
> improve on, for example, "Can't execute - not in Foo mode"?

IOW, please specify the dreamt-of feature in some detail.
Hand-waving solicits only "Great idea!" or "Hell no!" -
more noise than light.

> > I'm open to a feature branch implementing such conditionality,
> > as a candidate for merging to master...

Before calling immediately for a pilot implementation,
how about a bit more of a spec of just what is intended?

> Again, what is this feature for?

Yup.

> Is it going to make editing easier for experienced users?
> Is it really going to attract new users, ones who would be
> very happy in Emacs but for the huge number of commands
> presented to them in an M-x?
> 
> I'm sceptical on both counts.

And are there perhaps better ways, even perhaps existing
ways, to accomplish the goals?  But first, just what are
those goals?