Re: Making `interactive' conditional

[Óscar Fuentes]

Drew Adams <address@hidden> writes:

[snip]

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

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

[snip]

> 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. That's something
decided by the developer, right? Overriding checks that throws errors as
something beyond the reach of the ordinary user, overriding the M-x
filter is one customization change away (in case it was active, to begin
with). So I don't understand what you are worried about.

> 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? If the user expects to see the command, he can use C-h f
to check its docstring and learn about its restrictions.

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

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.

> 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. Operating solely on
the command names (prefixes that match mode names, etc) are hacks that
work on arbitrary premises.

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

But what me (and Lars, and most people here, AFAIU) are proposing is,
precisely, making possible to filter M-x candidates!

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.

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

By the developer, of course. The same person who wrote the command and
knows how and when it is correct to use it.

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

I'm not interested on seeing thousands of commands, not. I use M-x to
find a command on the provided list. If the list contains many commands,
it will be more difficult to find your command, no matter how smart is
your completion method. The fact that the set of available commands
grows with time, as more and more packages are `require'd by your Emacs
session, makes things worse.

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

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.

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

[snip]

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

Sorry for not commenting on the rest of your message. I'm bit busy now.
But this:

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

[snit]