bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Ihor Radchenko]

Steps to reproduce:

1. ./src/emacs -Q --batch -l ~/Downloads/dump.el 
With dump.el:

(dump-emacs-portable "/tmp/emacs-dumped.dmp")

2. ./src/emacs -Q --dump-file="/tmp/emacs-dumped.dmp"

3. C-<SPC> C-p C-p

Expected: active region is highlighted
Observed: Transient mark mode is not enabled and thus active region is
          not highlighted.

Configured using:
 'configure --with-native-compilation CFLAGS=-g3 --with-pdumper=yes'

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Gerd Möllmann]

Ihor Radchenko <yantar92@posteo.net> writes:

> Steps to reproduce:
>
> 1. ./src/emacs -Q --batch -l ~/Downloads/dump.el 
> With dump.el:
>
> (dump-emacs-portable "/tmp/emacs-dumped.dmp")
>
> 2. ./src/emacs -Q --dump-file="/tmp/emacs-dumped.dmp"
>
> 3. C-<SPC> C-p C-p
>
> Expected: active region is highlighted
> Observed: Transient mark mode is not enabled and thus active region is
>           not highlighted.

Just an analyis.

AFAICS, this one comes from a special handling of some custom variables.
In function command-line, we have

  ;; Re-evaluate predefined variables whose initial value depends on
  ;; the runtime context.  But delay the warning about
  ;; `user-emacs-directory' being inaccessible until after processing
  ;; the init file and the command-line arguments, in case the user
  ;; customized `user-emacs-directory-warning' to nil via those.
  (let ((user-emacs-directory-warning nil))
    (when (listp custom-delayed-init-variables)
      (mapc #'custom-reevaluate-setting
            ;; Initialize them in the same order they were loaded, in
            ;; case there are dependencies between them.
            (reverse custom-delayed-init-variables))))
  (setq custom-delayed-init-variables t)

The list of custom-delayed-init-variables is built by function
custom-initialize-delay. If you grep for that, you'll finds a number of
declarations containing an :initialize with the delaying function.

In a re-dumped Emacs, the variable is not a list, so nothing is done. In
the particular case of transient-mark-mode, the default value, which is
set in C, is nil, so it keeps that value.

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Ihor Radchenko]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> The list of custom-delayed-init-variables is built by function
> custom-initialize-delay. If you grep for that, you'll finds a number of
> declarations containing an :initialize with the delaying function.
>
> In a re-dumped Emacs, the variable is not a list, so nothing is done. In
> the particular case of transient-mark-mode, the default value, which is
> set in C, is nil, so it keeps that value.

Thanks for the analysis.
I dag a bit further and it looks like :initialize is used in
`define-minor-mode' and `defcustom' with the latter simply deferring
:initialize keyword processing to `defcustom'.

The :initialize keyword in `defcustom' is implicitly assumed to be
evaluated during Emacs startup, in the Emacs sessions that will use the
custom definition.

Actually, I think that I will not be wrong to say that (defvar foo
<value>. ..), (defcustom foo <value> ...), and similar expressions are
often assumed to evaluated in the same Emacs session that will use the
library. For example, Org mode often calculated default variable values
dynamically:

(defcustom org-clock-x11idle-program-name
  (if (executable-find "xprintidle")
      "xprintidle" "x11idle")
...)

Re-dumping such code is prone to subtle bugs when the dumping
environment differs from the runtime.

Things get worse when loading a library relies on side effects:

