Re: Making `interactive' conditional

[Artur Malabarba]

On Jan 10, 2016 7:02 AM, "Lars Magne Ingebrigtsen" <address@hidden> wrote:
>
> John Wiegley <address@hidden> writes:
> >
> > 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>])
>
> That does sound kinda exciting.  To take a random example, `M-x
> delete-matching-lines' could have a :when of `buffer-writable-p' and not
> auto-complete when in a read-only buffer.  Etc.

I like this too.
One minor detail: I think I would invert the second keyword (i.e., use :unless or :error-if, instead of :when). This way the return value of the function could be used as the error message. 

> > 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).
>
> Hm...  I think that sounds a bit too magical to be workable in general.
> I may be wrong, but I think that would probably lead to undesirable side
> effects

I agree with Lars, we shouldn't overdo this with magical guesswork. There are plenty of commands which work outside their major mode. I think that the point of this feature would be to remove from completion (or signal a friendly error) commands that would be guaranteed to error out (probably in some enigmatic way) if invoked outside the expected context.

This includes, for instance, the package-menu commands, which will immediately barf if the current buffer doesn't contain a tabulated list of packages.