emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Leaving out non-applicable commands on Mx


From: Óscar Fuentes
Subject: Re: Leaving out non-applicable commands on Mx
Date: Sat, 09 Jan 2016 03:15:14 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

John Wiegley <address@hidden> writes:

>>>>>> Óscar Fuentes <address@hidden> writes:
>
>> On the M-x prompt, the set of candidates is restricted to those that make
>> sense given the current context. Leaving out functions that are specific to
>> modes not enabled is a start. So if you are editing a C file and press `M-x
>> g' almost all gnus* functions shall not be considered as candidates for
>> completion.
>
> This sounds like a feature that should evolve first as a separate package in
> ELPA, and after proving itself, be considered for core. But I sense ways in
> which this could go wrong: expecting to find a command, failing for some
> undiscovered reason X, and then the user believing no such command exists.

This could ony happen if there is a mistake on how that command is
declared. A bug like any other.

>> The M-x interface can be an improvement over both keybindings and the menu
>> on terms of usability, given the correct methods, but having thousands of
>> irrelevant candidates every time you invoke M-x is an inconvenience for that
>> goal, not to say plain dumb.
>
> Core Emacs behavior doesn't need to change to demonstrate this feature, does
> it? Write a new execute-extended-command and see if it works as well as you
> hope.

It is necessary to annotate the functions with the context they are
suppossed to work on. Something like

(defun foo-something ()
  "docstring"
  (interactive)
  (declare this-applies-to-foo-mode)
  ...)

Doing that for every function is unnecessary work, so a method for
saying "all the functions defined on this .el file apply to foo-mode,
except foo-bar and foo-zoo" is a sensible enhancement. (We also could
exploit the fact that we know wich functions are autoladed. Most
autoloaded functions are context-free, while the non-autoloaded
functions on the same file are context-specific).

Maintaining all this information on an external resource is
unmanageable, it simply wont work. So yes, the Elisp source files need
to be annotated (that's the work I'm volunteering for).

For reading the annotations (and, possibly, for performance reasons,
applying the filter) modifications are required on some Emacs
infrastructure. From past discussion it seems that those modifications
are expected to be small, though.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]