RE: Making `interactive' conditional

[Drew Adams]

> > This might be OK if the only reason you every use M-x is to execute a
> > command.  But it's not.  People (in particular, me) use it to discover
> > Emacs, to find the exact name of a command which has only vaguely
> > embedded itself in the memory, to get this name into the kill ring to be
> > yanked into another source file or into documentation, and so on.  Try
> > M-x <tab> <prior> sometime, and explore the wealth of Emacs commands.
> > :-)
> 
> The current implementation of M-x is, possibly, the worst way of
> exploring the wealth of Emacs commands.

I disagree strongly.  With good ways to match, and especially
with the ability to narrow (e.g. what is provided by Icicles
and Helm, and possibly other completion contexts), it is far
better, not worse, than `apropos-command' - for example.

Interactive, incremental, on-demand help of different degrees.
It is a fantastic tool for _discovery_ - another
Emacs-needs-better theme that has been brought up recently.

> 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.

Don't you ever use `C-h f' or `C-h v' to discover/explore
(even for spelling information)?

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?

I hope not.  I would hope that you see the point of
showing a user all of the function names that match the
current input.

> C-h f, the fine manual or,
> better, browsing the sources is what I would do (and have done) for
> exploring what Emacs has to offer.

See above.  If it is such a great idea to let Emacs Dev
predetermine which commands are appropriate for the current
`M-x' context, then why limit this great feature to `M-x'?
Surely `C-h f' and `C-h v' and ... can be enhanced the same
way?

Even thinking that Emacs Dev can specify what constitutes
"the current context" for a given user is presumptuous.
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.

Let's not be so presumptuous.  Instead, if we provide
guesses to try to help, let a user choose our guesses,
instead of imposing them.  And even more importantly, let
users ignore our brilliant guesses and decide for
themselves what they consider the "current context" to be.

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_.

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.

> Besides, if you insist on using M-x for learning about new commands, I
> suppose that having only those that apply to your current context is
> helpful, to say the least.

Sure.  But WHO decides just what the "current context" means,
and when?  Is it the currently invoked command that is reading
your input that decides?  Can the user decide, interactively?

Or is it some Emacs maintainer who goes over all of the commands
in a wholesale fashion, applying some simplistic rule ahead of
time, prior to even distributing Emacs to users?

No one has spoken against being able to filter `M-x' candidates
to fit the user's current context.

[Please read that again, if it's not clear.]

The question is how what constitutes the "current context" is
determined/decided, and by whom, and when.

> > Again, what is this feature for?  Is it going to make editing easier for
> > experienced users?  Is it really going to attract new users, ones who
> > would be very happy in Emacs but for the huge number of commands
> > presented to them in an M-x?
> 
> How user-friendly is to type M-x and be offered with thousands of
> commands that have zero relation to the task you are performing?

If that's what you're doing then I submit that maybe you are
not using `M-x' as well as you might.  (Unless for some reason
you want to see those thousands.)

[And aside from considering `M-x' for this, I would hope that
you would have something more specific than just `M-x' to use,
to help you carry out the "task you are performing".  If you
are using `M-x' only to invoke commands, and you are using
only or mainly `M-x' to invoke commands, then something is
missing.]

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.

But YOU should be able to do that, together with the invoked
command (`M-x' in this case, which already filters using
`commandp') - not just some hard-coded filtering done at
code time.

_Late binding_ is a user's friend, especially for a user of
an interactive, self-documenting, and extensible environment
such as Emacs.

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.

> Some of those commands can cause undesirable effects if you
> invoke them by accident,

Too vague.  If so, then fix those particular commands.
Make sure that the commands themselves take care of the
context in which they are invoked.

Let's not try to solve _that_ problem using a
one-size-fits-all, abstract, general rule, applied at
code time to a huge code base.

> I experienced that as a beginner and is very confusing.

When that happens, file a bug report so we can fix that
command.  Such a problem is particular to _that_ command
and should be fixed in a way that is appropriat to _it_.

> Talking about discoverability and your M-x learning method, if I'm
> interested on learning what can I do while editing a C file, how does
> help me having to skim over thousands upon thousands of unrelated
> commands that only make sense for their respective modes?

No one is arguing that you should need to scan thousands
of unrelated commands.  The question is _how_ to determine
which commands _you_ want to see in the _current context_.

That question needs to be answered with finesse, not just
using a sledge hammer.  And the best way to start answering
it is to give _you_, the user, great ways to filter
interactively.

_You_ should decide just how you see the current context,
what you see it to be.  Emacs should not be second-guessing
you about that.

There are many users and many use cases for something
even as simple as `M-x'.  Do not presume to guess what
is good for everyone.

> Why we hide the menus of the modes that are not active for the current
> buffer? Why we have local keymaps? Where were you at the time those
> repressing features were imposed on the masses?

Modes and buffers and such are useful ways to categorize
or define contexts.  And there are others.  We could do
with some more (IMO).  (Common Lisp "packages", i.e.,
namespaces is one.)

But looking for ways to precisely specify a context is
_opposite_ to what is being proposed here.  What is being
proposed here is to _interpret_ the absence of a context
specification as a particular context, ahead of time.

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).

`M-x' is completely general, and it should remain so.

Nothing prevents a mode or library from defining a
different command that reads command names and invokes
one that is chosen by the user, and that imposes a
particular interpretation of the current context, i.e.,
provides only certain command names as candidates.

That's exactly what's called for - not breaking the
legs off of `M-x' to make it fit some rigid mold.