RE: Making `interactive' conditional

[Drew Adams]

> >> M-x is for *executing* commands,
> >> not for learning about them (unless your learning method
> >> consists on executing commands you don't know about).
> >
> > Very wrong.  `M-x' is for lots of things.  And discovery,
> > even for the limited completion that vanilla Emacs offers,
> > is one of the most important.
> 
> The fact that M-x shows a list of candidates does not make it an
> adequate tool for discovering. The fact that it lists *everything*,
> regardless of what yo are doing at the moment, less so.
> 
> > Don't you ever use `C-h f' or `C-h v' to discover/explore
> > (even for spelling information)?
> 
> I'm talking about M-x. `C-h *' is a different thing.

Why is it different, in terms of discovery?  Why wouldn't
your same arguments ("The fact that it lists *everything*,
regardless of what yo are doing at the moment" etc.) apply
to `C-h f'?

> > Are you going to go whole-hog on this new idea, and so
> > decide to limit the completion candidates for `C-h f' to
> > only the functions that some Emacs Dev programmer decided
> > are "appropriate" for the current context?
> 
> AFAIK, nobody suggested changing `C-h *', you just introduced that
> topic. Please don't do that. It is not a constructive way of
> discussing technical matters.

Sure it is.  Don't your same arguments apply?  Why should
we stop at `M-x'?  Seems to me that the same arguments for
and against the proposal apply here as well.  Can you point
out something different in this regard?

> > Even thinking that Emacs Dev can specify what constitutes
> > "the current context" for a given user is presumptuous.
> 
> But it is not presumptuous to put code in the command that
> checks the context and errors out if it it not the correct one. 

No, it is not.  Users can pick and choose commands and key
bindings to use.  The _very general_ command
`execute-extended-command' (`M-x') has much wider scope.
Much greater damage, if your presumption is off the mark.

> > Not only does it depend on many tangible factors - more
> > than just the current mode(s).  It depends also on intangible
> > factors - in particular the user's current aim/intention.
> 
> But you are not opposed to checks in the commands about its
> applicability. If a command has a check that errors out on
> non-editable buffers, what's wrong with not showing that
> command on M-x on that circunstance?

I already answered that.  (1) The command needs to raise
that error anyway - it won't necessarily be invoked by `M-x'.
(2) Such a particular command does not have as part of its
mission to show users which commands have names matching
given input.  `M-x' does.  And I gave additional reasons.
Feel free to read what I've already written.

> > Let _users_ filter, on demand.  Provide different, useful
> > ways for them to quickly and powerfully filter candidates
> > out/in, thus shaping the set of candidates (and thus
> > defining the context!), _themselves_.
> 
> Again, you are arguing about something that you made up. As mentioned
> several times, it is not decided (not even discussed, except by you) if
> the feature will be activated by default.

Oh, so the talk about binding this behavior to `M-x' does not
apply?  I made that up?  Great to hear.  We can all forget
about that then.

Let me clear: (1) It should not be activated by default.
(2) If Emacs Dev is convinced that this is a great idea then
it can create a _new) command that implements it.  There is
no reason to hijack `execute-extended-command' for this.

And there is certainly no reason to hijack `M-x' for it.
Provide the new and wonderful behavior in a new command, and
let users come to love it on their own and bind it to whatever
keys they like.

In a decade or two we can decide whether it should become
the new norm.  Just like other innovations (and some of them
have been left by the wayside).  Perhaps, as an Ido user, you
are desirous for Ido to become the new norm for minibuffer
input, and perhaps someday it will.  But you'll notice that
we didn't just switch the default behavior to it the day it
rolled off the press.

