|Subject:||Re: Making `interactive' conditional|
|Date:||Sun, 10 Jan 2016 10:36:48 -0200|
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
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|