----- org-persist.el ---------
;; Point to temp directory when `org-persist--disable-when-emacs-Q' is set.
(when (and org-persist--disable-when-emacs-Q
           ;; FIXME: This is relying on undocumented fact that
           ;; Emacs sets `user-init-file' to nil when loaded with
           ;; "-Q" argument.
           (not user-init-file))
  (setq org-persist-directory
        (make-temp-file "org-persist-" 'dir)))
----------------------------

I suspect that it is only truly safe to re-dump parts of the libraries
that do not emit (byte-code ...) in the compiler output.

For example, the following is .elc part corresponding to the above
defcustom:

(defvar org-x11idle-exists-p (byte-code "\b\302>?\205%17\303\304\305	\"!\306=\205%17\303	!\306=\207" [system-type org-clock-x11idle-program-name (windows-nt ms-dos) call-process-shell-command format "command -v %s" 0] 4))#@46 Return the current X11 idle time in seconds.\x1f

The variable itself can be defined, but its value is (byte-code ...) and
thus should be evaluated during startup, and not dumped.

And the side-effect clause is a complete (byte-code ...):

(byte-code "\b\203%d	\204%d\303\304\305\"%12\306\307\n!!\310%1!\204%%0\211\306\311%3!!\211\262%3\232\203%12\312%1!\2044%0\313\314\n\"\266%2\202D%0\315\316\317\"\210\315\316\320\"\210\315\316\321\"\266%2\315\322\323\"\210\324\325!\207" [org-persist--disable-when-emacs-Q user-init-file org-persist-directory make-temp-file "org-persist-" dir directory-file-name file-name-as-directory file-exists-p file-name-directory file-writable-p message "Missing write access rights to org-persist-directory: %S" add-hook kill-emacs-hook org-persist-clear-storage-maybe org-persist-write-all org-persist-gc after-init-hook org-persist-load-all provide org-persist] 5)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Eli Zaretskii]

> Cc: 66742@debbugs.gnu.org
> From: Ihor Radchenko <yantar92@posteo.net>
> Date: Thu, 26 Oct 2023 11:42:57 +0000
> 
> Actually, I think that I will not be wrong to say that (defvar foo
> <value>. ..), (defcustom foo <value> ...), and similar expressions are
> often assumed to evaluated in the same Emacs session that will use the
> library.

There should be no such assumption, and so you will be wrong saying
that.  We actually try paying attention to this aspect when reviewing
patches where a defcustom has a default value that is not a constant,
precisely for this reason.

> For example, Org mode often calculated default variable values
> dynamically:
> 
> (defcustom org-clock-x11idle-program-name
>   (if (executable-find "xprintidle")
>       "xprintidle" "x11idle")
> ...)

That's a bug in Org, unless the rest of the code doesn't arrange for
this defcustom to be re-evaluated at startup.

> Things get worse when loading a library relies on side effects:
> 
> ----- org-persist.el ---------
> ;; Point to temp directory when `org-persist--disable-when-emacs-Q' is set.
> (when (and org-persist--disable-when-emacs-Q
>            ;; FIXME: This is relying on undocumented fact that
>            ;; Emacs sets `user-init-file' to nil when loaded with
>            ;; "-Q" argument.
>            (not user-init-file))
>   (setq org-persist-directory
>         (make-temp-file "org-persist-" 'dir)))
> ----------------------------

Which library does the above load, and how is it related to something
determined at dump time?

> I suspect that it is only truly safe to re-dump parts of the libraries
> that do not emit (byte-code ...) in the compiler output.
> 
> For example, the following is .elc part corresponding to the above
> defcustom:
> 
> (defvar org-x11idle-exists-p (byte-code "\b\302>?\205%17\303\304\305	\"!\306=\205%17\303	!\306=\207" [system-type org-clock-x11idle-program-name (windows-nt ms-dos) call-process-shell-command format "command -v %s" 0] 4))#@46 Return the current X11 idle time in seconds.\x1f
> 
> The variable itself can be defined, but its value is (byte-code ...) and
> thus should be evaluated during startup, and not dumped.
> 
> And the side-effect clause is a complete (byte-code ...):
> 
> (byte-code "\b\203%d	\204%d\303\304\305\"%12\306\307\n!!\310%1!\204%%0\211\306\311%3!!\211\262%3\232\203%12\312%1!\2044%0\313\314\n\"\266%2\202D%0\315\316\317\"\210\315\316\320\"\210\315\316\321\"\266%2\315\322\323\"\210\324\325!\207" [org-persist--disable-when-emacs-Q user-init-file org-persist-directory make-temp-file "org-persist-" dir directory-file-name file-name-as-directory file-exists-p file-name-directory file-writable-p message "Missing write access rights to org-persist-directory: %S" add-hook kill-emacs-hook org-persist-clear-storage-maybe org-persist-write-all org-persist-gc after-init-hook org-persist-load-all provide org-persist] 5)

You lost me here.

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Actually, I think that I will not be wrong to say that (defvar foo
>> <value>. ..), (defcustom foo <value> ...), and similar expressions are
>> often assumed to evaluated in the same Emacs session that will use the
>> library.
>
> There should be no such assumption, and so you will be wrong saying
> that.  We actually try paying attention to this aspect when reviewing
> patches where a defcustom has a default value that is not a constant,
> precisely for this reason.

This is a surprise to me!
Is it documented anywhere? I thought that we should expect the value to
be evaluated unless explicitly wrapped into (eval-when-compile ...).

Also, I just looked up defvar instances across Emacs and I am seeing
multiple cases when the value is calculated dynamically, assuming
loading time:

cvs-diff-program, diff-use-changed-face, url-mime-encoding-string,
url-dav-lock-identifier, type-break-time-last-command,
reftex-section-numbers, ispell-library-directory, artist-pointer-shape,
so-long-version, shadow-system-name, bdf-cache-file,
vhdl-mode-menu-list, sh-shell, js-js-tmpdir, gud-sdb-needs-tags,
tetris-next-x, tetris-score-y, <a number of Org mode variables>,
vip-startup-file, vi-scroll-amount, tramp-cache-read-persistent-data,
tramp-archive-enabled, socks-username, newsticker--latest-update-time,
dictionary-color-support, mh-uncompface-executable, mh-swish++-binary,
mh-swish-binary, mh-mairix-binary, mh-namazu-binary, mh-grep-binary,
mh-spamassassin-executable, mh-sa-learn-executable,
mh-bogofilter-executable, mh-spamprobe-executable, mh-pgp-support-flag,
kkc-init-file-name, image-dired-queue-active-limit,
mm-temp-files-cache-file, erc-autoaway-last-sent-time,
viper-custom-file-name, viper-current-frame-saved,
copyright-current-year, cl--random-state (!!! that can easily cause
subtle issues), dframe-have-timer-flag, todo-files, todo-archives,
todo-done-separator, diary-font-lock-keywords, math-expr-opers,
calc-gnuplot-display, archive-7z-program.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, 66742@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 12:44:37 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Actually, I think that I will not be wrong to say that (defvar foo
> >> <value>. ..), (defcustom foo <value> ...), and similar expressions are
> >> often assumed to evaluated in the same Emacs session that will use the
> >> library.
> >
> > There should be no such assumption, and so you will be wrong saying
> > that.  We actually try paying attention to this aspect when reviewing
> > patches where a defcustom has a default value that is not a constant,
> > precisely for this reason.
> 
> This is a surprise to me!
> Is it documented anywhere?

What do you want to document?

> I thought that we should expect the value to
> be evaluated unless explicitly wrapped into (eval-when-compile ...).

At what time do you think defcustom's value is evaluated?

> Also, I just looked up defvar instances across Emacs and I am seeing
> multiple cases when the value is calculated dynamically, assuming
> loading time:

Of course, it's loading time.  But AFAIU you were talking about
evaluation during dumping, i.e. when Emacs is built.  This is only
relevant for defcustom's in packages that are preloaded, because those
packages are loaded at build time, not at run time.  So for those
packages, and only for those packages, any defcustom whose default
value is not a constant, should be re-evaluated at startup, to make
sure the value is suitable for the system on which Emacs runs.

> cvs-diff-program, diff-use-changed-face, url-mime-encoding-string,
> url-dav-lock-identifier, type-break-time-last-command,
> reftex-section-numbers, ispell-library-directory, artist-pointer-shape,
> so-long-version, shadow-system-name, bdf-cache-file,
> vhdl-mode-menu-list, sh-shell, js-js-tmpdir, gud-sdb-needs-tags,
> tetris-next-x, tetris-score-y, <a number of Org mode variables>,
> vip-startup-file, vi-scroll-amount, tramp-cache-read-persistent-data,
> tramp-archive-enabled, socks-username, newsticker--latest-update-time,
> dictionary-color-support, mh-uncompface-executable, mh-swish++-binary,
> mh-swish-binary, mh-mairix-binary, mh-namazu-binary, mh-grep-binary,
> mh-spamassassin-executable, mh-sa-learn-executable,
> mh-bogofilter-executable, mh-spamprobe-executable, mh-pgp-support-flag,
> kkc-init-file-name, image-dired-queue-active-limit,
> mm-temp-files-cache-file, erc-autoaway-last-sent-time,
> viper-custom-file-name, viper-current-frame-saved,
> copyright-current-year, cl--random-state (!!! that can easily cause
> subtle issues), dframe-have-timer-flag, todo-files, todo-archives,
> todo-done-separator, diary-font-lock-keywords, math-expr-opers,
> calc-gnuplot-display, archive-7z-program.

This is not relevant, since packages that aren't preloaded will be
loaded at run time, and therefore the values will be evaluated in the
correct context.  If you are talking about these, then I don't
understand what prompted you to raise this issue to begin with, and in
a thread that discusses dumping.

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Eli Zaretskii]

> Cc: gerd.moellmann@gmail.com, 66742@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 16:10:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > I thought that we should expect the value to
> > be evaluated unless explicitly wrapped into (eval-when-compile ...).
> 
> At what time do you think defcustom's value is evaluated?
> 
> > Also, I just looked up defvar instances across Emacs and I am seeing
> > multiple cases when the value is calculated dynamically, assuming
> > loading time:
> 
> Of course, it's loading time.  But AFAIU you were talking about
> evaluation during dumping, i.e. when Emacs is built.  This is only
> relevant for defcustom's in packages that are preloaded, because those
> packages are loaded at build time, not at run time.  So for those
> packages, and only for those packages, any defcustom whose default
> value is not a constant, should be re-evaluated at startup, to make
> sure the value is suitable for the system on which Emacs runs.
> 
> > cvs-diff-program, diff-use-changed-face, url-mime-encoding-string,
> > url-dav-lock-identifier, type-break-time-last-command,
> > reftex-section-numbers, ispell-library-directory, artist-pointer-shape,
> > so-long-version, shadow-system-name, bdf-cache-file,
> > vhdl-mode-menu-list, sh-shell, js-js-tmpdir, gud-sdb-needs-tags,
> > tetris-next-x, tetris-score-y, <a number of Org mode variables>,
> > vip-startup-file, vi-scroll-amount, tramp-cache-read-persistent-data,
> > tramp-archive-enabled, socks-username, newsticker--latest-update-time,
> > dictionary-color-support, mh-uncompface-executable, mh-swish++-binary,
> > mh-swish-binary, mh-mairix-binary, mh-namazu-binary, mh-grep-binary,
> > mh-spamassassin-executable, mh-sa-learn-executable,
> > mh-bogofilter-executable, mh-spamprobe-executable, mh-pgp-support-flag,
> > kkc-init-file-name, image-dired-queue-active-limit,
> > mm-temp-files-cache-file, erc-autoaway-last-sent-time,
> > viper-custom-file-name, viper-current-frame-saved,
> > copyright-current-year, cl--random-state (!!! that can easily cause
> > subtle issues), dframe-have-timer-flag, todo-files, todo-archives,
> > todo-done-separator, diary-font-lock-keywords, math-expr-opers,
> > calc-gnuplot-display, archive-7z-program.
> 
> This is not relevant, since packages that aren't preloaded will be
> loaded at run time, and therefore the values will be evaluated in the
> correct context.  If you are talking about these, then I don't
> understand what prompted you to raise this issue to begin with, and in
> a thread that discusses dumping.

To clarify: a defcustom whose default value is not a constant needs to
be re-evaluated during startup, if we want the dumped Emacs to be able
to run on another system or with different environment than at dump
time.

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> To clarify: a defcustom whose default value is not a constant needs to
> be re-evaluated during startup, if we want the dumped Emacs to be able
> to run on another system or with different environment than at dump
> time.

Is there a facility in place to do such re-evaluation?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, 66742@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 09:04:23 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To clarify: a defcustom whose default value is not a constant needs to
> > be re-evaluated during startup, if we want the dumped Emacs to be able
> > to run on another system or with different environment than at dump
> > time.
> 
> Is there a facility in place to do such re-evaluation?

Yes, see custom-initialize-delay, and the code in startup.el that
supports it.

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is there a facility in place to do such re-evaluation?
>
> Yes, see custom-initialize-delay, and the code in startup.el that
> supports it.

According to Gerd Möllmann, `custom-initialize-delay' does not work
here. AFAIU, `transient-mark-mode' is already supposed to use it (see
cus-start.el).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, 66742@debbugs.gnu.org
> Date: Fri, 27 Oct 2023 10:53:00 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Is there a facility in place to do such re-evaluation?
> >
> > Yes, see custom-initialize-delay, and the code in startup.el that
> > supports it.
> 
> According to Gerd Möllmann, `custom-initialize-delay' does not work
> here. AFAIU, `transient-mark-mode' is already supposed to use it (see
> cus-start.el).

