Re: Enabling a globalized-minor-mode by default

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> Loading an ELisp file should not affect the visible behavior of Emacs,
>> so according to that principle a global mode that's pre-enabled should
>> only ever exist if it's bundled with Emacs.
>> For the same kind of reasons merely installing a package should not
>> affect the visible behavior of Emacs.
> OK.  I see that "(elisp) Defining Minor Modes" indeed says that
> define-minor-mode's INIT-VALUE should be nil under "most" circumstances.
> Nothing in the docstring suggests that though AFAICT; maybe it would be
> worth hinting at this?

I guess the docstring is so long already that adding a couple more lines
couldn't hurt, but really it's just a general principle, not specific to
minor modes.

Would the patch below help?

    diff --git a/lisp/emacs-lisp/easy-mmode.el b/lisp/emacs-lisp/easy-mmode.el
    index e3eb9294ed..1cde808e7a 100644
    --- a/lisp/emacs-lisp/easy-mmode.el
    +++ b/lisp/emacs-lisp/easy-mmode.el
    @@ -137,6 +137,10 @@ define-minor-mode
     usage of the mode argument.
     
     Optional INIT-VALUE is the initial value of the mode's variable.
    +  Note that the minor mode function won't be called by setting
    +  this option, so the value *reflects* the minor mode's natural
    +  initial state, rather than *setting* it.
    +  In the vast majority of cases it should be nil.
     Optional LIGHTER is displayed in the mode line when the mode is on.
     Optional KEYMAP is the default keymap bound to the mode keymap.
       If non-nil, it should be a variable name (whose value is a keymap),

>> [ And yes "affect the visible behavior" is not well defined, or at least
>>   it needs to be tempered by some tolerated exceptions.  For example,
>>   it's considered normal for a package to add itself (via its autoloads)
>>   to `auto-mode-alist`, which does have a visible impact on Emacs's
>>   behavior.  ]
>
> Interesting!  I see "(elisp) Major Mode Conventions" and "(elisp)
> Packaging Basics" both mention this use-case; would it make sense to add
> this "acceptable use" (and maybe others, if they exist) to "(elisp) When
> to Autoload"?

Hmm... I'm not sure it fits in there (this section is currently
perfectly applicable to packages bundled with Emacs, which is
a different situation since those *can* enable a minor mode this way
(after going through the corresponding years of negotiation to get
people to reluctantly agree to the default behavior ;-) )

Maybe we need some reorganisation or a new Node.

>>> Is that bad form somehow, or is that the way to go?
>> Yup.
> M-x spit-take

[No match]

¡Ha!

>> Only `(global-magit-file-mode 1)` needs to be added to the init file
>> (or do the equivalent via Customize) and it shouldn't be redundant
>> because t shouldn't be the default value ;-)
> Got it.  I would joke and say that this will all be solved when (1) we
> get Magit into GNU ELPA and (2) we implement bundling GNU ELPA packages
> into Emacs,

(1) seems a bit difficult for now, but we should get (½) pretty soon
(i.e. Magit seems like one of the main candidates for the new NonGNU ELPA).

(2) is not terribly hard to do (there's some proof of concept code for
it already) and there's a general interest to make it happen, so we may
get lucky and get that in Emacs-28 (after I miserably failed to make it
happen for Emacs-25 :-( ).

Maybe we could then wait for (2½) where Emacs bundles some NonGNU ELPA
packages as well.  This involves a delicate political decision, so don't
hold your breath!


        Stefan