[Top][All Lists]

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

Re: [PATCH] font-core: add font-lock-{enable, disable}-global-for functi

From: Dmitry Gutov
Subject: Re: [PATCH] font-core: add font-lock-{enable, disable}-global-for functions
Date: Mon, 05 Jan 2015 01:07:30 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Thunderbird/33.0

On 01/04/2015 10:42 PM, Stefan Monnier wrote:

But the redundancy is rather problematic

As long as one is for `customize-variable' and the other for elisp, I think it's good enough.

> not to mention the fact that
the semantics is unclear (e.g. how does it interact with derived modes?
How does it interact with explicit calls in the mode hook? ...).

Right, these two aspects are not 100% transparent to a common user. Improving on either would be hard, though, if we want the derived modes sometimes to be affected (if we don't, that can just be documented).

Maybe we should provide something like M-x customize-minor-mode-states RET
which would collect the presence/absence of `foo-mode' or `(lambda ()
(foo-mode N))' in all the hooks and let the user add/remove them from
those hooks.

That might be handy.

But that wouldn't solve the "derived modes problem" any better than a docstring would (if it would, how?).

And scanning hooks for enabled/disabled modes would be necessarily imprecise: even if we take care of the three main variations (`foo-mode', (lambda () (foo-mode 1)), (lambda () (foo-mode -1))), that still leaves out random functions (lambdas or named) that include a `foo-mode' call among other code, that a more advanced user could have in their init file, or some yet-another package might include in their "initialize me" function.

If a function has been compiled, can we even scan its body for `foo-mode' calls?

reply via email to

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