Re: Making `interactive' conditional

["Óscar Fuentes" <ofv@wanadoo.es>]

Alan Mackenzie <acm@muc.de> writes:

>> OK Yuri, now you've got me excited. Let's not talk about "filtering M-x";
>> let's talk about making `interactive' conditional. The former is a UI concern,
>> while the latter I consider a core API issue.
>
> What you're proposing is exactly "filtering M-x"; censoring it, if you
> will; a sort of "not in front of the children" attitude that restricts
> what you can see by somebody else's criteria.  I think most people on
> this list would be opposed to censorship in most areas (for example,
> national authorities deciding what part of the WWW is suitable for
> browsing).  Yet, here we are, talking about introducing the same sort of
> thing into Emacs.

The amount of drama an hyperbole in emacs-devel never ceases to surpass
my expectations. On any other place I would read your commentary as
tongue-in-cheek, but not in emacs-devel, I'm afraid... :-)

> 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. M-x is for *executing* commands,
not for learning about them (unless your learning method consists on
executing commands you don't know about). 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.

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.

[snip]

> _ANY_ form of censorship must be optional, and not merely up to the
> point where some authority decides it's acceptable to impose on the
> masses.

To be on the safe side, I propose that we involve the EFF, Amnesty
International, Reporters Without Borders and the Council of Europe,
among others, as overseers of this process.

>> Thus, proper UI behavior for M-x falls out by design, and we get to make use
>> of conditionality for other purposes, such as better errors when command
>> functions are called outside their expected environment.
>
> Any chance of an example of such an improvement?  How are we to improve
> on, for example, "Can't execute - not in Foo mode"?
>
>> I'm open to a feature branch implementing such conditionality, as a candidate
>> for merging to master. As described above, I expect the C code impact to be
>> fairly minimal, and the changes to `M-x' to also be minor. The automation
>> logic seems like the trickiest part, as it would have to happen whenever a
>> feature is loaded.
>
> 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? Some of
those commands can cause undesirable effects if you invoke them by
accident, I experienced that as a beginner and is very confusing.

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?

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?