It could be that re-dumping somehow defeats this mechanism, in which
case we need to debug why it does.  I didn't mean to say that
custom-initialize-delay is a magic wand for this particular case, I
just pointed to a feature that we already have which is supposed to
handle these situations.  If it doesn't work after re-dumping, it
needs to be fixed or generalized to do so, or maybe we should come up
with a similar but different feature.

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Mauro Aranda]

On 27/10/23 07:53, Ihor Radchenko wrote:
 > Eli Zaretskii <eliz@gnu.org> writes:
 >
 >>> Is there a facility in place to do such re-evaluation?
 >>
 >> Yes, see custom-initialize-delay, and the code in startup.el that
 >> supports it.
 >
 > According to Gerd Möllmann, `custom-initialize-delay' does not work
 > here. AFAIU, `transient-mark-mode' is already supposed to use it (see
 > cus-start.el).

Have you tried making custom-delayed-init-variables nil before the
redumping thing?

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Ihor Radchenko]

Mauro Aranda <maurooaranda@gmail.com> writes:

>  > According to Gerd Möllmann, `custom-initialize-delay' does not work
>  > here. AFAIU, `transient-mark-mode' is already supposed to use it (see
>  > cus-start.el).
>
> Have you tried making custom-delayed-init-variables nil before the
> redumping thing?

