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: Stefan Monnier
Subject: Re: Leaving out non-applicable commands on Mx
Date: Fri, 08 Jan 2016 23:14:14 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

> 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

This is the crucial part, indeed.

> Maintaining all this information on an external resource is
> unmanageable, it simply wont work.

It's better if it's managed directly in the packages's sources, indeed,
but it will still work if the info is only available for some packages,
and for many packages, this info could be managed externally with fairly
little harm.

So while I agree that the right way to do it is "in core", I think it'd
still be useful if packaged as a GNU ELPA package (or a bundled package
but fully self-contained).

Also, the new package could provide some function/macro which core
packages may use conditionally.  E.g. Gnus could "declare its
mode-specific commands" using this new macro/function (if/when defined),
so that it provides support for the "filtering-m-x" package.

> So yes, the Elisp source files need to be annotated (that's the work
> I'm volunteering for).

An important part of this work is on the design of the "annotation
system" so that it's lightweight.

E.g. ideally, this same annotation system should be able to wrap the
corresponding commands so that they signal an error if you happen to
trigger them in the wrong mode (currently many commands do such a check
by hand, so the annotation system could *replace* this manual test).
Being "able to" doesn't mean that it should necessarily do so, just that
the design would probably be better if it took into account such
related-but-slightly-different use-cases.


        Stefan




reply via email to

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