[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27639: 25.2; Fix syntax for minor mode enabling in dir locals in man
bug#27639: 25.2; Fix syntax for minor mode enabling in dir locals in manual
Tue, 11 Jul 2017 20:32:22 +0300
> From: Kaushal Modi <address@hidden>
> Date: Tue, 11 Jul 2017 16:57:32 +0000
> Cc: address@hidden
> indent-tabs-mode is the mode variable, so setting it to t is not a
> The mistake (as explained in the Reddit post) was setting a 'custom-mode' to
> t and expecting that that would
> rightaway enable that 'custom-mode' minor mode.
There's no variable by that name, so it's little surprise that it
> But why do you think we should only advertise one method, but not the
> From (emacs) Minor Modes
> Most minor modes also have a "mode variable", with the same name as
> the mode command. Its value is non-‘nil’ if the mode is enabled, and
> ‘nil’ if it is disabled. In general, you should not try to enable or
> disable the mode by changing the value of the mode variable directly in
> Lisp; you should run the mode command instead.
That's unrelated to file-local variables, IMO.
> In any case, as a user, I find it clearer to understand that you must never
> enable minor modes by just setting
> their var; you should call that minor mode fn instead.
And I object to the "never" part. This is Emacs: we should teach
users to know and understand what they are doing, not follow recipes
prepared by others like a kind of cookbook. If the mode variable is a
simple variable, and setting it is all that it takes to turn on or off
the mode, why should we tell users it's wrong?
> Also, if a user uses the (mode . minor) convention instead of (minor-mode .
> t), they do not have to worry
> about declaring them safe.
Let them find that out by themselves, and see if they care. Who
knows, we might even find a few bugs that way -- perhaps some mode
variable should have a safe-local-variable property that we failed to
IOW, I think it's wrong to try to save users from themselves. We
should provide clear documentation which explains the pros and cons,
and then let the users decide based on knowledge, not on blindly
following advice that makes some of the methods "magic".
OK, that's my opinion. What do others think?