This new behavior hasn't rolled off the press.  It hasn't
even been described clearly yet.  But we do seem to be
talking about changing `execute-extended-command' (`M-x'),
AFAICS.  (Yes, John asked that this be done in a sandbox,
for now.  That's one good thing, at least.)

> > Icicles and Helm have tried to do exactly that, and have
> > succeeded to some extent.  Let's move in the direction
> > of giving users _more_ control, and faster and more
> > powerful control - not in the direction of supposing,
> > at code time, that we know what's good for them.
> 
> Annotating commands with information about its applicability is
> something that gives users more control, because they have more
> knowledge and can process it to taylor their needs.

I have not objected to associating any such info with commands.
I might have something to say about how that is done, but I
don't object to our doing so, as long as this is open to users
as well: to add, subtract, and modify such associations.

> Operating solely on the command names (prefixes that match
> mode names, etc) are hacks that work on arbitrary premises.

I described a lot more in the way of interactive filtering
than filtering by mode name.  Please read what I wrote.
And beyond the examples I gave or other examples that may
already be realized here or there, the possibilities are
endless.  The point is to let _users_ filter easily, in
various ways.

> > No one has spoken against being able to filter `M-x'
> > candidates to fit the user's current context.
> 
> But what me (and Lars, and most people here, AFAIU) are
> proposing is, precisely, making possible to filter M-x candidates!

As I understand it, the proposal is not about _users_
filtering the candidates, especially interactively.

The proposal is for, in effect, a code-time filtering
by Emacs Dev.

There's a world of difference between the two.  And again,
I'm not against Emacs Dev coming up with its best behavior
in this regard, and then _letting users choose_ to experiment
with the resulting _new_ command.  But I am not in favor of
it hijacking `M-x' for this new (and so far vaguely specified)
pie in the sky.

> The recent proposal about using this feature in place of tests that
> error out when the context is not the expected one, is a new
> development. I'm not much convinced about that, btw.

As I stated:

1. You cannot, in any case, do without the error-raising code
   in the command bodies (and it was argued that you would be
   able to, as if that would be a great savings).  Commands
   can be invoked in various ways, and such errors need to be
   raised.

2. It is not always an improvement to prevent a user from
   raising an error.  It can be helpful for a user to see an
   error message.  When a given command is _not_ present as a
   completion candidate you have no way of knowing why (or
   even whether the command exists).

   [FWIW, I argued something similar against the sequential
   fall-through behavior of `completion-styles', with no user
   feedback as to which completion styles failed and which
   style ultimately succeeded.  Learning that something does
   _not_ work can be helpful.]

> > The question is how what constitutes the "current context" is
> > determined/decided, and by whom, and when.
> 
> By the developer, of course. The same person who wrote the command and
> knows how and when it is correct to use it.

User first, command-developer second, Emacs Dev last.

No one has objected to the developer of a command defining
it so that it reads input with completion and so that the
completion candidates are limited to whatever the developer
thinks is appropriate.

Developers already do that, using a predicate with
`completing-read' or `read-file-name'.

But why should a developer of command `foo' decide whether
a user can see the command _name_ `foo' as an `M-x'
candidate?  Let the user decide what command names to show -
just as s?he does using pattern-matching.

> As I mentioned on other messages, M-x with the correct UI is often more
> convenient than keybindings and menus on usability terms (ergonomics,
> discoverability, mnemonics). On that aspect, M-x is severely handicapped
> by the presence of a growing large number of irrelevant candidates.

That seems to be what is behind your use case, indeed.
If you use only `M-x' to invoke commands then yes, I can
see why you might regard it as too blunt a hammer.  Most
users use additional key bindings to invoke commands, not
just `M-x'.

You can use `M-x' for nearly everything, if you are so
inclined (but you still need at least some keys bound to
a command such as `self-insert-command', even just to
enter input for `M-x'.)

[You could be even more ascetic, and limit yourself to only
Icicles key completion - only key `S-TAB'.  That lets you
invoke any command, including character-insertion.
http://www.emacswiki.org/emacs/Icicles_-_Key_Completion#ThreeKeyEmacs]

But why would you, when you can make use of multiple keys?

Your answer is that, in your setup, `M-x' lets you abbreviate
command names radically, and using abbreviated command names
is handier than using multiple keys.  That's to be counted
as one user's interesting preference, but it is hardly a
common one.

> > You should be able to quickly & easily filter `M-x' candidates
> > by pattern matching.  And hopefully you would be able to also
> > filter them with additional conditions/predicates.
> 
> Precisely, I use ido+flx for that, and it works great up to
> some extent (see above).  But ido (and helm, and Icicles, I
> guess) work on command names, which is quite limiting.
> A hack, really.

I can't speak for Helm, but I've already said that Icicles
does _not_ limit you to pattern-matching (for command names
or anything else).  You can filter, on the fly, using
arbitrary predicates.

But the point is not what is available today but where Emacs
could head.  Instead of what is currently being proposed,
I'd sooner see making it easy for _users_ to be able to
filter powerfully and flexibly.  And no, I'm not talking
only about matching candidate names.

> > Lifting such decisions to the earliest possible stage, code
> > time, is going backward.  Let's concentrate, instead, on
> > giving users _more_, not less, control over the set of
> > completion candidates.
> >
> > Let's help users filter more powerfully, instead of
> > hard-coding what we think is the right filtering them.
> > Let users decide.
> 
> You are misunderstanding the whole issue. Annotating the commands gives
> more information, hence more power, to the users. It is up to them to
> how to use that information. Emacs will provide the necessary
> infrastructure to filter commands on that annotations, but that's all.

I'll be glad to find that I have misunderstood, but so far
I don't think so.  If the only change is to "annotate"
existing functions (and why stop with just commands?) with
additional information about contexts where Emacs Dev thinks
their invocation might be especially useful, I have nothing
against that.

But note the qualifiers: "might be especially useful".
This can only be a code-time developer guess, at best.

That's a far cry from making `M-x' obey such annotations,
treating them as restrictions: hard, predefined filtering.

And I do think I understand the current proposal when I
think that it is about predefined `M-x' filtering, and
not just annotating functions with suggestive context info.

> > You cannot (should not) assume that the only appropriate
> > user context for `M-x' is the current major mode (or
> > that mode plus the current minor modes).
> 
> Again, nobody said or implied what you say above. You are making that
> up. Please try to understand what we are discussing here before wasting
> your energies fighting something that does not exist. Same for the rest
> of your message starting on that paragraph.

We disagree.  It seems pretty clear to me that the proposal
is about `M-x' filtering, not just about annotating functions
with suggested context information.

But it also seems clear that the proposal is, so far, quite
vague.

Just what kind of annotation and how it will be specified
(associated with commands), and what kind of `M-x'
filtering and how it will (or won't) be controlled by users -
such things have not been specified clearly, if at all.