RE: Making `interactive' conditional

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

> I think this is converging to what Stefan pointed earlier (which I found
> very convincing/exciting): in its most basic form, this proposal could
> supersede a lot of ad-hoc checking that many many commands do (by calling
> `barf-if-buffer-read-only', for example).

Those commands still need to do that in their bodies, for the same
reason that a command does it in the body today, even when it might
also do it in the `interactive' form (e.g., to prevent further
processing of an `interactive' form that reads multiple inputs).

Regardless of how or where or why such a function is invoked, it
needs to raise such an error and let the user know what the
invocation problem is.

Preventing a function from being calling incorrectly (in your view)
interactively does not prevent it from being called incorrectly (in
your view) non-interactively.

> Similarly, there are many commands that are marked interactive because
> they are bound to keys in certain contexts, but make no sense (and will
> just immediately error out if called from M-x) otherwise.

The way we handle that normally is for such keys to be bound in a
mode map.  If you are in that mode then they are bound to those
context-specific commands; otherwise, no.

In such a case it makes sense to not make those commands available
on key bindings outside of the mode.

That rationale is entirely absent for the case of `M-x', which is
(and should be) completely general.

Leave it to the context-defining mode to decide whether a given
command should be bound in that context.  Don't cripple `M-x'.

> I find it reasonable to think that if a command is just going to
> exit in error as soon as I call it I probably don't want it to
> feature prominently among M-x completions.

1. But the proposal now being considered goes far beyond not
   showing it as a command-name completion for `M-x'.  It is no
   longer about the possibility of _completion_ but is instead
   about the possibility of _invocation_ - in any way (IIUC).

2. Sometimes a user wants to see what commands exist (e.g. match
   a given pattern), whether or not a given command can be used
   in the current context.

   Completion lets you see what the matching command names are,
   irrespective of whether you might want to invoke a particular
   one - or any one.

   It is up to the particular _command that is completing_
   function names to match input to decide whether to remove
   some names from the outset.

   `M-x' is one particular command that completes function names.

   But it is the most general command-invoking command we have.
   It should not filter beyond `commandp' at the outset.  But a
   user could well be given minibuffer keys that let the _user_
   filter `M-x' candidates in additional ways.

3. A user might well _want_ to see the specific error message,
   in particular because it might not be obvious _why_ (in your
   view) a given command name is not available as a candidate.

   Making `M-x' filter out certain candidates beforehand tells
   the user _nothing_ about (a) whether such commands exist or
   (b) why they are currently considered unavailable.  IOW,
   less help for a user.