Re: Enabling a globalized-minor-mode by default

["Kévin Le Gouguec" <kevin.legouguec@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> 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?


> [ 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"?


>> Is that bad form somehow, or is that the way to go?
>
> Yup.

M-x spit-take


>> Admittedly, maybe forcing a globalized minor mode on users by default is
>> bad form.  For context, I am trying to make magit-file-mode work
>> out-of-the-box, i.e. without users having to (1) (require 'anything) in
>> their config or (2) customize global-magit-file-mode to t explicitly,
>> which should be redundant because this is the default value.
>
> `require` is definitely not needed here.

(Right; I actually started this whole "crusade" after seeing you argue
that a .emacs should not require anything[1][2][3]).


> 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, but I'm pretty sure that would score way too high on some
twisted bad-taste private-joke form of bingo, and it's not a game I care
to play ;o)


[1] https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg00947.html
    emacs-devel <jwvh7xjchxv.fsf&#45;monnier+emacs@gnu.org>

[2] https://gitter.im/magit/magit?at=5ea154f561a0002f7943209e

[3] https://gitter.im/magit/magit?at=5eac311a9f0c955d7d9a89b9