I tried

(message ":: %S" custom-delayed-init-variables)
(setq custom-delayed-init-variables nil)
(dump-emacs-portable "/tmp/emacs-dumped-2.dmp")

But

(message ":: %S" custom-delayed-init-variables)

outputs

:: t

, which means that ./src/emacs -Q --batch -l ~/Downloads/dump2.el  
already processed all the `custom-delayed-init-variables' prior to
dumping.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> This is a surprise to me!
>> Is it documented anywhere?
>
> What do you want to document?

I think we misunderstand each other.

>> I thought that we should expect the value to
>> be evaluated unless explicitly wrapped into (eval-when-compile ...).
>
> At what time do you think defcustom's value is evaluated?

Load time, even for pdumped libraries.

>> Also, I just looked up defvar instances across Emacs and I am seeing
>> multiple cases when the value is calculated dynamically, assuming
>> loading time:
>
> Of course, it's loading time.  But AFAIU you were talking about
> evaluation during dumping, i.e. when Emacs is built.

No. It is not what I am talking about.
In this bug report, I am talking about re-dumping the already built
Emacs with the aim of adding extra arbitrary libraries. According to
manual page for dump-emacs-portable,

     If you want to use this function in an Emacs that was already
     dumped, you must run Emacs with the ‘-batch’ option.

This implies that re-dumping is one of the intended use-cases.

> ... This is only
> relevant for defcustom's in packages that are preloaded, because those
> packages are loaded at build time, not at run time.  So for those
> packages, and only for those packages, any defcustom whose default
> value is not a constant, should be re-evaluated at startup, to make
> sure the value is suitable for the system on which Emacs runs.

I can see your point, although I wish it were not so tricky.
In any case, even within a scope of this bug report, the reproducer I
provided does not load any extra packages. So, at least, there is some
bug with preloaded packages.

Maybe, the caveats with runtime/re-dump time evaluation should be
documented.

> ...
> This is not relevant, since packages that aren't preloaded will be
> loaded at run time, and therefore the values will be evaluated in the
> correct context.  If you are talking about these, then I don't
> understand what prompted you to raise this issue to begin with, and in
> a thread that discusses dumping.

... but ideally, I wish that we would not have to patch the existing
libraries in order to preload them. Otherwise, `dump-emacs-portable'
function is not very useful in practice (except for building Emacs) and
will most likely lead to subtle bugs if attempted by users.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: gerd.moellmann@gmail.com, 66742@debbugs.gnu.org
> Date: Thu, 26 Oct 2023 13:25:50 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is not relevant, since packages that aren't preloaded will be
> > loaded at run time, and therefore the values will be evaluated in the
> > correct context.  If you are talking about these, then I don't
> > understand what prompted you to raise this issue to begin with, and in
> > a thread that discusses dumping.
> 
> ... but ideally, I wish that we would not have to patch the existing
> libraries in order to preload them.

You don't need to patch any libraries, you need to arrange for the
defcustom's to be re-evaluated at startup time.

But if we want to be able to re-dump any library, and let it run on a
different system after that, we should indeed stay away of
non-constant default values of user options as much as we can.
However, getting there will not be easy and will take a long time, if
ever.