From: Ihor Radchenko <yantar92@posteo.net>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: 66742@debbugs.gnu.org
Subject: bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs
Date: Thu, 26 Oct 2023 11:42:57 +0000 [thread overview]
Message-ID: <874jidd2ym.fsf@localhost> (raw)
In-Reply-To: <m2msw53fzp.fsf@Pro.fritz.box>
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>
next prev parent reply other threads:[~2023-10-26 11:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-25 9:26 bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs Ihor Radchenko
2023-10-26 9:11 ` Gerd Möllmann
2023-10-26 11:42 ` Ihor Radchenko [this message]
2023-10-26 12:06 ` Eli Zaretskii
2023-10-26 12:44 ` Ihor Radchenko
2023-10-26 13:10 ` Eli Zaretskii
2023-10-26 13:15 ` Eli Zaretskii
2023-10-27 9:04 ` Ihor Radchenko
2023-10-27 10:37 ` Eli Zaretskii
2023-10-27 10:53 ` Ihor Radchenko
2023-10-27 10:56 ` Eli Zaretskii
2023-10-27 10:59 ` Mauro Aranda
2023-10-27 11:08 ` Ihor Radchenko
2023-10-26 13:25 ` Ihor Radchenko
2023-10-26 13:31 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874jidd2ym.fsf@localhost \
--to=yantar92@posteo.net \
--cc=66742@debbugs.gnu.org \
--cc=gerd.moellmann@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).