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

[Alan Mackenzie]

Hello, John.

On Sat, Jan 09, 2016 at 12:55:28PM -0800, John Wiegley wrote:
> >>>>> Yuri Khan <address@hidden> 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.

What you're proposing is exactly "filtering M-x"; censoring it, if you
will; a sort of "not in front of the children" attitude that restricts
what you can see by somebody else's criteria.  I think most people on
this list would be opposed to censorship in most areas (for example,
national authorities deciding what part of the WWW is suitable for
browsing).  Yet, here we are, talking about introducing the same sort of
thing into Emacs.

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

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

If it is to be implemented, then the right place is indeed in core.  But
just because we can implement it doesn't mean we should.  It would add,
marginally, to the complexity of Emacs, to the difficulty of learning
it.  What do we gain that would offset this loss?  What is this feature
for?

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.

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

At which point I see the complexity rapidly increasing, unforeseen Bad
Things happening, and generally a lot of pain.

> The use of such automation would be configurable and off by default,
> at least until we believe it's ready for prime-time.

_ANY_ form of censorship must be optional, and not merely up to the
point where some authority decides it's acceptable to impose on the
masses.

> 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"?

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

Again, what is this feature for?  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.

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

-- 
Alan Mackenzie (Nuremberg, Germany).