From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Enabling a globalized-minor-mode by default Date: Fri, 11 Sep 2020 11:03:10 -0400 Message-ID: References: <87pn6tmoti.fsf@gmail.com> <87ft7olm6c.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12909"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Cancel-Lock: sha1:RT0mjov00ND7Ga+Fp5So+rI3Z1M= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 11 17:04:18 2020 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kGkb3-0003G6-El for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 11 Sep 2020 17:04:17 +0200 Original-Received: from localhost ([::1]:52584 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kGkb1-0004st-5T for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 11 Sep 2020 11:04:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGkaA-0004qu-HN for help-gnu-emacs@gnu.org; Fri, 11 Sep 2020 11:03:22 -0400 Original-Received: from static.214.254.202.116.clients.your-server.de ([116.202.254.214]:34594 helo=ciao.gmane.io) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kGka8-0001PS-TY for help-gnu-emacs@gnu.org; Fri, 11 Sep 2020 11:03:22 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kGka5-0001yI-17 for help-gnu-emacs@gnu.org; Fri, 11 Sep 2020 17:03:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Received-SPF: pass client-ip=116.202.254.214; envelope-from=geh-help-gnu-emacs@m.gmane-mx.org; helo=ciao.gmane.io X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/11 11:03:17 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:124019 Archived-At: >> 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