GNU bug report logs - #38843
define-globalized-minor-mode enable boolean will prevent loading with :require

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 38843 in the body.
You can then email your comments to 38843 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Paul W. Rankin" <hello <at> paulwrankin.com>
To: bug-gnu-emacs <at> gnu.org
Subject: define-globalized-minor-mode enable boolean will prevent loading
 with :require
Date: Wed, 01 Jan 2020 17:10:19 +1000

When defining a global minor mode with define-globalized-minor-mode, an
automatic custom option is created to enable that minor mode. If the
user wishes to enable this global minor mode at startup, he/she toggles
this boolean to "on" and saves his/her init. This should enable the
global minor mode upon startup (if available).

If a global minor modes is based on local minor modes, it may use a
:require keyword in the global minor mode definition, e.g. from
page-break-lines:

    ;;;###autoload
    (define-global-minor-mode global-page-break-lines-mode
      page-break-lines-mode page-break-lines-mode-maybe
      :require 'page-break-lines
      :group 'page-break-lines)

Toggling the option global-page-break-lines-mode in this case will add
the following to the user's init:

    '(global-page-break-lines-mode t nil (page-break-lines))

The problem occurs when page-break-lines is for whatever reason
unavailable, it will prevent Emacs from loading.

The customize system is designed not to prevent loading even when
libraries are unavailable, e.g.settings remain after uninstalling the
associated program/library because it makes sense if the user chooses to
reinstall. That is, the presence of settings pertaining to unavailable
programs/libraries should not prevent Emacs from loading.

So, what is the solution here? This feels to me like a bug with the way
define-globalized-minor-mode saves this boolean...

Message #8 received at 38843 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Paul W. Rankin" <hello <at> paulwrankin.com>
Cc: 38843 <at> debbugs.gnu.org
Subject: Re: bug#38843: define-globalized-minor-mode enable boolean will
 prevent loading with :require
Date: Fri, 30 Oct 2020 15:49:20 +0100

"Paul W. Rankin" <hello <at> paulwrankin.com> writes:

> If a global minor modes is based on local minor modes, it may use a
> :require keyword in the global minor mode definition, e.g. from
> page-break-lines:
>
>     ;;;###autoload
>     (define-global-minor-mode global-page-break-lines-mode
>       page-break-lines-mode page-break-lines-mode-maybe
>       :require 'page-break-lines
>       :group 'page-break-lines)
>
> Toggling the option global-page-break-lines-mode in this case will add
> the following to the user's init:
>
>     '(global-page-break-lines-mode t nil (page-break-lines))
>
> The problem occurs when page-break-lines is for whatever reason
> unavailable, it will prevent Emacs from loading.

So the problem is basically that you've switched a minor mode on via
Customize, but then deleted the minor mode.  I'm actually not sure
whether it makes sense for Emacs to signal an error or not here: You've
asked to have a mode switched on, but then Emacs can't do that because
it can't find the file it's defined in.

So this is, in some ways, no different from having a `require' in your
.emacs that no longer exists.

On the other hand, it's a bit unfriendly, and doing the same with other
mode variables doesn't bug out.  The following patch fixes the problem.

Does anybody have an opinion here?

diff --git a/lisp/custom.el b/lisp/custom.el
index cc445fe765..94c36dedd9 100644
--- a/lisp/custom.el
+++ b/lisp/custom.el
@@ -1010,7 +1010,9 @@ custom-theme-set-variables
 	       set)
 	  (when requests
 	    (put symbol 'custom-requests requests)
-            (mapc #'require requests))
+            (mapc (lambda (lib) (ignore-error file-missing
+                                  (require lib)))
+                  requests))
           (setq set (or (get symbol 'custom-set) #'custom-set-default))
 	  (put symbol 'saved-value (list value))
 	  (put symbol 'saved-variable-comment comment)


-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 38843 <at> debbugs.gnu.org (full text, mbox):

From: "Paul W. Rankin" <hello <at> paulwrankin.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 38843 <at> debbugs.gnu.org
Subject: Re: bug#38843: define-globalized-minor-mode enable boolean will
 prevent loading with :require
Date: Sat, 31 Oct 2020 01:25:47 +1000

> On 31 Oct 2020, at 12:49 am, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> 
> So the problem is basically that you've switched a minor mode on via
> Customize, but then deleted the minor mode.  I'm actually not sure
> whether it makes sense for Emacs to signal an error or not here: You've
> asked to have a mode switched on, but then Emacs can't do that because
> it can't find the file it's defined in.

The customize system is designed not to prevent loading even when libraries aren't found, e.g. settings persist after uninstalling their library, because it makes sense that if the user then chooses to reinstall they get to keep their settings. The counter option is that uninstalling a package removes that packages settings, forcing the user to go through and set them all again.

The separation of settings and source is a good thing, and ought not to trip Emacs over. The absence of the source should not matter a wink to the settings.

Message #14 received at 38843 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Paul W. Rankin" <hello <at> paulwrankin.com>
Cc: 38843 <at> debbugs.gnu.org
Subject: Re: bug#38843: define-globalized-minor-mode enable boolean will
 prevent loading with :require
Date: Sun, 01 Nov 2020 13:16:36 +0100

"Paul W. Rankin" <hello <at> paulwrankin.com> writes:

> The separation of settings and source is a good thing, and ought not
> to trip Emacs over. The absence of the source should not matter a wink
> to the settings.

Well, I'm still not 100% sure -- I don't see it as a clear a separation
as that, but I've gone ahead and made this not signal an error in Emacs
28.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.