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

[Eli Zaretskii <eliz@gnu.org>]

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