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

[Dmitry Gutov <dgutov@yandex.ru>]

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?