[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Making `interactive' conditional
From: |
Drew Adams |
Subject: |
RE: Making `interactive' conditional |
Date: |
Sun, 10 Jan 2016 09:55:57 -0800 (PST) |
> 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.
- RE: Leaving out non-applicable commands on Mx, (continued)
- RE: Leaving out non-applicable commands on Mx, Drew Adams, 2016/01/08
- RE: Leaving out non-applicable commands on Mx, Drew Adams, 2016/01/08
- Re: Leaving out non-applicable commands on Mx, Óscar Fuentes, 2016/01/08
- Re: Leaving out non-applicable commands on Mx, Yuri Khan, 2016/01/09
- RE: Leaving out non-applicable commands on Mx, Drew Adams, 2016/01/09
- Making `interactive' conditional (was: Leaving out non-applicable commands on Mx), John Wiegley, 2016/01/09
- RE: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx), Drew Adams, 2016/01/09
- RE: Making `interactive' conditional (was: Leaving out non-applicable commands on Mx), Drew Adams, 2016/01/11
- Re: Making `interactive' conditional, Lars Magne Ingebrigtsen, 2016/01/10
- Re: Making `interactive' conditional, Clément Pit--Claudel, 2016/01/10
- RE: Making `interactive' conditional,
Drew Adams <=
- Message not available
- Re: Making `interactive' conditional, Artur Malabarba, 2016/01/10
- Re: Making `interactive' conditional, Richard Stallman, 2016/01/10
- Re: Making `interactive' conditional, Lars Magne Ingebrigtsen, 2016/01/11
- Re: Making `interactive' conditional, Stefan Monnier, 2016/01/11
- Re: Making `interactive' conditional, Óscar Fuentes, 2016/01/11
- RE: Making `interactive' conditional, Herring, Davis, 2016/01/11
- Re: Making `interactive' conditional, Óscar Fuentes, 2016/01/11
- RE: Making `interactive' conditional, Herring, Davis, 2016/01/11
- Re: Making `interactive' conditional, Óscar Fuentes, 2016/01/11
- Re: Making `interactive' conditional, Lars Magne Ingebrigtsen, 2016/01/11