From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66742: 30.0.50; transient-mark-mode is not enabled after re-dumping Emacs Date: Thu, 26 Oct 2023 16:10:53 +0300 Message-ID: <83zg05fs0y.fsf@gnu.org> References: <8734xz2guk.fsf@localhost> <874jidd2ym.fsf@localhost> <837cn9h9ko.fsf@gnu.org> <87r0lhblje.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21353"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 66742@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 26 15:11:47 2023 Return-path: Envelope-to: geb-bug-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 1qw09K-0005M7-DI for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Oct 2023 15:11:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qw097-0003C3-1z; Thu, 26 Oct 2023 09:11:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qw095-0003Bq-Ii for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 09:11:31 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qw095-00028W-AE for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 09:11:31 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qw09a-0007Ko-17 for bug-gnu-emacs@gnu.org; Thu, 26 Oct 2023 09:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Oct 2023 13:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66742 X-GNU-PR-Package: emacs Original-Received: via spool by 66742-submit@debbugs.gnu.org id=B66742.169832588928153 (code B ref 66742); Thu, 26 Oct 2023 13:12:02 +0000 Original-Received: (at 66742) by debbugs.gnu.org; 26 Oct 2023 13:11:29 +0000 Original-Received: from localhost ([127.0.0.1]:60940 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qw093-0007K1-6n for submit@debbugs.gnu.org; Thu, 26 Oct 2023 09:11:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qw091-0007Jp-Rm for 66742@debbugs.gnu.org; Thu, 26 Oct 2023 09:11:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qw08R-000229-Pp; Thu, 26 Oct 2023 09:10:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CnT4RgX42UFri0S8m+wiOjf8mF+xO/jiwbry+Yg1PRs=; b=rUcGEp4OlmNr SNumFxnOq9+9rMN6AQsdZYxkVZGl4t1hKU1+CaujYiIfL8vpfeAqsbYo15ijNgOkZQlMYhxHP5AbD Es504lGppu4RYynt7ogEn6lhI8DUH14fh6oTRW36wmycMjgQ4YgScDvApvALjGxXaZnkT0wKibzo2 DjHtQjTf42L216zSa6cScFkJTL6k+sgrPj6NR+rpXoxH0LZn4cBqlXdBWpD1UZyLcP16xfNxpHIEV 0l6/xN/pSudL58LuJTnBEcv6wfSSbwxHSN6KVjWgLIUjFp1dd2p4M3k6dK6tTBa+DxhjTioQQ9EYl EzPKOfq5SVyhb+C0q4Lobw==; In-Reply-To: <87r0lhblje.fsf@localhost> (message from Ihor Radchenko on Thu, 26 Oct 2023 12:44:37 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:273275 Archived-At: > From: Ihor Radchenko > Cc: gerd.moellmann@gmail.com, 66742@debbugs.gnu.org > Date: Thu, 26 Oct 2023 12:44:37 +0000 > > Eli Zaretskii writes: > > >> Actually, I think that I will not be wrong to say that (defvar foo > >> . ..), (defcustom foo ...), 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, , > 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.