Received: (at 80574) by debbugs.gnu.org; 5 Sep 2026 18:41:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Sep 05 14:41:05 2026
Received: from localhost ([127.0.0.1]:59579 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1x2vK5-0000rQ-7R
for submit <at> debbugs.gnu.org; Sat, 05 Sep 2026 14:41:05 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1204)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1x2vK3-0000qL-1T
for 80574 <at> debbugs.gnu.org; Sat, 05 Sep 2026 14:41:03 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B7A2B10012F;
Sat, 05 Sep 2026 14:40:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1788633656;
bh=SV3VhcnT3ExKPkg2GIfQQCHQ6e38XQixy3i6muRmXIA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=HYy+UJS5KicuEZxy+8r9fkSsIXFAS+M9qUCWF56OzV+dQbhBT8PX//LxHKiGlQJcZ
xDFsS5TYhqKTvEhQCAftkkRSD1nIQ0X1aGuRIR43qRCG9Ay5r3/NVVI2TRSfr6TrFM
j2d0mrsEUak16uak0zsV7M+9qgmvvTNWxObH9cQx2Clp2ELu9QbYqXvg1Sh+vYoHwe
zpIEbv3VXKLwQTjGTgYtdbOwnJqAhL4TM/oy+diJwrlOvExgatg6pUkjBSA5IfM1we
SL+XBudCQ+pa9WUdJ0366f8Z45QTIgB8yXNFtKgQHLD4bM2RHfhU5eIUjwI/q58K3s
31gsT3mWeJGGg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9A80610008C;
Sat, 05 Sep 2026 14:40:56 -0400 (EDT)
Received: from pastel (104-195-199-161.cpe.teksavvy.com [104.195.199.161])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6C4DA12026C;
Sat, 5 Sep 2026 14:40:56 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Jonas Bernoulli <jonas@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer, [PATCH] (intern): Don't obey `read-symbol-shorthands` any
more (bug#80574)
In-Reply-To: <jwvld9f1y72.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwvld9fzgnx.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <87wlt16wjq.fsf_-_@HIDDEN>
<jwvld9f1y72.fsf-monnier+emacs@HIDDEN>
Date: Sat, 05 Sep 2026 14:40:55 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.112 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80574
Cc: 80574 <at> debbugs.gnu.org,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
I pushed an improved version of the patch to `master` after revising the
other `intern(-soft)` in that file.
=== Stefan
Stefan Monnier [2026-09-05 12:08:28] wrote:
> Jonas Bernoulli [2026-09-04 14:16:57] wrote:
>
>> I think this lead to a font-lock regression:
>>
>> (require 'cond-let)
>>
>> (cond-let--and-let ((v 1)) (1+ v))
>> ;; ^^^ font-lock-keyword-face
>>
>> (and-let ((v 1)) (1+ v))
>> ;; ^^^ Previously elisp-shorthand-font-lock-face and font-lock-keyword-face
>> ;; Now just elisp-shorthand-font-lock-face
>>
>> ;; ("Previously" := 31.1)
>>
>> ;; Local Variables:
>> ;; read-symbol-shorthands: (("and-let" . "cond-let--and-let"))
>> ;; End:
>
> The patch below seems to fix this problem (which incidentally confirms
> that that function should live in elisp-mode.el).
>
>
> === Stefan
>
>
> diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
> index 1ea1916ff4a..0e9b232baa2 100644
> --- a/lisp/emacs-lisp/lisp-mode.el
> +++ b/lisp/emacs-lisp/lisp-mode.el
> @@ -269,7 +269,7 @@ lisp--el-match-keyword
> (while (re-search-forward
> (concat "(\\(" (rx lisp-mode-symbol) "\\)\\_>")
> limit t)
> - (let ((sym (intern-soft (match-string 1))))
> + (let ((sym (shorthands-intern-soft (match-string 1))))
> (when (and (or (special-form-p sym) (macrop sym))
> (not (get sym 'no-font-lock-keyword))
> (lisp--el-funcall-position-p (match-beginning 0)))
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Stefan Monnier <monnier@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Debbugs Internal Request <help-debbugs@HIDDEN>
to internal_control <at> debbugs.gnu.org.
Full text available.Received: (at 80574-done) by debbugs.gnu.org; 30 Jul 2026 02:20:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 29 22:20:03 2026 Received: from localhost ([127.0.0.1]:56799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1wpGNP-0004g2-Bk for submit <at> debbugs.gnu.org; Wed, 29 Jul 2026 22:20:03 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8633) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1wpGNL-0004fN-NB for 80574-done <at> debbugs.gnu.org; Wed, 29 Jul 2026 22:20:00 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D0F5610016C; Wed, 29 Jul 2026 22:19:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1785377991; bh=VSWvxs/ArZ0vLQa+IJbNJMfHyRKmcYgP9ySO2ik+D14=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=YfO09HzzT8AZ9y3d/PljTgHjTUHaKsG63OcfJhfp6UQXclPQzfj32Msu8Hg1BhSNG NOU8nXRfgoAqg/0SFuhyzT86FZS1Ox1mPFJSipP6y7OgZM9oO7rwsAvRMsUyOg0RLg 34D/dL9nCeJe0Sxqfkc0RdS6RME2iVVQh58GOuoGF6NNgKOuf2mELYXej/pfv7x3cL NJ2idDs+JPXejjEHIe1lJ0EnwLg5yFWORSmCa47H4Ozou5hLst5jHUQvETRxF/XEGX GrVBvk99WFgDJZyDZmxlpZa2fk/K7yne0ScJgeXmltklRvDy9HL6k9ql42IMr37JKf pJqQXHdWP4nuw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C9277100081; Wed, 29 Jul 2026 22:19:51 -0400 (EDT) Received: from pastel (104-195-207-192.cpe.teksavvy.com [104.195.207.192]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8B201120313; Wed, 29 Jul 2026 22:19:51 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvh5lqokl5.fsf-monnier+emacs@HIDDEN> Message-ID: <jwvtsph1aoj.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN> <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> <861phfg9si.fsf@HIDDEN> <jwvy0jnixrk.fsf-monnier+emacs@HIDDEN> <CALDnm51LfN-rHNaYqUcbY6R8Dme2A-xdXOPUiyojua7eGPQVUg@HIDDEN> <86h5qbdjru.fsf@HIDDEN> <jwvh5lqokl5.fsf-monnier+emacs@HIDDEN> Date: Wed, 29 Jul 2026 22:19:49 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.120 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574-done Cc: gerd.moellmann@HIDDEN, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>, 80574-done <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > I attach the overall patch below. > Any comments or objection to pushing it to `master`? Pushed to `master`, closing, === Stefan
Stefan Monnier <monnier@HIDDEN>:Stefan Monnier <monnier@HIDDEN>:
Received: (at 80574) by debbugs.gnu.org; 23 Jul 2026 11:47:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jul 23 07:47:53 2026
Received: from localhost ([127.0.0.1]:57723 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wmru5-0006Ms-Js
for submit <at> debbugs.gnu.org; Thu, 23 Jul 2026 07:47:53 -0400
Received: from mail.eshelyaron.com ([107.175.124.16]:52470 helo=eshelyaron.com)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <me@HIDDEN>) id 1wmru3-0006Me-Bg
for 80574 <at> debbugs.gnu.org; Thu, 23 Jul 2026 07:47:52 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eshelyaron.com;
s=mail; t=1784807270;
bh=NZnU/eZLi5vOGRyYXpuGEpPGqPU/X2JFSsSbhr5Wpq4=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=WRqNYNC3/M19IvWUz02xUTIY/hcDzJP5aMk1K2RsBYzYGrK9BNAazTV9SGtTZGwVa
GFf27fIyz0h8a5oh5xN6l5Jr1agWgz7iQ2/Yi3lE2hgm4gpAS0Gbxmw+Ska+VHAFpj
N62wWP3T+eC2Ui3p4UQCed5cAFQ3qPevTd2SCUfKnmhxKmIRNdt7OZyvUiNxoqwPQw
qM9ZYs37MWSAlMrIbNTsQ6wPoFEgmLZ+2pdQOkvtUiEwAvk9WJ8zSUf5IAdQz8iUbP
ib+pQJxwst2hZztVsuIEeST3ArdfNzR7K/TfhlZSKMYuOOvStIPGS4ZiK2eHrKAtbS
hIOE5Zqaj6ZRQ==
From: Eshel Yaron <me@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <jwv4ihscare.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN>
<jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN>
<jwvikazydsx.fsf-monnier+emacs@HIDDEN>
<CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN>
<jwvbjgrnwak.fsf-monnier+emacs@HIDDEN>
<jwv4ihscare.fsf-monnier+emacs@HIDDEN>
Date: Thu, 23 Jul 2026 13:47:47 +0200
Message-ID: <8733xa3p24.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 80574
Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org,
=?utf-8?B?Sm8=?= =?utf-8?B?w6NvIFTDoXZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Stefan Monnier writes:
>> Lessee:
>>
>> % cat ~/tmp/foo.txt
>> Some foo
>> Local Variables:
>> read-symbol-shorthands: (("vc-cvs-registered" . "message"))
>> End:
>> % /usr/bin/emacs -Q --batch ~/tmp/foo.txt
>
> BTW, this hole still applies to the `emacs-31` branch.
>
> I tried it with a `foo.el` as follows:
>
> ;; -*- lexical-binding: t; -*-
>
> (yes-or-no-p "Gotcha? ")
>
> ;; Local Variables:
> ;; read-symbol-shorthands: (("vc-cvs-registered" . "load"))
> ;; End:
>
> where merely visiting the file runs its code before you get to see it.
Ouch!
That "hole" seems a lot like an arbitrary code execution vulnerability.
I'm adding a mitigation in trust-manager that effectively ignores symbol
shorthands in untrusted buffers (see commit e5aacea). That should
hopefully help Emacs 30 users stay safe.
I hope this can also be mitigated in core before the Emacs 31 release.
Best regards,
Eshel
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 22 Jul 2026 20:33:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jul 22 16:33:03 2026
Received: from localhost ([127.0.0.1]:52708 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wmdci-0001eu-Ub
for submit <at> debbugs.gnu.org; Wed, 22 Jul 2026 16:33:03 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23080)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1wmdcf-0001eU-G5
for 80574 <at> debbugs.gnu.org; Wed, 22 Jul 2026 16:32:59 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 86D5D1001F0;
Wed, 22 Jul 2026 16:32:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1784752368;
bh=0Dl5taQIS/8QZmambzqNDFPk0xRn24KYlHAGEWkLliU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=fAPKkr6SocVZy61MUCs4cSIFKmJsLpBN50geUmE+1QzepdnIQ7ntlDB4HDStUdnkI
ZLtRBGLIsm5jBwqJHFk26b1TT1RJglva5Bb4teiUgUSGB1pMBBeMX1S65Lhuqf0515
00TOd+prGvcoFLlgOv5s0E49/wGFZbw01uQT/b5wm5SNnMs26xa4YzrQWwqL9ltJUH
/itfndCZu1A2T+4bA7yBClIGn3RjrANfLAP8pprO+8UugzvxW58yb49zj/uWyVbGgH
m6/krtIqNFfRCMX0bdqf6/4gHCEqj9kZTntJhf8rgj796f/HGNVWL946tgOt3prvSA
PS4nxjQZH01iA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1D8261000B7;
Wed, 22 Jul 2026 16:32:48 -0400 (EDT)
Received: from pastel (104-195-207-192.cpe.teksavvy.com [104.195.207.192])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CDF0D1207AB;
Wed, 22 Jul 2026 16:32:47 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <86h5qbdjru.fsf@HIDDEN>
Message-ID: <jwvh5lqokl5.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
<jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN>
<jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN>
<jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN>
<jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN>
<jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN>
<jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN>
<jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> <861phfg9si.fsf@HIDDEN>
<jwvy0jnixrk.fsf-monnier+emacs@HIDDEN>
<CALDnm51LfN-rHNaYqUcbY6R8Dme2A-xdXOPUiyojua7eGPQVUg@HIDDEN>
<86h5qbdjru.fsf@HIDDEN>
Date: Wed, 22 Jul 2026 16:32:45 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.116 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
--=-=-=
Content-Type: text/plain
> So here's my last proposal: install this on master after the emacs-31
> release branch is cut. That will give us the entire development cycle
> of Emacs 32 to see if there are any problems, and if so, how best to
> fix them. But I cannot agree doing this so close to cutting the
> release branch of Emacs 31.
I pushed to `scratch/intern-without-shorthands` the current state of
that patch.
Beyond fixing a few places that need to use `shorthands-intern` in order
to avoid regression, it also includes a fix to the long-standing problem
that `C-h o icalendar-uid-format RET` followed by clicking on the link
to jump to that variable's definition failed to find that definition
(because it's written "ical:uid-format" instead in the file).
I'm pretty sure the code still includes regressions (more places where we
need to use `shorthands-intern` or somesuch), but it's difficult to find
them by looking at the source code.
I attach the overall patch below.
Any comments or objection to pushing it to `master`?
=== Stefan
--=-=-=
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: inline; filename=intern.patch
Content-Transfer-Encoding: quoted-printable
commit 201520c0f4f33b4d8659f539a48dc519532a4075 (HEAD -> intern-without-sho=
rthands, origin/scratch/intern-without-shorthands)
Author: Stefan Monnier <monnier@HIDDEN>
Date: Wed Jul 22 15:57:32 2026 -0400
=20
etc/NEWS: Document the change in `intern` and shorthands
=20
commit 3f70cfde38a11f7054a812c337d399ff473c27f0
Author: Stefan Monnier <monnier@HIDDEN>
Date: Tue Jul 21 20:38:45 2026 -0400
=20
fund-func: Find definitions that use shorthands
=20=20=20=20
* lisp/emacs-lisp/find-func.el (find-func--regexp-of-symbol-name):
New function.
(find-function-search-for-symbol): Use it to find shorthands.
=20=20=20=20
* lisp/emacs-lisp/cl-generic.el (cl--generic-search-method):
Find method defined with shorthands (and funny chars).
=20
commit 4b23583f600ca2d0cfef742ad80c258f6dbbc3eb
Author: Stefan Monnier <monnier@HIDDEN>
Date: Wed Jul 22 13:12:30 2026 -0400
=20
doc/lispref/symbols.texi (Converting to/from shorthands): New subsection
=20
commit 7c7616e3f09c80723da7c766b6d188d717247ae3
Author: Stefan Monnier <monnier@HIDDEN>
Date: Wed Mar 11 21:46:10 2026 -0400
=20
(intern): Don't obey `read-symbol-shorthands` any more (bug#80574)
=20=20=20=20
* src/lread.c (Fintern, Fintern_soft, Funintern): Don't obey
`read-symbol-shorthands` any more.
=20=20=20=20
* lisp/emacs-lisp/shorthands.el (shorthands-of-symbol): New function,
adapted from `elisp--read-symbols-shorthands`.
(shorthands-to-longhand, shorthands-intern, shorthands-intern-soft)
(shorthands-unintern): New functions.
(shorthands-font-lock-shorthands): Use `shorthands-intern-soft`.
=20=20=20=20
* lisp/progmodes/elisp-mode.el (elisp-context-menu)
(elisp--company-doc-buffer, elisp--company-doc-string)
(elisp--company-location, elisp--company-kind)
(elisp--company-deprecated, xref-backend-definitions)
(elisp--xref-find-definitions, eval-sexp-add-defvars)
(elisp--current-symbol): Use `shorthands-intern(-soft)`.
(elisp--read-symbol-shorthands): Use `shorthands-of-symbol`.
(elisp-completion-at-point): Use the `elisp--longhand` to simplify.
Use `shorthands-intern(-soft)`.
=20=20=20=20
* lisp/minibuffer.el (completion-shorthand-try-completion):
Simplify using `shorthands-to-longhand`.
=20=20=20=20
* lisp/emacs-lisp/lisp-mode.el (lisp-indent-function):
* lisp/thingatpt.el (symbol-at-point): Use `shorthands-intern(-soft)`.
=20=20=20=20
* test/src/lread-tests.el (lread-unintern):
Use `shorthands-(un)intern(-soft)`.
=20
diff --git a/doc/lispref/symbols.texi b/doc/lispref/symbols.texi
index 4fd0c83450e..8f8ec84b137 100644
--- a/doc/lispref/symbols.texi
+++ b/doc/lispref/symbols.texi
@@ -781,6 +781,45 @@ Shorthands
Symbol forms whose names start with @samp{#_} are not transformed.
@end itemize
=20
+@subsection Converting to/from shorthands
+
+Shorthands are automatically expanded by the Lisp reader.
+If you want to apply @code{read-symbol-shorthands} to a symbol
+name without going through the reader, for example because the symbol
+comes from another buffer (e.g., the minibuffer), you can use
+@code{shorthands-to-longhand}. Similarly, if you are looking for
+a symbol in a buffer, you can consider all its possible
+shorthand forms with the use of @code{shorthands-of-symbol}.
+
+@defun shorthands-to-longhand string
+Return the full name (so called ``longhand'' form) of the symbol whose
+shorthand is @var{string}. It always returns a string since
+if there is no use of any shorthand notation in @var{string}, it just
+returns @var{string} unchanged.
+@end defun
+
+@defun shorthands-of-symbol string-or-symbol
+Return the list of all the alternative ways to write this symbol.
+The argument can be a symbol or its name, and=20
+the return value is a list of strings. Note that the return value
+includes only the shorthand forms of the argument, not its longhand
+form, so it is common and normal for the return value to be @code{nil}.
+@end defun
+
+@defun shorthands-intern string &optional obarray
+Interns the string @var{string} in the obarray @var{obarray},
+just like @code{intern}, except that it obeys
+@code{read-symbol-shorthands} and thus expands any shorthand in
+@var{string} if applicable before interning it.
+Returns the interned symbol.
+@end defun
+
+@defun shorthands-intern-soft string &optional obarray
+Same as @code{shorthands-intern}, except that it returns @code{nil}
+if there is no symbol by that name in the obarray instead of
+interning a new symbol.
+@end defun
+
@node Symbols with Position
@section Symbols with Position
@cindex symbol with position
diff --git a/etc/NEWS b/etc/NEWS
index 85d1af8d71c..1a1f6771905 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -211,6 +211,13 @@ To install the grammars, use 'M-x markdown-ts-mode-ins=
tall-parsers'.
* Incompatible Lisp Changes in Emacs 32.1
=20
++++
+** 'intern' and 'intern-soft' ignore 'read-symbol-shorthands'.
+This means they revert to the behavior of Emacs<28.
+In those cases where shorthands need to be obeyed, you now need to use
+'shorthands-intern', 'shorthands-intern-soft', or 'shorthands-to-longhand'.
+And 'shorthands-of-symbol' provides the reverse mapping.
+
** Pcase
=20
+++
diff --git a/lisp/emacs-lisp/cl-generic.el b/lisp/emacs-lisp/cl-generic.el
index 320bc4c3d8e..5fc89836abe 100644
--- a/lisp/emacs-lisp/cl-generic.el
+++ b/lisp/emacs-lisp/cl-generic.el
@@ -1166,8 +1166,11 @@ cl-find-method
(defun cl--generic-search-method (met-name)
"For `find-function-regexp-alist'. Search for a `cl-defmethod'.
MET-NAME is as returned by `cl--generic-load-hist-format'."
+ ;; Presumably our caller is `find-function-search-for-symbol'.
+ (declare-function find-func--regexp-of-symbol-name "find-func" (name))
+ ;; FIXME: Handle also shorthands in the cdr of MET-NAME!
(let ((base-re (concat "(\\(?:cl-\\)?defmethod[ \t]+"
- (regexp-quote (format "%s" (car met-name)))
+ (find-func--regexp-of-symbol-name (car met-name))
"\\_>")))
(or
(re-search-forward
diff --git a/lisp/emacs-lisp/find-func.el b/lisp/emacs-lisp/find-func.el
index 76b8798ca25..96358870888 100644
--- a/lisp/emacs-lisp/find-func.el
+++ b/lisp/emacs-lisp/find-func.el
@@ -403,6 +403,20 @@ find-library-other-frame
(find-library-name library)))
(run-hooks 'find-function-after-hook)))
=20
+(defun find-func--regexp-of-symbol-name (name)
+ (let ((names (cons (if (stringp name) name
+ (symbol-name name))
+ (shorthands-of-symbol name))))
+ (regexp-opt
+ (mapcar (lambda (name)
+ ;; Definitions like the ` (backquote) need to backslash
+ ;; quote their name in the file, but (symbol-name symbol)
+ ;; doesn't. Add a \ to catch this.
+ (replace-regexp-in-string "[][\\()\"`' ,]"
+ "\\\\\\&" name))
+ names))))
+
+
;;;###autoload
(defun find-function-search-for-symbol (symbol type library)
"Search for SYMBOL's definition of type TYPE in LIBRARY.
@@ -442,35 +456,33 @@ find-function-search-for-symbol
(car regexp-symbol)
regexp-symbol)))
(with-current-buffer (find-file-noselect filename)
- (let ((regexp (if (functionp regexp-symbol) regexp-symbol
- (format (symbol-value regexp-symbol)
- ;; Entry for ` (backquote) macro in loadde=
fs.el,
- ;; (defalias (quote \`)..., has a \ but
- ;; (symbol-name symbol) doesn't. Add an
- ;; optional \ to catch this.
- (concat "\\\\?"
- (regexp-quote (symbol-name symbol)=
)))))
- (case-fold-search))
+ (let ((case-fold-search))
(save-restriction
(widen)
(with-syntax-table emacs-lisp-mode-syntax-table
(goto-char (point-min))
- (if (if (functionp regexp)
- (funcall regexp symbol)
- (or (re-search-forward regexp nil t)
- ;; `regexp' matches definitions using known forms =
like
- ;; `defun', or `defvar'. But some functions/varia=
bles
- ;; are defined using special macros (or functions)=
, so
- ;; if `regexp' can't find the definition, we look =
for
- ;; something of the form "(SOMETHING <symbol> ...)=
".
- ;; This fails to distinguish function definitions =
from
- ;; variable declarations (or even uses thereof), b=
ut is
- ;; a good pragmatic fallback.
- (re-search-forward
- (concat "^([^ ]+" find-function-space-re "['(]?"
- (regexp-quote (symbol-name symbol))
- "\\_>")
- nil t)))
+ (if (if (functionp regexp-symbol)
+ (funcall regexp-symbol symbol)
+ (let ((regexp-of-symbol
+ (find-func--regexp-of-symbol-name symbol)))
+ (or (re-search-forward
+ (format (symbol-value regexp-symbol)
+ regexp-of-symbol)
+ nil t)
+ ;; `regexp' matches definitions using known forms
+ ;; like `defun', or `defvar'.
+ ;; But some functions/variables are defined using
+ ;; special macros (or functions), so if `regexp'
+ ;; can't find the definition, we look for
+ ;; something of the form "(SOMETHING <symbol> ..=
.)".
+ ;; This doesn't pay attention to TYPE (or even
+ ;; distinguish definitions from uses),
+ ;; but is a good pragmatic fallback.
+ (re-search-forward
+ (concat "^([^ ]+" find-function-space-re "['(]?"
+ regexp-of-symbol
+ "\\_>")
+ nil t))))
(progn
(beginning-of-line)
(cons (current-buffer) (point)))
@@ -682,7 +694,7 @@ find-function
Use \\[xref-find-definitions] to find definitions of functions and variabl=
es
that are not part of Emacs."
(interactive (find-function-read))
- (find-function-do-it function nil 'switch-to-buffer))
+ (find-function-do-it function nil #'switch-to-buffer))
=20
;;;###autoload
(defun find-function-other-window (function)
@@ -690,7 +702,7 @@ find-function-other-window
=20
See `find-function' for more details."
(interactive (find-function-read))
- (find-function-do-it function nil 'switch-to-buffer-other-window))
+ (find-function-do-it function nil #'switch-to-buffer-other-window))
=20
;;;###autoload
(defun find-function-other-frame (function)
@@ -698,7 +710,7 @@ find-function-other-frame
=20
See `find-function' for more details."
(interactive (find-function-read))
- (find-function-do-it function nil 'switch-to-buffer-other-frame))
+ (find-function-do-it function nil #'switch-to-buffer-other-frame))
=20
;;;###autoload
(defun find-variable-noselect (variable &optional file)
@@ -726,7 +738,7 @@ find-variable
=20
See also `find-function-recenter-line' and `find-function-after-hook'."
(interactive (find-function-read 'defvar))
- (find-function-do-it variable 'defvar 'switch-to-buffer))
+ (find-function-do-it variable 'defvar #'switch-to-buffer))
=20
;;;###autoload
(defun find-variable-other-window (variable)
@@ -734,7 +746,7 @@ find-variable-other-window
=20
See `find-variable' for more details."
(interactive (find-function-read 'defvar))
- (find-function-do-it variable 'defvar 'switch-to-buffer-other-window))
+ (find-function-do-it variable 'defvar #'switch-to-buffer-other-window))
=20
;;;###autoload
(defun find-variable-other-frame (variable)
@@ -742,7 +754,7 @@ find-variable-other-frame
=20
See `find-variable' for more details."
(interactive (find-function-read 'defvar))
- (find-function-do-it variable 'defvar 'switch-to-buffer-other-frame))
+ (find-function-do-it variable 'defvar #'switch-to-buffer-other-frame))
=20
;;;###autoload
(defun find-definition-noselect (symbol type &optional file)
@@ -776,7 +788,7 @@ find-face-definition
=20
See also `find-function-recenter-line' and `find-function-after-hook'."
(interactive (find-function-read 'defface))
- (find-function-do-it face 'defface 'switch-to-buffer))
+ (find-function-do-it face 'defface #'switch-to-buffer))
=20
(defun find-function-on-key-do-it (key find-fn)
"Find the function that KEY invokes. KEY is a string.
diff --git a/lisp/emacs-lisp/lisp-mode.el b/lisp/emacs-lisp/lisp-mode.el
index d9e11761657..1ea1916ff4a 100644
--- a/lisp/emacs-lisp/lisp-mode.el
+++ b/lisp/emacs-lisp/lisp-mode.el
@@ -1276,7 +1276,8 @@ lisp-indent-function
;; inside the innermost containing sexp.
(backward-prefix-chars)
(current-column))
- (let* ((function (intern-soft
+ ;; FIXME: Using `shorthands-intern-soft' is wrong for non-Emacs Lisp.
+ (let* ((function (shorthands-intern-soft
(buffer-substring (point)
(progn (forward-sexp 1) (point))=
)))
(local (assq function lisp-indent-local-overrides))
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index 9c668bb3720..c57bb53aa21 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -29,6 +29,48 @@
(require 'files)
(require 'mule)
=20
+(defun shorthands-of-symbol (s)
+ "Return a list of shorthand alternative spellings of S.
+S can be either a string or a symbol. The returned shorthands are strings,
+in the order they are found in `read-symbol-shorthands'."
+ (let ((retval ())
+ (full-name (if (symbolp s) (symbol-name s) s)))
+ (dolist (mapping read-symbol-shorthands)
+ (let ((shorthand (car mapping))
+ (longhand (cdr mapping)))
+ (when (string-prefix-p longhand full-name)
+ (push (concat shorthand
+ (substring full-name (length longhand)))
+ retval))))
+ (nreverse retval)))
+
+(defun shorthands-to-longhand (string)
+ "Return the longhand form of STRING according to `read-symbol-shorthands=
'.
+Returns a string. If no shorthand applies, returns STRING."
+ (let ((mappings read-symbol-shorthands))
+ (while (and mappings (not (string-prefix-p (caar mappings) string)))
+ (setq mappings (cdr mappings)))
+ (if mappings
+ (concat (cdar mappings) (substring string (length (caar mappings))=
))
+ string)))
+
+(defun shorthands-intern (string &optional ob)
+ "`intern' STRING into the obarray OB, obeying `read-symbol-shorthands'."
+ (intern (shorthands-to-longhand string) ob))
+
+(defun shorthands-intern-soft (string &optional ob)
+ "Return the interned symbol of name STRING in the obarray OB, if any.
+If not found, return nil.
+Contrary to `intern-soft', this obeys `read-symbol-shorthands'."
+ (intern-soft (shorthands-to-longhand string) ob))
+
+(defun shorthands-unintern (string ob)
+ "`unintern's the symbol of shorthand name STRING in obarray OB.
+Obeys `read-symbol-shorthands'."
+ (unless (obarrayp ob)
+ (signal 'wrong-type-argument (list #'obarrayp ob)))
+ (unintern (shorthands-to-longhand string) ob))
+
(defun hack-read-symbol-shorthands ()
"Compute `read-symbol-shorthands' from Local Variables section."
;; FIXME: relies on the `hack-local-variables--find-variables'
@@ -65,7 +107,7 @@ shorthands-font-lock-shorthands
(print-name (match-string 1))
(probe (and (not (memq existing '(font-lock-comment-face
font-lock-string-face)))
- (intern-soft print-name)))
+ (shorthands-intern-soft print-name)))
(symbol-name (and probe (symbol-name probe)))
(prefix (and symbol-name
(not (string-equal print-name symbol-name))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 74c7cd9baa2..6c13fcabe54 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -5127,24 +5127,12 @@ completion-initials-try-completion
=20
(defun completion-shorthand-try-completion (string table pred point)
"Try completion with `read-symbol-shorthands' of original buffer."
- (cl-loop with expanded
- for (short . long) in
- (with-current-buffer minibuffer--original-buffer
- read-symbol-shorthands)
- for probe =3D
- (and (> point (length short))
- (string-prefix-p short string)
- (try-completion (setq expanded
- (concat long
- (substring
- string
- (length short))))
- table pred))
- when probe
- do (message "Shorthand expansion")
- and return (cons expanded (max (length long)
- (+ (- point (length short))
- (length long))))))
+ (let ((expanded (with-current-buffer minibuffer--original-buffer
+ (shorthands-to-longhand string))))
+ (when (and (not (equal expanded string))
+ (try-completion expanded table pred))
+ (cons expanded (+ (- point (length string))
+ (length expanded))))))
=20
(defun completion-shorthand-all-completions (_string _table _pred _point)
;; no-op: For now, we don't want shorthands to list all the possible
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index be98e03d342..1b7323cad39 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -160,7 +160,8 @@ elisp-context-menu
'middle-separator)
=20
(let* ((string (thing-at-mouse click 'symbol t))
- (symbol (when (stringp string) (intern string)))
+ ;; FIXME: Why don't we know if we receive a string or a symbol?
+ (symbol (when (stringp string) (shorthands-intern string)))
(title (cond
((not (symbolp symbol)) nil)
((and (facep symbol) (not (fboundp symbol)))
@@ -981,7 +982,7 @@ elisp--form-quoted-p
;; the *Completions* buffer.
=20
(defun elisp--company-doc-buffer (str)
- (let ((symbol (intern-soft str)))
+ (let ((symbol (shorthands-intern-soft str)))
;; FIXME: we really don't want to "display-buffer and then undo it".
(save-window-excursion
;; Make sure we don't display it in another frame, otherwise
@@ -998,7 +999,7 @@ elisp--company-doc-buffer
(help-buffer))))))
=20
(defun elisp--company-doc-string (str)
- (let* ((symbol (intern-soft str))
+ (let* ((symbol (shorthands-intern-soft str))
(doc (if (fboundp symbol)
(documentation symbol t)
(documentation-property symbol 'variable-documentation t))=
))
@@ -1011,7 +1012,7 @@ elisp--company-doc-string
(declare-function find-function-library "find-func" (function &optional l-=
o v))
=20
(defun elisp--company-location (str)
- (let ((sym (intern-soft str)))
+ (let ((sym (shorthands-intern-soft str)))
(cond
((fboundp sym) (find-definition-noselect sym nil))
((boundp sym) (find-definition-noselect sym 'defvar))
@@ -1029,20 +1030,13 @@ obarray-cache
interning or uninterning a symbol), this variable is set to nil.")
=20
(defun elisp--read-symbol-shorthands (s)
- "Return a fresh list of shorthand-ed alternative spellings of symbol S."
- (let ((retval ()))
- (cl-loop
- for (shorthand . longhand) in read-symbol-shorthands
- for full-name =3D (symbol-name s)
- when (string-prefix-p longhand full-name)
- do (let ((sym (make-symbol
- (concat shorthand
- (substring full-name
- (length longhand))))))
- (put sym 'elisp--longhand s)
- (push sym retval)
- retval))
- retval))
+ (let ((shs (shorthands-of-symbol s)))
+ (when shs
+ (mapcar (lambda (sh)
+ (let ((sym (make-symbol sh)))
+ (put sym 'elisp--longhand s)
+ sym))
+ shs))))
=20
(defun elisp--completion-local-symbols ()
"Compute collections of all Elisp symbols for completion purposes.
@@ -1142,15 +1136,18 @@ elisp-completion-at-point
(quoted
(list nil (elisp--completion-local-symbols)
;; Don't include all symbols (bug#16646).
- :predicate (lambda (sym)
- ;; shorthand-aware
- (let ((sym (intern-soft (symbol-na=
me sym))))
- (or (boundp sym)
- (fboundp sym)
- (featurep sym)
- (symbol-plist sym))))
+ :predicate
+ (lambda (sym)
+ (let ((sym (or (get sym 'elisp--longhand)
+ sym)))
+ (or (boundp sym)
+ (fboundp sym)
+ (featurep sym)
+ (symbol-plist sym))))
:annotation-function
- (lambda (str) (if (fboundp (intern-soft str)) "=
<f>"))
+ (lambda (str)
+ (if (fboundp (shorthands-intern-soft str))
+ " <f>"))
:company-kind #'elisp--company-kind
:company-doc-buffer #'elisp--company-doc-buffer
:company-docsig #'elisp--company-doc-string
@@ -1183,8 +1180,9 @@ elisp-completion-at-point
(if (memq (char-syntax c) '(?w ?_=
))
(let ((pt (point)))
(forward-sexp)
- (intern-soft
- (buffer-substring pt (poin=
t))))))))
+ (shorthands-intern-soft
+ (buffer-substring
+ pt (point))))))))
(error nil))))
(pcase parent
;; FIXME: Rather than hardcode special cases here,
@@ -1247,7 +1245,7 @@ elisp-completion-at-point
(cddr table-etc)))))))))
=20
(defun elisp--company-kind (str)
- (let ((sym (intern-soft str)))
+ (let ((sym (shorthands-intern-soft str)))
(cond
((or (macrop sym) (special-form-p sym)) 'keyword)
((fboundp sym) 'function)
@@ -1257,7 +1255,7 @@ elisp--company-kind
(t 'text))))
=20
(defun elisp--company-deprecated (str)
- (let ((sym (intern-soft str)))
+ (let ((sym (shorthands-intern-soft str)))
(or (get sym 'byte-obsolete-variable)
(get sym 'byte-obsolete-info))))
=20
@@ -1466,7 +1464,7 @@ xref-backend-identifier-at-point
=20
(cl-defmethod xref-backend-definitions ((_backend (eql 'elisp)) identifier)
(require 'find-func)
- (let ((sym (intern-soft identifier)))
+ (let ((sym (shorthands-intern-soft identifier)))
(when sym
(let* ((pos (get-text-property 0 'pos identifier))
(namespace (if (and pos
@@ -1571,7 +1569,7 @@ elisp--xref-find-definitions
;; `symbol' is a name for the default constructor created by
;; cl-defstruct, so return the location of the cl-defstruct.
(let* ((type-name (match-string 1 doc))
- (type-symbol (intern type-name))
+ (type-symbol (shorthands-intern type-name))
(file (find-lisp-object-file-name
type-symbol 'define-type))
(summary (format elisp--xref-format-extra
@@ -2044,7 +2042,7 @@ eval-sexp-add-defvars
(while (re-search-forward
"(def\\(?:var\\|const\\|custom\\)[ \t\n]+\\([^; '()\n\t]+\=
\)"
pos t)
- (let ((var (intern (match-string 1))))
+ (let ((var (shorthands-intern (match-string 1))))
(unless (or (special-variable-p var)
(syntax-ppss-toplevel-pos
(save-excursion
@@ -2580,7 +2578,7 @@ elisp--current-symbol
(let ((c (char-after (point))))
(and c
(memq (char-syntax c) '(?w ?_))
- (intern-soft (current-word)))))
+ (shorthands-intern-soft (current-word)))))
=20
(defun elisp-function-argstring (arglist)
"Return ARGLIST as a string enclosed by ().
diff --git a/lisp/thingatpt.el b/lisp/thingatpt.el
index 578f4ab9819..f17c02f35da 100644
--- a/lisp/thingatpt.el
+++ b/lisp/thingatpt.el
@@ -787,7 +787,9 @@ sexp-at-point
(defun symbol-at-point ()
"Return the symbol at point, or nil if none is found."
(let ((thing (thing-at-point 'symbol)))
- (if thing (intern thing))))
+ ;; FIXME: Should we use the reader so as to properly handle
+ ;; backslashes and such?
+ (if thing (shorthands-intern thing))))
=20
(defvar thing-at-point-decimal-regexp
"-?[0-9]+\\.?[0-9]*"
diff --git a/src/lread.c b/src/lread.c
index b079e83dd06..48d2420f96e 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4782,27 +4782,10 @@ DEFUN ("intern", Fintern, Sintern, 1, 2, 0,
obarray =3D check_obarray (NILP (obarray) ? Vobarray : obarray);
CHECK_STRING (string);
=20
-
- char* longhand =3D NULL;
- ptrdiff_t longhand_chars =3D 0;
- ptrdiff_t longhand_bytes =3D 0;
- tem =3D oblookup_considering_shorthand (obarray, SSDATA (string),
- SCHARS (string), SBYTES (string),
- &longhand, &longhand_chars,
- &longhand_bytes);
+ tem =3D oblookup (obarray, SSDATA (string), SCHARS (string), SBYTES (str=
ing));
=20
if (!BARE_SYMBOL_P (tem))
- {
- if (longhand)
- {
- tem =3D intern_driver (make_multibyte_string (longhand, longhand_chars,
- longhand_bytes),
- obarray, tem);
- xfree (longhand);
- }
- else
- tem =3D intern_driver (string, obarray, tem);
- }
+ tem =3D intern_driver (string, obarray, tem);
return tem;
}
=20
@@ -4821,24 +4804,13 @@ DEFUN ("intern-soft", Fintern_soft, Sintern_soft, 1=
, 2, 0,
=20
if (!SYMBOLP (name))
{
- char *longhand =3D NULL;
- ptrdiff_t longhand_chars =3D 0;
- ptrdiff_t longhand_bytes =3D 0;
-
CHECK_STRING (name);
string =3D name;
- tem =3D oblookup_considering_shorthand (obarray, SSDATA (string),
- SCHARS (string), SBYTES (string),
- &longhand, &longhand_chars,
- &longhand_bytes);
- if (longhand)
- xfree (longhand);
+ tem =3D oblookup (obarray, SSDATA (string), SCHARS (string), SBYTES =
(string));
return FIXNUMP (tem) ? Qnil : tem;
}
else
{
- /* If already a symbol, we don't do shorthand-longhand translation,
- as promised in the docstring. */
Lisp_Object sym =3D maybe_remove_pos_from_symbol (name);
string =3D XSYMBOL (name)->u.s.name;
tem
@@ -4872,14 +4844,7 @@ DEFUN ("unintern", Funintern, Sunintern, 2, 2, 0,
else
{
CHECK_STRING (name);
- char *longhand =3D NULL;
- ptrdiff_t longhand_chars =3D 0;
- ptrdiff_t longhand_bytes =3D 0;
- sym =3D oblookup_considering_shorthand (obarray, SSDATA (name),
- SCHARS (name), SBYTES (name),
- &longhand, &longhand_chars,
- &longhand_bytes);
- xfree(longhand);
+ sym =3D oblookup (obarray, SSDATA (name), SCHARS (name), SBYTES (nam=
e));
if (FIXNUMP (sym))
return Qnil;
}
diff --git a/test/src/lread-tests.el b/test/src/lread-tests.el
index e621a9d58b9..d6676ce9bf6 100644
--- a/test/src/lread-tests.el
+++ b/test/src/lread-tests.el
@@ -454,47 +454,47 @@ lread-unintern
;; with shorthand
(let* ((oa (obarray-make))
(read-symbol-shorthands '(("a=C2=B7" . "ZZ=E2=80=A2")))
- (s1 (intern "a=C2=B7abc" oa))
- (s2 (intern "a=C2=B7def" oa))
- (s3 (intern "a=C2=B7ghi" oa)))
+ (s1 (shorthands-intern "a=C2=B7abc" oa))
+ (s2 (shorthands-intern "a=C2=B7def" oa))
+ (s3 (shorthands-intern "a=C2=B7ghi" oa)))
(should (equal (oa-syms oa) (list s1 s2 s3)))
(should (equal (symbol-name s1) "ZZ=E2=80=A2abc"))
- (should (eq (intern-soft "ZZ=E2=80=A2abc" oa) s1))
- (should (eq (intern-soft "a=C2=B7abc" oa) s1))
- (should (eq (intern-soft "ZZ=E2=80=A2def" oa) s2))
- (should (eq (intern-soft "a=C2=B7def" oa) s2))
- (should (eq (intern-soft "ZZ=E2=80=A2ghi" oa) s3))
- (should (eq (intern-soft "a=C2=B7ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2abc" oa) s1))
+ (should (eq (shorthands-intern-soft "a=C2=B7abc" oa) s1))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2def" oa) s2))
+ (should (eq (shorthands-intern-soft "a=C2=B7def" oa) s2))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "a=C2=B7ghi" oa) s3))
=20
;; unintern using long name
- (should (eq (unintern "ZZ=E2=80=A2abc" oa) t))
- (should-not (intern-soft "ZZ=E2=80=A2abc" oa))
- (should-not (intern-soft "a=C2=B7abc" oa))
+ (should (eq (shorthands-unintern "ZZ=E2=80=A2abc" oa) t))
+ (should-not (shorthands-intern-soft "ZZ=E2=80=A2abc" oa))
+ (should-not (shorthands-intern-soft "a=C2=B7abc" oa))
(should (equal (oa-syms oa) (list s2 s3)))
- (should (eq (intern-soft "ZZ=E2=80=A2def" oa) s2))
- (should (eq (intern-soft "a=C2=B7def" oa) s2))
- (should (eq (intern-soft "ZZ=E2=80=A2ghi" oa) s3))
- (should (eq (intern-soft "a=C2=B7ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2def" oa) s2))
+ (should (eq (shorthands-intern-soft "a=C2=B7def" oa) s2))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "a=C2=B7ghi" oa) s3))
=20
;; unintern using short name
- (should (eq (unintern "a=C2=B7def" oa) t))
- (should-not (intern-soft "ZZ=E2=80=A2def" oa))
- (should-not (intern-soft "a=C2=B7def" oa))
+ (should (eq (shorthands-unintern "a=C2=B7def" oa) t))
+ (should-not (shorthands-intern-soft "ZZ=E2=80=A2def" oa))
+ (should-not (shorthands-intern-soft "a=C2=B7def" oa))
(should (equal (oa-syms oa) (list s3)))
- (should (eq (intern-soft "ZZ=E2=80=A2ghi" oa) s3))
- (should (eq (intern-soft "a=C2=B7ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "a=C2=B7ghi" oa) s3))
=20
;; unintern using symbol
(should (eq (unintern s3 oa) t))
- (should-not (intern-soft "ZZ=E2=80=A2ghi" oa))
- (should-not (intern-soft "a=C2=B7ghi" oa))
+ (should-not (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa))
+ (should-not (shorthands-intern-soft "a=C2=B7ghi" oa))
(should (eq (oa-syms oa) nil)))
=20
;; edge case: a symbol whose true name is another's shorthand
(let* ((oa (obarray-make))
(s1 (intern "a=C2=B7abc" oa))
(read-symbol-shorthands '(("a=C2=B7" . "ZZ=E2=80=A2")))
- (s2 (intern "a=C2=B7abc" oa)))
+ (s2 (shorthands-intern "a=C2=B7abc" oa)))
(should (equal (oa-syms oa) (list s2 s1)))
(should (equal (symbol-name s1) "a=C2=B7abc"))
(should (equal (symbol-name s2) "ZZ=E2=80=A2abc"))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 21 Jul 2026 21:17:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jul 21 17:17:14 2026
Received: from localhost ([127.0.0.1]:46113 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1wmHpw-0000a6-2w
for submit <at> debbugs.gnu.org; Tue, 21 Jul 2026 17:17:14 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20883)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1wmHpn-0000Z1-C6
for 80574 <at> debbugs.gnu.org; Tue, 21 Jul 2026 17:17:05 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BE70C1001AC;
Tue, 21 Jul 2026 17:16:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1784668616;
bh=9+hx4UvaRIknNsY11taQwivaFkG4+0b/7fTCvhb/5eY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=VVywzJYglX+x0Saw3T9T0MMwrf/FPWelqfT4EAxwfjQKs9ZKmCcOApar79oVJ7Ob0
DB0AaZ+90DbMFEWr/ZqCEs13/vMm+FuZRIGV8GwPcqVdokH5o3h5udsGigUkr6lvrc
ZoZGWrNyEBQNcMxeDdwb43daPl5eXeFLIxnnJOwkJk4ToqaW/QFHyE3Yzjqcaxz2ek
fvVGn6+H+YdtmvogJc0tshN+jzVeTRFwmkOLMEUpGRSi6SnvSNUvGxTeO1pZj+G5Y7
5lSMUPVkOvsL6hzpQiE/ErSGAnw+UP5IOdPOFEXnxIt+CIKq85w/Gwd3owTtKHwZ1Z
YUuF9UcUgfcEA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BC586100070;
Tue, 21 Jul 2026 17:16:56 -0400 (EDT)
Received: from alfajor (modemcable209.196-177-173.mc.videotron.ca
[173.177.196.209])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8E5C51208A5;
Tue, 21 Jul 2026 17:16:56 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwv4ihscare.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN>
<jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN>
<jwvikazydsx.fsf-monnier+emacs@HIDDEN>
<CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN>
<jwvbjgrnwak.fsf-monnier+emacs@HIDDEN>
Date: Tue, 21 Jul 2026 17:16:55 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.225 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80574
Cc: 80574 <at> debbugs.gnu.org,
=?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Lessee:
>
> % cat ~/tmp/foo.txt
> Some foo
> Local Variables:
> read-symbol-shorthands: (("vc-cvs-registered" . "message"))
> End:
> % /usr/bin/emacs -Q --batch ~/tmp/foo.txt
BTW, this hole still applies to the `emacs-31` branch.
I tried it with a `foo.el` as follows:
;; -*- lexical-binding: t; -*-
(yes-or-no-p "Gotcha? ")
;; Local Variables:
;; read-symbol-shorthands: (("vc-cvs-registered" . "load"))
;; End:
where merely visiting the file runs its code before you get to see it.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 20 Mar 2026 14:29:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 20 10:29:10 2026 Received: from localhost ([127.0.0.1]:33613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3aqb-00027n-HD for submit <at> debbugs.gnu.org; Fri, 20 Mar 2026 10:29:10 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:47596) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w3aqY-00027L-JN for 80574 <at> debbugs.gnu.org; Fri, 20 Mar 2026 10:29:07 -0400 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-48374014a77so18976305e9.3 for <80574 <at> debbugs.gnu.org>; Fri, 20 Mar 2026 07:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774016945; x=1774621745; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=iAztfVmJ5kiYfms4CUEpq3mkValpBurA2pYocnraCBI=; b=fD1mrIrDKhzDc7SzHJfE9bqNADqSY/1TFYEI1RfAw3OkSZVvS9XTYcPCmEcfqAm7a0 ecDgA6UZkk3DBggDZZWC5zU7KjDnQNveBWUMl2KoiBIxi128Gr3OAYHsQww0cPdnKMoa HNtWu2avrUomqcbhXprq1IpP0POMvTJuKpfH18qwtfy71CAaUrixkO9YvKwOdeNciBGM dGnmGTis6VGF2T1TiCZlSJs3pukgMrvpAOOhCBUnI7SBZN5QfDOQilPa/+II8Dmm3oBl 6zL6BFPecxKpIQxMSXfhGvvXc6O5uaeKwm/yPZE1BBh0waxMDV4ndUD/X8xXmJhLImlW v5dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774016945; x=1774621745; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=iAztfVmJ5kiYfms4CUEpq3mkValpBurA2pYocnraCBI=; b=Vpha1OU/V5Vog/t7kkP931VH+UmUUpB6xvfrSF4Mjmb6dEn4ZbR6GZNau9QUKXd4k5 XCDQo9aVHPaYWrJ2ojzxJrO7yQxzhOMqae7fnFElCWCAL0FvZOtzCdxUxwUAOuf43EC/ jty5SGwiutamE/0jzCiXSrUsm+gSDkBRszgifqAqcXfJhXAu7OHCN3TNvqQKh7Dm1knn 9i6P+jO/+sESAv6xNlgTzyFAAwXJU5oQBtazzgYUSaGnTkIZlVKR2q5V4X//1Pwb14w1 ua50uUft8QHDlEb6HcHgFGCd4vYwa4vKkwqr1xitCPAaBSWoZl8ijKkkGBFhBt9sHzDv YNCg== X-Forwarded-Encrypted: i=1; AJvYcCV6BDgHB57BP01aT5RJ4N0osTVynCko3Xt+NGy2mS4FRkL6IOI/IH52nkywyZXdd7pcpaUuhw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzeeWg/lHnKx3iS6kDYfsnx7md6EDLBFzIx1gyK5GrE8xfcWsHC tB+dK9ax4jRwCGu+CF/Tuaulk8esyZ/lf8qUkeBcC/6LyH5SQfaVeCV7 X-Gm-Gg: ATEYQzy6UdRqBuVg5TRHzJQj054z/DDFcH5gRuGcHY/QRFW2kTmvbDv8pnRKYq58/U1 LefWsXxtZQT9Tz9An4F3A1w/ShNwZAfpPBsgEjQKxtoBeJN2Efpu0Vbu3k8kdCzHyklydx/xdbk IDYqRVrQ0HLNWV85H0NWmyh9j4muEmm6rtmJFkE8nfUS1JRzTu7DdEcyDkZnhKj0qfxFRhW+qfO XvE1ELOzZxBUbhUSuhSUSRSz9k1XAxlMX3laTSpAgJvYdeEOWwVUMwNu7PiYjXJQGXfLwCcdqWz FWGOH7Baeq/ktYMSAWkBQt+RBthH4jXVYDOFmgMyat2i5FuXQQCyBLx8hl/2eGDdeoi5U4Ckyr5 wHDBI2ReXdyKI0ULWvdEvFT4r7HPBjXb3ohUHdBcm3Edhy7u+K9W9HV6SD4HDEigDgLsaEkazqa kdOAoRxbUZ6USBjXEykOpthiojZ4PnukzJTXJaezEuUMu/Gf5k0yaGiNmnisFhS9CHbhuw3PlqI +sIl+MvjQOvsEId99441VCjSxWoZWXZPpuiEQ== X-Received: by 2002:a05:600c:1d1b:b0:485:3cf3:1010 with SMTP id 5b1f17b1804b1-486febb5fefmr53363715e9.2.1774016945206; Fri, 20 Mar 2026 07:29:05 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b644addfbsm7205505f8f.3.2026.03.20.07.29.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Mar 2026 07:29:04 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86h5qbdjru.fsf@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN> <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> <861phfg9si.fsf@HIDDEN> <jwvy0jnixrk.fsf-monnier+emacs@HIDDEN> <CALDnm51LfN-rHNaYqUcbY6R8Dme2A-xdXOPUiyojua7eGPQVUg@HIDDEN> <86h5qbdjru.fsf@HIDDEN> Date: Fri, 20 Mar 2026 14:29:10 +0000 Message-ID: <87y0jmr2vd.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Eli Zaretskii <eliz@HIDDEN> writes: > So here's my last proposal: install this on master after the emacs-31 > release branch is cut. That will give us the entire development cycle > of Emacs 32 to see if there are any problems, and if so, how best to > fix them. But I cannot agree doing this so close to cutting the > release branch of Emacs 31. Sounds fine to me. But in that case, do consider (1) the patch I sent to make r-s-shorthands "unsafer" and (2) to restrict it to elisp mode (haven't sent a patch for this one). The accidental or even potentially malicious cases that Stefan conjectured seem fairly real to me. Even though they haven't materialized in 4 (?) years, the situation could change as more people start using them (even if incorrectly). Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 20 Mar 2026 07:48:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 20 03:48:24 2026 Received: from localhost ([127.0.0.1]:55647 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3Uam-0007QS-8J for submit <at> debbugs.gnu.org; Fri, 20 Mar 2026 03:48:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33888) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w3Uaj-0007Pf-VC for 80574 <at> debbugs.gnu.org; Fri, 20 Mar 2026 03:48:22 -0400 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 <eliz@HIDDEN>) id 1w3Uad-0003Zp-Tv; Fri, 20 Mar 2026 03:48:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=iilQRP1HtKR+jSbp1qLIEc1k7wAffkTmdUozogH4QQM=; b=Zj7lMgcrmEsvCtYLBnjb GD2TIbr4Bo62BnCBi+Akk4nGj9S3eZxpolNf7WcWL5GlYJz4+odgl96aG4xOs6OrbsRFDLLjSXdVv 2UbvRDp06oRDIG9eq4SUWS9L/kcgh0RqNOj27b0TnXO6LE8beP8L9m1lZVw5aQbNYq2rbDNPCsEZd q/HAFjcsaLEGK34EcdfE20H5PJZs3yPePLkt3riIXxQ3EfepQpnCcGNIk2p4O/mIetDl6vsDS4FyP 3GeExsV+SMd23JLzD8hwbyDGqIFaihcI4PTbpEZ3HoKuUAU+7GQJylqkh5lh70wpN4QTGdioOoee0 t5MXjPY1xoT4sA==; Date: Fri, 20 Mar 2026 09:47:49 +0200 Message-Id: <86h5qbdjru.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> In-Reply-To: <CALDnm51LfN-rHNaYqUcbY6R8Dme2A-xdXOPUiyojua7eGPQVUg@HIDDEN> (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 19 Mar 2026 17:15:01 +0000) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN> <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> <861phfg9si.fsf@HIDDEN> <jwvy0jnixrk.fsf-monnier+emacs@HIDDEN> <CALDnm51LfN-rHNaYqUcbY6R8Dme2A-xdXOPUiyojua7eGPQVUg@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: João Távora <joaotavora@HIDDEN> > Date: Thu, 19 Mar 2026 17:15:01 +0000 > Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, > Gerd Möllmann <gerd.moellmann@HIDDEN> > > > Every string picked up from a buffer with shortands in effect will be > > marked. > > Eww! > > My sense of aesthetics recoils at the idea of `buffer-substring` > checking the value of `read-symbols-shorthands` and attaching it to > every string as a text-property if it's non-nil, just for the benefit of > some hypothetical scenarios we haven't been able to find in the real > world yet. > > I have to say I feel the same. And it wouldn't work for xref-find-definition and similar things, cause the string is > picked up from user input in the mini buffer. Then we should find a way to cover those cases as well. No one said this problem must be solved by a single measure. If you have better ideas than the above, I'm all ears. > I've been thinking about this a bit more and perhaps Stefan's outstanding patch is really the way to go... all > things considered. Sorry, I cannot agree to making such a change without any additional safety at this time. So here's my last proposal: install this on master after the emacs-31 release branch is cut. That will give us the entire development cycle of Emacs 32 to see if there are any problems, and if so, how best to fix them. But I cannot agree doing this so close to cutting the release branch of Emacs 31. P.S. This part of the discussion started when I said that if this particular obstacle is overcome, we can install the patch. But what happened instead was that Stefan kept telling me that every potential problem I raised with this change either doesn't exist or is already solved in the patch, or is no worse than what we have already. IOW, instead of discussing the possible measures to prevent the potential problems with the change, this whole discussion was used up to once again convince me that my objections are unfounded and should be summarily dismissed. I'm sorry, but that's not what I hoped will be the result of this discussion, and frankly I feel that my time was wasted without any useful outcome.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 19 Mar 2026 17:15:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 19 13:15:19 2026 Received: from localhost ([127.0.0.1]:48612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3Gxq-0005Cf-Gx for submit <at> debbugs.gnu.org; Thu, 19 Mar 2026 13:15:18 -0400 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]:48612) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w3Gxn-0005CF-5J for 80574 <at> debbugs.gnu.org; Thu, 19 Mar 2026 13:15:16 -0400 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-417c34b0509so795139fac.1 for <80574 <at> debbugs.gnu.org>; Thu, 19 Mar 2026 10:15:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773940513; cv=none; d=google.com; s=arc-20240605; b=Y/YDXzi/f8zchajg8f+0yNR+FpYd/vgY/oz7PxCrZfRXAPEU7KOvo+Fe2XipKi2oRA tm8pG/OsmvHdhqihCK9mYw0Shr8cO+aB5Qexr084tcpeWkP7/FavuCYq2zKSdQihu0Xk 2ZNCHjb8Up3FpuMvovkHFVn+rzpqUUlqdRT28nJkWj3j7vp+VyGdRj3qxw0iwnlzw/it qLJkpR15d0PZ+i+qUZUJyXA5YqJN/37bpii07+hc8O7fju7dPtJpBSmdyCKyAFAqVGNn tmQs0DxP126Pd9j4PDyFabOepMb0V7oJi1saGzWdcrGDKox9+kTLRqh66WJ7uOkmeQ4z Zcaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=2vPSORM86fN/y6o5CS4Znu8xRA49mpn/pl/oXFf7kho=; fh=GuzsZvxgB1OntAVrdWtG1KGhq5VnsdLoKIBFjCExP50=; b=MGQ2wBqO+lk0Hl6kQv6M8t8kdQA6qLwCxjK/BJjS56NE9d0q+UVAxc9SX6pbgZD03v fFTav4ZujWiXlgp6wX9EMGvM5uHzyUwTHnDgfscaEYnK9D2bAK/4C3ZdvyPWhjZdhVD9 a/VqDE4MsXjp0i1zm/UvteDzYo5BBILT5Fx4v4xdaXGJYwmuVHn25S1ODsIGobzLhZEP yhifMPYWCpbic213fQRk7BXDGMunsUESSHGPo/vVAQ03HDt99p+yL7dyP85xXV2juzgc o/0frbT7Q4pYWE79MLTIfkrVsa1KIAPK1b5DHooGOqkOUlflcF3epCSyAmik6RmHGm0q P8Ig==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773940513; x=1774545313; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2vPSORM86fN/y6o5CS4Znu8xRA49mpn/pl/oXFf7kho=; b=El5HiMyhxVxQkJaWVL5sfoJaaKdAEZnIn54xvPx10snpQ1+beF/Q/z4cJvikR59f7o 8Ji52VKdtsC6+iITmHy7vy+6Upn3vM/D2kySf/GYVB6/KRBVROeBXgFV/1Xt3ioqNO/d Sn6YKwxbMjm/b7nnpl7HuVQNhtTPV+f+7JIQPWVE924j5kc9sXwB2vn7yotdNnxPEqGL 0T7A/2sIFxC6Yfct6oroCrBUDFm0HyO6Kw6eI0C7fDiQI5m3UFY4AK59gXv4HwS6iVe2 uer4PUikpWOQSSLTA/OyFDpr0oqxndGUA2cBJvyGgb8acmiWFLcQ+yJOSqsAtSIrdsMI DAhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773940513; x=1774545313; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2vPSORM86fN/y6o5CS4Znu8xRA49mpn/pl/oXFf7kho=; b=fNQkrZ0ae4aEHGpxoUPjo+F5m83CJoqiCHz0/euRVDcNJubDECpquiy9D53zC7DG65 WPIr1ynfZyR4bkLqPAQJRC5GJKxNDYjbWRqzAhJT1fP4c7jtvhLsrGtwPTqotcMgr92h OtRisACBqSF41jg6NyAi00UBudQa9vfvVWeTZQWMv17Ftv7or0XtyXNygVzNDV5xc+x6 o2hNsRzUlCBv0nLE7haiFHsQcv/CHFMowQI6+f/vnjcxhcTrYtaGDW+Z65stkUPFgHY3 Duf/0fBinCjZRrFa/FmF42gHsblHz/XJrBx3Yl0oAv9Ei4bwcC4/u76QdgESynx9touA 8+ow== X-Forwarded-Encrypted: i=1; AJvYcCVPKsRxo312DlZ0hlYNJSqjwlC75wruukJTlbD7/CeLd83ZMPtjy3xzXVVqxOvkwiWU1zob2w==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxkhPbGNjIkfe+L2uMIRFeDkaOau+hsFIfAiNAHQECX9hi7ezh/ 1QaT7QZEP/oyYfe6wodVKotEG9EsJzSfCd1ZLOaL6h2wuYxv234i+ZsQK4rsMx0r8Jcvth02QC3 LtTcTSXalcMr1PIuD3e2xse1sFxQOw0U= X-Gm-Gg: ATEYQzwk4pHcCBiQYmzrukEMa4bJmkJLXujBuafd26L0BSYlfHDBlscaK+7iWxnaB1q sBb7lp04dMoSOAmcMuJgTf9geZLHKUSw3809TS5GO9KRvHBkzMPERzrBqtXbDc8vUBWpW/PPC65 V0pK08wRKtN1weDYDgxE2X0pGrslNbwUDlNyI2qsWYIsaONW6L9g0XU0nL5NhtL+PFyWSZX+SUK K9lyJDl3pTvRigI5MXxTNy8C7oJJMd9hboZAPe3zvVoJxRiHRNU4003S5mgdopGxclvV83/+mBS hDERZ+w11RRC8spoPXFh75bgmv9uVSUCY1hiblOs4dqzAW05fqifjqqFHJJYVIJVkg0= X-Received: by 2002:a05:6870:fb9e:b0:417:a283:9c81 with SMTP id 586e51a60fabf-41bd41cdfe3mr5368696fac.35.1773940513423; Thu, 19 Mar 2026 10:15:13 -0700 (PDT) MIME-Version: 1.0 References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN> <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> <861phfg9si.fsf@HIDDEN> <jwvy0jnixrk.fsf-monnier+emacs@HIDDEN> In-Reply-To: <jwvy0jnixrk.fsf-monnier+emacs@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 19 Mar 2026 17:15:01 +0000 X-Gm-Features: AaiRm51mMraWie7zGJermCGvM5opnZq3-7IZrNpgIpQlnYgkKQ-udhL-Uavuxwg Message-ID: <CALDnm51LfN-rHNaYqUcbY6R8Dme2A-xdXOPUiyojua7eGPQVUg@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000027c706064d63b6f7" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: =?UTF-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --00000000000027c706064d63b6f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 19, 2026, 16:41 Stefan Monnier <monnier@HIDDEN> wrote= : > >> > That's why I think it would be good to have some way of "marking" a > >> > string to allow lower-level code identify such strings when we know = we > >> > should expand shortands, but no longer can easily determine which > >> > read-symbols-shorthands to use? > >> I have no idea what that would look like. > >> What code do you suggest would mark such strings? > > Every string picked up from a buffer with shortands in effect will be > > marked. > > Eww! > > My sense of aesthetics recoils at the idea of `buffer-substring` > checking the value of `read-symbols-shorthands` and attaching it to > every string as a text-property if it's non-nil, just for the benefit of > some hypothetical scenarios we haven't been able to find in the real > world yet. > I have to say I feel the same. And it wouldn't work for xref-find-definition and similar things, cause the string is picked up from user input in the mini buffer. I've been thinking about this a bit more and perhaps Stefan's outstanding patch is really the way to go... all things considered. Jo=C3=A3o > --00000000000027c706064d63b6f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto">On Thu, Mar 19, 2026, 16:41 Stefan Monn= ier <<a href=3D"mailto:monnier@HIDDEN">monnier@HIDDEN= a</a>> wrote:</div><div class=3D"gmail_quote gmail_quote_container" dir= =3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>> > T= hat's why I think it would be good to have some way of "marking&qu= ot; a<br> >> > string to allow lower-level code identify such strings when w= e know we<br> >> > should expand shortands, but no longer can easily determine w= hich<br> >> > read-symbols-shorthands to use?<br> >> I have no idea what that would look like.<br> >> What code do you suggest would mark such strings?<br> > Every string picked up from a buffer with shortands in effect will be<= br> > marked.<br> <br> Eww!<br> <br> My sense of aesthetics recoils at the idea of `buffer-substring`<br> checking the value of `read-symbols-shorthands` and attaching it to<br> every string as a text-property if it's non-nil, just for the benefit o= f<br> some hypothetical scenarios we haven't been able to find in the real<br= > world yet.<br></blockquote></div><div dir=3D"auto"><br></div><div dir=3D"au= to">I have to say I feel the same. And it wouldn't work for xref-find-d= efinition and similar things, cause the string is picked up from user input= in the mini buffer.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I&#= 39;ve been thinking about this a bit more and perhaps Stefan's outstand= ing patch is really the way to go... all things considered.</div><div dir= =3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o</div><div class=3D"gmail_qu= ote gmail_quote_container" dir=3D"auto"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad= ding-left:1ex"> </blockquote></div></div> --00000000000027c706064d63b6f7--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 19 Mar 2026 16:41:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 19 12:41:36 2026 Received: from localhost ([127.0.0.1]:48507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3GRD-0000bT-DG for submit <at> debbugs.gnu.org; Thu, 19 Mar 2026 12:41:35 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21270) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w3GRA-0000aq-Pd for 80574 <at> debbugs.gnu.org; Thu, 19 Mar 2026 12:41:33 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5F21D44314B; Thu, 19 Mar 2026 12:41:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773938486; bh=AAh1bix8hMejx1zOUsg7nNQpBi18HD9w7a1tgzjxtDQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZHLsCOsTuzBbFR31Lv0UUnis8GxTw97zUKa8elLYt6Dxq3SArzVqnU3xFzFdowoO8 qMrpUF42OvUZr2MAFcJiI19Cm2dmfPnWxy6RnIm6AzGbw09Ehi++H1u9nBiHd7kEvo MWeAP5jj0oFvrBfnpVcTLzPhOkh0hLn3l86zNeuS1Ant3FHvt3h2Oxe4eUCGWTGuEE LiaELAJSEy8kSyJb0aaV3EsuMUIHfJ0LVTEzS1G2YFd7ZpZ8VOq8SEGZY8g25pO1wy Vx1GrxNdaGQyS+WTDDGUzyAvH/hCWhxQEo3sC3UITLWGmaMBqRBXqspxG2EN4xxRxl ZKkN3ptGwwS5Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4D081443140; Thu, 19 Mar 2026 12:41:26 -0400 (EDT) Received: from alfajor (modemcable209.196-177-173.mc.videotron.ca [173.177.196.209]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2635512037A; Thu, 19 Mar 2026 12:41:26 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <861phfg9si.fsf@HIDDEN> Message-ID: <jwvy0jnixrk.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN> <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> <861phfg9si.fsf@HIDDEN> Date: Thu, 19 Mar 2026 12:41:25 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.382 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> > That's why I think it would be good to have some way of "marking" a >> > string to allow lower-level code identify such strings when we know we >> > should expand shortands, but no longer can easily determine which >> > read-symbols-shorthands to use? >> I have no idea what that would look like. >> What code do you suggest would mark such strings? > Every string picked up from a buffer with shortands in effect will be > marked. Eww! My sense of aesthetics recoils at the idea of `buffer-substring` checking the value of `read-symbols-shorthands` and attaching it to every string as a text-property if it's non-nil, just for the benefit of some hypothetical scenarios we haven't been able to find in the real world yet. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 19 Mar 2026 14:43:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 19 10:43:16 2026 Received: from localhost ([127.0.0.1]:47177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w3Eag-0002zQ-Ej for submit <at> debbugs.gnu.org; Thu, 19 Mar 2026 10:43:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53484) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w3Eac-0002xY-8N for 80574 <at> debbugs.gnu.org; Thu, 19 Mar 2026 10:43:11 -0400 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 <eliz@HIDDEN>) id 1w3EaV-0004ED-Vm; Thu, 19 Mar 2026 10:43:04 -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=fyf+5nM5IuCO2spNN/raf8C2hRN1RF4/Xh/kM4xpBbc=; b=mZUATTSP32/b yQVcSHnG49b89n/57p/acP3dMoumk6j3WeZW8o5Frd61nOemu2ejIMYBZnMTn439fM2Bu+aXmcZfw mU8sTqjkxPxcWg3Xpb4xX8W9/uBA6s9j23ZG0SY1csNQb3mnYRCrocr2ttxbXo9nXc5AkbDNYRqVn xk9oUtoy/UtkbgFKRpdH/faWv0nCbfhC0xvf7MFHCKhMDmA8EnBTJMiK7CMdcOxoQMx8ff5BDTFwj VhiNjoARjayqaRkC6mnMT+edlCJ8IRBPPvQvfaeX56aWmLmlMjqs9QDay/hkX7lfIsvn1jJpHS/k1 NBLdvjnGX6k2w3kV1uvlxQ==; Date: Thu, 19 Mar 2026 16:42:53 +0200 Message-Id: <861phfg9si.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 17 Mar 2026 11:53:12 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN> <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org, gerd.moellmann@HIDDEN > Date: Tue, 17 Mar 2026 11:53:12 -0400 > > > That's why I think it would be good to have some way of "marking" a > > string to allow lower-level code identify such strings when we know we > > should expand shortands, but no longer can easily determine which > > read-symbols-shorthands to use? > > I have no idea what that would look like. > What code do you suggest would mark such strings? Every string picked up from a buffer with shortands in effect will be marked. > If we "no longer can easily determine which read-symbols-shorthands > to use" then we can't expand the shorthands any more, so marking the > string at that point seems pointless. If the string is marked with the buffer, I think we can. Or maybe the string should be marked with the shorthands themselves.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 17 Mar 2026 15:53:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 17 11:53:20 2026 Received: from localhost ([127.0.0.1]:50346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2WjQ-0005pt-0b for submit <at> debbugs.gnu.org; Tue, 17 Mar 2026 11:53:20 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34131) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w2WjN-0005oe-7c for 80574 <at> debbugs.gnu.org; Tue, 17 Mar 2026 11:53:18 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 60C6F442F1E; Tue, 17 Mar 2026 11:53:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773762790; bh=dZM/7YbL36RgAuFSY/InW0JV3Sc5pYwTARL7stf9Qfc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KioKV5mme9vZvgMENllXFHmO5yQydO51kigbGC4hdn1x4QIruBSgD9pzDhbSFw9Cs zOoLo8vpp6om96LDECNn/Z3hjdmyemV0biBkc2ocKTEvhkaTvLmD0j20OavjdwBj7A RHPdXZNvz7K39btoYMas11GeLRIxBvODBVek6CqLkWe/kWvqzvtRl+T2LxI+QJdVLv FoeDvCsNHFjgOT7JPGcnQ/2kJUHCjeULJxE12/IH00pdh1KA9AfNnPcrjuQDcHbVPd gqO4ZDBZ3Z7ZmOif0+MJU0/i5J7H5pdg15S9GHBfPESq6VvA6cevficc6Gg3Az8Tid mww5tJ8+IQchw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 20F5B442F1D; Tue, 17 Mar 2026 11:53:10 -0400 (EDT) Received: from alfajor (unknown [10.35.232.150]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 132DC12062C; Tue, 17 Mar 2026 11:53:10 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86a4w6iq2a.fsf@HIDDEN> Message-ID: <jwvv7eulb4y.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> <86a4w6iq2a.fsf@HIDDEN> Date: Tue, 17 Mar 2026 11:53:12 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> > If not, what are other callers of 'intern' that could be affected? >> There are probably pieces of code that read symbol names (identifiers) >> from the minibuffer and keep them as strings before passing them on to >> some lower-level function that does the `intern` in which case the code >> that calls `intern` may not be the one that should expand the >> shorthands (e.g. because it may run in the wrong buffer or it may >> sometimes be called from other places where shorthands have already >> been expanded), and instead the shortand expansion should happen further >> up rather than in the code that calls `intern`. > Do we have examples of such code in our tree? Do we have functions > which do that and that could be called by Lisp programs? Can we review > those and see how best to handle them? Yes, we have such an example in `completion-shorthand-try-completion`, which my patch handles already, simply by calling `shorthands-to-longhand`. >> My patch does, in the form of `shorthands-to-longhand`. > Can we make such changes where necessary as part of this patch? Yes, the patch already does. >> >> > That's why I suggested a text property: it will follow the string >> >> > forever, as long as it lives, and each one of its consumers can draw >> >> > the conclusions it needs. >> >> But that would tend to lose the connection between the string and the >> >> `read-symbols-shorthands` that applies to it. >> > Feel free to suggest better ideas. >> >> The better idea I suggested for that is to call `shorthands-to-longhand` >> at the point where we know we should expand shortands and we know >> which `read-symbols-shorthands` to use. > These could be two different places, not a single place, though. I can't think of a scenario where that would be the case. > That's why I think it would be good to have some way of "marking" a > string to allow lower-level code identify such strings when we know we > should expand shortands, but no longer can easily determine which > read-symbols-shorthands to use? I have no idea what that would look like. What code do you suggest would mark such strings? If we "no longer can easily determine which read-symbols-shorthands to use" then we can't expand the shorthands any more, so marking the string at that point seems pointless. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 17 Mar 2026 12:44:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 17 08:44:09 2026 Received: from localhost ([127.0.0.1]:48018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2TmK-0000b7-Fn for submit <at> debbugs.gnu.org; Tue, 17 Mar 2026 08:44:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44914) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w2TmH-0000a4-3B for 80574 <at> debbugs.gnu.org; Tue, 17 Mar 2026 08:44:06 -0400 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 <eliz@HIDDEN>) id 1w2TmB-0005cO-DL; Tue, 17 Mar 2026 08:43:59 -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=PD0XesmhJwltBCC2lXN4y3WXcJLxbWykKI4ohZrBCtw=; b=A+mljNKwCjlH u4LKp6APrRXJ5UqK2wpE1SyeP1/MUEvBCURmEVP7ZuBuvHObwO3gxB4XmMMlMnBoeXNvIMlofsCzY 2I6JK93tHfiQ4tvlHYQbpeK512yjx4fF/j23EpQKkOdeOResKvR/STcufOigd4+DirCg1UcHwJXjF mPqgGFVuJwXgjL1QhJAGZeBbvxbq2CT01VZUrp/VDWkJ17wmfHxa3qdPVRPqNOKFCL3vr74lkdofa Tw6c7DGKLOGDC3kD5aNa4+C1T2ITEZrH7Nf+FC8Y9FksDwf/mACDkoJ2Qd3HRrYEMOIxfLIDyKRch gVsK0/KJdbhllfrr/pk4Kg==; Date: Tue, 17 Mar 2026 14:43:57 +0200 Message-Id: <86a4w6iq2a.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Mon, 16 Mar 2026 17:07:55 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org, gerd.moellmann@HIDDEN > Date: Mon, 16 Mar 2026 17:07:55 -0400 > > >> AFAICT this `Fintern` is there to handle the (unusual) case where > >> someone uses a string as a face rather than the corresponding symbol. > >> E.g. > >> > >> (put-text-property BEG END 'face "bold") > >> > >> AFAICT it would be incorrect to apply shorthands here: > >> > >> - Shorthands apply to symbols found in ELisp files, not to strings. > > > > So you are saying that the only 'intern' call that matters is in code > > that reads Lisp, i.e. 'read' etc.? > > Mostly, yes. Well, "mostly" means "no" in this case, as you explain below. Meaning that there are other calls of 'intern' that matter. > > If not, what are other callers of 'intern' that could be affected? > > There are probably pieces of code that read symbol names (identifiers) > from the minibuffer and keep them as strings before passing them on to > some lower-level function that does the `intern` in which case the code > that calls `intern` may not be the one that should expand the > shorthands (e.g. because it may run in the wrong buffer or it may > sometimes be called from other places where shorthands have already > been expanded), and instead the shortand expansion should happen further > up rather than in the code that calls `intern`. Do we have examples of such code in our tree? Do we have functions which do that and that could be called by Lisp programs? Can we review those and see how best to handle them? > >> - If we really did want to apply shorthands, the relevant > >> `read-symbol-shorthands` to use would be the one that applies to the > >> ELisp file where the string was written rather than that of the buffer > >> where the string was placed in a `face` property. > > Then we should provide a way of doing so. > > My patch does, in the form of `shorthands-to-longhand`. Can we make such changes where necessary as part of this patch? > >> > That's why I suggested a text property: it will follow the string > >> > forever, as long as it lives, and each one of its consumers can draw > >> > the conclusions it needs. > >> But that would tend to lose the connection between the string and the > >> `read-symbols-shorthands` that applies to it. > > Feel free to suggest better ideas. > > The better idea I suggested for that is to call `shorthands-to-longhand` > at the point where we know we should expand shortands and we know > which `read-symbols-shorthands` to use. These could be two different places, not a single place, though. That's why I think it would be good to have some way of "marking" a string to allow lower-level code identify such strings when we know we should expand shortands, but no longer can easily determine which read-symbols-shorthands to use?
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 17 Mar 2026 02:45:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 22:45:19 2026 Received: from localhost ([127.0.0.1]:43544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2KQo-0007aY-RL for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 22:45:19 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37826) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w2KQl-0007Un-Ey for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 22:45:16 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2BDC581DB6; Mon, 16 Mar 2026 22:45:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773715507; bh=JkoIi9un4R2v3yWlWolJsdV7iJzT/h38ScBFeJVEvsw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bNI6gvI1ZPoVEnzJ1EEooP3WLkJjIsFs+QsDYtNWAD+8oJemAv5whGSfy3VIEyLkP RY2KuA9dmFGtjnEIUxuKTF1yEnB8RpqvT5IuCh+9znO5+v1Ons1irg6i0/W5bkdn8J p+5NS20mHMXBY7H4TikWAhgb203Qzmkqei+DqQ5gpWGSWbxsx33WNIbPUjFcACvVx1 lIJXRz5GTmnhC7JCh279640a9fzqQvulK488zmjTqVn/hRRxZ1GreDATN5Ly65DF9R krTf6+5CWWtfJW3f+dJha0gepHG0O51y8KkroUdxaJJ4IeWlyT/7RJZduQRijg88bT igmBjod0uCuRw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 91C8780644; Mon, 16 Mar 2026 22:45:07 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5AEAD120480; Mon, 16 Mar 2026 22:45:07 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <87jyvbxwyp.fsf@HIDDEN> Message-ID: <jwvbjgnch3k.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <87wlzcyb21.fsf@HIDDEN> <jwvpl54ec2e.fsf-monnier+emacs@HIDDEN> <87se9zybnu.fsf@HIDDEN> <jwvse9zcxeo.fsf-monnier+emacs@HIDDEN> <87jyvbxwyp.fsf@HIDDEN> Date: Mon, 16 Mar 2026 22:45:06 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.242 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> [ Another funny `intern` case is the one that normalizes events, which >> could bite if you use a shorthand prefix like "C-", "M-", ... ] > Link to source? `apply_modifiers_uncached` in `src/keyboard.c`. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 21:53:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 17:53:34 2026 Received: from localhost ([127.0.0.1]:41026 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2FsT-0001wX-8V for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 17:53:33 -0400 Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:42010) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w2FsQ-0001w5-9h for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 17:53:32 -0400 Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-48538c5956bso1431245e9.0 for <80574 <at> debbugs.gnu.org>; Mon, 16 Mar 2026 14:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773698009; x=1774302809; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=NiDmRAbTzLNwVaymlUZgxt9vWcsFjJY27S2DiFdtinE=; b=Zf8Uw2fPdiTw65K/9lwyQOArKEYyr4awHE9cjtmdi5Zio47XgiqVt3Hc17JI49jr6E vGrSb49D28m8xl7axrUqAuDW2Mgz5KDAZKqGTIbz75/AgslzuncVlbYfDA/SZrqFjNoY EkCCDwEsGFgwARdsxYQz6o/8/02N20gWN9qKTzr7kEwKU/JLjaCNJclutZ63NpSY1uR/ fn/rAFCbuwj40I/2l3DcHT4Two+90oWDeHbCwL2f1ySJD5LNvzXK2fxPKY9tnUYRyJaf AK7wmXl1n64/9ECigaKEJpsl9hmSkyWaf+WBvuRxoSvleysjBuEWPo8GU08rL6ctsmkX Eq1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773698009; x=1774302809; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NiDmRAbTzLNwVaymlUZgxt9vWcsFjJY27S2DiFdtinE=; b=kItIyPk063jVfHmZh4wWPCd7s1F7I2vDaWwh7fHf5JbZJZ50A2O3jeeLrKXyVaNmTa cPCbuP1Eqhx9sa9D5PVdbMEh+8FrTL2ReiMvFpcqFXsFt3jp2qR3r2caAsScQvOh6X0D n5I/S3pKzxVTjHhxQVH6Z/SjWkzoJGej/FEXeDC3FkDaWwY8zxleptsx0jYF840iNOJs 6o7946sBceX4V/+d9QTkbn9GW0rSiq2O90iu+RpKfRGs0rmLE0aU+OO4P7E1HpTEhWFs MTC5qcxUKExNi17yAlMaQGZrWieyNOhugvhiXBKOmMA5m6n/9zdOov9VsjZVWO1nOYGL MfCw== X-Forwarded-Encrypted: i=1; AJvYcCWPgkAyDtATH0HeG1V2d++DcdtMdLGpTDznBJ/ZUOxMMsj70ZwUXDEEDA5fBvBLAKfsY+oxHg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzEIRf1jimmYiyUoe2D/d65Hok3LM+MZF1VimnswXZ7rjcIiHUb 5bRljjqSor9lIm1PHsNUKOtU5IwCeiBhWpGba0qA8DGarR1YWdwD86dz X-Gm-Gg: ATEYQzxdJ/59ndPIDRiupylAKUXKUh9+G237hgLKc876WvcDha7b08hGQdG30mmsxRd vT/iHHPd+fwWYvLHG9iSRH+AENh2ixCHCSdpAbg6Q++ftz/m+DsEIzRBqzH+T4HO5jEAB50H3/5 Nuo2pf27KONW58ZzIf6TIUU7aXgKoGO/zx/ECS+IVdDBAx+dymBGsfYnRJJCcpWq1sRQhKkw+8D t6t6Mra6ebYYGzWjA//DVHLBAzfqQpU9Mkzjl82inzjZqodslK0HHvsWel40zPqtcNLSYakByrj LDkjvXrQ0F5om/HfTgDB6d3ls4qSYqnW0QhCJBAJRCW0mWQ3F62l6L/Rk9g0xUvcBoM4gHq3Kay 2mkdVhGjvhxpGjYI6Mh4yE92Pxq7WsC2hPROOKqXXujL+ZpO3PBDl3jV5Od6uUFefkFZB/qZQ9D k0Z5HAyH+1L7KvpvRFNWo0gIygVWzsuuN+pOncEshGcZBb+IpIkKmcc+2qDdCmUcyg6v9NwOISp ZtRWw5W41y1PcG7OVySEBfRO+zZmPPl8qQi9g== X-Received: by 2002:a05:600c:3b08:b0:483:6d9e:e4f5 with SMTP id 5b1f17b1804b1-4856eab4fccmr17042655e9.5.1773698009009; Mon, 16 Mar 2026 14:53:29 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4856eae3396sm20715765e9.9.2026.03.16.14.53.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 14:53:28 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvse9zcxeo.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <87wlzcyb21.fsf@HIDDEN> <jwvpl54ec2e.fsf-monnier+emacs@HIDDEN> <87se9zybnu.fsf@HIDDEN> <jwvse9zcxeo.fsf-monnier+emacs@HIDDEN> Date: Mon, 16 Mar 2026 21:53:34 +0000 Message-ID: <87jyvbxwyp.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: >> I've a branch containing this and other patches. > > [ Not sure if we can accept that code, because IIUC there are some > unresolved questions about the legal implications. I don't follow > this closely, so I'll let Eli or Sean confirm/deny. ] Yeah, makes sense. The pcomplete one was written by hand though. > >> The pcomplete patch in >> that branch is almost done, just needs some care about the autoloading >> aspect, which needs to be done specially. It interns things in a >> separate obarray but is backward compatible to uses that define >> functions on the main on. I was working on it until I noticed pcomplete >> has been deprecated since Emacs 27 (good riddance) and convinced myself >> it wasn't worth it (guess I'm not an LLM yet). > > Actually, it's "`pcomplete`, the command" that's been deprecated. > Not "Pcomplete, the library". It's just that the Pcomplete library is > now supposed to be used via `pcomplete-completions-at-point`. I see. Then the pcomplete patch is relevant I suppose, I just have to fix it. >> But seems vc uses the global obarray for everything, even Git revision >> sha's get interned there??? Not all these uses will ever clash with >> Elisp/shorthands though. > > With current implementation of `intern`, whether they clash or not is > mostly a question of what `read-symbol-shorthands` happens to hold, so > we can't rule it out. If we make read-symbol-shorthand apply only to Elisp buffers, easy fix, so "clashing" is tantamount to "command being called with an Elisp buffer current". Thus we can indeed rule out many of these cases. > [ Another funny `intern` case is the one that normalizes events, which > could bite if you use a shorthand prefix like "C-", "M-", ... ] Link to source? >>>> My point is that such things only becomes >>>> "shorthand-file-visiting-dangerous" in very specific conditions. >>> Agreed, but remember I want to fix the bug rather than only the >>> associated security hole. >> Is that ever called from an Elisp buffer? > > It's in `editorconfig.el`, so can be called in any file buffer. It can, but does it _need_ to? This piece of code, odd as it is, is an example that is correct in calling intern-soft and indeed doesn't want shorthands. So my fix would just be to call it in a temp buffer though (or do that thing where obarray is passed explicitly and that disables shorthands). Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 21:33:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 17:33:53 2026 Received: from localhost ([127.0.0.1]:40870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2FZR-00089q-59 for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 17:33:53 -0400 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:47465) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w2FZL-00089E-Hs for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 17:33:51 -0400 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-48374014a77so53423935e9.3 for <80574 <at> debbugs.gnu.org>; Mon, 16 Mar 2026 14:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773696826; x=1774301626; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zsPqBnoThMwzgcRKd4bxRogA2vsvhKuDdNf2jIixDls=; b=OJ9rkE1Dudc7zQyKymuqsh0o0TzGGVziZnCB7IpqpNH6IS1j9n34bteuHCxZZlr7dS RtPrXyStm1G+qB+nGLgjbhLanzzuEffoTFwYoT3X6hvFe0++ZoiKKu6CsurqRZsKoNFZ wDFbmPE43/3VurT+zEt3dRbH18AZ6fUERWXLVCzVI0tKog66CuA8Lpb0n1dU5BVIHCS6 qJfpBQCNP+1TsnvxoVUKqoeGKcs4XOyzI8gj6uUcXVCYYIVizne7h+LomFfKCYlDQ6q6 fYu4Yh+xxz96jxsiqdsloR0RTXdXwrYIksYArE7l15tXoRtnpusqsrxWRsc92dNjgjm+ HqPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773696826; x=1774301626; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zsPqBnoThMwzgcRKd4bxRogA2vsvhKuDdNf2jIixDls=; b=sg53PY1i//GwftraabJwqusnXicuoiJ13UrB4ZRGyXfFZCVsKLp5szrPOAJN005owl v29fvMJBug0KHzldYf9zBCyqxx3wSvxUPWJrIMlDbv7PVlNo6th+XPKkSHrnqWz+304g dsG/i+gvEYCp8KZrdVqiranpPmZ6rdlM0sv2IQB57UVNf1tZI/5RIgOhsU956ShBmKil PUYEUWH3H7RICFgiQG03U1z+k7m1b7Q2y01Ln3po9ctwBSBei6k4yhfibH/nMdAJtM9K M474OXgkOBh2pyTDgmlNS+HJu3gtGj5YjRsL24AjxP5sLKaetlccPFTDXnisSLTjmigI 0iTw== X-Forwarded-Encrypted: i=1; AJvYcCVUNc7Lx3hqxLRhZtuBCU6f3D2ExBJjiCis5HNbW4E8XcubGrReNHVYIltpJMtomKw7V+pGNw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy59H8u7KONVzWcP4Ri79CRUVgTxYXl7KKadcjg7bW5K6GW7duN UKE8IPmRgWIDAGFJG/1d/4UwKh5WjZOksB+1cnLBGuq6Q9ZwLT6fPVUUmwZULg== X-Gm-Gg: ATEYQzxWameD+9AXP3gc6RXobN15BOupKcE+0f0df1xccU2oIDms3HWnQySj2f07o/x e7193eB9Y0ooi4B6KIe9vyJOwbzmN3D9g9BhDYmmDu4JazVlBb8cf5qDLLXIXSDd1DWn8Qn/Awl KcOgodghenMnngDdUAA4VzqjVcPoQFs9K2IRf367k+RMIa8SQyvPqbjrD/LE220x/sMCkbx/VKC 3W3oKJ7glU7hrm1V3SMEOyEI8haLbr1uqh+Ib5dhldfb91Y86TPqH+H834zi9DZx8ZKrxOwwGG7 yfshBAdCSiHWaqb0+ib+12Yi52K+gi2w/tgSAKxB3OQfgE+zINAX3Vdq8Agp110Eta/wPELxdXu o0kZviUyDgU9JrCVHJOusNzmYSoCyE6BPWXmg/KuOjHdu1M3TpxVa5ZvNQcOVXA+W4+Dl2NSMPG mLKesW+BRYlOLS/GI1G/0J/1345/RsFPNOrwLCWoZihQJ1hUjGpkpIrB92gqE1cxvH1RiWzC4UV Nu5TgWi8NWCZ+hHP8y0P2JmS0M= X-Received: by 2002:a05:600c:1f96:b0:485:40db:d40c with SMTP id 5b1f17b1804b1-485566cf8f0mr264003295e9.3.1773696826103; Mon, 16 Mar 2026 14:33:46 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4855725572csm209419135e9.2.2026.03.16.14.33.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Mar 2026 14:33:45 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> Date: Mon, 16 Mar 2026 21:33:49 +0000 Message-ID: <87o6knxxvm.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: >>> AFAICT this `Fintern` is there to handle the (unusual) case where >>> someone uses a string as a face rather than the corresponding symbol. >>> E.g. >>>=20 >>> (put-text-property BEG END 'face "bold") >>>=20 >>> AFAICT it would be incorrect to apply shorthands here: >>>=20 >>> - Shorthands apply to symbols found in ELisp files, not to strings. >> >> So you are saying that the only 'intern' call that matters is in code >> that reads Lisp, i.e. 'read' etc.? > > Mostly, yes. Sorry, but this is at least a bit misleading. The answer should be "Statistically, yes". 'read' is a of course a prominent user of 'intern', and thus needs to be aware of shorthand translation, but any piece of code that analyses strings relevant to Lisp code also needs to be aware of them. What we do have is a large number of 'intern' callers that use the single Lisp symbol namespace as a substitute for a quick-n-dirty hash table, and these users outweigh the "legitimate" ones. >>> > That's why I suggested a text property: it will follow the string >>> > forever, as long as it lives, and each one of its consumers can draw >>> > the conclusions it needs. >>> But that would tend to lose the connection between the string and the >>> `read-symbols-shorthands` that applies to it. >> Feel free to suggest better ideas. > > The better idea I suggested for that is to call `shorthands-to-longhand` > at the point where we know we should expand shortands and we know > which `read-symbols-shorthands` to use. These are all variations on the same theme. You don't actually know which current 'intern' or 'Fintern' users have been doing the right thing obeying shorthands for the last 4 years and 3 major versions. What has been identified so far accurately is that some users definitely _don't_ need to obey it (because they're using the obarray for what we called "dubious" or "smelly" uses). The text property idea actually seems solid from a conceptual point, as it really tracks the provenance of the string about to be expanded. But it could be fraught with other perils and is definitely awkward, burdening programmers about how they get text from a buffer or file. Again (and I know I've said this a million times already) I think the best course of action for safety/bugs is to 1) keep the status quo -- all 'intern' respects shorthands 2) gate r-s-shorthands behind a safe predicate 3) additionally make r-s-shorthands not apply to anything but Elisp buffers 4) address the known dubious uses of 'intern'. 2 is blanket safety 3 and 4 cover a very large percentage of the accident/attack surface Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 21:08:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 17:08:06 2026 Received: from localhost ([127.0.0.1]:40755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w2FAT-00066B-S5 for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 17:08:06 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9883) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w2FAR-00065a-5L for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 17:08:03 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id CBE1481DB6; Mon, 16 Mar 2026 17:07:57 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773695276; bh=v1tgUeYvq/lElEGWmaU9DRmGyFLm3tbVQMxN8fD87fc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=jVuJQzxuJvD3ExGOjDBcHMW9Vd8Sa3k9/9RiZmkXRSS/UPfuToaF41XmKkvF2OpLi 9nTHIpTAjxlrEwKaIi4mXxNyUSAOBr4OaHHo9PJm96WXJZ2Mw8J1Xnqbts/3EzJuMu 6s/oE/cxcNDO6NJXWkcf9wquSrIsdLthc2sR3NUvlpwfr4FRIUkEOcvTqJilva2H5e J/tBZwjF9F8CVbgdaToZrDhWAG/3F4I3ZNbwkHECKoaTOOdWk0IglN7uemPf6THrjj 9JK+GTWhgltXF7KMUo3KScTA9vIBEq8DjCPLsidgNEay3EtmWqPHS/dJMrAXpMHb4H C0xYo3xw7Zgqw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E1E6180644; Mon, 16 Mar 2026 17:07:56 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AFE9F12038D; Mon, 16 Mar 2026 17:07:56 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86fr5ziyw3.fsf@HIDDEN> Message-ID: <jwvms07cwxf.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> <86fr5ziyw3.fsf@HIDDEN> Date: Mon, 16 Mar 2026 17:07:55 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.243 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> AFAICT this `Fintern` is there to handle the (unusual) case where >> someone uses a string as a face rather than the corresponding symbol. >> E.g. >> >> (put-text-property BEG END 'face "bold") >> >> AFAICT it would be incorrect to apply shorthands here: >> >> - Shorthands apply to symbols found in ELisp files, not to strings. > > So you are saying that the only 'intern' call that matters is in code > that reads Lisp, i.e. 'read' etc.? Mostly, yes. > If not, what are other callers of 'intern' that could be affected? There are probably pieces of code that read symbol names (identifiers) from the minibuffer and keep them as strings before passing them on to some lower-level function that does the `intern` in which case the code that calls `intern` may not be the one that should expand the shorthands (e.g. because it may run in the wrong buffer or it may sometimes be called from other places where shorthands have already been expanded), and instead the shortand expansion should happen further up rather than in the code that calls `intern`. >> - Coders who want to use shorthands to name their faces can use the >> symbol instead of the string to refer to the face. > They can, but they don't have to. As I said, "Coders who want to", yes. >> - If we really did want to apply shorthands, the relevant >> `read-symbol-shorthands` to use would be the one that applies to the >> ELisp file where the string was written rather than that of the buffer >> where the string was placed in a `face` property. > Then we should provide a way of doing so. My patch does, in the form of `shorthands-to-longhand`. >> > That's why I suggested a text property: it will follow the string >> > forever, as long as it lives, and each one of its consumers can draw >> > the conclusions it needs. >> But that would tend to lose the connection between the string and the >> `read-symbols-shorthands` that applies to it. > Feel free to suggest better ideas. The better idea I suggested for that is to call `shorthands-to-longhand` at the point where we know we should expand shortands and we know which `read-symbols-shorthands` to use. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 20:59:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 16:59:49 2026
Received: from localhost ([127.0.0.1]:40722 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w2F2T-0005Wk-Cf
for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 16:59:49 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39942)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w2F2R-0005WP-30
for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 16:59:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E401A100034;
Mon, 16 Mar 2026 16:59:40 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773694779;
bh=sTuWcrKAA0qGx8mPwSVO4IiRBllwEHDqb+Gllc66y7U=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=hIPbbmc/f6JJxgiWRGp38JbtB5D3zql227038S/zSQUOev/t+0wQ8zDfkR8sg8uwG
VQidHoCjdF7OoCovcpXTnr3WGRnXCyMxsg7RaqVdkp27ajBr1fTigI4o8B5vHKnUXR
/eZJRzyLT99AuEaChqsd18PmuXrkA/T6/t2cMwX+SYzGrsTkRW9v1t5UMUqOOaPUjL
DdEKcNeJwSOZ3v6YLm4SJnsJm8ZmBzsg2ubR42RSTrAGXeL9oURGYEphXXS19gXwqW
A6BPrzPxITIVYN5Vche4ThJZQgXMWUL30q51WBZWmsBox0NyZJQrSAqDjpaDjJQBGo
vLleZZlYKeH4Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9F91E100029;
Mon, 16 Mar 2026 16:59:39 -0400 (EDT)
Received: from pastel (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 67B731209B4;
Mon, 16 Mar 2026 16:59:39 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <87se9zybnu.fsf@HIDDEN>
Message-ID: <jwvse9zcxeo.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
<jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN>
<jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN>
<jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <87wlzcyb21.fsf@HIDDEN>
<jwvpl54ec2e.fsf-monnier+emacs@HIDDEN> <87se9zybnu.fsf@HIDDEN>
Date: Mon, 16 Mar 2026 16:59:37 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.057 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
> I've a branch containing this and other patches.
[ Not sure if we can accept that code, because IIUC there are some
unresolved questions about the legal implications. I don't follow
this closely, so I'll let Eli or Sean confirm/deny. ]
> The pcomplete patch in
> that branch is almost done, just needs some care about the autoloading
> aspect, which needs to be done specially. It interns things in a
> separate obarray but is backward compatible to uses that define
> functions on the main on. I was working on it until I noticed pcomplete
> has been deprecated since Emacs 27 (good riddance) and convinced myself
> it wasn't worth it (guess I'm not an LLM yet).
Actually, it's "`pcomplete`, the command" that's been deprecated.
Not "Pcomplete, the library". It's just that the Pcomplete library is
now supposed to be used via `pcomplete-completions-at-point`.
> But seems vc uses the global obarray for everything, even Git revision
> sha's get interned there??? Not all these uses will ever clash with
> Elisp/shorthands though.
With current implementation of `intern`, whether they clash or not is
mostly a question of what `read-symbol-shorthands` happens to hold, so
we can't rule it out.
[ Another funny `intern` case is the one that normalizes events, which
could bite if you use a shorthand prefix like "C-", "M-", ... ]
>> I just remembered one case in Emacs itself, due to yours truly:
>>
>> ;; Fallback, let's try and guess.
>> (let ((suffixes '("-indent-level" "-basic-offset" "-indent-offset"))
>> (guess ()))
>> (while (and parents (not guess))
>> (let* ((mode (pop parents))
>> (modename (symbol-name mode))
>> (name (substring modename 0
>> (string-match "-mode\\'" modename))))
>> (dolist (suffix suffixes)
>> (let ((sym (intern-soft (concat name suffix))))
>> (when (and sym (boundp sym))
>> (setq guess sym))))))
>> (when guess `((,guess . ,size))))
>>
>>> My point is that such things only becomes
>>> "shorthand-file-visiting-dangerous" in very specific conditions.
>> Agreed, but remember I want to fix the bug rather than only the
>> associated security hole.
> Is that ever called from an Elisp buffer?
It's in `editorconfig.el`, so can be called in any file buffer.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 16:36:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 12:36:06 2026
Received: from localhost ([127.0.0.1]:36175 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w2AvG-00061g-4E
for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 12:36:06 -0400
Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:47123)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>)
id 1w2AvC-000614-6j
for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 12:36:04 -0400
Received: by mail-wm1-x336.google.com with SMTP id
5b1f17b1804b1-4852fdb36a8so56988115e9.2
for <80574 <at> debbugs.gnu.org>; Mon, 16 Mar 2026 09:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1773678961; x=1774283761; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=FahhY8fPlm58VJ4dAp60zGAbD7GV4b42zQkY8joyY4A=;
b=K5whlGrcW7PHwGvYD91WziqbkLNWfYpiQn9w+ATIBrUuLfJ2lGjnybtIM6Sj8NyMk5
6lOH+bsyGPXG84gUtHHZp4Qt2AOdqOKEjEKMUT8TC4C+enOcnQ7BlVZ07UyOHJYpufwA
wngTMWfMyIgBFrbdG55Lg9YdYOPMfMBSrUb+H859Q6uQ8szuN1kXWB9H9TFgYRNWPVxI
N2S9/pF5Xwrq0i7kgngcURs/t1v66sr6+C19gW5/w+D4cuWSEvRwdFo0KA+SOmMwXhat
UBT5wOMmKdQSLAeDv/+6hIjnBpEM5VNRT4iNXW72t6q1RtP2EGUXZew7MiLhhNAwSs9Y
ud7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1773678961; x=1774283761;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=FahhY8fPlm58VJ4dAp60zGAbD7GV4b42zQkY8joyY4A=;
b=YG94PiHfwMWbASNGxSu6iuuW99xz+u+RmFHP5A55+DM/L2X7/hTJh6dtL6Irwhf+aB
hL84VUxr3luHG3ijdZo6GLNeg4t4w3IlcFIMmf30EdLJ/nxkbtWTItVRwSBtZXGQZRkF
oxUCa+XutbaHcxlY1ULqgkHgivso1etzj9a757vQ4//fjWVeeVd7lO/lDCESfwpMAP6z
i1EmYh+tp/b0fhoymI2DsvaAZfhKNRg69pnV5K+Z7mFpRTXG9r61KICWycPxbCrdqZrE
3v7exlItifx7xPZ3K+5D7/wxIKlc04Pf+NjovEjlz037bH0MxdNefRGmatk/jcPDn0KK
R2fA==
X-Forwarded-Encrypted: i=1;
AJvYcCUBQHk3JELDeFnFhfskO98C6zmww4g3O5v2Z+GGpaKCCkkvqmXTNcbe7uPfpdR09wmQ/5NGZw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyXk/Qphi6xFCB7yQI+FXyOV+VyyON5uIzondB7Kxzn0hQHDb2a
DgtZwR4OINQXYr66DBSKpp10c5cZV4sTZrKqGGe+3kNH7Vl2EYzJUpIX
X-Gm-Gg: ATEYQzzPVOu6xJlBG0V7Wor6YQCw393+qN22GYGdH/pe5wKA4i9ffKZGVG7Ucwyk4LX
aKPwaBQ/1Y0hynBPdzTtZ+P0kyXmqWREPX7ehPwdAVlF5ZOSSLocyWuZ0xvoNvmU5m8KVrpFFY8
o4CO7HjaZMLP9IN1YBlSgjYGNGkjcL9qHKujOokwzSOd8pz9PH4X6sGxL61CguxrTygR+phYbkD
tEByH1U87/v6yvUFnvbrpeICHSOExc8B6hefRI6VsnEwcJJSYwqi4hl92SD1XkbswanIPfFleAZ
/al09JrvvpAGlf7rxYUbxsf/HsHfeCG7jBCEGF95I/ZHQSWbx1aUtgsNEBrvFuWnoTAhWsp69tA
AsqBChpnpPFahJ7ZzILsVV000iKrdPKC/a69fYVbjkb2+cHQhtlX/iIq6+KBYuay9521mI4WWTc
yBXq/TMBJ5eRCob/F8bQhqn9twFKvGzo0mIpA3hWQhBUogb59Rbqxkdbdkj787TbXLWrbfqgArH
q+ij4ACUSBGMWtiQ01UUcAiXF4=
X-Received: by 2002:a05:600c:3b14:b0:485:3f1c:d8a4 with SMTP id
5b1f17b1804b1-485566d6e54mr241271235e9.9.1773678960583;
Mon, 16 Mar 2026 09:36:00 -0700 (PDT)
Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-4856eaa39cesm6004095e9.10.2026.03.16.09.35.59
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 16 Mar 2026 09:35:59 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <jwvpl54ec2e.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
<jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN>
<jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN>
<jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <87wlzcyb21.fsf@HIDDEN>
<jwvpl54ec2e.fsf-monnier+emacs@HIDDEN>
Date: Mon, 16 Mar 2026 16:36:05 +0000
Message-ID: <87se9zybnu.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
Stefan Monnier <monnier@HIDDEN> writes:
>>> AFAIK, it's not trivial at all because of the sheer number of them (and
>>> their impact on APIs which means that such changes need to be
>>> synchronized).
>> I haven't seen so far any case where the dubious/smelly use of intern
>> isn't an implementation detail and part of an API.
>
> By API I meant things like `pcomplete/<COMMAND>`, `eshell/<COMMAND>`,
> `vc-<BACKEND>-<OP>`, etc...
> These conventions form APIs which are documented and some external
> packages rely on. These are not merely implementation details.
Yes, forgot about that, you're right.
I've a branch containing this and other patches. The pcomplete patch in
that branch is almost done, just needs some care about the autoloading
aspect, which needs to be done specially. It interns things in a
separate obarray but is backward compatible to uses that define
functions on the main on. I was working on it until I noticed pcomplete
has been deprecated since Emacs 27 (good riddance) and convinced myself
it wasn't worth it (guess I'm not an LLM yet).
>>> Tho your patch would need to preserve backward compatibility with
>>> external backends until they've been converted, so the security issue
>>> would remain for those.
>> I have more patches to those too, if you want.
>
> Go for it!
In pushed branch 'scratch/less-dubious-intern' there are all these
patches (all but the pcomplete one, LLM-generated, lightly reviewed).
For vc they address the cases where I thought it was most necessary (the
'intern' results are funcalled). But seems vc uses the global obarray
for everything, even Git revision sha's get interned there???
Not all these uses will ever clash with Elisp/shorthands though.
>>>> So? Where would you write this (extremely odd) code? in a file? in the
>>>> 'eval' prompt? In an (extremely dubious) tool that can be run
>>>> interactively from any elisp buffer? If the latter, just fix that tool.
>>> Yes, it's odd and broken. But I'm pretty sure you can find such code
>>> either in Emacs, or one of the ELPAs.
>
> I just remembered one case in Emacs itself, due to yours truly:
>
> ;; Fallback, let's try and guess.
> (let ((suffixes '("-indent-level" "-basic-offset" "-indent-offset"))
> (guess ()))
> (while (and parents (not guess))
> (let* ((mode (pop parents))
> (modename (symbol-name mode))
> (name (substring modename 0
> (string-match "-mode\\'" modename))))
> (dolist (suffix suffixes)
> (let ((sym (intern-soft (concat name suffix))))
> (when (and sym (boundp sym))
> (setq guess sym))))))
> (when guess `((,guess . ,size))))
>
>> My point is that such things only becomes
>> "shorthand-file-visiting-dangerous" in very specific conditions.
>
> Agreed, but remember I want to fix the bug rather than only the
> associated security hole.
Is that ever called from an Elisp buffer? If not, it's not a problem,
just funky code like we all write. Make Just make a FIXME there. By
the way, I have a handful of 'intern' to review in eglot.el too. Never
runs in Elisp buffers though.
>>>> In short, in my view, 'intern' is for reflecting into the "one"
>>>> obarray, and that obarray is where symbols read from Elisp programs
>>>> are and will be read.
>>> I agree with this view.
>>>> It's not for using as a generic lookup data structure and
>>>> avoiding such uses are, in my view, where efforts should go.
>>> And I agree as well.
>> Do you? If you did, then the efforts would be going there and they
>> aren't :-)
>
> Why do you think I implemented `cl-generic.el`?
:-) And I am thankful, but that was 10 years ago :-) So it's about time to
put it to use.
>>> Where we seem to disagree is:
>>> - I think most of those dubious uses of `intern` will be with us for
>>> years to come.
>> Yup, disagree on this defeatist view, foremost.
>
> I had `vc-call-backend` already in mind when I implemented
> `cl-generic.el` (hint: I'm the original author of `vc-call-backend`).
> The replacement should be a no-brainer.
> Yet, here we are, 10 years later, and noone did a thing about it.
> [ Tho, it's been mentioned a few times over the last few months,
> so maybe finally someone going to take the bait. ]
I gave my LLM the bait and it took it. I think that patch is in the
branch.
>> Plus your patch puts out the message that "dubious intern is now
>> safe", so it actually encourages/perpetuates the problem.
>
> You might be right on the poor effect of the signaling.
> I hope `cl-generic` is sufficiently nicer to compensate.
It's nice, but it by itself isn't going to do the work.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 15:21:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 11:21:34 2026 Received: from localhost ([127.0.0.1]:34934 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w29l7-0002U4-T9 for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 11:21:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50710) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w29l5-0002TG-5l for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 11:21:32 -0400 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 <eliz@HIDDEN>) id 1w29kz-0001KI-Nj; Mon, 16 Mar 2026 11:21:25 -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=39PYqKcQiYDJiRrhAJdixzvQQ119UsAKH/rrDj4q/U0=; b=UA2k4pTV2lln VcAHeQimHy/j6J8SUVnOBI93H9tG1A6ojU55+Aq8CUEdxSxYrF6I/HCxIDoxsUokwSMPJYDBoK8dW 4qMyaGcgqQH4rdn7njxsuEVlg3jBaw7ezLg5kDufiMeFYihmkfvB26gggAtsPu4dd9PvSur27qp45 By9cq8uOsK1vvZ429vnTtnaS7IvwGic9/2PJWAB6pgHWis8C+9C7KjebhRL0liKxM4wUjZvEbt4Uf vH1b9Cwv0q4qvuyLhOXa7E6V/o2BNPQYyvxnuPQ/b7PAGjBNQDSp97UrUNTMB6aRVthdamxNwSYuw cdSZvs2B1QaeM3oV+Rl9tQ==; Date: Mon, 16 Mar 2026 17:21:00 +0200 Message-Id: <86fr5ziyw3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv8qbretob.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Mon, 16 Mar 2026 10:50:13 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN> <jwv8qbretob.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org, gerd.moellmann@HIDDEN > Date: Mon, 16 Mar 2026 10:50:13 -0400 > > > I suggest to go over all of them and see. But, just to humor you, > > what about the call in resolve_face_name? > > AFAICT this `Fintern` is there to handle the (unusual) case where > someone uses a string as a face rather than the corresponding symbol. > E.g. > > (put-text-property BEG END 'face "bold") > > AFAICT it would be incorrect to apply shorthands here: > > - Shorthands apply to symbols found in ELisp files, not to strings. So you are saying that the only 'intern' call that matters is in code that reads Lisp, i.e. 'read' etc.? If not, what are other callers of 'intern' that could be affected? > - Coders who want to use shorthands to name their faces can use the > symbol instead of the string to refer to the face. They can, but they don't have to. > - If we really did want to apply shorthands, the relevant > `read-symbol-shorthands` to use would be the one that applies to the > ELisp file where the string was written rather than that of the buffer > where the string was placed in a `face` property. Then we should provide a way of doing so. Do we have such a way? If not, can we add something? > > That's why I suggested a text property: it will follow the string > > forever, as long as it lives, and each one of its consumers can draw > > the conclusions it needs. > > But that would tend to lose the connection between the string and the > `read-symbols-shorthands` that applies to it. Feel free to suggest better ideas.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 14:50:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 10:50:28 2026
Received: from localhost ([127.0.0.1]:34560 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w29H1-0007EQ-QH
for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 10:50:28 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57145)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w29Gx-00079V-K0
for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 10:50:25 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5506B442C61;
Mon, 16 Mar 2026 10:50:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773672614;
bh=GdvoAwMTPpYROzJZ+4S0sEwb9bvd2FetbDUAoa93J5Q=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=geY0f26rOnsSmfB1d7zUkWfg7O6hv2UJjSAAT2WopFTZfhKqqwB5f0WTY9uMfIqv/
mOlF2yD2rxTo83YJu68tKT33PVRHUN+aCC9h7J1xi590j+HpGzYf/CSAAXqTxIyE7G
k2zIC32iNRKano3NaJC7durvgpwv/OmfvPXgTUlt2TUwiQOS/H2+TSUJHbA2Geqh3l
Ox9eMTInjuIFcLHCTgfGljp5XdXDEGg1+nfV6+29yJQeO/Motx7MbXg5o/JgFLR8Hh
XM1kkbleX+4csoZ2NQhFhHGfey8pOIqpW8rxo6WEcFKCUJZN18wTWscdbxfUhwkGnA
sdfimx5YKnASw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B6F22442C53;
Mon, 16 Mar 2026 10:50:14 -0400 (EDT)
Received: from pastel (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 831FA120760;
Mon, 16 Mar 2026 10:50:14 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <86ldfshs1s.fsf@HIDDEN>
Message-ID: <jwv8qbretob.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
<jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN>
<jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN>
<jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN>
<jwvikawg8m2.fsf-monnier+emacs@HIDDEN> <86ldfshs1s.fsf@HIDDEN>
Date: Mon, 16 Mar 2026 10:50:13 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.054 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
>> I haven't bothered to try and fix those calls because so far my
>> impression was that it would have been a waste of time.
> Why waste of time?
Because I had the impression that the basic idea of the patch
(i.e. `intern` should obey `read-symbol-shorthands` only when explicitly
told to) was rejected, which made any follow on work based on that idea
a waste of time.
>> I haven't found any call where the choice seems hard to make, OTOH.
>> Do you have an example where you couldn't convince yourself one way or
>> the other?
> I suggest to go over all of them and see. But, just to humor you,
> what about the call in resolve_face_name?
AFAICT this `Fintern` is there to handle the (unusual) case where
someone uses a string as a face rather than the corresponding symbol.
E.g.
(put-text-property BEG END 'face "bold")
AFAICT it would be incorrect to apply shorthands here:
- Shorthands apply to symbols found in ELisp files, not to strings.
- Coders who want to use shorthands to name their faces can use the
symbol instead of the string to refer to the face.
- If we really did want to apply shorthands, the relevant
`read-symbol-shorthands` to use would be the one that applies to the
ELisp file where the string was written rather than that of the buffer
where the string was placed in a `face` property.
>> > I don't understand why you object so strenuously to looking for a way
>> > of telling the low-level code what to do about this.
>> I don't object at all.
> Then let's discuss the various ways by which the callers of these APIs
> could specify whether or not to obey shorthands. Alternatively, let's
> try finding some way for the APIs themselves to figure out whether or
> not to obey them. I don't want to give up on that without trying our
> best.
I did propose 3 different ways already (the one in my patch, the
(intern STRING OBARRAY SHORTHANDS) one and the (intern STRING SHORTHANDS)).
> This is only possible if the caller knows that the string will be
> interned at some point. It isn't always easy, and could be
> impractical. For example, resolve_face_name could be called on some
> face whose name is obtained from the inheritance chain of another
> face, and the caller might not even be aware that the face will be
> involved and certainly will have no control on its format.
The shorthands expansion should have happened long before we get to this
point. Shorthands are for humans, so they should be used only at the
entrypoints: things like reading from a minibuffer or `read`ing from an
ELisp file. They should be expanded right there, at which point we know
*which* `read-symbols-shorthands` should be used.
> That's why I suggested a text property: it will follow the string
> forever, as long as it lives, and each one of its consumers can draw
> the conclusions it needs.
But that would tend to lose the connection between the string and the
`read-symbols-shorthands` that applies to it.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 12:35:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 16 08:35:26 2026 Received: from localhost ([127.0.0.1]:59652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w27A8-0003yc-CQ for submit <at> debbugs.gnu.org; Mon, 16 Mar 2026 08:35:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54382) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w27A3-0003sT-M8 for 80574 <at> debbugs.gnu.org; Mon, 16 Mar 2026 08:35:11 -0400 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 <eliz@HIDDEN>) id 1w279s-00006F-Vt; Mon, 16 Mar 2026 08:34:57 -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=0FBkFLAMNQGb1HwRT18/XLMMilxCowrm1RxT8j2KnTw=; b=MOVEgd272x04 Dv3BOm912AyxvZR26ZUZ+E2mP+6agCkiMHzjq7gYVynLg35AzrkWZgjrFK7gauBk9ROrb8RhirPLS CrHCtn55U0Cg03IJtyxcguLWt6Xznx65YOIhmhbPcHDpno8qMhn21qOhZ7us7CbDM89CwVtNEFglp zcjsgNhlrTB2cWaTwEo7+y6yizoQ35vi+QWV9eh3TB4zOxjEItfOMCRL1YJYGap8XieGdKSerUBBa 2+DtJrMfR9DRMIWvTAmv/v/CPYWKcYsXM/OzX6WodB3xQQZXnvz2ZQAs4PiF6qkoErF1U7GPy5tCR QcRfOiWCW5vjArVr10Ic1g==; Date: Mon, 16 Mar 2026 14:34:07 +0200 Message-Id: <86ldfshs1s.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 15 Mar 2026 16:47:20 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org, gerd.moellmann@HIDDEN > Date: Sun, 15 Mar 2026 16:47:20 -0400 > > > And I will say once again that with your patch, we don't have any way > > of knowing the "cases that need it", in general. You have found a few > > of them, but those are the easy ones. There are currently several > > calls to 'intern' and 'Fintern' in the C code, and when I looked at > > them, I couldn't convince myself for quite a few of them whether they > > can safely be oblivious of the shorthands. And I imagine there will > > be similar problems with some Lisp code, if it's far enough from the > > application level, where it is easier to know whether shorthands can > > or cannot come into play. > > There are definitely some calls in there which would benefit from > obeying shorthands (I'm thinking for example of the `Fintern` calls in > `callint.c` or in `minibuf.c`). > [ I haven't found yet any call to `intern` that would benefit from > obeying shorthands. ] That's the wrong question, IMO. The right question would be "are there any calls where we are certain shorthands should NOT be obeyed?" > I haven't bothered to try and fix those calls because so far my > impression was that it would have been a waste of time. Why waste of time? we are presumably fixing potential problems before they happen: how can that be a waste? > I haven't found any call where the choice seems hard to make, OTOH. > Do you have an example where you couldn't convince yourself one way or > the other? I suggest to go over all of them and see. But, just to humor you, what about the call in resolve_face_name? Faces can be defined in Lisp packages and thus should (AFAIU) obey shorthands, but they can also be defined by the C code or maybe in some other ways. > > This leaves us without any hope of doing TRT in these cases, possibly > > even after the problem is found and reported. > > That doesn't match my experience so far. This said, this problems is > not made worse by my patch: current calls to `(F)intern` just always > obey `read-symbol-shorthands` even when they shouldn't, whereas with my > patch they always ignore it even when they shouldn't. The current code has the advantage that we are using them for the last 4+ years, so we have a good idea what is the probability of problems of the first kind. We have no such idea about the second kind. > > I don't understand why you object so strenuously to looking for a way > > of telling the low-level code what to do about this. > > I don't object at all. Then let's discuss the various ways by which the callers of these APIs could specify whether or not to obey shorthands. Alternatively, let's try finding some way for the APIs themselves to figure out whether or not to obey them. I don't want to give up on that without trying our best. > My current code lets the code decide by choosing between `intern` and > `shorthands-intern` or by letting the callers use > `shorthands-to-longhand` manually before passing the result to the > lower-level code. But right from the start I mentioned that we could do > it many other ways. > > The only other suggestion I remember seeing from you is to use the > presence of a particular text-property on the string as an indicator > whether to bey `read-symbol-shorthands`. I can't think of a situation > where we couldn't just call `shorthands-to-longform` instead of > annotating the string with a text-property for `intern` to do > the expansion. This is only possible if the caller knows that the string will be interned at some point. It isn't always easy, and could be impractical. For example, resolve_face_name could be called on some face whose name is obtained from the inheritance chain of another face, and the caller might not even be aware that the face will be involved and certainly will have no control on its format. That's why I suggested a text property: it will follow the string forever, as long as it lives, and each one of its consumers can draw the conclusions it needs.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 16 Mar 2026 02:56:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 22:56:08 2026
Received: from localhost ([127.0.0.1]:53691 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1y7i-0007r3-Vv
for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 22:56:08 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5993)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w1y7d-0007pL-Hp
for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 22:56:05 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 570E210013E;
Sun, 15 Mar 2026 22:55:55 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773629749;
bh=WASKMIHYgiZDFhAldB2ZrvIY2EhcsWM3zZ540lU5S4o=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=HnRm5nF8iiiIGBIv58VwfXdoSdVz2YIzKrgRbZ7ezoHiW1oRGQ8OVvUV9ZaUtTxUv
Uq3eV46R2+dZgqBkOwJUYDksMOH+IDYwkVndm5kp+2MC3+7mTUp4i5zOTj+ARRj4Fy
2O7y9SsyaAUPx3ar7BX9iOywciewGNZXfqWIP98V21siRiizVEE452M7y8zyhNgPVH
LuKH8p9zLQtSZO8o7gJJRIUOD+pCH/aaebBqjAEhFoZUXWjaEb0TiTmEDCdW3qQsz/
uF4tFYAnZZQGQtjclY2EbdbjdO1vSTiq3FJJh+Q8hJoFHKYVk1UQ+aFJqGSwtNXN6N
upZT+N++SmhJQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C017610002D;
Sun, 15 Mar 2026 22:55:49 -0400 (EDT)
Received: from pastel (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8423C120588;
Sun, 15 Mar 2026 22:55:49 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <87wlzcyb21.fsf@HIDDEN>
Message-ID: <jwvpl54ec2e.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
<jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN>
<jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN>
<jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <87wlzcyb21.fsf@HIDDEN>
Date: Sun, 15 Mar 2026 22:55:48 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.061 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
>> AFAIK, it's not trivial at all because of the sheer number of them (and
>> their impact on APIs which means that such changes need to be
>> synchronized).
> I haven't seen so far any case where the dubious/smelly use of intern
> isn't an implementation detail and part of an API.
By API I meant things like `pcomplete/<COMMAND>`, `eshell/<COMMAND>`,
`vc-<BACKEND>-<OP>`, etc...
These conventions form APIs which are documented and some external
packages rely on. These are not merely implementation details.
>> Tho your patch would need to preserve backward compatibility with
>> external backends until they've been converted, so the security issue
>> would remain for those.
> I have more patches to those too, if you want.
Go for it!
>>> So? Where would you write this (extremely odd) code? in a file? in the
>>> 'eval' prompt? In an (extremely dubious) tool that can be run
>>> interactively from any elisp buffer? If the latter, just fix that tool.
>> Yes, it's odd and broken. But I'm pretty sure you can find such code
>> either in Emacs, or one of the ELPAs.
I just remembered one case in Emacs itself, due to yours truly:
;; Fallback, let's try and guess.
(let ((suffixes '("-indent-level" "-basic-offset" "-indent-offset"))
(guess ()))
(while (and parents (not guess))
(let* ((mode (pop parents))
(modename (symbol-name mode))
(name (substring modename 0
(string-match "-mode\\'" modename))))
(dolist (suffix suffixes)
(let ((sym (intern-soft (concat name suffix))))
(when (and sym (boundp sym))
(setq guess sym))))))
(when guess `((,guess . ,size))))
> My point is that such things only becomes
> "shorthand-file-visiting-dangerous" in very specific conditions.
Agreed, but remember I want to fix the bug rather than only the
associated security hole.
>>> In short, in my view, 'intern' is for reflecting into the "one"
>>> obarray, and that obarray is where symbols read from Elisp programs
>>> are and will be read.
>> I agree with this view.
>>> It's not for using as a generic lookup data structure and
>>> avoiding such uses are, in my view, where efforts should go.
>> And I agree as well.
> Do you? If you did, then the efforts would be going there and they
> aren't :-)
Why do you think I implemented `cl-generic.el`?
>> Where we seem to disagree is:
>> - I think most of those dubious uses of `intern` will be with us for
>> years to come.
> Yup, disagree on this defeatist view, foremost.
I had `vc-call-backend` already in mind when I implemented
`cl-generic.el` (hint: I'm the original author of `vc-call-backend`).
The replacement should be a no-brainer.
Yet, here we are, 10 years later, and noone did a thing about it.
[ Tho, it's been mentioned a few times over the last few months,
so maybe finally someone going to take the bait. ]
> Plus your patch puts out the message that "dubious intern is now
> safe", so it actually encourages/perpetuates the problem.
You might be right on the poor effect of the signaling.
I hope `cl-generic` is sufficiently nicer to compensate.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 22:36:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 18:36:54 2026 Received: from localhost ([127.0.0.1]:51332 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1u4r-0003fv-Sk for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 18:36:54 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:46193) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1u4p-0003f6-4k for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 18:36:52 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4852c9b4158so34464995e9.0 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 15:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773614209; x=1774219009; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=EE+ph6XAQR3K/aJyZxoUH3DcnMzDToxQLUOtycNqOtA=; b=QkhNk++Af9vmv9Gq63uS1ksGeOjaTQkuYkaKAgDRBKExMOBvPOXL0hTW3KqfO8Y3fX wrZRup7yDAjeOzX2uljFMPAqtGjfSImUGjMJgfYM4TlubvQnEZK2aXFmpMMhxSYyrK5/ 4fUqIdNGpw8ibYylYoztgxpb9TI28Yfyl6iwsC/VGnLALPCNnxIVY6stRcfDmGKZciex euDytLrxiu1uFBvmBrQ8OaSIRKYchf2Q/R0BkBz0Xsp5/92OIOCL0FmZZhndQTXveb6l qfHnK1B9MwBRKuOYUdSfUMJl2EXKIaxjMOdRvXLP8UqtKB1r0ffjp/oArzI/3PjPGbP1 568g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773614209; x=1774219009; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EE+ph6XAQR3K/aJyZxoUH3DcnMzDToxQLUOtycNqOtA=; b=RzuyyU9lk09ivYQl93HWk9lj94a58cbvUfQ3dEp4NkoLNwaBpB+A9LPENw0ScW1cR+ /CzYHlOfCAI1XOC+eIUO9cgK4nNgo18UI4JGy7dE10Lup+K8GMFPnBR1zNkcYfQjJSw+ T6M0OfdfVB+cp4hFOXRftWPZYy3mG//rqo8rZKyRVWHY1jq3WpfO6ujxPTIu1LiUbXbg 6oQZ9fd5ErpI4YhHtxok+VeVBdkVkowynujc8mE98iC4MRaBy9qlQ2FxTYcyTdiqxA7p M+70UKJjBCsLs/WxHWhfjEyjO/lfcfn8jAk90saMlYhZyco0957w1kmpGV5IW45YGX0M aN7A== X-Forwarded-Encrypted: i=1; AJvYcCULUan/CywZAVfYX/Ff9cskQYOCocQrOZNvhuXFxtSAR6PocGmcAOjswbiQ7cBpJNWhCmcALQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw2uoQno7uRZV7eBENgoxeJLPPjVJNFuIOmRgq0/eo0f7Vl9NSy Ml1s5yip53XG0GT6Yb66ckrlOxs0qF8Lbgr9S9yP8W7cpiujBfawiNy/ X-Gm-Gg: ATEYQzzJlclQ40SFAXl+s7lT/tJZmgx57WCITHttdCTTlz7v5UA6829gfEdTPjoQ/7A S0yaYTkpCAlREPluNhRNDC9JfoXQggGMjfuQ1ffepik7Qh+DZH0guagd/kSNjFju8B3AoCh6DU6 gq8vSqUm+MDlLfFRyrT4xuPYpRsZVRY4kZRSgSsKjYOsayBzUJwZxOKxL6wmHyiktfIq3CHCzMQ mruaBsdoi1E4NMElBXt+wjwGt2ho0BlWcxx+hq/938MURfL/NxWcJ0zIDsASoP4HWrljCqFhxrI X5RsF5Ktuz1vN+JN3W8qqPx9VwL6sibMfaqafuGNAQmj9srsTr5jEI4hiX2CgHhqObnPsPvuMq5 qD5KauotqK8yOzuVmOMgCpv7VviUPd1ZTp4wj+wG+5FsmV/lYAEKA+XdqCVoq1QF88GnRSnnwMw pG6YEoXrwefwuzr1mC58f2+mxi6VFxOYN643jD/3eXfFj4JftSCOKtOZoCi/8qqSkxs6mVkxAyd JyTFoZqxa0LdWJuXw5cvv63Wgo= X-Received: by 2002:a05:600c:3b14:b0:485:3f1c:d8a4 with SMTP id 5b1f17b1804b1-485566d6e54mr187699335e9.9.1773614209205; Sun, 15 Mar 2026 15:36:49 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b45e5c233sm543352f8f.33.2026.03.15.15.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 15:36:48 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> Date: Sun, 15 Mar 2026 22:36:54 +0000 Message-ID: <87wlzcyb21.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: > AFAIK, it's not trivial at all because of the sheer number of them (and > their impact on APIs which means that such changes need to be > synchronized). I haven't seen so far any case where the dubious/smelly use of intern isn't an implementation detail and part of an API. >> But, yes, the one "security" example you concocted -- vc-cvs-registered >> -- would be immediately fixed by a patch already in this thread that >> does leverage generic functions. > > Tho your patch would need to preserve backward compatibility with > external backends until they've been converted, so the security issue > would remain for those. > [ and presumably the other `(intern (concat "vc-" ...` would still > offer some exposure to attacks. ] I have more patches to those too, if you want. Again, after being shown the pattern, an LLM (or half-motivated human :-) ) makes quick work of that. >> So? Where would you write this (extremely odd) code? in a file? in the >> 'eval' prompt? In an (extremely dubious) tool that can be run >> interactively from any elisp buffer? If the latter, just fix that tool. > > Yes, it's odd and broken. But I'm pretty sure you can find such code > either in Emacs, or one of the ELPAs. My point is that such things only becomes "shorthand-file-visiting-dangerous" in very specific conditions. For example pcomplete is intern-heavy, but does it ever run in Elisp buffers? So far the only package I've seen that exposes the risks you're trying to mitigate is vc.el. >> In short, in my view, 'intern' is for reflecting into the "one" >> obarray, and that obarray is where symbols read from Elisp programs >> are and will be read. > I agree with this view. >> It's not for using as a generic lookup data structure and >> avoiding such uses are, in my view, where efforts should go. > And I agree as well. Do you? If you did, then the efforts would be going there and they aren't :-) Anyway, we do seem to agree on some basics, which is good. > Where we seem to disagree is: > > - I think most of those dubious uses of `intern` will be with us for > years to come. Yup, disagree on this defeatist view, foremost. Plus your patch puts out the message that "dubious intern is now safe", so it actually encourages/perpetuates the problem. > - Given the risks, and the number of uses of `intern` out there, > I believe the only sane way to go forward is to make `intern` > oblivious to `read-symbol-shorthands` by default (and add some other > mechanism, whether a new function, a new argument, or whatnot for > those cases that need it). Given the risks, which are demonstrably minimal (3 major versions and no reports, and the one exploit you posted doesn't seem to expose much of an attack surface), I believe the way forward is to address the now known cases of dubious intern and to simply gate read-symbol-shorthands for visitors of .el files. The latter both as attack/accident mitigation and for the readability aspect, too. A visitor to a shorthanded file that is _not_ aware of the shorthands is likely to be confounded anyway, so it makes sense to tell them upfront that every 's-foo' they're about to see in this file they've chosen to visit actually means 'snusnu-foo'. But we've been going in circles. You have my respect for putting in tremedous effort to help improve Emacs, here I merely tried to steer it (selfishly?) in a way that served both your purposes and my interest as a user. But if Emacs doesn't get significantly worse after your patch then I'm ok, so good luck. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 20:47:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 16:47:38 2026 Received: from localhost ([127.0.0.1]:50335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1sN4-0007kV-Kh for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 16:47:38 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22715) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1sMy-0007i9-Gf for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 16:47:31 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8949A10013E; Sun, 15 Mar 2026 16:47:22 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773607641; bh=6YqijeXSL816AK41mVTogCH5coYiZM+Nzr+HRzFtEnU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PJplzBeKLC05C20gwNiG5ALjy/0WxCmeRGFEvf4wZfVAS+eMkK51Mn3Z/P9zIpveX YgZ+NBwC39cf2ST57Cyj3L+D9DWTFMEFtdJZoN8lWH4GRGOn56B+A+3lk/hAnxepEz Z1Onz4JaJFI6u17dpj8iuv5a0GpKEqv/XgusQCdvknTCww3oPDfi/c0Hh34CO1czSu 9uEAw0vOgV3mSIRsuG3FbdCkWA1V0Ru6Laonj+NdllrtBbHIg7Jo+fraoUT/Eyzz7R vPATvpOQoHChEYeryNUHODGnRGrXG141cNpXka9BpKpPkxEBPQHcWU059fYO9h6aZi PJOf99AR5UyfQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4940910002D; Sun, 15 Mar 2026 16:47:21 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 13E58120BFD; Sun, 15 Mar 2026 16:47:21 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86pl54j1x3.fsf@HIDDEN> Message-ID: <jwvikawg8m2.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> <86pl54j1x3.fsf@HIDDEN> Date: Sun, 15 Mar 2026 16:47:20 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.064 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> - Given the risks, and the number of uses of `intern` out there, >> I believe the only sane way to go forward is to make `intern` >> oblivious to `read-symbol-shorthands` by default (and add some other >> mechanism, whether a new function, a new argument, or whatnot for >> those cases that need it). > > And I will say once again that with your patch, we don't have any way > of knowing the "cases that need it", in general. You have found a few > of them, but those are the easy ones. There are currently several > calls to 'intern' and 'Fintern' in the C code, and when I looked at > them, I couldn't convince myself for quite a few of them whether they > can safely be oblivious of the shorthands. And I imagine there will > be similar problems with some Lisp code, if it's far enough from the > application level, where it is easier to know whether shorthands can > or cannot come into play. There are definitely some calls in there which would benefit from obeying shorthands (I'm thinking for example of the `Fintern` calls in `callint.c` or in `minibuf.c`). [ I haven't found yet any call to `intern` that would benefit from obeying shorthands. ] I haven't bothered to try and fix those calls because so far my impression was that it would have been a waste of time. I haven't found any call where the choice seems hard to make, OTOH. Do you have an example where you couldn't convince yourself one way or the other? > This leaves us without any hope of doing TRT in these cases, possibly > even after the problem is found and reported. That doesn't match my experience so far. This said, this problems is not made worse by my patch: current calls to `(F)intern` just always obey `read-symbol-shorthands` even when they shouldn't, whereas with my patch they always ignore it even when they shouldn't. So if a call sometimes needs it and sometimes doesn't, we neither the status quo nor my patch gets it right, and we can't fix that call without changing it (presumably by pushing the responsibility out to its callers), and my patch doesn't make such a fix any harder. > I don't understand why you object so strenuously to looking for a way > of telling the low-level code what to do about this. I don't object at all. My current code lets the code decide by choosing between `intern` and `shorthands-intern` or by letting the callers use `shorthands-to-longhand` manually before passing the result to the lower-level code. But right from the start I mentioned that we could do it many other ways. The only other suggestion I remember seeing from you is to use the presence of a particular text-property on the string as an indicator whether to bey `read-symbol-shorthands`. I can't think of a situation where we couldn't just call `shorthands-to-longform` instead of annotating the string with a text-property for `intern` to do the expansion. > From where I stand, that's the single problem that blocks the > acceptance of your patch. Thanks. That's the first glimpse of hope I see in this thread. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 20:04:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 16:04:13 2026 Received: from localhost ([127.0.0.1]:49597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1rh6-0000RW-1q for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 16:04:13 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52158) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w1rh2-0000QT-F3 for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 16:04:09 -0400 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 <eliz@HIDDEN>) id 1w1rgx-0000hd-2r; Sun, 15 Mar 2026 16:04:03 -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=zQo/2/c16dw+wArBX3SGjx2XPiglXZMOTyOTh4Lv7OU=; b=SFdYAUG5bj3p wD7d3NvbLrT2Hv8X2zpDUn2cQltqEj4/DY/+t8WnYUMPRQTS6sRenmWSlAAC7+m7+dQlH+DOzucul AkLbmYoQqmLuHVaV4UIrCipjIR99eKnQ8WHKO8ntrTSMFcZzWf2Ik0ZINRmvQV1/Gir6CFXB/RTVs 2WJPOXaSGvrdIwBfzKsyewhszaTkg1j4fwxTmrLi6WcmfAhRSqvswRludmhn2PhkkYXoMAuyeFiOA KtPyWoWbd4FEMnUGozIrdRdztNlRl04CZ6Sh8AtsLKzbqXdhfelaC6jLs7X93NZ4qn+DNWGn/VXG8 A6wSX2FkW1boQqbDHqZg/g==; Date: Sun, 15 Mar 2026 22:03:20 +0200 Message-Id: <86pl54j1x3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sun, 15 Mar 2026 12:57:22 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, > gerd.moellmann@HIDDEN > Date: Sun, 15 Mar 2026 12:57:22 -0400 > > - Given the risks, and the number of uses of `intern` out there, > I believe the only sane way to go forward is to make `intern` > oblivious to `read-symbol-shorthands` by default (and add some other > mechanism, whether a new function, a new argument, or whatnot for > those cases that need it). And I will say once again that with your patch, we don't have any way of knowing the "cases that need it", in general. You have found a few of them, but those are the easy ones. There are currently several calls to 'intern' and 'Fintern' in the C code, and when I looked at them, I couldn't convince myself for quite a few of them whether they can safely be oblivious of the shorthands. And I imagine there will be similar problems with some Lisp code, if it's far enough from the application level, where it is easier to know whether shorthands can or cannot come into play. This leaves us without any hope of doing TRT in these cases, possibly even after the problem is found and reported. I don't understand why you object so strenuously to looking for a way of telling the low-level code what to do about this. From where I stand, that's the single problem that blocks the acceptance of your patch.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 16:57:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 12:57:35 2026 Received: from localhost ([127.0.0.1]:46331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1omU-00079u-Sg for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 12:57:35 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3518) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1omR-000795-8w for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 12:57:32 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 431B744135D; Sun, 15 Mar 2026 12:57:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773593843; bh=xTdYju/zpCn2r2UjGw3oJSNYiL18jKFdpb4nuKS7O8U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iTWug/i73R4hstcEoFFcRBIsh6wIkom1c13yxJtz2WuOQOvbKRRxQY/l82HcaYeJ0 glaRyhA+BOSb/hf6auMZFwUeHsAu7rjs2/r1XfcuLaV1aIM1F4ERY3HOXWf1KbxbdG UlCsKJE3t4FXFBcD8ZLwGss0oLch4vFDcBva3BJaKng3orT61v1SO6IzyfvtN+zO0H lvRe7UVS8cb8RkXM8/yDnDsNK6SEg9HJT+leOmXfsGMg6a0lDvXwwUktSmKCkSsvbX RBWjwxeK6BOHsMvud/fROfP8aANgiedyj2QP9+XtY7lJ+6S/nXrWVa/WF2DAFjUC69 Ayi+XkbiHmAsg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 927074412B4; Sun, 15 Mar 2026 12:57:23 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 58303120DA5; Sun, 15 Mar 2026 12:57:23 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <878qbtozh7.fsf@HIDDEN> Message-ID: <jwv5x6xgiuc.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> <878qbtozh7.fsf@HIDDEN> Date: Sun, 15 Mar 2026 12:57:22 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.059 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > I explained why any use of flymake or things that use macro-expansion > could trigger it. It's true these are now turned off by default, but > very often turned on. But again, shorthands are then a tiny part of the risks. > And it's not clear if some uses of things that are on by default or > _can_ be turned on without problems, like Eldoc or font-lock can't > ever run code grabbed from shorthand-redirected symbol properties. If they do, then again the risk applies even to non-shorthand-redirected symbols. >> IIUC you're talking about the case where the user executes some code >> from a buffer. If the user doesn't trust the code in the buffer, then >> it's already dangerous even without shorthands. > But even if you don't trust the code, any new code that might > conceivably run 'shorthand-intern' via a long chain of direct or > indirect function calls links will have to be audited, and that's > not practical. Of course, any code can have bugs and introduce security issues. I don't see anything specific to shorthands here. The point of my patch is now shorthands expansion happens only when the programmer thought it was necessary (and presumably safe). If the programmer was wrong, all bets are off, just like any other code. >> As I explained this has never been not-broken. Compare >> >> (car (read-from-string "a\\ b")) >> >> and >> >> (intern "a\\ b") > > Those cases occur in a infinitesimal part of all elisp in the world, > if they occur at all, it's hardly an argument for widening the gap. There is no "gap": there is layering. `intern` is in a lower layer and `read` does some processing before calling `intern`. Expansion of `read-symbol-shorthands` naturally fits in that processing. Even the choice of the var's name argues in its favor. >> It's trivial to adjust the very real custom reader you linked to call >> `shorthands-to-longhand` before doing the `intern` and it will still >> produce the exact same sexp. > Sure, just as it is trivial to change the non-Elisp reflective uses of > intern. AFAIK, it's not trivial at all because of the sheer number of them (and their impact on APIs which means that such changes need to be synchronized). > But, yes, the one "security" example you concocted -- vc-cvs-registered > -- would be immediately fixed by a patch already in this thread that > does leverage generic functions. Tho your patch would need to preserve backward compatibility with external backends until they've been converted, so the security issue would remain for those. [ and presumably the other `(intern (concat "vc-" ...` would still offer some exposure to attacks. ] > So? Where would you write this (extremely odd) code? in a file? in the > 'eval' prompt? In an (extremely dubious) tool that can be run > interactively from any elisp buffer? If the latter, just fix that tool. Yes, it's odd and broken. But I'm pretty sure you can find such code either in Emacs, or one of the ELPAs. >> The scoping of a file-local var should be limited to the text present in >> that file. > ...past, present or future, doesn't matter. Sorry, I don't know what you meant by that. > No, I concocted that example just like you concocted your define-key. Fair enough. > In short, in my view, 'intern' is for reflecting into the "one" > obarray, and that obarray is where symbols read from Elisp programs > are and will be read. I agree with this view. > It's not for using as a generic lookup data structure and > avoiding such uses are, in my view, where efforts should go. And I agree as well. Where we seem to disagree is: - I think most of those dubious uses of `intern` will be with us for years to come. - The not-so-dubious ones need to be more careful about which lexical context applies to a particular identifier than just having `intern` apply whatever is the current value of `read-symbol-shorthands`. - Given the risks, and the number of uses of `intern` out there, I believe the only sane way to go forward is to make `intern` oblivious to `read-symbol-shorthands` by default (and add some other mechanism, whether a new function, a new argument, or whatnot for those cases that need it). === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 16:07:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 12:07:18 2026
Received: from localhost ([127.0.0.1]:45669 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1nzq-0001UZ-1a
for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 12:07:18 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53673)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w1nzn-0001Tv-CB
for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 12:07:16 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A50FB81CF3;
Sun, 15 Mar 2026 12:07:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773590828;
bh=eHdWR/tgIJ7jJLLTj9W1JhhWP6T19k4vuCcQV15aY+U=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=G86sEPP/4zLTWeNXcY5J0Org2vQXjsiB/mYXoeVgk+Zu1kpeQ6CYEJOXnTAamXCXR
4tRB5VSH8QDkKl8i55zFsiHm++UgLdEZVJRhCFFZtBeM6Av0aY6aHr2UzJj0xAM1Nr
C74bSpaasPt/hiXCwNR6m2iRFJUOYjHNdal4gyaa1020LBtQ4ublylcbEda5WXmK8B
o1xMI1zFIgAjrN0DlXtZy8Rm1vABFLOvA64pGDnMRQ0eOBhWgn21JvYRbkhOIlCw9b
I6wd0Y7q3LicXqo4PHHYojFeC6CGfrJnR3LQI5oudx1zdvQxs8c1sI0v3o1vUp2lgo
MapxsjoeqaerA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BF4F081C62;
Sun, 15 Mar 2026 12:07:08 -0400 (EDT)
Received: from pastel (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8D051120C79;
Sun, 15 Mar 2026 12:07:08 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <jwvms09gps1.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwvbjgpgjrg.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
<jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN>
<jwvms09gps1.fsf-monnier+emacs@HIDDEN>
Date: Sun, 15 Mar 2026 12:07:07 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.245 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
[...]
> [ I wrote the below before checking `breadcrumbs.el`, assuming that the
^^^^^
above
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 15:59:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 11:59:40 2026 Received: from localhost ([127.0.0.1]:45557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1nsQ-0000Us-Ch for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 11:59:39 -0400 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:55698) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1nsL-0000U8-Oi for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 11:59:35 -0400 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-4852b81c73aso33227745e9.3 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 08:59:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773590372; x=1774195172; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0Vv0IV08WDyEalkdnllveXGCMt5OUe4e/NVBfw6PCnA=; b=Ne8vO27kMHy8L9R/L0WPp8VARhVXQvFyeIYPlRGFVpeOQVVAl3q37wJ7BoENE0Xy6f 0kuMjTKGhAtztHAI01ufOwCjtS9Qp9xQ4aQ+fMXyDo49lGE7xoVv2CZxKPGfon0ufnqL We6TY3y+fe0fq+Q0iPGBrJzTdWvlQnjcOi4f4uA+xMXxwbwIdGDa4+9bky7KVct7cCNm VzlCSn7b5A508d2dx9QoncwDGpCgZ+NakwF2r7TXoyIQKvSpF+0WmvfRJ9kUiSrTpjjy XoYf6DOQxzNs34b3BwmUU7kuZu9s9rG3o3ERG7/YDN9XA+AGp10kcG0f0zvydAuQ6Cs1 ahRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773590372; x=1774195172; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0Vv0IV08WDyEalkdnllveXGCMt5OUe4e/NVBfw6PCnA=; b=cHk4hbICpguyK7MMIkivo7gF6f0Y2DsJXF7vIh1NW5BcdIQ2kNhWK8J0fJk4ZWk9dX P1unmkBEzMKcuxzZ7HM8W5eT6t1/MpJHVHrUMO0zgMkJnuDjPuVYGGFeWR1cka8bLPja 7D/kACieFeXnUu9AyoY69Pl+GgQDeChEzOI7Bu6RjPJZWDpCSHRiSgDF8Kk7Rsz85tTj Xo28AJ/onvAyuVTUWfih7qGevKQ4Wgyo1O0UJszpfzRKYiZ375flk2fK1pODr5pxf4FF URYd0r6Musau7hwaDlYtQBlLn1l8sjX5siX8vX1XtIGA6G4bKeaGarnqSu5AMz1hcGax 84yg== X-Forwarded-Encrypted: i=1; AJvYcCWEQ2r2/5Me5OEmZB1ysr7dPY+fNiPGg4rSp1DxVkBriPvwZ6Jv8qdwqX3jZx0FbgIEpUQlaw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyFajU6V6JxpoJoI3rNcI+fTmqv/dXns3zMKLlFOJzrmtFMOTQN RB12Y/os4IAheOC8pCgdqN8NIwO2GeFeiOZzATd4oOiwEtjLmCzoCpDN X-Gm-Gg: ATEYQzyr3+8yITRbsIBPP8wm8CkRyk7PH05Ht41TbyLEc6kwPr2DSokptdfn8ofjr8W i8U1c+WhfoBvZKXN5WxOT6A1xxHSqUQvgVDsteFD+IkX0Y0KNoZXqQIY+laaiAZlcraxODMpDFe CQH+t+krO163oKal2DUQOFMa2JJchVLseG8XQElmq1X/IQfXuEGqJJq6qE2+Gf12VbvOLI1vAnL nT8WGybCaotuwa9yolbQeEclrGL7vZo/6KcEmX86ongTYoBOmDSf/hG094hn8DOKbOR/jvSgkTP 1CyQHA9joteCycn1UcldJiLRLaTxP7ErI6OV6I5rLWWSx548k6NAWLmfrk1fPoVnVnAHOmnL1Ic ZlMqyUeuUyrZ7+3A+gH+qKHhJtErfwRerxAfxh9VEIFuYHQWfnSZQ/B2h/Hw8zSKmBGYUboFYy/ zXsc6mX88q4NbbTSOJdlBm/PJOTMHTuUKXgDIEBnpLJ47R6SWp/MKIVBnmfeSafOeURLzmVS4Tu OHb1pwdIeb55KL5YzhZUv86Es4= X-Received: by 2002:a5d:64e4:0:b0:43b:4388:64f8 with SMTP id ffacd0b85a97d-43b438868bfmr1510241f8f.12.1773590372214; Sun, 15 Mar 2026 08:59:32 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe2186e3sm39876874f8f.26.2026.03.15.08.59.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 08:59:31 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvms09gps1.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN> <jwvms09gps1.fsf-monnier+emacs@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 15 Mar 2026 15:59:32 +0000 Message-ID: <878qbtozh7.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: >>>> 1. doesn't mitigate the security/accidental aspects of shorthands >>>> anyway, >>> That's a bold claim. Can you back it up? >> I've already done so up thread: > > I didn't see that. Can you be more specific. I explained why any use of flymake or things that use macro-expansion could trigger it. It's true these are now turned off by default, but very often turned on. And it's not clear if some uses of things that are on by default or _can_ be turned on without problems, like Eldoc or font-lock can't ever run code grabbed from shorthand-redirected symbol properties. >> it's still too easy for users to end up executing shorthanded code in >> files with absurd "list" -> "shoot-rocket" shorthands they >> never reviewed. > > IIUC you're talking about the case where the user executes some code > from a buffer. If the user doesn't trust the code in the buffer, then > it's already dangerous even without shorthands. But even if you don't trust the code, any new code that might conceivably run 'shorthand-intern' via a long chain of direct or indirect function calls links will have to be audited, and that's not practical. > As I explained this has never been not-broken. Compare > > (car (read-from-string "a\\ b")) > > and > > (intern "a\\ b") Those cases occur in a infinitesimal part of all elisp in the world, if they occur at all, it's hardly an argument for widening the gap. > It's trivial to adjust the very real custom reader you linked to call > `shorthands-to-longhand` before doing the `intern` and it will still > produce the exact same sexp. Sure, just as it is trivial to change the non-Elisp reflective uses of intern. > You changed the C code of `read` to add support for shorthands, so it > seems only natural that you'd need to change the code of an ELisp > reimplementation of `read` to add support for shorthands. The reason the word "shorthand" appears in the C implementation of read at all is just an efficiency detail. It could just as well be using 'intern' directly, only it'd probably be a bit slower. > If I used shorthands in my files, I would also like the idea that my > users would get correct eldoc info when browsing my code, without being > prompted by Emacs about some potentially dangerous setting (which they > may not be in a position to judge). If they aren't in a position to judge, they will report it as a bug every time they hover over "sm-foo" and see the docstring for "smonnier-foo" in the eldoc area. > I have no idea if they all could be converted to generic functions and > I don't need to know. Not all of them. Some, like pcomplete, would be much simpler off just interning into another obarray. But, yes, the one "security" example you concocted -- vc-cvs-registered -- would be immediately fixed by a patch already in this thread that does leverage generic functions. > Again, you find a known problem and try to come up with a tool to detect > its occurrence, but that leaves many other problems. You don't need > recursive expansion for the problem to be real. Take for example > a helper that does: > > (define-key (symbol-value (intern (format "%s-map" major-mode))) ...) > > This will re-expand according to the current `read-symbol-shorthands`, > which can be different from the one that applied to the file in which > that major mode was defined. So? Where would you write this (extremely odd) code? in a file? in the 'eval' prompt? In an (extremely dubious) tool that can be run interactively from any elisp buffer? If the latter, just fix that tool. >>> or not nor whether it comes from the current buffer or not. >> You've already said this a few times in this thread, and while it's not >> super-relevant, it's not true. It doesn't need to "come from" the >> buffer you're looking at, i.e. be part of the buffer-string/physically >> manifested there. > > The scoping of a file-local var should be limited to the text present in > that file. ...past, present or future, doesn't matter. > [ I wrote the below before checking `breadcrumbs.el`, assuming that the > line of code comes from `breadcrumbs.el`. I have since seen that's > not the case, so I don't know where this code is from. Maybe your > init file? ] No, I concocted that example just like you concocted your define-key. In short, in my view, 'intern' is for reflecting into the "one" obarray, and that obarray is where symbols read from Elisp programs are and will be read. It's not for using as a generic lookup data structure and avoiding such uses are, in my view, where efforts should go. But as I said to Gerd and Eli, go ahead, consider my objections merely academic. Just make sure you've actually given a very good go at shorthand enabled files with Eldoc, Font-Lock, completion, etc, etc so whatever is currently working doesn't break tomorrow. My public extensions breadcrumb.el and beardbolt.el use it, and I use in a couple other personal code projects. I don't use any other Elisp tooling other than Emacs's so personally I'm good. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 15:12:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 11:12:31 2026 Received: from localhost ([127.0.0.1]:44810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1n8o-0002Be-52 for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 11:12:30 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:42298) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1n8k-0002Ak-PZ for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 11:12:28 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-485409ab264so25790665e9.1 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 08:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773587545; x=1774192345; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=03j+9KaDjl/IDMp8IWr47ddO62nF8JRITQM5FkiMR58=; b=cnvko33Ay6P4F6Ygn7/VIoLVhIu8aT+LSlC0WWXeNIazp6FDUoWuSR0bg3IAwdmReV cKigBkz53lB/2Vs1hCJhdwb6MybR7zP5oipQtL9HyS4NDhP9XNjH5e1qD/WObMlbd23m Bx9pViPyGjgRaKqz2y0Vd4cHDUD8R3yqsZvMAKthXq5smPWLRww70JL1FSG7X7CPJqBz DfZUhj9dIzvgHl9AroJZ8m71om/IlU2Xk7j/C0dNBxQHc4NxpKSipeT5TX+u1mqMnY2T 5DWlZKNEVkf8fyP5WSmVGA+7dtUoxI5yfNaLhARQpSKhDET6o9G7yRPIxzawGUESyreN A9Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773587545; x=1774192345; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=03j+9KaDjl/IDMp8IWr47ddO62nF8JRITQM5FkiMR58=; b=ZE6EfPY8/zpjTvmpUVP9fGfxWlbgjeJ9kT3TvS1IvZV0ygKItRqR9w/wIiIt9zgUXn 1O/BK8BkE4zxRSwAZ8X+pqksBqVY84jwLe2QGH28bBmFVak4lyF5jTc1vQY6RJuYmJs5 1JxTT2JsW/OdKdKF/5a+6OgnWrDPCEcst7KeO5wFJH9HdsDZvyMCwPM8l+bqFJ91Vlxq j9lThm/ccSOe6fU0v97tAk7gcZTe85s72ApsEEL6jwZCDPeSwKUpEqzwGZQyZZz9W/Wo N+gZ553ujlaGpdFiTrTbh7xngfLO3HXtRHdN5hXAByYVG3vpS9L1gPTtuU6I+MzcOMtN QE0g== X-Forwarded-Encrypted: i=1; AJvYcCXrXBHpewzG6+2h3KFRW7K7xhxTze3RP+FuRRi7mjdSB/wRcZNj16TyvyUE/Eb2ap0lLf4Ing==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyC10BxGhEkrQy0X6Kk0cNrmLl3O4Xjf7+O6S3Yu6dGI13HCBLs IdVYRwGl0464+HhwJiIV6dA6QtsauYrK5HVAjljSsOWrBt7BfJogTItlri11FA== X-Gm-Gg: ATEYQzzbfLGS6q5cI5m9iwWzXx61qcvyNI5oAclOlznTF9AXYHqIVaB7JSIURBxIl1H ceA2dNoTA2oBvphnFY0TQuuQ/2zg6m0h8B8L+F8CAqFcNaCNy0fKzu28pYVWRTMydYdXY2TAzcZ xyZ44fiEIU9ht83iWCQf4tpZFm6XrPul3Y2GpYrq4sCQF0O/TSCPtCoVCb7lLnlMAjCqFoYLRkI nCCbcLWumwNM6vQKqgJ4oJxlWy/4w9aYHPaN4Z6oP1QiKRKtyuSIAucp6EXii7KJycX9zHSlZc5 dILUuhRxdcNLzgjox+sLGXue442zWkr8zxmzd7GYvAO3fbYBHFic5w/ZzGapihDlae2hmIdyo92 gjRGqyT75BFcCPz5Lz0+6RXLYNgYDn/BcnfGiVUOGsxfx54x/Ur7tqllbBE4SsgKAvAgKl1FFBs 9OWEVUdHfR80me9HHa3yv3ts/N8Fi/l8Eka+88DC08ZG4k4OVapHdcu1PR284VSj8ZMfJcdoT6D DTeCrvY2zVN00Om88Q7QgaAuKM= X-Received: by 2002:a05:600c:a016:b0:47e:e981:78b4 with SMTP id 5b1f17b1804b1-48555b2c949mr145882325e9.12.1773587545118; Sun, 15 Mar 2026 08:12:25 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48556424322sm70142205e9.8.2026.03.15.08.12.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 08:12:23 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <m2zf49xk5u.fsf@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <m2cy15zqh4.fsf@HIDDEN> <87pl55pba7.fsf@HIDDEN> <m27brdz39o.fsf@HIDDEN> <87ldftp6l8.fsf@HIDDEN> <m2zf49xk5u.fsf@HIDDEN> Date: Sun, 15 Mar 2026 15:12:30 +0000 Message-ID: <87h5qhp1nl.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > >> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >> >>>> So in theory it will be just as "dangerous" as taking shorthands into >>>> account. In any namespace system, what you see is not necessarily what >>>> you get. >>> >>> Not sure. For PACKAGE:NAME I can make PACKAGE refer to some other >>> package with nicknames, but changing NAME is not possible. >> >> Right, but that's enough for a maliciously/haphazardly designed current >> package to make a "PACKAGE:NAME" source code manifestation point to >> something completely different. > > I guess so, as would be an add-function or setf symbol-function > somewhere buried in a malicious Lisp file. Right, but that requires execution of a file whereas package lookups are necessary just for tooling to work. > Problem is I don't have the energy or motivation for things like that. > My neck hair stands up from just imagining the discussions, or even > trying to land code in Emacs. I guess I'm simply too old for that > project :-). I can understand that perfectly Indeed, let's leave for the younger folks like Stefan and Eli :-) Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 15:06:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 11:06:14 2026
Received: from localhost ([127.0.0.1]:44730 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1n2j-0001CX-D0
for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 11:06:14 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55244)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w1n2g-0001C3-Kt
for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 11:06:11 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8A1EF10013E;
Sun, 15 Mar 2026 11:06:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773587161;
bh=0hGmPwhDPOzNLLMg4fVvgdxptcTdhPF3mkpeHv5TO/k=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=cefhNrfZLKAQLPPM1yiLrAhwTaWZXlDEYbNuBi0MyHYHPkX2YYZPVS9fFfZa0zQoK
xE9QpdYpe1ctxTVQzzchzQMuEUDesCKPFYy1ZJQwHh8UbMPGUlVG/0EhtSlDMj7Kbv
WjCbiECD/pSRPZT6kiQoZhlEMRFav+65Q+St/kGfuj4Y3V7F4jbg38K0ZnHfsdj+BG
nz24GUFz/J7JHZypSAJk/+A9PhminzloJUguq1nON2N0REPjqY7EoMDs3rNxfsNouL
soJX0NJwla+GwA7kwhpDkmc3lGrfCH4EJZoaeEJa46f6Odbb6xMFx3G2lTYjuC2LZU
TKmfVMc7Zu96g==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D57F210002D;
Sun, 15 Mar 2026 11:06:01 -0400 (EDT)
Received: from pastel (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9BFB0120F15;
Sun, 15 Mar 2026 11:06:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <87tsuhpcv5.fsf@HIDDEN>
Message-ID: <jwvms09gps1.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
<jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> <87tsuhpcv5.fsf@HIDDEN>
Date: Sun, 15 Mar 2026 11:05:54 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.067 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
>>> 1. doesn't mitigate the security/accidental aspects of shorthands
>>> anyway,
>> That's a bold claim. Can you back it up?
> I've already done so up thread:
I didn't see that. Can you be more specific.
> it's still too easy for users to end up executing shorthanded code in
> files with absurd "list" -> "shoot-rocket" shorthands they
> never reviewed.
IIUC you're talking about the case where the user executes some code
from a buffer. If the user doesn't trust the code in the buffer, then
it's already dangerous even without shorthands.
>>> 2. creates an assimetry between 'read' and 'intern' that was never
>>> ever there and likely isn't there in any Lisp implementation in
>>> the world.
>> Can you clarify what is the symmetry that you think is thus broken?
>
> I've also done so up thread. Once of the version first lessons I
> learned in Lisp was that 'read' 'intern's strings into symbols. And
> naturally calling 'intern' on a string would do the same thing read does
> with that string. That is broken.
As I explained this has never been not-broken. Compare
(car (read-from-string "a\\ b"))
and
(intern "a\\ b")
> The today, built-in 'read' on a
> stream that produces "(f-foo f-bar f-baz)" is indistinguishable from
> calling a custom-reader (such as the very real one I linked to) on the
> same stream. Both readers intern 'foo-foo', 'foo-bar' and 'foo-baz' if
> shorthands are configured "f- > foo-".
It's trivial to adjust the very real custom reader you linked to call
`shorthands-to-longhand` before doing the `intern` and it will still
produce the exact same sexp.
> Tomorrow (with your patch) the second reader will produce the
> nonsensical "f-foo", etc, because you broke that very first lesson.
You changed the C code of `read` to add support for shorthands, so it
seems only natural that you'd need to change the code of an ELisp
reimplementation of `read` to add support for shorthands.
>>> 3. makes introduction of proper CL packages harder.
>> I highly doubt it. Do you have any evidence for that?
> With your turning off the syntax smarts from 'intern', then calling it
> with "foo:foo" will, I suppose, intern "foo<colon>foo" into the
> current package.
I think you're supposing wrong. Nothing in my change would require such
a thing. And Gerd seems to agree.
[ Maybe I would object to `intern` using `*package*` when the second arg
is nil, for the same reasons I object to it obeying
`read-symbol-shorthands` (I say "maybe" because I haven't thought
about it nearly enough to have an opinion), but that doesn't mean that
the change I'm proposing would make adding proper CL packages
harder. ]
> Shorthands are very similar to package-local nicknames, by the way.
> CL-packages have package-local nicknames [1]. In fact, they are
> preferred over global nicknames. In short, just like shorthands, you
> can refer to the same symbol by many manifestations and the mapping is
> usually coded up in some file in a DEFPACKGE form, much in the same way
> read-symbol-shorthands do it.
Packages preserve
(equal FOO (symbol-name (intern FOO)))
And the "prefix" that they can modify can point only to another existing
package. That very significantly reduces the amount of "rewriting" that
packages can do compared to shorthands (which can rewrite pretty much
any symbol to any other).
> Now, how can you be sure none of the non-Elisp reflective "smelly"
> uses of 'intern' will also accidentally link to one of those symbols
> and cause the first ever recorded case of the havoc you're trying
> to prevent?
That's up to those adding packages to figure out.
>>> 4. as we've all already admitted, creates the real possibility of new
>>> bugs in parts of Elisp-reflective tools that are working fine in
>>> shorthand buffers. You seem to view this as an advantage, but you're
>>> still inflicting potential pain on someone.
>> I obviously don't see the risk of such regression to be an
>> advantage, no. I consider it as a worthwhile price to pay.
> Yes, but I thought you viewed this as an opportunity to experimentally
> determine, via bug reports, what parts of Emacs-(land) 'intern'-use are
> indeed Elisp-reflective, and which aren't. That would indeed be a small
> advantage.
No, I definitely did not view it that way. Even now that you mention
it, I'd be hard pressed to consider it an advantage.
>>> In contrast _I_ have a hard time understanding why you (or "we" I don't
>>> mind helping) don't just do the much simpler safe-local-variable thing
>> I can't speak for why the maintainers haven't done that yet, sorry.
> My bet is (I may be wrong) it _will_ eventually be adopted, making your
> shorthand-intern patch phyrric at best.
I don't know about phyrric: I like the idea of my tools obeying the
shorthands even in those files I did not explicitly mark as trusted.
[ FWIW, I don't tell my Emacs session that I trust the ELisp
files I edit. ]
Luckily I have already fixed that in my local Emacs with the patch
under discussion.
If I used shorthands in my files, I would also like the idea that my
users would get correct eldoc info when browsing my code, without being
prompted by Emacs about some potentially dangerous setting (which they
may not be in a position to judge). And I can't fix that in my local
Emacs. =F0=9F=99=81
I'd consider it a good reason not to use shorthands.
>>> and take the advantage of the fact that we've already isolated the
>>> cases of what I called "smelly intern", in which 'intern' into the
>>> global obarray is (ab)used because Emacs didn't have hash tables or
>>> developers were "lazy" to use dedicated map data types or simply
>>> dedicated obarrays.
>> That's orthogonal to this discussion, actually:
> How? How orthonal?? The _very thing_ you are trying to fix is preventing
> exactly _those_ 'intern' uses from accidentally finding symbols via
No. I'm not looking for known dangerous uses of shorthands and trying
to avoid them (which seems to be what you're after). I'm looking for
safe uses of shorthands and making them work. So I can sleep at night
without having to worry about the thousands of uses of `intern` that
I didn't check.
I have no idea if they all could be converted to generic functions and
I don't need to know.
>> - After changing all those places, blindly obeying the value of
>> `read-symbol-shorthands` in the current-buffer in `intern` will still
>> encourage bugs because `intern` doesn't know if the string it receives
>> has already been longhand-expanded
>
> Never been a problem to this day, but it could know that easily or not
> need to know it at all. We could very easily statically verify no
> recursive prefix expansion is possible, i.e. go through the map
> verifying that no longhand is a prefix of a shorthand.
Again, you find a known problem and try to come up with a tool to detect
its occurrence, but that leaves many other problems. You don't need
recursive expansion for the problem to be real. Take for example
a helper that does:
(define-key (symbol-value (intern (format "%s-map" major-mode))) ...)
This will re-expand according to the current `read-symbol-shorthands`,
which can be different from the one that applied to the file in which
that major mode was defined.
>> or not nor whether it comes from the current buffer or not.
> You've already said this a few times in this thread, and while it's not
> super-relevant, it's not true. It doesn't need to "come from" the
> buffer you're looking at, i.e. be part of the buffer-string/physically
> manifested there.
The scoping of a file-local var should be limited to the text present in
that file.
> Shorthands, like any namespacing mechanism, are
> useful to designate an infinite space of names sharing a common
> characteristic. So if in my file all "bc-" is shorthand to
> "breadcrumb-", you still want intern called with "bc-yowza" to lookup
> the "breadcrumb-yowza" symbol, even though it was never written before.
For that to work correctly, `intern` needs know somehow that "bc-yowza"
is associated to the `read-symbol-shorthands` of your `breadcrumbs.el`
rather than the `read-symbol-shorthands` of other files.
Currently, we don't have any mechanism in place for `intern` to get
that info nor for the programmer to pass that info.
> Even
>
> (intern (format "bc-%s" (read-from-minibuffer "sym fragment: ")))
>
> should keep working and point to breadcrumb-whatever. This works today
> and it should keep working like this.
Not if the above code where written in a file unrelated to
`breadcrumbs.el`, right?
So IIUC what you're saying is that the above call to `intern` by virtue
of being written in `breadcrumbs.el` should use the
`read-symbol-shorthands` that apply to that file.
I can agree with that desire, but currently I don't know of any way to
record the necessary info. It seems we'd need to go up the stacktrace
to look for the "enclosing" function that calls `intern` and then check
the file in what that function was defined.
Or maybe we could turn `intern` into a macro that expands to a call to
a lower-level `intern` but passing additional "lexical
context" information.
[ I wrote the below before checking `breadcrumbs.el`, assuming that the
line of code comes from `breadcrumbs.el`. I have since seen that's
not the case, so I don't know where this code is from. Maybe your
init file? ]
In any case, you say "should keep working", but AFAICT it currently
works only if you're inside the `breadcrumbs.el` file, right,so it's not
like it's working reliably to "point to breadcrumb-whatever".
My patch would definitely break that line of code, tho the fix is
trivial, of course.
=3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 14:05:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 10:05:42 2026 Received: from localhost ([127.0.0.1]:44092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1m69-0001LG-At for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 10:05:41 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:61678) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1w1m66-0001Kn-38 for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 10:05:38 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-4852afd42ceso32373065e9.2 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 07:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773583536; x=1774188336; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8HyTD3upFVMWmosGQBh9SXzNPKvYtYGzj0bmA2WtRww=; b=MKxBsgnRt4h3ChblFfWnrgO5jNJr5VeyIipv97yx9rFYw25Za3tiS3IAwHMX+439EQ T09WDC4iV07yY6kwFf0Kph26MCIV4WJepfR6O6i/CurppTXsQv9JzsqHlAkbbtUp2u8G 1Sfah7TGO3HfyNQPATSBIzUBnje0DT7jfPM+WHwRbYggH779TnYTz462w6DI+Jhtqrdx SuTLmHMcJ0y36bjDHZmosUNwvp4f6Wow8qxSL1cREcZyeERlNYOibYQyziW/0XqZq9fh LEBcwYJ5a/lbRYavpsLD6aG7IEAyh/58J6Wvq8m/zRhIw+5ujo00oEr7s7116C59Lrp8 vO7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773583536; x=1774188336; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=8HyTD3upFVMWmosGQBh9SXzNPKvYtYGzj0bmA2WtRww=; b=bb6iDF6l3DyBGHA/f/Pu5aIK+GRwa6cHQvxvCTv7LeUNzOt4GcWb3zZOhQP8A1EbA6 MRTBnX4BP/R7RKU8LggKkUlUvtWbD7ty+j93qhP3DymkxrYt4Zky8QN5V+Tk/jyqN++U iiYX2dvpyDJt7T63wB6x4SUHmt/Na9AthQpd+HxF2QgyPRdwjkjxi1yZRk+C/ABAG8Y/ x02RUzkROfl4kHuBxsWHxBUZFJwqGzbDjTnOXnXRzimipGCF2rvX7MxtMnvBwaHqTjiS I8ER0Mlj8TGqvCapNXdNajvICpKSmGAVLUGXS/YlrpgMpFm+Jb1ZGpchDOrIYk+u8z8Z 6caw== X-Forwarded-Encrypted: i=1; AJvYcCWevktZG3o7+OMAtJ0AxR0oA3z51MXV14UHAg6RMgxqC36SBnzigHZn0FkOeylMQHOilw995g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzDJ6jM9L+g6ZGXXCmCJpCGqwDL9vYikQfJeW4N5aBFD2y9+vD/ hk9cpfLEqoOTObPomUFQXTHbX5BN7yOjOBbjoy5jh7bImx0thRdfUchToGyJ3w== X-Gm-Gg: ATEYQzz0LEwF2QMUsD5KLbqJMRVxELBBJAnXdDWnTaQZUNLAXuXw2sPXgadno+YH50M MyXIMA/jZRSa5SdghGBVgRfCY7J26ikaPh/swipiCyGRFA76b+LFnYHiA+zVCqkv7N3vxplWiWv TUp3LfDaTgpOPEtiBCeJmma99s03act9HexlI7OAC9qzLRyrGgnknqPtuqiXw+VEuO6sYCh/ymf z0gu2sJ9Sq1vZHgJ/jWaKUnYrJT40EgFL0Nc+rGIBtIfDjTxvAnamkjnzKQfG1d9ImPauI953Mk dy1AVTR7uu6z9bpiaFy13h5N1CMNFU/llU+anK0GbQMKSiSVEZbEAlfizIMt/xWCm7iJVVmXsFb KjQVR41I0lo0jddn7Tx4HwSoYfK2nlWrf5OOXHT/3zZKer+irOpmqnURhdKNm+RPnJ5eNYzGcD1 7wS8RPMR1R0c6e7jIAlxSj9XzBuMzo11SiS6TqRklSqL8I0tsJsfDyz/P2usOb42dtHSl8Q9qhW 23w/Zb8FEz/2WC1y2/olDF4+tR2BhY3Hhk= X-Received: by 2002:a05:600c:3b25:b0:485:3a03:ceca with SMTP id 5b1f17b1804b1-485567029b6mr168006455e9.23.1773583536207; Sun, 15 Mar 2026 07:05:36 -0700 (PDT) Received: from pro4 (p200300e0b714f100915b4da84a01975d.dip0.t-ipconnect.de. [2003:e0:b714:f100:915b:4da8:4a01:975d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4854b65fed7sm328715215e9.11.2026.03.15.07.05.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 07:05:35 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <87ldftp6l8.fsf@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <m2cy15zqh4.fsf@HIDDEN> <87pl55pba7.fsf@HIDDEN> <m27brdz39o.fsf@HIDDEN> <87ldftp6l8.fsf@HIDDEN> Date: Sun, 15 Mar 2026 15:05:33 +0100 Message-ID: <m2zf49xk5u.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >>> So in theory it will be just as "dangerous" as taking shorthands into >>> account. In any namespace system, what you see is not necessarily what >>> you get. >> >> Not sure. For PACKAGE:NAME I can make PACKAGE refer to some other >> package with nicknames, but changing NAME is not possible. > > Right, but that's enough for a maliciously/haphazardly designed current > package to make a "PACKAGE:NAME" source code manifestation point to > something completely different. I guess so, as would be an add-function or setf symbol-function somewhere buried in a malicious Lisp file. Maybe One could prevent some stuff when a package is locked. Or with a new kind of lock. > > Jo=C3=A3o > > PS: I hope you understand that in no way am I defending shorthands as in > any way better than proper CL packages...=20=20 Yes, I understand that. > Maybe if, as a first/introductory step, you proposed introduced > packages with package-local nicknames as a strictly file-local thing > (somehow...) and if a shorthand prefix convention with '::' and ':' is > agreed on, many shorthand-using packages would easily convert to CL > packages instead. Problem is I don't have the energy or motivation for things like that. My neck hair stands up from just imagining the discussions, or even trying to land code in Emacs. I guess I'm simply too old for that project :-).
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 13:26:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 09:25:59 2026 Received: from localhost ([127.0.0.1]:41953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1lTg-00043D-MJ for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 09:25:59 -0400 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:47541) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1lTc-00042J-BP for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 09:25:53 -0400 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-48374014a77so36017315e9.3 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 06:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773581151; x=1774185951; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=mckXzaIpLvdzHmfi7J0E8Vx1WdsIRJd+C059tUiezpo=; b=YiCG6ndsC5L30lForPV71uBOIX/PLxp0lXLv1hhA7YQwLuBjS/VPmFvxGV45+401mH KwvcNZOHnwTmthIV+nliOIq4y1uZtimo7/i9hgwt633RJ1YFbiCsveT2/W7h0vfUwx2L 7O3n4LYXdZTV9LzrDyUlE2QC8IXI8j/D5V1datyO94cU96APQFeBveYoDnW0r7wAdYID PESMgrkSP0LFY7EZToNrfEsyQJwZOsowROqD3h/M5CAFl/R7TxLFOx3v5ci4eZctirOQ RrnJCNe/C9jENUwPzzF1cbvQkexjCK/umOoUZC6MdK8v8im58oFmxWKyc7MEYlgwuhOD QQcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773581151; x=1774185951; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=mckXzaIpLvdzHmfi7J0E8Vx1WdsIRJd+C059tUiezpo=; b=SY+c9TyYjIXtIChe65uq4EnlzmtVID985x73x33IDa7LTjyKvymS8Qq8pe2w3G1A82 W6mdaJpY9u0Aeog84TNqF1l3G6rUehmMo8mMHlf0s4A9xCiXZ/q+S+Rw56cNXsv4HsDH 8x8sdoR7ApIE8RHVXsT0WOg5mdF+RweuKlxfGcN1p9YzrwoT2H0DVWDfkkzaQiPdmU6z YpYtizgZVxJlmGMpIJHQap1pNK5oHVsesIPHDOf6j2p4Rhc5w2EYmK04ep6l6GLXH4zX y0RumNCsV8IDXPg4lzVG53J6sCdZIxqrVyiwc4PaSToiyMrQUOpEpbqOLNVZXXpr3JCV z3xw== X-Forwarded-Encrypted: i=1; AJvYcCXOtcx5zTgZQJPQgOxP2k0zRyYhefKDQ/dyI5pBHyz087+hrj9JIG7fFzi+jiy96BH3sG+lfw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzNO+8PIt/3bkfzS3vpJlPs/kpVmCMLHaNLlVlz3rU8rxZaF6Fe /FBXgE+cO04oQkBlmuWBdjS0bkj9Brx9mlYHMkQgEGJgZBZMpTVcWryftDh36g== X-Gm-Gg: ATEYQzxN9xlY3Egt3SK5iEG/r6/fo8URbe3GqDdEEe2a32n16Vr9uCgZUHv6BEMyESG 7pKG1Wgk9Xwq1j3l91COZMdNEYVb57pculkhFqGPDiGVWCGAfF1F/62dGHxofi3WD2Pu8P7OCi/ dNRcPKTt1rJsNUVonVqc7746u1exBDmqS7bOTn9GMXgGdK1HJ1CUNQ7Xoa7vLYh0nHuXEuNhbxk rWaJJMvGsgPGldmBcvU8JRqf/oQ3YuyyjjgV06zCcH6Kfcm/iDhph0lXIIX3gPMrUc7OmeXqC0R NRmMBvxtOK1fGLa2/IhQbbjzbjzvDnaWBebDRCoWpBQI9+dCKPJXPu6gKM6OuES2QFL1YGk5nMW nDNKWZQIeCWZXSeneGO4gIBkxlUifcC7sBUNu1YiZj75MUYHkT+X5RyVtT8+Bfld9D2qoWx+Zb6 EgfKEKRl1KkKwiLm3y/UrmNlBaPjICWfMzxRiSvuyjdPmOU7k71/sU2nI6KuoH+y0nkJn+gIV5p rl6PAkSkXQo7NegFvz5NTWcmiE= X-Received: by 2002:a05:600c:64cf:b0:477:7b16:5fb1 with SMTP id 5b1f17b1804b1-485566cf893mr158897565e9.7.1773581150519; Sun, 15 Mar 2026 06:25:50 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4855640d915sm69492865e9.4.2026.03.15.06.25.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 06:25:49 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <m27brdz39o.fsf@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <m2cy15zqh4.fsf@HIDDEN> <87pl55pba7.fsf@HIDDEN> <m27brdz39o.fsf@HIDDEN> Date: Sun, 15 Mar 2026 13:25:55 +0000 Message-ID: <87ldftp6l8.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >> So in theory it will be just as "dangerous" as taking shorthands into >> account. In any namespace system, what you see is not necessarily what >> you get. > > Not sure. For PACKAGE:NAME I can make PACKAGE refer to some other > package with nicknames, but changing NAME is not possible. Right, but that's enough for a maliciously/haphazardly designed current package to make a "PACKAGE:NAME" source code manifestation point to something completely different. Jo=C3=A3o PS: I hope you understand that in no way am I defending shorthands as in any way better than proper CL packages... Maybe if, as a first/introductory step, you proposed introduced packages with package-local nicknames as a strictly file-local thing (somehow...) and if a shorthand prefix convention with '::' and ':' is agreed on, many shorthand-using packages would easily convert to CL packages instead.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 12:27:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 08:27:38 2026 Received: from localhost ([127.0.0.1]:41243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1kZF-0004IO-FE for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 08:27:37 -0400 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:53742) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1w1kZD-0004I6-Ok for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 08:27:36 -0400 Received: by mail-wr1-x42f.google.com with SMTP id ffacd0b85a97d-439fe4985efso3313097f8f.3 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 05:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773577654; x=1774182454; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Og7F468thgsyPET5AwMsO1D1R6Oljsgb6OPWTiPu4Z0=; b=NBMwIGq20WT8JkBwT4eukLjtoOj4dAlp/gmtC5OpVYDQa1wnr3Xz+XcYvfmn9Tg8OL KnBFt/KCU+Y3b2lrDmA23hhdfuVhaQte9C84hJTroRNAJ7AdmlNsHf4uZ/xStBmsXYE7 k0P0L7ZhHaunbjX3OEOHJnyZ17GyKGYsIyTqR2LE1SrxCT9vgTlncTYI/mai2dQJN7dH qOjDXYpXrL0R8vF5PxK7Ohuq8xgyxjrqlOTbcDzYVptxV45/NoBtBniJM1m64B+tA8s5 fyECJ6ZBQngnxqD794YhN65FEL+oaO+hsGwoUy1ydoIVUN0cYkhxbNnV+YxpRY4LGSN9 Yerg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773577654; x=1774182454; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Og7F468thgsyPET5AwMsO1D1R6Oljsgb6OPWTiPu4Z0=; b=WEp5LsTvPgVJsS8FZWSiBVN4nnum6tELsm61Go3dKRJrp4mnFpjlK0dEamD56vhTXG epP/wmBQGfNqawXJmPAk9zJTqUCJfvh+wSrRNjVNvL4qLlv82jQbchmW5NUl+ZmJpkwa p3g55XOa96J28N5eRCRg0XET7h8LKz75TI3hGKu8+FmOa0qKLBJLyx55ZpK8GG0/3Ykz Xn0nZ0pZOY1zNv1NRMML1huHQCrFYiDpxWkfmn+nyILUyG/lbkCtBF94QZ9+06xn4sn1 bL1aGG9qiNfrGo3F+fWRc6SCgvkSJXlwHkUFGt5e+I6Nc+Mj6PBQ5fUpW0RO3nf96ibj YLAw== X-Forwarded-Encrypted: i=1; AJvYcCUP5nSD9KXJIE5tejVe6bucXd55vRuK57PCMWwGZsTuftHv1sTUXnUk0O3fbpP2DCyQIpA6Sw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YysMFz5QPXVDeSetySRYOGgQD6vL/IM8TUCljjoLj/kiiIBqErc MnuGHZUrfX+503u3cTjEp14wRhiJXTyj41xhfJHNnAAXpacrMp+OfXWs95BTSQ== X-Gm-Gg: ATEYQzynj1pEWDdVZnutObuvRFkSm57bf7KxyN8QHkioJMjzC1XEWQg1gRkqcT3HSjE hjc+6pXKgn2VqpzPLZ3w4Frk3vZ8f+oJnyD8OEB7fPsp6+Xc17iJB9UVYc3hOy2l6/W8C13qdeD SRrswM2jPrxvw+ZxnYbrz+7wkZTqkyhzae2RynsJMyjzkIHMzQ94ad+pe2TTAZDwI4Me4676PQI cxktGtLgVDfGyVGY6N314r32WNRddD923NfRpC4e/BffGPlMrtXDZC6uNyZiEdHCpE5AQ9EUVWz 1CpqpKnVKEoPmZRuqm9BBOcTA9RUW+Vpz5ttSwsteiS+I5rr0XTaB6J4C5Er3VjiD0ty3Z/4PQG hROe82Jzn0K8qnYCngo7nMC2I342JvhD0JZta29vPnXTP/6eJ+1qI7lyCaLdB81zxBotWnbWM1e askiPC+gPTESSDOkybhiQQbAVsaCQq7AmCfkgqCmA8t3MOQd6qo4LDud2CRT/CBATOnKCFOSiwa ecGX6NYzcHUbDB6lmiq74BtUfLZMApBdXQ= X-Received: by 2002:a05:6000:2501:b0:439:c43a:acb6 with SMTP id ffacd0b85a97d-43a04d7a11fmr17676165f8f.10.1773577653777; Sun, 15 Mar 2026 05:27:33 -0700 (PDT) Received: from pro4 (p200300e0b714f100915b4da84a01975d.dip0.t-ipconnect.de. [2003:e0:b714:f100:915b:4da8:4a01:975d]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-43b41065f8csm5061765f8f.30.2026.03.15.05.27.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 05:27:33 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <87pl55pba7.fsf@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <m2cy15zqh4.fsf@HIDDEN> <87pl55pba7.fsf@HIDDEN> Date: Sun, 15 Mar 2026 13:27:31 +0100 Message-ID: <m27brdz39o.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >> Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: >> >> From reading Stefan's initial report, I agree with him that translating = the >> symbol name while interning doesn't feel right. But I'm kind of biased >> anyway :-). And, BTW, I don't think packages will ever land. > > OK, guess I picked the wrong expert witness then :-) :-) > But even without shorthands, your 'intern' version is also package-aware > right? So it will do translation taking names, nicknames and > package-local nicknames into account, no?=20=20 Intern itself not so much. It's using the package passed as argument, or the current package (*package*). The symbol name passed to intern is left unchanged, without shorthands. The reader, on the other hand looks up package names as you say, nicknames, package-local nicknames and so on. > So in theory it will be just as "dangerous" as taking shorthands into > account. In any namespace system, what you see is not necessarily what > you get. Not sure. For PACKAGE:NAME I can make PACKAGE refer to some other package with nicknames, but changing NAME is not possible.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 11:44:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 07:44:31 2026 Received: from localhost ([127.0.0.1]:40894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1jtW-0007is-Tg for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 07:44:31 -0400 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:45415) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1jtU-0007iZ-Aq for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 07:44:29 -0400 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-439cd6b09f8so2921170f8f.3 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 04:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773575067; x=1774179867; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=CxIBRo7GGxNNtlAPBkGSzbEoo4elwpz0JIlxGEhwjb4=; b=Kqgrtz7yE2H+eBODvfluktOC7+Ny+sO0HndhVA12TxzuBPpQqgfsnC1S5Ko5F+isOG iXvCWlZ2rPXYbcYKaYmiiYHX/Wqk/HVvazP6q8xunqCH5YqsZEYHA7spvTU/vVBOwzZs HVVG+EVu2wmy6/tZENhZy5C8NvbxARnpjz31NOWOm3Vq3QSEBW6yPSsHTSe+JlJ1+ZZc 0A97Db1hGxreDWB817LZCuVby8F3xH/MDZPCtLcN1uC0Qxqzm4z+ImRfOTqTOtqG/42E tvO+bNPgw3l7BMov29zeuwKu4vlmRT+ytny0fIGGplsUikU9LU62YumZsXfciewtrWIV pH6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773575067; x=1774179867; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CxIBRo7GGxNNtlAPBkGSzbEoo4elwpz0JIlxGEhwjb4=; b=JjDEZEbF0EkjW6n5Edxas84Q4Z7GwSbUO7vlz2ISAvrcbf2q8LpiSijDgm9WrfLcll mZXyxK4/jXKKIMkC+l54O089eUNY5dMvSVwTxotM10a9Sa/ImqijZ8lD+iwerkRyR2Xi s0qjtVnG/W9I2qc/cRvQXRdTmX7B8BQpxG1adGgy4pXhU5kODp8ylBm2phltwOQoZGnf /nBaLcV/AwBkGi4qiKbwudJzjRf/C27b3vrSzaRIjPAeZ/yzSMFFrd35R1STP5Gnkw9X eieG7edGIAmnVwNzNWVCR5POq4Mhq9fqwAzizRMa8/wEh3Ky3N50c82BcbeTzNnptGQt IPwg== X-Forwarded-Encrypted: i=1; AJvYcCXwKh3nsqNuOxRKB9qjbofcgCj567b4yWYqsIiWxOFRfjoV3SI4quIR3BgjXm4EjQLNkjjyxw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzhrEaXG/cbxpJxt2ysRpXbK1z906ZwXxo080hG4MLrbTlnnQI7 rofa3ArGRvKn8UjmTQd6g9ChuOeTc3U+Co0o8WXb02tovNcfYPrJV6pNLRmzBw== X-Gm-Gg: ATEYQzxOt0hTsoA+BqE7eSfv0Xw/tYNtF2BNESLdDvVW2Lvkh2onWPq3MFFRVNZxELu xHkWdINAv58yeO+CC3PTheoEgEaGW65zmfvcI8aRFz9L3zsPDB9DukYFF4365z4wV3VkbboAyZU c1H1EXNMtAEPis7HIkd7/1HCMMLkX/xzbGe04JPDliY2NBbJLDN9ghGpiYiKpuSkgi08JoyFdjZ MmrWYFGJV8YSimrgt44Rs2pKszdC2FdnrmdSQwV0mIvOYKPE/7FZRucF0RLlvsYtdzOf7UzA5nf OS/onPNwJf6Oxy1sLRbysmdbBx6naysqr09XxPqWT0kkTX16AqEbbIvfg9ktsGILNiYr/dORNuK j6baCofCqJ3K2Ev7weDsWi2wWmKfMBCX13IvuOKnCG58AgZCZ2NVHPih/osSU0zBuKwnX4lZ69d Ka26TrOkB5Gd38b8bS6TkpLWjrpINpHlDG3piB9H+j/McTGYxDKLn4H43LTTztz/PjKtGGa1wJS JCl1jL2ZTG8L3Q3kh1WsEtzSfINcJs/D0QpgA== X-Received: by 2002:a05:6000:26d1:b0:439:d750:42f6 with SMTP id ffacd0b85a97d-43a04d8b557mr17374860f8f.24.1773575066630; Sun, 15 Mar 2026 04:44:26 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe20bb90sm34867134f8f.19.2026.03.15.04.44.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 04:44:26 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <m2cy15zqh4.fsf@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <m2cy15zqh4.fsf@HIDDEN> Date: Sun, 15 Mar 2026 11:44:32 +0000 Message-ID: <87pl55pba7.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes: > > From reading Stefan's initial report, I agree with him that translating t= he > symbol name while interning doesn't feel right. But I'm kind of biased > anyway :-). And, BTW, I don't think packages will ever land. OK, guess I picked the wrong expert witness then :-) But even without shorthands, your 'intern' version is also package-aware right? So it will do translation taking names, nicknames and package-local nicknames into account, no? So in theory it will be just as "dangerous" as taking shorthands into account. In any namespace system, what you see is not necessarily what you get. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 11:10:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 07:10:29 2026 Received: from localhost ([127.0.0.1]:40486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1jMa-0008Th-Li for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 07:10:29 -0400 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:54761) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1jMV-0008Po-OO for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 07:10:26 -0400 Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-439b9b1900bso2322805f8f.1 for <80574 <at> debbugs.gnu.org>; Sun, 15 Mar 2026 04:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773573022; x=1774177822; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3Lq+lEjWgxv4UlI4S7EBqjvZ82Hh4kWb0EgrNdJftdA=; b=cAbt+4VWQqDxhUFnkdmGaAQBWRNaExo5YGh8nFQ48g389VSCO8Yy3Cb24DhCR7vRR6 HNIaCzMSrNROMSM0F0zvA7c8oAvASUnh2KISMQRr58+fiPIVS3MKTJl/1NcQXsa/TU/o cnLygOG8lT9f+8OXgh5W+7Efv8czK3yJuvC6XaF+oe+A41KZ0vD4jnyHO29PAqHcM8tM GzCQs7QGU1kvdlqgjiQNoqCsGlDKd3gwY4O3K/TAtv7K3SQIUVjMtlujulJlNaiWxW4Y MxPJLdP6HxeUUsUjvdKHbIxzIJqOWpitywQ8b5O5ofLCC5pZmKaYDXty9jaas5GzxINT KQ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773573022; x=1774177822; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3Lq+lEjWgxv4UlI4S7EBqjvZ82Hh4kWb0EgrNdJftdA=; b=R/qVHxPGPlpMaz6yfaZcoTnMJSQamhHCkRNP4xhYMne0JqlvAeQPxwxqC8nAaVCU3x JAf9cmTzKwmJwFeGc7Uh7tbd3SBQEv+4A931ZVnTwIXXrVeqsnmgn8p5/cr6mzlJJu95 /qzMymdnjY2ulHPbzX0NcfMs0UH3MzZS/G2OpK6dpw5L2pXs/ej/fj2cOeQYzIvlEcGI Lp9LCRzahx3+ezed7tX4sT69+Q3+XFIipcI4V6mI+ZxBW2Mkdxja0EWtvwDLG0keomif F9hHqtofteU/l5m9Pg2CzSkMarITS5Yus32joTwPbAXMZr2mRvTuolL2ravq7m58WATw SOHQ== X-Forwarded-Encrypted: i=1; AJvYcCXO2FgEcqCn/YEcE39PlY8tAhD6FLL1Jj0vqkDvqCrN6sWSOuQzic5bIq2s/mLjjF7M1t8duw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxuCBgX4DEHdHvu2jucuKT5yBzaaqlAJDmqXz54QAHbTYmz0gOa I+dMXOORpXwlQ1upJkJW9TTy7qoB23tst6ksIGZdhWmG0QHOT5pSujD3GKAapA== X-Gm-Gg: ATEYQzxaJUcVVib8eJVhAvCR92dLceluyTnIkmI6HjEGWmJQXMKQUlPZPRvs39pbJLp dDwHoJPlqHJ4AA2fDHS/couBCEXCkvxvCLBWyTKCYxiFBIaH0N3snbT5sifVJVrLW22EIU3Y9xM ne/ijqoB5MxkE6HKEcXq9YaZiPmiOHGa7tuB9VlzEFt8o4yxBGvF4THvWQByOS9wbzWQVjEtKlL 2ZYMwBMQvqf+frVMG0AKKA1xHStk0gdJiZF3GbjeoReOvLAtQh/lwzAbQGfet/+RkLNvv7w2taa oY1eD96nllHHmmQ/krZMTHXjRqxjEEu+FKiZrH+0xSQYcu8RnWmr+umvtcGic6gYHn2J06DIH0n GZ41q2BqmFzeWQ2GS3GRnDh0KyjziaIYafQJGMt5hnkvnYnWwIOd7IGtfQJT2qgYbAAWQJJwZyo kZyssIwNBrS/VLJvAPFnfpdKBgbNinEFDojfv+vYlRReLeM9Cwpdmm42+TB4wvj0DiHcV81NOBE iC84+weiNqgLJkUiHLOhLDLX5U1ZZg2lVYkwQ== X-Received: by 2002:a05:6000:288c:b0:439:c799:dbfa with SMTP id ffacd0b85a97d-43a04d78446mr16654542f8f.9.1773573022027; Sun, 15 Mar 2026 04:10:22 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe226473sm33262452f8f.32.2026.03.15.04.10.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Mar 2026 04:10:21 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> Date: Sun, 15 Mar 2026 11:10:22 +0000 Message-ID: <87tsuhpcv5.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: >> 1. doesn't mitigate the security/accidental aspects of shorthands >> anyway, > > That's a bold claim. Can you back it up? I've already done so up thread: it's still too easy for users to end up executing shorthanded code in files with absurd "list" -> "shoot-rocket" shorthands they never reviewed. >> 2. creates an assimetry between 'read' and 'intern' that was never >> ever there and likely isn't there in any Lisp implementation in >> the world. > > Can you clarify what is the symmetry that you think is thus broken? I've also done so up thread. Once of the version first lessons I learned in Lisp was that 'read' 'intern's strings into symbols. And naturally calling 'intern' on a string would do the same thing read does with that string. That is broken. The today, built-in 'read' on a stream that produces "(f-foo f-bar f-baz)" is indistinguishable from calling a custom-reader (such as the very real one I linked to) on the same stream. Both readers intern 'foo-foo', 'foo-bar' and 'foo-baz' if shorthands are configured "f- > foo-". Tomorrow (with your patch) the second reader will produce the nonsensical "f-foo", etc, because you broke that very first lesson. >> 3. makes introduction of proper CL packages harder. > > I highly doubt it. Do you have any evidence for that? With your turning off the syntax smarts from 'intern', then calling it with "foo:foo" will, I suppose, intern "foo<colon>foo" into the current package. It will not, as would be the case lookup an external symbol with name "foo" in the package any package named, nicknamed, or locally-nicknames foo. Shorthands are very similar to package-local nicknames, by the way. >> As I suspected Gerd's cl-package branch also has normal 'intern' >> also consider packages (maintaining the symmetry). > > I can't see which part of my patch would prevent `intern` from > considering `*packages*`. =20=20 CL-packages have package-local nicknames [1]. In fact, they are preferred over global nicknames. In short, just like shorthands, you can refer to the same symbol by many manifestations and the mapping is usually coded up in some file in a DEFPACKGE form, much in the same way read-symbol-shorthands do it. That mapping has to be considered at load/compile-time and (if possible, it's not always possible in CL) at file-visit-time, just like read-symbol-shorthands. Now, how can you be sure none of the non-Elisp reflective "smelly" uses of 'intern' will also accidentally link to one of those symbols and cause the first ever recorded case of the havoc you're trying to prevent? >> 4. as we've all already admitted, creates the real possibility of new >> bugs in parts of Elisp-reflective tools that are working fine in >> shorthand buffers. You seem to view this as an advantage, but you're >> still inflicting potential pain on someone. > > I obviously don't see the risk of such regression to be an > advantage, no. I consider it as a worthwhile price to pay. Yes, but I thought you viewed this as an opportunity to experimentally determine, via bug reports, what parts of Emacs-(land) 'intern'-use are indeed Elisp-reflective, and which aren't. That would indeed be a small advantage. >> In contrast _I_ have a hard time understanding why you (or "we" I don't >> mind helping) don't just do the much simpler safe-local-variable thing > > I can't speak for why the maintainers haven't done that yet, sorry. My bet is (I may be wrong) it _will_ eventually be adopted, making your shorthand-intern patch phyrric at best. >> and take the advantage of the fact that we've already isolated the >> cases of what I called "smelly intern", in which 'intern' into the >> global obarray is (ab)used because Emacs didn't have hash tables or >> developers were "lazy" to use dedicated map data types or simply >> dedicated obarrays. > > That's orthogonal to this discussion, actually: How? How orthonal?? The _very thing_ you are trying to fix is preventing exactly _those_ 'intern' uses from accidentally finding symbols via shorthands (even though that never happened except in extremely artifically conconcted cases). So a child can understand that if you address those cases to _not_ use 'intern' or to use it differently (separate obarray, for example) the problem you are trying to fix is solved. In fact, up-thread you hinted a version of "intern" where they keep using it but where a second explicit argument of 'obarray' means non-shorthand-obeying. While still not ideal, this would be even easier to do across the Emacs code base and be much safer: i.e. no "worthwhile price to pay". > - After changing all those places, blindly obeying the value of > `read-symbol-shorthands` in the current-buffer in `intern` will still > encourage bugs because `intern` doesn't know if the string it receives > has already been longhand-expanded Never been a problem to this day, but it could know that easily or not need to know it at all. We could very easily statically verify no recursive prefix expansion is possible, i.e. go through the map verifying that no longhand is a prefix of a shorthand. > or not nor whether it comes from the current buffer or not. You've already said this a few times in this thread, and while it's not super-relevant, it's not true. It doesn't need to "come from" the buffer you're looking at, i.e. be part of the buffer-string/physically manifested there. Shorthands, like any namespacing mechanism, are useful to designate an infinite space of names sharing a common characteristic. So if in my file all "bc-" is shorthand to "breadcrumb-", you still want intern called with "bc-yowza" to lookup the "breadcrumb-yowza" symbol, even though it was never written before. Even (intern (format "bc-%s" (read-from-minibuffer "sym fragment: "))) should keep working and point to breadcrumb-whatever This works today and it should keep working like this. Jo=C3=A3o [1]: https://gist.github.com/phoe/2b63f33a2a4727a437403eceb7a6b4a3
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 04:06:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 15 00:06:23 2026
Received: from localhost ([127.0.0.1]:36068 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1ckA-0007KN-3n
for submit <at> debbugs.gnu.org; Sun, 15 Mar 2026 00:06:23 -0400
Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:49206)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1w1ck7-0007Jm-1v
for 80574 <at> debbugs.gnu.org; Sun, 15 Mar 2026 00:06:20 -0400
Received: by mail-wm1-x331.google.com with SMTP id
5b1f17b1804b1-4853fd7b59aso20740675e9.2
for <80574 <at> debbugs.gnu.org>; Sat, 14 Mar 2026 21:06:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1773547577; x=1774152377; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=L6v7QZkea5L6rG6NQ0it52tiQeTOosvhDcI2whf0uUs=;
b=Khw9QS3PGdwV5Sn5aW5qMoGl9gMgydGOpDGGWXPZHNgU4t2jrtoEw26zu1pW6xkL27
JXSaWszajrY9+QuhsvZAjW7YZjXxBaR7WkqszFAhNI6+u1aFpaAiSgjC/pl/3SsG+QEd
LQOlBgHuvNtfSYWyJdSqBgv+GDTFqO3QwO6vUvBpPA7j8gAEYh96whuxwPB0ZfAkeanm
lPJJhT9z191PvS6TkSSfLRHXCGXhyc5V2gUfGmKv24QYRBY4yD+P1ZkQsbcEjN9rgdH3
lhZZdQ7YDyPa04mhLiVE0RW/17h0fV8MOg5gyRNI+ST/9to+52NvezM1EGXZ4sKZltnl
trhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1773547577; x=1774152377;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=L6v7QZkea5L6rG6NQ0it52tiQeTOosvhDcI2whf0uUs=;
b=MuT4PmMksEGm77Jykvsj1aDQzPj2QJO5x1RzDif0/biSPXU5jcGtls63LMQW8gACD0
zK7PapZRLx4grqo2f2reOnpDKn1+RT1gRzDWwXys8Q4/VJ/hCcu732D0VH/7k5nhuJ87
E+whU2AUb0pD5SCLX17Zue87AMITzPvGP7vKXd8kWKwOLxvatTEYEAsNpP60ZSbT0jMI
gxp3uMu8UoZ0ixQXJBxbSuaVmVp9Lam7VFJAgxjXwEEBzRdZUxpL3AtwJmSs3s/Z1BDo
aygroMua6JoCgPwkazlMEakN5Jbk98uf5LsM0Q7dqCGni75cYJleUOlInZGHi7Rfl687
leyw==
X-Forwarded-Encrypted: i=1;
AJvYcCXeSe11qEFL9JEbEVcCHMdxGhWh7uOM/i7PozVYuKao2tsBe6JBTCwfZeqQ+Q3aXYeeWS/Ojg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwD+cUhZbp/2mqwNdIjvV9IheMcD9kt7UU4KvYadeh8aqMZhy0Z
/sBCpF9uu1YeOQ4waEYF99ZZMSb70tDM3FZYeBvJxnUwOJQycM4lC2eU6lAOJw==
X-Gm-Gg: ATEYQzzyJqShcZRnuvpYLqZmuYpjkF2TnVB9n3y9RHyFWGEeQByrsPKygBkQttbFoM8
Q7gt00J856UdYF9+ZdZYbn73XEAkCYA2E1dV4AwurIR5dDbTxm8Sxfx2SCLcChMGn2JbLlPMyZu
MTpNBS9vpW3xK9R5ae7Ml3G9aCFAyw8C4G1eEH7YPLRlUOJDq2YfQ+cd4bqACjoGCY1OwI5Dz5y
xOgLNACCc87gLG8HvrDWnrsXiA4W5Hs0L/cMRsyYSkTxNcYqndnV7RE1RvCoKPdy4FG5WUHArgY
JnTgPhfSf2l6mmhVxHNmRxoOAGRU9dn27o6artL0KCJmKlgZ2vm5aFjfZTunXNEzwOwQLLDK33H
F+KwmCADfqP9bWDgJ9XNu32btx1ugn+jqy5WbT0T2f92nh4fwl1UhglBFpfTtf19FJpKQY4HbCF
zEjSjIUAeYVHb7ehdrOfLjxqhroiIYdYW/BzumWYQ7yL8trFS/TV0xqXe1QNcUE8z08JUdrFLma
5sIY3PDfT0NmcPxkx/TVwv1iU9iBkK2P+s=
X-Received: by 2002:a05:600c:4753:b0:485:3fe6:2209 with SMTP id
5b1f17b1804b1-485566d516dmr131568235e9.11.1773547577047;
Sat, 14 Mar 2026 21:06:17 -0700 (PDT)
Received: from pro4 (p200300e0b714f100915b4da84a01975d.dip0.t-ipconnect.de.
[2003:e0:b714:f100:915b:4da8:4a01:975d])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-48557c6e2b1sm56880655e9.28.2026.03.14.21.06.15
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 14 Mar 2026 21:06:16 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <87zf4aumsm.fsf@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN>
Date: Sun, 15 Mar 2026 05:06:15 +0100
Message-ID: <m2cy15zqh4.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80574
Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org,
Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:
> 3. makes introduction of proper CL packages harder. As I suspected
> Gerd's cl-package branch also has normal 'intern' also consider
> packages (maintaining the symmetry). Speaking of that, maybe Gerd's
> opinion on this might be relevant? CC'ing him
I'm afraid I can't say much of help. For a long time I didn't have
shorthands in my cl-packages fork at all. When Magit started using them,
I've grudgingly added them on top of CL packages, but I did that like it
is in master of course, to be "compatible": intern translates the symbol
name according to shorthands like master does it.
DEFUN ("intern", Fintern, Sintern, 1, 2, 0,
doc: /* */)
(Lisp_Object string, Lisp_Object package)
{
string =3D translate_shorthand (string);
return pkg_emacs_intern (string, package);
}
PACKAGE here is a package object, obarrays don't exist, STRING is the
symbol-name,
static Lisp_Object
translate_shorthand (Lisp_Object name)
{
if (NILP (Vread_symbol_shorthands) || !STRINGP (name))
return name;
Lisp_Object found =3D find_shorthand ((char *) SDATA (name), SBYTES (na=
me));
return STRINGP (found) ? found : name;
}
...and s on. It wasn't particularly difficult.
From reading Stefan's initial report, I agree with him that translating the
symbol name while interning doesn't feel right. But I'm kind of biased
anyway :-). And, BTW, I don't think packages will ever land.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 15 Mar 2026 02:25:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 22:25:34 2026 Received: from localhost ([127.0.0.1]:34912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1bAc-00027x-3b for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 22:25:34 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3153) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1bAZ-00021s-7g for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 22:25:32 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A2A41100146; Sat, 14 Mar 2026 22:25:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773541523; bh=6MqnhMwIvBcqUwPSiHQBO2O7PjAv/sBPcEK5x5XYs9c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=CNHfQFsAB5+ZB0xTpZeDpMOHrVCvf1LUACmqZBR1RvM0v23dpwysvyxpBHmZY2yUJ Zlnfs41h07KWLPyp5SAwKoD4ZAlCrBpokDhanx2AQE4dPuWfTyYxGB0NT8rGkqcHdD iGLGCqllLvLIQY2SPrNI03NdZRc3KuB7ChFbDmBN3Kb4sz7lpSTGK510G2F0n+itDK XPlHFr3YbT6CfP8bHBSRByluobSAdP9Cj7uaxrWtyUQRByPL9ipYp6DnormoKGyY4m uHPU4+J0kmf6Mmg2afgAJzeEcEt67xKvArL27dkmj3DeRHsxO8SrVmwo82Ch2vu3a1 nYd/G0kMr8cJg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4468B10002E; Sat, 14 Mar 2026 22:25:23 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0FAC2120C75; Sat, 14 Mar 2026 22:25:23 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <87zf4aumsm.fsf@HIDDEN> Message-ID: <jwvy0jthmmm.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN> <jwvfr62i5te.fsf-monnier+emacs@HIDDEN> <87zf4aumsm.fsf@HIDDEN> Date: Sat, 14 Mar 2026 22:25:22 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.069 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> I still have a hard time understanding why anyone would > Here's again the rationale. Your "specialized shorthand-aware intern" > patch: > > 1. doesn't mitigate the security/accidental aspects of shorthands > anyway, That's a bold claim. Can you back it up? > 2. creates an assimetry between 'read' and 'intern' that was never > ever there and likely isn't there in any Lisp implementation in > the world. Can you clarify what is the symmetry that you think is thus broken? > 3. makes introduction of proper CL packages harder. I highly doubt it. Do you have any evidence for that? > As I suspected Gerd's cl-package branch also has normal 'intern' > also consider packages (maintaining the symmetry). I can't see which part of my patch would prevent `intern` from considering `*packages*`. > 4. as we've all already admitted, creates the real possibility of new > bugs in parts of Elisp-reflective tools that are working fine in > shorthand buffers. You seem to view this as an advantage, but you're > still inflicting potential pain on someone. I obviously don't see the risk of such regression to be an advantage, no. I consider it as a worthwhile price to pay. > In contrast _I_ have a hard time understanding why you (or "we" I don't > mind helping) don't just do the much simpler safe-local-variable thing I can't speak for why the maintainers haven't done that yet, sorry. > and take the advantage of the fact that we've already isolated the > cases of what I called "smelly intern", in which 'intern' into the > global obarray is (ab)used because Emacs didn't have hash tables or > developers were "lazy" to use dedicated map data types or simply > dedicated obarrays. That's orthogonal to this discussion, actually: - After my patch, such changes are still desirable. - After changing all those places, blindly obeying the value of `read-symbol-shorthands` in the current-buffer in `intern` will still encourage bugs because `intern` doesn't know if the string it receives has already been longhand-expanded or not nor whether it comes from the current buffer or not. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 21:24:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 17:24:43 2026
Received: from localhost ([127.0.0.1]:59505 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1WTS-0002UU-FM
for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 17:24:43 -0400
Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:51205)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>)
id 1w1WTP-0002U5-K1
for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 17:24:40 -0400
Received: by mail-wm1-x336.google.com with SMTP id
5b1f17b1804b1-485410a0a8aso30375935e9.2
for <80574 <at> debbugs.gnu.org>; Sat, 14 Mar 2026 14:24:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1773523478; x=1774128278; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=0B9/TDyEsNPJt9vJXZvsNtI+JJxnhESYNZuXrYSPtxc=;
b=BwyUwy4FhX4NZ8IkSGMsdjS2smkRzPnQ4SlT+WI7SjsaY2EvPsHGrNYcQ6oDLQdUSS
Vt2Gh7Z1CKGnNUc388OljUe80BOOA5tWGPfyA2cw9JdcW/BsSHrft+f2NodUkTFjPh1A
wtEowLVhxuloZZ2Lpw28CKGD/cwD0xt6HAjm56jDb1gDBaKgnQ/hcoPsBPqmmsYInQeJ
7dDkkuzSUqhhPgU1xPm12kXhaGjWH6M+GbpvSMeIt4ySgM7cdT7WyzJi7ZrGWlzLjD5U
XqVk6H0mZBtgavLnRuipnvktZTnXxLUvowADoW/T9e7MXmRHKv5jlgF/G2ZsryhshMC3
NklA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1773523478; x=1774128278;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=0B9/TDyEsNPJt9vJXZvsNtI+JJxnhESYNZuXrYSPtxc=;
b=P9QBiuyJLSzJvNtwUGmhBOyHQtg49uG9u9yBa3zfKt5DWq/USOUVt8Mm/Is0axCmza
T8+KmXPgy9TquPvpVDTZ178/8omm/2fiaN3jd/+jw7JOIPvqwii1YqvcC+scWIMZbhK2
vS7nBIIxxEtBc1/FTCI7iQs+zrtFVeLvAAwYWCaV4wE4Ez8nUBX4sAVAir/++O0Tmn5o
b2IsyNDTEJrrS65GBgh/i4mmaCSelyLAjvN6Fq3eG9qvCGsH2Sy8gDNJF5EkF4xS0lkK
sOSctLDPs8tqiZDpbUU4ktoPWkfolkvKrFCLz5nnAYZ/VucQDAdThNLFXvNJayqNTuMm
wurQ==
X-Forwarded-Encrypted: i=1;
AJvYcCXpFts6jtQiwivYyUG9xTrrA3rvR2d6Xp94eCzAOpYf73RE54rg+UQuOxfUE0SuOvbqGu4FQA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyCVOWdWEWM4qIuf/hu2GEYPjF2esNV3ct8k09Wc5jambbhM7sa
xALf7lGv0WuDT9fK+QnYa2td8bY41cxS3lURZYNb+tGk7k0nAnfk9o8E
X-Gm-Gg: ATEYQzzOJBaLXES5j69QXJ3hP1BhXCmgmMGffnDP9cpEXhPI/3Sezjp/3WyIYx3b7KG
worSWbKIXOrWLoNVU03YpjwAMSomfdxD+nru3BBMfrX/cVdQcgfFEXAwIZlXS4whto7OgBjB9sV
2qoVIObFXT2eBj0t9bkbr6XVWUqcknVpRJQPSuTxawNdCD/JEG+1MR7qsQ+36ahBm3eXmArx1s/
G8Gt4U4w6cDtwJdTK08gmWfaNmgfmRwirQFub4PNBH6oTjj73Mo/OFpHXkmSj/UyTASgDXWzUxS
jWauy5UJhtj4EcJPGV3Ac+w2lY6XlsRKYPHbjAAyXdcxXarFr1/cgWU+N4Y8KO5I9VWUp2x8pvq
7l+RfPKX3+613VB59HmarUGa5jckfH2FJeL7Q7DGlQ1FmlnlHxyLytMJlqvGzPkVGEpX2GYKknt
F5eqIoblobXAgw2wnoRjZD05qMdkX6wbetiAFuW1aJro3UBI2J4qM+QU9kC2fNXwyCcEDBoDePd
oFozmCumrNlvc8wAz8FzexVxOg=
X-Received: by 2002:a05:600d:c:b0:485:17a7:ba0d with SMTP id
5b1f17b1804b1-4855670e7ddmr93380245e9.32.1773523477598;
Sat, 14 Mar 2026 14:24:37 -0700 (PDT)
Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-48557c7ae54sm52377395e9.31.2026.03.14.14.24.35
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 14 Mar 2026 14:24:35 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <jwvfr62i5te.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
<jwvfr62i5te.fsf-monnier+emacs@HIDDEN>
Date: Sat, 14 Mar 2026 21:24:41 +0000
Message-ID: <87zf4aumsm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80574
Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
Stefan Monnier <monnier@HIDDEN> writes:
> I still have a hard time understanding why anyone would
Here's again the rationale. Your "specialized shorthand-aware intern"
patch:
1. doesn't mitigate the security/accidental aspects of shorthands
anyway, the only way to mitigate them effectively is to restrict the
file-visiting use of read-symbol-shorthands. I'm attaching a patch
I've already sent elsewhere that does this.
=20=20=20
2. creates an assimetry between 'read' and 'intern' that was never ever
there and likely isn't there in any Lisp implementation in the world.
3. makes introduction of proper CL packages harder. As I suspected
Gerd's cl-package branch also has normal 'intern' also consider
packages (maintaining the symmetry). Speaking of that, maybe Gerd's
opinion on this might be relevant? CC'ing him
4. as we've all already admitted, creates the real possibility of new
bugs in parts of Elisp-reflective tools that are working fine in
shorthand buffers. You seem to view this as an advantage, but you're
still inflicting potential pain on someone.
In contrast _I_ have a hard time understanding why you (or "we" I don't
mind helping) don't just do the much simpler safe-local-variable thing
and take the advantage of the fact that we've already isolated the cases
of what I called "smelly intern", in which 'intern' into the global
obarray is (ab)used because Emacs didn't have hash tables or developers
were "lazy" to use dedicated map data types or simply dedicated
obarrays.
This can actually have really good performance impacts: Emacs commands
(thinking mostly about completion, but perhaps there are others) degrade
significantly when the main obarray fills up from long running sessions
(and we all know Emacs is overwhelmingly used for very long-running
sessions). Also I probably don't need to tell you that hash tables
don't really come in "one size fits all": specific problems can benefit
spectacularly from specific variations on the structure.
Jo=C3=A3o
=20
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index 9c668bb3720..ad7db9d154d 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -29,6 +29,11 @@
(require 'files)
(require 'mule)
=20
+(defvar read--symbol-shorthands-safep nil)
+
+(defun read--symbol-shorthands-safep (val)
+ (and read--symbol-shorthands-safep (consp val)))
+
(defun hack-read-symbol-shorthands ()
"Compute `read-symbol-shorthands' from Local Variables section."
;; FIXME: relies on the `hack-local-variables--find-variables'
@@ -39,7 +44,8 @@ hack-read-symbol-shorthands
;; trying to look for shorthands in the files that implement shorthands.
(let ((hack-read-symbol-shorthands-function #'ignore))
(alist-get 'read-symbol-shorthands
- (hack-local-variables--find-variables))))
+ (let ((read--symbol-shorthands-safep t))
+ (hack-local-variables--find-variables)))))
=20
(setq hack-read-symbol-shorthands-function #'hack-read-symbol-shorthands)
=20
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 946d3ba10be..fe4dea564a1 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -2864,7 +2864,7 @@ elisp-byte-compile-buffer
(delete-file elc))))))
=20
-(put 'read-symbol-shorthands 'safe-local-variable #'consp)
+(put 'read-symbol-shorthands 'safe-local-variable #'read--symbol-shorthand=
s-safep)
=20
(provide 'elisp-mode)
;;; elisp-mode.el ends here
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 19:23:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 15:23:10 2026
Received: from localhost ([127.0.0.1]:58620 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1UZp-0006AS-S0
for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 15:23:10 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3690)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w1UZn-00069P-Ls
for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 15:23:08 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A47ED4416A8;
Sat, 14 Mar 2026 15:23:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773516180;
bh=UOccJKV9Ycv/CYFIY535Q6SXFsPK0A/kkpkbuOHiAqI=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=Mlxza8FUZDDseSTkQRtiBrbtKHus0rhzwuFn1d4UyqrvUqLGnJhjuePgXIx4obUwl
uqP8ChqDS3azDUQHa9IpqmljCvY2yprKwi36YJXRrzzwHPavSTzo5EfFnlKYFzw4yG
lPWWk/0p8NJ/wrgFbly2jrcUfbXPAAB64owGv3K0ZVi0haTRrcfNUTY++kPa25H/Hn
Q/L2HiCeXV7twre2+RjgMZo/Xxsm/uGWwx0twEQwfSxHYVoood9Vl5dpbdWZCq+0R6
RV7dzBsm6BYBhNK6jn1vth78mt33rVdKUfWY1r0J3XX+lZ4uoAcckTdp5QfBzQgGdG
SWfFo5wV+ToWw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 909F8440230;
Sat, 14 Mar 2026 15:23:00 -0400 (EDT)
Received: from pastel (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 66CDD120E9B;
Sat, 14 Mar 2026 15:23:00 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <86bjgq8gvr.fsf@HIDDEN>
Message-ID: <jwvfr62i5te.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN>
<jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN>
<jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN>
<CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN>
<jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN>
<jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> <86bjgq8gvr.fsf@HIDDEN>
Date: Sat, 14 Mar 2026 15:22:59 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.068 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
> For example, how about some special text property on strings which
> should be intern'ed taking shorthands into considerations?
Eww!
Not interested to help anyone go there, sorry.
> Or some similar mechanism which will allow primitives to know when
> shorthands should be in effect?
Of course, instead of
(shorthands-intern FOO BAR)
we could use
(intern FOO BAR read-symbol-shorthands)
or
(intern FOO read-symbol-shorthands)
I even mentioned those possibilities in my first post.
> How hard could it be to implement something like that, and thus allow
> people to avoid any regressions, at least those which we can envision?
As long as the default is to obey shorthands I think this is a recipe
for keeping latent bugs with security impacts.
I still have a hard time understanding why anyone would prefer that over
adding to the existing occasional frank and honest failures to
understand shorthands in a few tools.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 17:23:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 13:23:32 2026 Received: from localhost ([127.0.0.1]:58143 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1Si4-0005et-9t for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 13:23:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54622) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w1Si1-0005dt-9j for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 13:23:30 -0400 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 <eliz@HIDDEN>) id 1w1Shv-0006zF-6q; Sat, 14 Mar 2026 13:23:23 -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=vTL1H8y7z+Fm9ZFAFeCWbIsIpC9jeKFIJmP6ewGpvpg=; b=N2m1Qy7UT/gc WHWHBpvOGP7pKhnTEYL40u8LN30TLexw3EtstuCcJa5diqTYF1WpTH1y3eXVVV6OHaEenMj5DcARq Gf1NEeAIdOOp4fn+IU+ClwzM6WKLSLcdiHgRhf1uWlwmDTIkBkjQtZtiZO+G0n4nm+X3HvWFhURQc rq29/UTjOnKf0OdFWfdzZOzXhKDlXkm5mChL5mH/2JPB8cFy14js0kjJ6WemHXO0Ve9h3txF5fvpy 2DA6Upu32fdcHY0/YhwWYL/Y9KlKp+G7E8LrP5JNIbYKDTJQ9PfL5EZyapIKnkPDC8c+gMJbVPngZ LA8MGvyrK9derQodhl8wdA==; Date: Sat, 14 Mar 2026 19:23:20 +0200 Message-Id: <86bjgq8gvr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 14 Mar 2026 13:03:00 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org > Date: Sat, 14 Mar 2026 13:03:00 -0400 > > > FTR and FWIW, I don't disagree with you on the above. My bother is > > that the solution you propose is problematic for the reasons I > > explained. > > I don't really understand the reasoning. > > The main risk with my patch is the introduction of regressions in the > tool's support of shorthands (while I wrote "without introducing any > known new bug", I must say this was poor choice of words: I'd be > surprised if it doesn't introduce any regression at all). I simply don't like changes that leave known holes and expect users to report them in order for us to fix them. I very much prefer that we provide guidance and means for users to avoid the problems in the first place. And you are AFAIU saying that this is impossible in principle, or at least impractical, with the changes you propose. > But AFAIK shorthands are still a fairly little used feature, and they're > still not fully supported by all our tooling. So a few potential > regressions (and easy to fix ones at that) in a not-yet-fully-supported > feature, seems like a bargain when it fixes a clear bug like the > security hole we have. It is even better to avoid the regressions in the first place, at least as long as users follow the procedures and take the measures we tell them to. There's even no way to process shorthands from C, where quite a few primitives call 'intern' or its ilk, and may need to process shorthands. But you seem to object to any effort of finding and/or implementing such procedures and measures, which I frankly don't understand. For example, how about some special text property on strings which should be intern'ed taking shorthands into considerations? Or some similar mechanism which will allow primitives to know when shorthands should be in effect? How hard could it be to implement something like that, and thus allow people to avoid any regressions, at least those which we can envision?
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 17:09:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 13:09:45 2026 Received: from localhost ([127.0.0.1]:58033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1SUg-0003OA-UN for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 13:09:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46048) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w1SUd-0003Mn-J1 for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 13:09:40 -0400 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 <eliz@HIDDEN>) id 1w1SUY-0005lk-8i; Sat, 14 Mar 2026 13:09:34 -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=zeuFUljUwScddpRlozSHFVAzv9zYVS359/2tkzCso6I=; b=ZZoqylhzGIIY Ijov27e0+W8OqGJgXmQzjTbP84A+VOoOByI5nouVn43EFBUsqM8trWX/4IDPn/yWFW4E5iCPxkIMr X2rlOyZXdEtbrO4bmPc0lTiUzGEQ182S6bSlETtINmfWomJRcpOdGdshqE4Wihdz5hhjjzNge8qYu BenWkhVCmaTAi9ZIWjjdefHrva8CRq6BwkkiTvDABbpk4mHgaTcqh66TbimUWJ9Sdu44Ue9r7FeaY eFWeJlV/OoB/BzoIZNZBpu75oNRqBHjHxd85lreOSDArtBI75CuZu0oj3BFFTmEMot+DF5Yd4uozF QmwW+LbnizyFJSfvwVIHeA==; Date: Sat, 14 Mar 2026 19:09:31 +0200 Message-Id: <86fr628his.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvwlzeid8f.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 14 Mar 2026 12:42:53 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN> <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN> <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> <86ikaybwyo.fsf@HIDDEN> <jwvv7eyjuvj.fsf-monnier+emacs@HIDDEN> <86ms0a8lkj.fsf@HIDDEN> <jwvwlzeid8f.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org > Date: Sat, 14 Mar 2026 12:42:53 -0400 > > Not directly no, but if I correctly read between the lines, it means you > intend to plug the security hole by marking `read-symbol-shorthands` as > an unsafe variable, which will introduce new bugs of the form "Emacs > doesn't understand the new shorthands feature when I do FOO" (where FOO > is something like "I did not tell Emacs that the > `read-symbol-shorthands` setting is safe"). > > I think "mark it unsafe" was a fine solution in the short term, but now > that we have a patch for the underlying problem, it seems like > a poor solution. But I'm bothered by the proposed solution, so it's not really a solution from my POV.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 17:03:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 13:03:12 2026 Received: from localhost ([127.0.0.1]:57983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1SON-0002YL-Qq for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 13:03:12 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:17212) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1SOL-0002Xf-02 for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 13:03:09 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 75501441697; Sat, 14 Mar 2026 13:03:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773507782; bh=FcE3LWTml791qH9VoQVFcFFlrmmfVoIG3fNFqLOmOUI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EJIxlJ2TURFxoMIWNdFYOwv51qdLIIVdRZPVJXfHCNR5vtLGmh6kXUdOeCK+2ChJv UNiEvxk0foEJnSP1vRbMjocCHCS6aJmKoBYTO4zVUpeGxdsGYOrAM3ZC7GhUvnktKY JzfFHck3eN67+TiQxJxS6/nhsSsQ4Ddo/jGQpBNciEcC+Z7zRYl/u02AGLPCvBiI13 PynEonhvAoo2s9HA8fbwVs8XtiBigws7gQTAEaGkEVN0sop6mJXxUFULBz3K8di2/7 eVy7LESsk3QB0XNo7GtMvyH0qSlQXJyOT/dhtfqQcsNoJPTYREWIzWvOokMJDYHopE wjk0cy5oX+gRw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5C42B441692; Sat, 14 Mar 2026 13:03:02 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2A7C8120490; Sat, 14 Mar 2026 13:03:02 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86jyve8kkk.fsf@HIDDEN> Message-ID: <jwvqzpmic4u.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> <86jyve8kkk.fsf@HIDDEN> Date: Sat, 14 Mar 2026 13:03:00 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.070 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > FTR and FWIW, I don't disagree with you on the above. My bother is > that the solution you propose is problematic for the reasons I > explained. I don't really understand the reasoning. The main risk with my patch is the introduction of regressions in the tool's support of shorthands (while I wrote "without introducing any known new bug", I must say this was poor choice of words: I'd be surprised if it doesn't introduce any regression at all). But AFAIK shorthands are still a fairly little used feature, and they're still not fully supported by all our tooling. So a few potential regressions (and easy to fix ones at that) in a not-yet-fully-supported feature, seems like a bargain when it fixes a clear bug like the security hole we have. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 16:43:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 12:43:05 2026 Received: from localhost ([127.0.0.1]:57860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1S4u-00086Y-N3 for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 12:43:05 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11657) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1S4r-000852-HM for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 12:43:02 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0844C100146; Sat, 14 Mar 2026 12:42:56 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773506574; bh=kpqOcbIdaPxNn54CsYpI8mlRQVbHvc7Kd0HoNvfGH1k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZvKT4Lfc/gNrLo0rkpS5kAFj/EeXW7Bstzj8uwO1ueyDW04zTROIt2amf1zY0wlpK HkbrE/PpIsSGo89xLXeTyC+7LHcwB3IJ92AoluZxVH4xATZJJ8mvSpu4C7YLFfsC5V UOlqLp5QU8bMpA8xSEkkMeIz2CZLo1pr8sEkN8Pl1mBkvvXC7jQOym/LU8g3rxPuF6 6YZbNHOwtBuc+rKizP+vF84as7+3MUPE1AGyIc8hEc3bgK42IIpXin51krn6fPNl6i ozlwE8gsjfLWIYNK2byyPE8nqobXDMcSGfzccGH7RiBPFGBeAjkcPccnhuJaCNCKms MQR3RaehxqXXQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8E51310002E; Sat, 14 Mar 2026 12:42:54 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 62C21120EC8; Sat, 14 Mar 2026 12:42:54 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86ms0a8lkj.fsf@HIDDEN> Message-ID: <jwvwlzeid8f.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN> <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN> <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> <86ikaybwyo.fsf@HIDDEN> <jwvv7eyjuvj.fsf-monnier+emacs@HIDDEN> <86ms0a8lkj.fsf@HIDDEN> Date: Sat, 14 Mar 2026 12:42:53 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.094 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > In general, having stuff broken where letting it work might be a > security risk is okay in my book, I agree, but only when the security risk is inherent to the operation or fixing the underlying bug is too hard/costly. There is no inherent security risk in setting `read-symbol-shorthands` (the only reason we have a security bug here is because we're careless about where we use that configuration variable) and, we already have a patch that fixes the underlying problem without introducing any known new bug. > Not sure this answers your questions, though. Not directly no, but if I correctly read between the lines, it means you intend to plug the security hole by marking `read-symbol-shorthands` as an unsafe variable, which will introduce new bugs of the form "Emacs doesn't understand the new shorthands feature when I do FOO" (where FOO is something like "I did not tell Emacs that the `read-symbol-shorthands` setting is safe"). I think "mark it unsafe" was a fine solution in the short term, but now that we have a patch for the underlying problem, it seems like a poor solution. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 16:03:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 12:03:58 2026 Received: from localhost ([127.0.0.1]:57453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1RT1-0001mz-9K for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 12:03:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42100) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w1RSv-0001ku-B9 for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 12:03:52 -0400 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 <eliz@HIDDEN>) id 1w1RSo-0004wv-SY; Sat, 14 Mar 2026 12:03:42 -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=zFH3a4RO+o99ra0/eI3+gO0/BuEceB8v8Vum6B6AWnY=; b=XSKy0CmDUIvQ zPIJpUtB8AALwGhNqpcEWIvn8dpVqfjQZ+CS+zF2AsGZWryz7eK9Gzdx4xWzxPWwKekPtNlx310MP W2E6FIjeZW+gpi2K2a6fbx1Wtkxj36LT930BarqTMGketFH7CCilqN9t4z10boYgjDousAMxdXrj2 0oiVQ8hRF4f5fHDWmGCnEZEutnjGW4nzd7f3U+GyEU8HCBwMRmu9B/T4MjTRSmSoH64jQouX0VDJn OJhMipb8cGhkhzWUgG4bl9GsZc3IR88yYiLZ7ZUsSGOzAslLSwp5sNF56bvkARTWk7+9/hDkGdH5h 3DGG279gBNNK6nzqcpz0QQ==; Date: Sat, 14 Mar 2026 18:03:39 +0200 Message-Id: <86jyve8kkk.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 14 Mar 2026 11:57:18 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org > Date: Sat, 14 Mar 2026 11:57:18 -0400 > > > So (at least my) life would go on with Stefan's patch quite peacefully, > > just a slightly less elegant/pure Lisp machine running underneath. > > Maintainers should try to decide how much they care for that... > > FWIW, my view is diametrically opposed on this one point: I think that > `intern` paying attention to `read-symbol-shorthand` is a hack > that breaks the elegance of the Lisp machine's symbol data structure. > `read-symbol-shorthand` belongs to the reader, whereas `intern` belongs > to the `symbol` data-structure and making it use `read-symbol-shorthand` > breaks the layering. > > This realization was the starting point of my hacking on this patch and > posting this bug report (as evidenced by my choice of `Subject:`). FTR and FWIW, I don't disagree with you on the above. My bother is that the solution you propose is problematic for the reasons I explained.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 15:57:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 11:57:27 2026 Received: from localhost ([127.0.0.1]:57385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1RMl-0000gn-Bl for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:57:27 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64173) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1RMj-0000gA-IB for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:57:26 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 2B09080B15; Sat, 14 Mar 2026 11:57:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773503839; bh=Nh8vC3L3ngat0TVWV2J8zJmK5sZKXYv8UHEfBkHY+zs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gAHkUEbG39BoeyWUhmj+xd6H6xbuZ+MVknrW5KkaHiXM2/EI+Vfvt+417bIcWwNBP tn+nX59Bit7ki19zg81Hc2WsKSxI0fylY5rFKFRuRTF6YnzzGxiEkYHINIYX0m6obx x4MOFOcWErDA9tVE/UvDOEwCv2pNUvKzdy1WYAK23LFmkjpA+RygUiegaszGYl/10K TwvvBADE4ARug0RbDq7aW0vlYPim7DuHX+zaY1ThLEWwiUdY4uOtlg9LQO3o/SmFqX k7ggmJT4W5froSCpvwcWCbiUcsl+F+EOV2jWRgHOGUilYbn0Z5iA1Nza0qZqkhmKI1 r9io6x3QVP66A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4AD3F81C23; Sat, 14 Mar 2026 11:57:19 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1D563120C79; Sat, 14 Mar 2026 11:57:19 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> Message-ID: <jwvjyvejtq4.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> Date: Sat, 14 Mar 2026 11:57:18 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.248 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > So (at least my) life would go on with Stefan's patch quite peacefully, > just a slightly less elegant/pure Lisp machine running underneath. > Maintainers should try to decide how much they care for that... FWIW, my view is diametrically opposed on this one point: I think that `intern` paying attention to `read-symbol-shorthand` is a hack that breaks the elegance of the Lisp machine's symbol data structure. `read-symbol-shorthand` belongs to the reader, whereas `intern` belongs to the `symbol` data-structure and making it use `read-symbol-shorthand` breaks the layering. This realization was the starting point of my hacking on this patch and posting this bug report (as evidenced by my choice of `Subject:`). === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 15:50:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 11:50:38 2026 Received: from localhost ([127.0.0.1]:57316 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1RG9-00080L-LG for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:50:38 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18871) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1RG6-0007yS-Jc for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:50:35 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F003D100146; Sat, 14 Mar 2026 11:50:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773503423; bh=9kXKGoHG/gybwLkQJJTex0s3f528L8FAk0kV0StqKDM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PZNH9eB8/xuhWEp/fBEAxKCy6hO9bMHumq6zlQM/JRyaKTjxACV9GiEj2wiqi7oFk 5//4cjAdc3PlqsvEGor+N2Sj7FdIE861f+JEgONngCIRY+9zTK8gOuI045I69b2i7o WQ/fnjKIxwGvPZkvXkMK3TPixG7p2oVisPFme55Cm+r4BWA6X6RVczpqPh/I2T9aKw 3x5utVwGloWsZ8HBTgk7LiJ0ea9LE+Vk9d8qX/U8Fw4ij+NJRqAV1zE3qo4zuFqBVn AK9ZOGnLIo4JMipXEXkhN6mh29o/2Kd4CCMSsmE3dQbAzkulFepU5Z4IQbuQgVoZBH kek1Jb3PMVgpw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B1AB1100029; Sat, 14 Mar 2026 11:50:23 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 808CA120B11; Sat, 14 Mar 2026 11:50:23 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <CALDnm51+qCxMjiY71W=bcPnfnm2jMkn-YmCXjh-c_9ZdkTo6fw@HIDDEN> Message-ID: <jwvpl56juh3.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN> <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN> <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> <CALDnm51+qCxMjiY71W=bcPnfnm2jMkn-YmCXjh-c_9ZdkTo6fw@HIDDEN> Date: Sat, 14 Mar 2026 11:50:22 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.097 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> But it's a single identifier, no matter how many different contexts in >> which the code can be used: IOW there are much fewer moving parts that >> can lead to harm. > I don't understand that either. Even small programs have a few > thousands of such identifiers, and when editing the buffer they change > rapidly. A single buffer search replace can transiently put the > buffer in a "dangerous" state. Your crystal ball may be quite more > advanced than I am, but for me this is too complex a stochastic > process to see things as clearly. Usually the identifiers that are in your buffer while you edit them are: - Under your control. - Evaluated/called only occasionally when you decide that current state is good enough to try running that code. So I think you're going to find it a hole lot harder to come up with recipe where the above scenario leads to serious breakage, except probably for scenarios where the same kind of serious breakage could occur without any shorthands in sight (e.g. a search replace puts transiently in the buffer `(delete-directory "~/backups" t)` ). So, my crystal ball is still very firmly in the "very unlikely" camp. And remember that the other side is "yup, known 0-day attack". > For example I don't "like" having to set trusted-content-p either in 30.1... You may like to try `futur-hacks-mode` where TAB completion performs `macroexpand-all` and flymake runs the byte-compiler, even without having to trust the code. > The shorthands feature is inherently prone to accidents, no amount of > patching can fix that, short of completely destroying its use. Have > you ever used the shorthands feature? In the beginning you get > creative trying to use clever shorthands and you immediately bump > into such conflicts. I had a bunch of comical ones where my > program would do silly things. I was trying to use '-' as a prefix and it > mostly > worked but then I added some arithmetic and boom. ;-). (Later on it was > decided to forbid all-punctuation manifestations from being > looked up). That's partly why I launched a discussion about coming up with a convention of what a shorthand prefix *should* usually look like. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 15:43:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 11:43:10 2026 Received: from localhost ([127.0.0.1]:57271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1R8v-0006oH-Hh for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:43:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36016) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w1R8t-0006n9-Ky for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:43:08 -0400 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 <eliz@HIDDEN>) id 1w1R8o-0002QT-AZ; Sat, 14 Mar 2026 11:43:02 -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=LKwmsMejpZqmaYsaUUfc+7qsjFadYBLgan1jbWDrqrE=; b=AprOS7+YhNkh NO6YYpIjLMrmiS/4bXRQA20V9qUTHzOjmAfdoFWKcqh5U1iu/7IjndyORa7svR/8lOH+LgaQGV009 a6E2Kpir/xsjekUWLrAMCiAn5QeT8SolgpUEz+mZ0eQVtYl9rtcwqNa+Xik8rvwyF+8lL4537yanu gfeHeAgCFtn9hUn55ZonmZDhjul25/W0IRbOBMyGwh88ut5luhUauNlJ7XmHKUY4bqB4SLufmQ+su atj6FKSZIW5mjSx8KvcMER/hJsIl9nUeNM9/k4j0CCYJWMBv6joRgtikWq1B8+TVtL7Y1gL/dgOab 1x2kF7tHeOI+0hsLUwVG+g==; Date: Sat, 14 Mar 2026 17:42:04 +0200 Message-Id: <86ms0a8lkj.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvv7eyjuvj.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 14 Mar 2026 11:33:33 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN> <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN> <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> <86ikaybwyo.fsf@HIDDEN> <jwvv7eyjuvj.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org > Date: Sat, 14 Mar 2026 11:33:33 -0400 > > Eli Zaretskii [2026-03-14 11:07:43] wrote: > > >> From: Stefan Monnier <monnier@HIDDEN> > >> Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org > >> Date: Sat, 14 Mar 2026 03:36:18 -0400 > >> > >> I'd *much* prefer to fix the problem at its source by making our > >> primitives safer by default, and forcing a more explicit choice for those > >> places we know should obey `read-symbol-shorthands`. > > > > If we can find a reasonably-practical way for finding and handling > > those places, perhaps that could be an alternative to consider. > > But for now you are saying there's no such way except waiting for bug > > reports. And that's not a good alternative in my book, especially > > given that the current code has yielded zero bugs in practice (well, > > except in artificially-concocted cases created specifically to make > > a point). > > The bugs we're talking about here are of the form "Emacs doesn't > understand the new shorthands feature when I do FOO". We already have > such bugs (I think I already mentioned `find-function` as such an > example). They're fairly harmless (users can work around them without > much trouble until they're fixed) and easy enough to fix. > > BTW. What are the alternatives to fix the underlying security issue? > Don't they also introduce bugs of the form "Emacs doesn't > understand the new shorthands feature when I do FOO"? > And/or going through all the calls to `intern(-soft)` and try to decide > whether they should or should not obey `read-symbol-shorthands`? Sorry, I don't understand what point you are trying to make, please elaborate. In general, having stuff broken where letting it work might be a security risk is okay in my book, as long as the user knows how to make stuff working again (after determining whether it's malicious code or not). Not sure this answers your questions, though.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 15:33:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 11:33:49 2026 Received: from localhost ([127.0.0.1]:57221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1Qzq-00053o-9q for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:33:48 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11630) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1Qzl-00051l-F6 for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 11:33:43 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0EB69100146; Sat, 14 Mar 2026 11:33:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773502414; bh=BPdpzDIX7WGtkC7g1+S+KNfemKRflEEol6Y4hW6944I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UVjqwrKHT7zOlvp9SfFCwRJNMYsoBLrahjKISH1WZDGPYRJhW1PP85leIK+nnBcAY OMvBztVil+wdWr4Lf8VQVghM5LSIrQkJzmZU9hMVEiax/vWH9MNjW9sQ1LV5Lk1hFQ iDbOorwZ6WDZaFfcrVn5K5ueQpESvZwaUazlU5Q8NwbGMslWUEcOECxbWOiFiEqnng XwV4AHJ3bPJahuMP7ofCgeHKvcWbkwi7M4G61mUIKbA4yuebuGajMl51ON1CJ3HIVI iaINcUqC3O9+t6v6J5PPZBmUD4jwYQZjKOBKbSg98llRRwvAcL/ZlKfZKagp7v/+wj ZdsIBGGU3Yotg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 25C26100029; Sat, 14 Mar 2026 11:33:34 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E994D1206B3; Sat, 14 Mar 2026 11:33:33 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86ikaybwyo.fsf@HIDDEN> Message-ID: <jwvv7eyjuvj.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN> <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN> <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> <86ikaybwyo.fsf@HIDDEN> Date: Sat, 14 Mar 2026 11:33:33 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.100 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) Eli Zaretskii [2026-03-14 11:07:43] wrote: >> From: Stefan Monnier <monnier@HIDDEN> >> Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org >> Date: Sat, 14 Mar 2026 03:36:18 -0400 >> >> I'd *much* prefer to fix the problem at its source by making our >> primitives safer by default, and forcing a more explicit choice for those >> places we know should obey `read-symbol-shorthands`. > > If we can find a reasonably-practical way for finding and handling > those places, perhaps that could be an alternative to consider. > But for now you are saying there's no such way except waiting for bug > reports. And that's not a good alternative in my book, especially > given that the current code has yielded zero bugs in practice (well, > except in artificially-concocted cases created specifically to make > a point). The bugs we're talking about here are of the form "Emacs doesn't understand the new shorthands feature when I do FOO". We already have such bugs (I think I already mentioned `find-function` as such an example). They're fairly harmless (users can work around them without much trouble until they're fixed) and easy enough to fix. BTW. What are the alternatives to fix the underlying security issue? Don't they also introduce bugs of the form "Emacs doesn't understand the new shorthands feature when I do FOO"? And/or going through all the calls to `intern(-soft)` and try to decide whether they should or should not obey `read-symbol-shorthands`? === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 09:34:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 05:34:47 2026 Received: from localhost ([127.0.0.1]:52447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1LOP-00063L-Sc for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:34:46 -0400 Received: from mail-oa1-x2d.google.com ([2001:4860:4864:20::2d]:48426) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1LOK-00062c-SW for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:34:44 -0400 Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-417c34b0509so1009977fac.1 for <80574 <at> debbugs.gnu.org>; Sat, 14 Mar 2026 02:34:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773480880; cv=none; d=google.com; s=arc-20240605; b=FqLIEm+HfhNlbq0pjeRGyqQpyXAdZOWgD3w8wBrHSeRVOXmOCjbxFpxmy6DfxOhmFm S6FIKn2MBal21YCzUqnzKYTL4lleNikm7dhSDbsJe1VeQNtNJ5AWCy9h/scCdXcYCnB0 ubIoq9Mw0TyHR4AsMzdjekkY5lAug9cdwTT5lUb8Ly6NeD8exXOFfKvR4wKi9S08dOCF Q4V1Rq9GAFDogjgG8sBOirO9x9XY8eg//4msYAup26BSY0Obxa10CvwGYaaM7ldUhiMZ 2vVb2PMR1yOuQoU3/rT5Z7WkoxnsOl5ysw8kowefaWGNH6Yg2yrdHerbZ1EZL81wBBsD wtAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=F4WhElnfQiBcqtjI8x4xFpuW7Oq/cNS8YhWDpbZ6DV4=; fh=5YvKKm9DO2czGMolugHUxygozk/6+mxPLYD7ZcYUUNE=; b=d9t4g+m91Z60m22y2Dm0zwEnfP6Bh96cbfemmCGOWDtho8aN7no5nXds8MqaZWHIoy KkLdkDCcZiPpcISYX4/pkoZaKAs1WLCEgsOOTnpjFEMM73ZyObNUh2CwEK2C56Bx+0ZE rO0SJe8W5G5XfpKqxp48bkuU1u/SWqKM/NruH4s1BQUXP2g1APbFpj8H7UjiEt1/9zdM pc3S/ptIxlIBckNUFwih2LBh7zxzAhEG1t+/dGuceYLZrFSNWcHbxYl5jc7dNzyBlHD5 goo2y99KnY8ngbV/OwQiPtkS/RbCL5CnpoDh7GgLsw/znx3O0AOjkRBsP2L3riTo+DLQ rIwA==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773480880; x=1774085680; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=F4WhElnfQiBcqtjI8x4xFpuW7Oq/cNS8YhWDpbZ6DV4=; b=lhVJoTxiK/lt62HRT21tTI+nWf5LkqrBGRKy3FXV0qQPj/LHPo4iz4Um3Fx29mDf+2 w4+dFdh2f+R9NwnfCHOD6P3IfNWWoFBLoqJRI4pl5TxajtLTxvKYnzeWx78XBEfW6ulK wcxFvjGCdVH6+QWnPks37Gm6wZPpb5QYAJmWIIAzEY9qEeHoN3/rlwiPYg09e/p2qDSX mgyFgFDQ+3wCCspiBcBo6J0Va1YUmHf5NFkeHU7FHq/Ez+L73LlV0lJLnxK7huLUYnpJ bBISJcyzMLTHeMfPaJiBtZXNoVIDALsRnonAGQVO8lfxN1QmfBnxhgU6N+MFuRMgKCSG 4XFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773480880; x=1774085680; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=F4WhElnfQiBcqtjI8x4xFpuW7Oq/cNS8YhWDpbZ6DV4=; b=g3ib0HCDsVDVEAOVtpwSeoB1UHCG9osQjoV55W7D8lhyayoIb5sKUwNAj7x7s39v8J FByx9vC/XEXPAvbHjj+bBiTWr/+KLuch+U60xj44RZmcENV8z3q1vA4G1ezB/zsEtpFu APC79JGwnjrNS1yH0Z00nc+c2voI52XfDeTKnqQqHNwgtZIaj9DkssySsw2gycElzvwi sLItXU90SC/xWXg/9kFbwRFtWM8D4DDhrJ3UDTR2acFeNReO10YsNenxcWxTfI4HafEl 0OUc2ialCLS5EFunEv+4txjgZV/FuxKaIghIzMX+QIC+JSWFHFNF9kB7ex+mrJCbR4wT ahvw== X-Forwarded-Encrypted: i=1; AJvYcCUJ1QLVevSXh0anc00rE/+lJnwX3dIgLiqLMhKeCQK7YyB47uyqfrGK6pHDvxHvvv924x0New==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxAO6Oq457urJlDsdElFR7Ve9DmmHFwjpO4gXe0VaHVcteIDsas OE0HFq5iX/sIuNhsQETuhqXFYDmyiyZmDmE+og0NpyqkoHLskLV8agXJQNZ3P72l6Ci3xxib7Lw Slue58GzO4pQHRLX+RJJuBFMQH6eh6ChCyw== X-Gm-Gg: ATEYQzxXADwrKT5mNElYwkZGaTtbDxVpiQeJnAwWeO0djtUSrUXixOaWcrmLa8Ls/7d N9IhD0auq2eY5Hegl5XMp1TQ9hfZcW5Min7p2i1HwuXXdlYhoX6hu8qmHSvvuBKIIXvPK8gKPsU EWQ4196cDIMBdjXAguBxJQ0zNXctoug7+fk9br3iLeU4CEaF6gn7JohigYhE46AIDL939wwvJ/d VAyx5DnjlAIWCp+6hC7L0rzefLLRpb+xqlmtiSXipBHi6Ak9qrY9MbpssMkoAXg300h+FLER9I9 2hsKCAwsBYpAx5HAiGI+powRLszo3a147D2DGZOhUSNsyK8+qCdXdAMUcV9l5dcVTJo0 X-Received: by 2002:a05:6870:160b:b0:3ec:4475:9baf with SMTP id 586e51a60fabf-417b93c1a8cmr3196381fac.26.1773480879918; Sat, 14 Mar 2026 02:34:39 -0700 (PDT) MIME-Version: 1.0 References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> <86o6kqbypl.fsf@HIDDEN> In-Reply-To: <86o6kqbypl.fsf@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Sat, 14 Mar 2026 09:34:29 +0000 X-Gm-Features: AaiRm52YXXBC_Pv_g6VJ_pRoF3RpmWEmwuf9H5inhFhujfVT0nd2iO2fVke_dI4 Message-ID: <CALDnm525uLAH9cS4h6ERAt4hqZ5Py9Qg845DYirz185MRMUFkQ@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer To: Eli Zaretskii <eliz@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000dd1492064cf8b101" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --000000000000dd1492064cf8b101 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 14, 2026, 08:30 Eli Zaretskii <eliz@HIDDEN> wrote: > > I'm also extremely uncomfortable to agree to a change which Jo=C3=A3o > opposes so strongly, sorry. I can understand why you would say that, since I did design and author this feature, but please try look at my arguments for their own relative merit..= . To put things into perspective , the opposition I'm showing here is academic more than anything else. I've opposed things in the past because I saw short term serious breakage. Here i see a little of that. That custom reader example I gave is someone's toy from 9 years ago. And, perhaps you have a better view of this, but I don't think people are writing third party Elisp-reflective tooling every day... So (at least my) life would go on with Stefan's patch quite peacefully, just a slightly less elegant/pure Lisp machine running underneath. Maintainers should try to decide how much they care for that... Jo=C3=A3o --000000000000dd1492064cf8b101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto">On Sat, Mar 14, 2026, 08:30 Eli Zaretsk= ii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN</a>> wrote:</div><di= v class=3D"gmail_quote gmail_quote_container" dir=3D"auto"><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"><br> I'm also extremely uncomfortable to agree to a change which Jo=C3=A3o<b= r> opposes so strongly, sorry.</blockquote></div><div dir=3D"auto"><br></div><= div dir=3D"auto">I can understand why you would say that, since I did desig= n and author this feature, but please try look at my arguments for their ow= n relative merit...</div><div dir=3D"auto"><br></div><div dir=3D"auto">To p= ut things into perspective , the opposition I'm showing here is academi= c more than anything else. I've opposed things in the past because I sa= w short term serious breakage. Here i see a little of that. That custom rea= der example I gave is someone's toy from 9 years ago. And, perhaps you = have a better view of this, but I don't think people are writing third = party Elisp-reflective tooling every day...</div><div dir=3D"auto"><br></di= v><div dir=3D"auto">So (at least my) life would go on with Stefan's pat= ch quite peacefully, just a slightly less elegant/pure Lisp machine running= underneath. Maintainers should try to decide how much they care for that..= .</div><div dir=3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o</div><div cl= ass=3D"gmail_quote gmail_quote_container" dir=3D"auto"></div></div> --000000000000dd1492064cf8b101--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 09:24:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 05:24:39 2026 Received: from localhost ([127.0.0.1]:52351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1LEa-0004Od-9h for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:24:39 -0400 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]:48396) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w1LEV-0004Nu-K6 for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:24:34 -0400 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-417c34b0509so1007294fac.1 for <80574 <at> debbugs.gnu.org>; Sat, 14 Mar 2026 02:24:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773480270; cv=none; d=google.com; s=arc-20240605; b=CcRmZz4Txqn1AtvZVZ8fvOcQWZiKw3/TrEP2VoPkWHD2knOzc2rPVdaWKhs/XU2+gv J4//tJaK/CkKO0nKteNd4b8LHRD1opq0HOrkZEoF67qUC4HGZLfEQ5g9fLWO+Mw+ZWil nWFbBGc8fksO0Grn3osqiPs6dq/2A7BCmXd2ZtMsIgNDFlx+itBb++mnJub0nBHgSRx8 hJgjX4M/gozoea/MISGZj0QBoW6VjzOhJUnVkJfNKCmwEwDkqCT1CrM/PJ7hx055M+Cs fK7Jxk+ms8D1zBUfNQ0CspylpAe4SnGPcLBJ9VZ3KQxbzdXFEPOmu+x7faJUQl94lAoW dlUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=rxqsrcvw9X+rqpfvn8e+Mqn2YNMbDvGJsq631GaccX4=; fh=BybPzA+/UtVRhHAHVAE2cW0cBoWH3p4f468eu4NtxYs=; b=fyZQfMtjk53+Si6aBwRYscN8603lFkHEx1nz9UGv1w59D0PPfNTla4nAuZBBZ+aKGj tdBjct3mY+j+PDyW/3qEW4VIYWbNPkXYGFnPXINLcwDFeho4RVGrE8gzVYIQ6STKjrdk yQZIRADuSa3YAJUTvNRcEDqfK8TzuCs77k/DNJbvvAPLCULswloPciFDULcuNj3lMaiW yMg7SfvXqweuv+U47LyO4TwKmS/5g4AGlyWCAeafq2llDYJDwukS9a6BF6pQRiA8QL2V FFCQZ5fmlS4JXV1uRwI8BgGOyn7VhY4I5jW2Ih3MbYoWr0sDC3zxtVjZSTOzTYmWJnpr CLsg==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773480270; x=1774085070; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rxqsrcvw9X+rqpfvn8e+Mqn2YNMbDvGJsq631GaccX4=; b=gRvRpebGGY3siwV46jZ5MPFeQ+ZENCVvhr1aW5IwxVUBbgwrnBZ1NAbr2uvPRh3sSN 3GgiI8sOUn2aNF2fwuanzpObgjFuPtimBRFsB45xEtUl27EnEBUy59++f4JKCcDlEEvR /hEtLFFP37hrQpyX/lvFiqbS0tO5cJh+6b1FVG/3e1qjBhhL1MCMnSG5SRsuoVa1wdr3 TB46NvXETFuQXLrQRf1hanJR1FxyDiV56Rjy8Djzp+aLTWN+3JZuvoWguaIFnoL52Z8Q EKAJp5NZ27DRsWZ64VCDLHO9IfN57g7BzSTdGmaFqk7AN1+wK3FF4kJOkPAk820HnHpS 51GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773480270; x=1774085070; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rxqsrcvw9X+rqpfvn8e+Mqn2YNMbDvGJsq631GaccX4=; b=ZVbP3NCm2ZIpEgE45l/lELazKHKC6C3l9Cz3t+5yHN24RZ3kXmHzZjO1bfY32EJaIG sY6eiqm3+BsBbCmKqbgkKuTd3GEepiRYi5RVLgx1wzn5cUkRhcIPuTq92e6u6Sf+M0cu h7YGMaCndmDR9+RDPg8cOiuysUKO02sPPlSsXdg+M3oZUnB+k8ryStem8lTYwZJXRCnF dpxOL4lRbRz5o+oz8EZdB0HijO/FpVi2iQHgHR0/76/bmzRF7viD17rklagbO85Y2N4C zPVToYIMIFS9Ba6mTVXftpSN6El+Z9+b3ruqnx9WyF7pebNhqbTWYtYzDYhy18+pMoR3 OuCw== X-Forwarded-Encrypted: i=1; AJvYcCVuN63samTNyhhfmUmnW1DcKqwUxZx5Wp785lUEFWFC61T6/pxGA6OPXioQfkVhS4muTdZWHg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw0vdzcmnhrlItCTFDLZkREL8GiY9nQQJasvrc4D+PRbvliPE8i 9eeZJh9qLkrAHzXDLa6OZZDYPZgkpE6BAX5Or2KZdsarB9iiPQa5fSrQYcfw6st7IuTNbSiV7Ws Wlyun7L7a/9qZZlyHIBuUSLBcvIfNToQ= X-Gm-Gg: ATEYQzzj4HG49LxchhquZAn86pzUghUlDPJyQ/r1sygpkIU4+rcGsFKVImMB3pY9Bhd BKcZncG886eA2ldjmRM+qenvOLVv7ArU6DphYmYW+TK7+EQmvZQrfPDCMI0aCV3gbKazAnncA6z NVB2NSYQ71r8L8CP3RAN9aenqWqdxnT6p/oHwfUPEph2gdTRwbdvLEfywu6tieNZ+DZLaoCQ7no 8q1mO2TH0hGIGA7u4opEITIn7pbZSv0YTQ8PE1H5N4bil7KK1ctlk9MqNM/W23Brw5cGhqG+Ynz 6pyneQnbs80r/eiUq3QZXHQxkuO8L/13zg2ua4XZG/f/lK18oDkFVLmAQ4KTRixcQpCm X-Received: by 2002:a05:6870:1b89:b0:408:694d:ff34 with SMTP id 586e51a60fabf-417b916d932mr3811817fac.9.1773480270131; Sat, 14 Mar 2026 02:24:30 -0700 (PDT) MIME-Version: 1.0 References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN> <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN> <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> In-Reply-To: <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Sat, 14 Mar 2026 09:24:19 +0000 X-Gm-Features: AaiRm53WXFclJNEyV0p9FVh4-jSYFad1r9TZMYcVg947XEbRZPEfWyFHwBHij40 Message-ID: <CALDnm51+qCxMjiY71W=bcPnfnm2jMkn-YmCXjh-c_9ZdkTo6fw@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000847640064cf88d6b" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --000000000000847640064cf88d6b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Mar 14, 2026 at 7:36=E2=80=AFAM Stefan Monnier <monnier@HIDDEN= al.ca> wrote: > > >> - When `read-symbol-shorthands` is erroneously obeyed, in contrast, > >> Emacs may erroneously use *any* symbol whatsoever instead of the > >> intended one. > > "shorthand" is also an arbitrary name you just came up with. If used > > unintended is just as likely to point to some nefarious effect as a wrongly > > linked symbol. > > But it's a single identifier, no matter how many different contexts in > which the code can be used: IOW there are much fewer moving parts that > can lead to harm. I don't understand that either. Even small programs have a few thousands of such identifiers, and when editing the buffer they change rapidly. A single buffer search replace can transiently put the buffer in a "dangerous" state. Your crystal ball may be quite more advanced than I am, but for me this is too complex a stochastic process to see things as clearly. > You mean mark `read-symbol-shorthands` as dangerous (since the above > silly setting of that var is just as dangerous in ELisp buffers as > elsewhere), so all the tooling will break if your ELisp file is not trusted? > > I don't think users of `read-symbol-shorthands` will like that, but, > yes, you can plug the security issue to some extent, Well, that's the nature of paranoia innit? Everyone's going about their business and then someone conjectures an attack or accident, which, however unlikely, forces everyone to get a new fancy lock installed. For example I don't "like" having to set trusted-content-p either in 30.1..= . > but it still leaves > the rest of the problem with accidental uses of `read-symbol-shorthands` > playing havoc in unlikely cases. The shorthands feature is inherently prone to accidents, no amount of patching can fix that, short of completely destroying its use. Have you ever used the shorthands feature? In the beginning you get creative trying to use clever shorthands and you immediately bump into such conflicts. I had a bunch of comical ones where my program would do silly things. I was trying to use '-' as a prefix and it mostly worked but then I added some arithmetic and boom. ;-). (Later on it was decided to forbid all-punctuation manifestations from being looked up). But your don't even have to play with shorthands to get bitten: even when you don't compile your code: completion/flymake tooling will run your accidentally harmful macros and eat your cat (or literally delete the project from under your feet, as it really did happen to me once way before shorthands). > I'd *much* prefer to fix the problem at its source by making our > primitives safer by default, and forcing a more explicit choice for those > places we know should obey `read-symbol-shorthands`. Ok. I think the most important part of the work you did is identifying to some very good degree what parts of the Emacs tree are known to need lookup.. Perhaps you can mark those locations with a comment or even a helper function. It has value because then you can get to patch all the other "smelly" intern systematically and improve things. Yes yes, you still miss out on third-party intern smells sure... but if the problem is statistically non-existing and probabilistically unlikely _and_ there's an overarching intrinsic need to gate the file-local value behind a user acknowledgement of mischief anyway... Jo=C3=A3o --000000000000847640064cf88d6b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto"><br> <br> On Sat, Mar 14, 2026 at 7:36=E2=80=AFAM Stefan Monnier <<a href=3D"mailt= o:monnier@HIDDEN" rel=3D"noreferrer noreferrer" target=3D"_blank"= >monnier@HIDDEN</a>> wrote:<br> ><br> > >> - When `read-symbol-shorthands` is erroneously obeyed, in con= trast,<br> > >>=C2=A0 =C2=A0Emacs may erroneously use *any* symbol whatsoever= instead of the<br> > >>=C2=A0 =C2=A0intended one.<br> > > "shorthand" is also an arbitrary name you just came up = with. If used<br> > > unintended is just as likely to point to some nefarious effect as= a wrongly<br> > > linked symbol.<br> ><br> > But it's a single identifier, no matter how many different context= s in<br> > which the code can be used: IOW there are much fewer moving parts that= <br> > can lead to harm.<br> <br> I don't understand that either. Even small programs have a few<br> thousands of such identifiers, and when editing the buffer they <br> change rapidly.=C2=A0 A single buffer search replace can transiently put<br= > =C2=A0the buffer in a "dangerous" state. Your crystal ball may be= quite more advanced than I am, but for me this is too complex a stochastic= process to see things as clearly.<div dir=3D"auto"><br></div><div dir=3D"a= uto"> > You mean mark `read-symbol-shorthands` as dangerous (since the above<b= r> > silly setting of that var is just as dangerous in ELisp buffers as<br> > elsewhere), so all the tooling will break if your ELisp file is not tr= usted?<br> ><br> > I don't think users of `read-symbol-shorthands` will like that, bu= t,<br> > yes, you can plug the security issue to some extent,</div><div dir=3D"= auto"><br></div><div dir=3D"auto">Well, that's the nature of paranoia i= nnit?</div><div dir=3D"auto">Everyone's going about their business and = then someone conjectures an attack or accident, which, however unlikely, fo= rces everyone to get a new fancy lock installed.<br> <br>For example I don't "like" having to set trusted-content-= p either in 30.1...<br> <br> > but it still leaves<br> > the rest of the problem with accidental uses of `read-symbol-shorthand= s`<br> > playing havoc in unlikely cases.<br> <br>The shorthands feature is inherently prone to accidents, no amount of p= atching can fix that, short of completely destroying its use.=C2=A0 Have<br= > you ever used the shorthands feature?=C2=A0 In the beginning you get<br> creative trying to use clever shorthands and you immediately bump <br> into such conflicts.=C2=A0 I had a bunch of comical ones where my <br> program would do silly things. I was trying to use '-' as a prefix = and it mostly<br> worked but then I added some arithmetic and boom. ;-). (Later on it was dec= ided to forbid all-punctuation manifestations from being <br> looked up).</div><div dir=3D"auto"><br></div><div dir=3D"auto">But your don= 't even have to play with shorthands to get bitten: even when you don&#= 39;t compile your code: completion/flymake tooling will run your accidental= ly harmful macros and eat your cat (or literally delete the project from un= der your feet, as it really did happen to me once way before shorthands).<b= r><br> > I'd *much* prefer to fix the problem at its source by making our<b= r> > primitives safer by default, and forcing a more explicit choice for th= ose<br> > places we know should obey `read-symbol-shorthands`.</div><div dir=3D"= auto"><br></div><div dir=3D"auto">Ok.=C2=A0 I think the most important part= of the work you did is=C2=A0 identifying to some very good degree what par= ts of the Emacs tree are known to need lookup..</div><div dir=3D"auto"><br>= </div><div dir=3D"auto">Perhaps you can mark those locations with a comment= or even a helper function.=C2=A0</div><div dir=3D"auto"><br></div><div dir= =3D"auto">It has value because then you can get to patch all the other &quo= t;smelly" intern systematically and improve things. Yes yes, you still= miss out on third-party intern smells sure... but if the problem is statis= tically non-existing and probabilistically unlikely _and_ there's an ov= erarching intrinsic need=C2=A0 to gate the file-local value behind a user a= cknowledgement of mischief anyway...</div><div dir=3D"auto"><br></div><div = dir=3D"auto">Jo=C3=A3o</div><div dir=3D"auto"><br><br></div></div></div> --000000000000847640064cf88d6b--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 09:07:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 05:07:59 2026 Received: from localhost ([127.0.0.1]:52227 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1KyT-0001eA-9q for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:07:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50090) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w1KyO-0001cC-3y for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 05:07:54 -0400 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 <eliz@HIDDEN>) id 1w1KyI-00088J-L6; Sat, 14 Mar 2026 05:07:46 -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=rqp0ZF8tXZjw0C/PENgWbZM52tiPumQYMFbO3ZhdQOY=; b=P8G06LIwKEkC QmmOd8QUNX+aG3GRFWrRUTHIIDSbBhM+eDhBz4XGV30eGlVJuZ0tieVFB/Ftpp+AZvmZWVsCLRAdM 0FeKMAundjAJ3s/+GQaiVGurwzOHJccEIwB/xSfnUloL1wvdBtOH0rr0deKpOXLMgzNFxZ+ZsC+Xh zBBo4Guy0ZxvgKLtah6eir+UU48BeaF/rJU15dDLMA9mippNdxiRuUQqhPTlM+kXbTcUMXmM2ciV/ Uu1L1c6kNfzsiFKhclTJVTFBb8lUQWu8joae1x6w1rUIy5Znig1uBgCfyXIybErwhIF4mdueT9gYO rST8/iaNCveQgjBapwqq4Q==; Date: Sat, 14 Mar 2026 11:07:43 +0200 Message-Id: <86ikaybwyo.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Sat, 14 Mar 2026 03:36:18 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN> <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN> <jwvcy17lymb.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org > Date: Sat, 14 Mar 2026 03:36:18 -0400 > > I'd *much* prefer to fix the problem at its source by making our > primitives safer by default, and forcing a more explicit choice for those > places we know should obey `read-symbol-shorthands`. If we can find a reasonably-practical way for finding and handling those places, perhaps that could be an alternative to consider. But for now you are saying there's no such way except waiting for bug reports. And that's not a good alternative in my book, especially given that the current code has yielded zero bugs in practice (well, except in artificially-concocted cases created specifically to make a point).
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 08:30:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 04:30:15 2026 Received: from localhost ([127.0.0.1]:51928 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1KNx-00048N-S2 for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 04:30:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45610) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w1KNs-00046q-RC for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 04:30:10 -0400 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 <eliz@HIDDEN>) id 1w1KNn-0002fB-AM; Sat, 14 Mar 2026 04:30:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=7J4mrOgBpNZa3AgXtiA3GQAZEwys+Zb+cLBjHFSDLdE=; b=RuNqd0FCgy0/wwDf6vF1 J/u3ARSs7/T1i6Nd3ea7PPRKJke3IVrVYX7kwDuwh3NvXqzZCoYHP+MbP7+3lgjT1zNXF4msA2tNO +aNy626hAC1PDPgFsnddSQWJLap7q2xfJ7Yb5FXhwjZcr13iRIXLSBypG1AXqHX4bZyBe9H1uwZND aqiD/OQxet3iC8I3NrYJdBB93Ds1jtPkmZiUFb/M1Uk8Y/D0g2RBdHTcIUCZfRQ3+yw7Ks1gRN0ER EPYm9QkXhhuuBw6DLdn1jbsylSqhgRe+VfvmHGYCaThm4O4HrjWQCU4ptUd+gvverKJWoGoLWv7rS icrIPmqPdiEZYQ==; Date: Sat, 14 Mar 2026 10:29:58 +0200 Message-Id: <86o6kqbypl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 13 Mar 2026 19:28:09 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org > Date: Fri, 13 Mar 2026 19:28:09 -0400 > > >> The functions themselves, no, but the overall behavior, maybe. > >> Or maybe in some cases yes, and in other cases it will be subtly fixed. > > So it sounds like we have no way of knowing when and how to fix the > > cases where we really do need to obey read-symbol-shorthands in > > functions that call intern internally. > > We have a simple way: wait for people to complain that "shorthands don't > work for <FOO>" and either the problem will date back to before Emacs-31 > (e.g. using `find-function`), or it will be no harder to fix than > replacing adding a call to `shorthands-to-longhand`. Sorry, that's not a solution I'd gladly adopt. I'm also extremely uncomfortable to agree to a change which João opposes so strongly, sorry.
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 07:36:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 14 03:36:32 2026
Received: from localhost ([127.0.0.1]:51605 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1JXz-0003m8-N0
for submit <at> debbugs.gnu.org; Sat, 14 Mar 2026 03:36:32 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2257)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w1JXw-0003kj-5u
for 80574 <at> debbugs.gnu.org; Sat, 14 Mar 2026 03:36:30 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 348C5100146;
Sat, 14 Mar 2026 03:36:22 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773473780;
bh=ex0OZi670jQbACBhGXBAtOXMRffz4CJQIN193N2uuQA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=OTb+IKVCfixhU0YNq3p+l7xzo4vnoKc6ABI4q3h2dvIYAg4xebl2p0n6NMlBB71sS
ONoYhh7MqwUDwpFJkC5H/keLIHwTaQs3v//kSQJfSOoNhtHtGJRtPnfn0gsJZ2TVy5
P3nFpbfMJRjznp59XjdsFkbocWs238gjgiK0xBBN4dIuRfdHjfSiWxaNBgEqdbroz0
tROqrHkfIzepaefSbnokQ5WA927sEkJlTYFUc0qBJ27ITzRnwRaG9UVKJ/MNr2AX18
vTgY2HYF+bNAFEhKSw1+/C1eXZFjsktR4HIs/KoX0ShhfTqUAwj9JBDZhkHhtLsMtx
p96FPeBMn9byA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id C781A10002E;
Sat, 14 Mar 2026 03:36:20 -0400 (EDT)
Received: from alfajor (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 90BE5120524;
Sat, 14 Mar 2026 03:36:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN>
Message-ID: <jwvcy17lymb.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN>
<jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN>
<jwvikazydsx.fsf-monnier+emacs@HIDDEN>
<CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN>
<jwvbjgrnwak.fsf-monnier+emacs@HIDDEN>
<CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN>
Date: Sat, 14 Mar 2026 03:36:18 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.106 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
>> - When `read-symbol-shorthands` is erroneously obeyed, in contrast,
>> Emacs may erroneously use *any* symbol whatsoever instead of the
>> intended one.
> "shorthand" is also an arbitrary name you just came up with. If used
> unintended is just as likely to point to some nefarious effect as a wrongly
> linked symbol.
But it's a single identifier, no matter how many different contexts in
which the code can be used: IOW there are much fewer moving parts that
can lead to harm.
Also this identifier is chosen/constructed in code we trust, and
moreover we can reasonably expect that this code uses shorthands in
a way that tries to avoid nasty ambiguities, which makes it that much
less likely that "shorthand" is harmful if it's accidentally not
expanded to "longhand".
>> Lessee:
>>
>> % cat ~/tmp/foo.txt
>> Some foo
>> Local Variables:
>> read-symbol-shorthands: (("vc-cvs-registered" . "message"))
>> End:
>> % /usr/bin/emacs -Q --batch ~/tmp/foo.txt
>>
>
> Ok, so how is that different from having an absurd (eval (shoot-rocket)) in
> the local variables of that same txt file? Is it because of the
> safe-variable-p predicate??
> Then it's trivial to fix that,
You mean mark `read-symbol-shorthands` as dangerous (since the above
silly setting of that var is just as dangerous in ELisp buffers as
elsewhere), so all the tooling will break if your ELisp file is not trusted?
I don't think users of `read-symbol-shorthands` will like that, but,
yes, you can plug the security issue to some extent, but it still leaves
the rest of the problem with accidental uses of `read-symbol-shorthands`
playing havoc in unlikely cases.
I'd *much* prefer to fix the problem at its source by making our
primitives safer by default, and forcing a more explicit choice for those
places we know should obey `read-symbol-shorthands`.
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 02:08:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 22:08:29 2026 Received: from localhost ([127.0.0.1]:49912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1EQT-0008V9-KX for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 22:08:29 -0400 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:40243) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <owinebar@HIDDEN>) id 1w1EQM-0008U4-CW for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 22:08:21 -0400 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-4836d9d54f6so2378275e9.1 for <80574 <at> debbugs.gnu.org>; Fri, 13 Mar 2026 19:08:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773454096; cv=none; d=google.com; s=arc-20240605; b=IaYD3IgcodD7AC3TbVf92BxW6DXid5WnWUD5WG1kpvcOCmaFBNN0rOf2PiHSFKQ6A+ AaZXJ+QQgYqqTmJrqlNVKW4P04EmDKroH8qEJUM6adtyx7wif3VRGEmL1kd+U8xrCrg5 qVXiqlYW1oYn6kTm+bTfyQrexsd/q3M20Lq4t+v8NrCL6E2o9dVeQS/803fdI4wVpgLH da+CUqjVBiF77hJO7CjqILkFczF6Vs4COQ/Dp82CBS9+8ygAIs8Ybl0HgsVUU+1TZ6hl XF6YmH9/yu3dRex2Qj1pNYDCzGGGLvB0QH0zAz8lVlw1LQuj4QZl2YuByqPkGt41qV6Y TZcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=v8mU6aUZXAX6allYp4z5ttafoAoI7iUGdtduCJsjhQ4=; fh=E/EgR2Z6TOY7bxoqphour9tOF+avGb0PssCkEzgLixg=; b=XEsg4rfiQyXzoIJQTpdTOj8F07UG7H+GCM2xmEcaGi71RHCwy9p4HvUBv4fq6tgqOU pw6m1QEp927LQ/4rJVv+E4E0MqUT8SKj6VjDZnXfDi3qKxpa4YAYV3ieNkweb9CArKVB KeFiq3clpt58KQIUeEG+Gxf4TzssZLFf0fnGsZT6fo6DdJ7Bvup5suJLo1tTOEtWwGUk xTFHvgC4wlrbfmLcqODSxhF7XdD2oGU/66euwC7VF6V9K0kME3GqUXwTDHurZk2URbiq gzcafJEbTi0THKtsVHXqyF5Lz6kx6X2/CNNBt+JngePf/+S0yims3GkMWIFTdajt8tc0 Uhfw==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773454096; x=1774058896; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=v8mU6aUZXAX6allYp4z5ttafoAoI7iUGdtduCJsjhQ4=; b=fwJ+x2b/AYZhZtnlgxWSLh/QDNSn2/gHFHgMFb2HWl04AB7a4ulwkNS1LqOwqxlgW6 nouls5NM3iCpqWjgAAwsMWS8BsghWX0PSQuzGXpXs6LfThPz2e2/ZYKlE7PgzBGMopBd e4wYauBOLDes64EIFXEwUoS5NOSTRs7vCv2J7LSb632OqqN4vqXAz5MFz2XkiDbt6jY9 TIJd1I3cTG4Gr4MZCzESo3lyLKp11jWUlSoCCd5DSgOKNOx85/Lb9sQ/+qvhDyod2V1R z3wL1LSNIGQ8ajPEQMr5zxzVXFjEYIjcl+BNokzeTtAbCxbEv462sOxGjgMqJBRX43yE 9DzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773454096; x=1774058896; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=v8mU6aUZXAX6allYp4z5ttafoAoI7iUGdtduCJsjhQ4=; b=DkQXjrUpWZv+eq4LWFzka2knAY/Tfdv331j6rwe+MEOXqezvCTdpn58PM1PkGsgSkQ aPOFdPx3D8GJDRejmct2lcf5Uiw9jYF852Px72aM3BMMcFKn6QZQfCXr9WOlvTc2UXvw WN35FOBzGF+La3AbGCxNhjj+eBV1RZnL8i+R3Y05UMMMpCwuE0zT7j4Ves//XD88uXMQ 2DOL35+K1R6MZzBgKxEIXftafukw63LW/NWyIJ8PSWfJIo5LUURTE+IsbE+TOtuioUoc MF5iRojTjdj3UOGi6tUPiHKlykv9kSTMA3nvZUuxr1OrXcQs5XP1cRanryQ4TvuB9Tqm Wz1A== X-Forwarded-Encrypted: i=1; AJvYcCVBNR7wjVFGuEfn7n1304OVAoaBjwcfWcJZfJatXzo/eAVbY6uzMXWkMuDmSQxdN2aAMw21+g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxW+HpWdIYfR0IFugFchr9jrF86qI+2oREMUCACgpI3Ljs++zHU sOlBn1TRe0zX8lnP0zDfk9b017G5mqt/ddOPcPYAtkDmXksZVOuPhEXUhJ65ffchnO9BPTNaFzn au5k1DJcOWZt1O3MwHO6YIMXygnOMyR0= X-Gm-Gg: ATEYQzz/fuWzpyTeX8O4EYbydca5nYd4jKYQTY3qMC15/ref1ljLUR6DrOfCOrvJViM SsS+nviqzCWWCvgMKBfGbUhnRXG/Cb7Nko9dKTWB3ObuGTe/4h8M4YexcfTFynt37vpOchqjcEE H1aGG0Gt6QU8pyIE/njO90cAT+UFpq5gaiyXjtctw8/EHj8e6vIpQ4tjz4aUwMJez/85L2a/Qkw q9JwUnWePICReOZWhtc1+7fE8DxW4Kq9SsI9qtjMKEVpblKMtzqYH4N4SM3O5SixbCTWp95zCMd grgOEbXZcdV6PYxqRo0qyDfX0z0UikR0deO8uRw= X-Received: by 2002:a05:600c:8b6f:b0:47b:d992:601e with SMTP id 5b1f17b1804b1-485566d9039mr46541585e9.2.1773454095905; Fri, 13 Mar 2026 19:08:15 -0700 (PDT) MIME-Version: 1.0 References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> In-Reply-To: <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> From: Lynn Winebarger <owinebar@HIDDEN> Date: Fri, 13 Mar 2026 22:08:04 -0400 X-Gm-Features: AaiRm52jQkTAHIwdgty2IYiRG3IoxJpo_CF7dBlN-4P5WraOhZf5qo06j2y7eYc Message-ID: <CAM=F=bD=dZW6Q+D1-MBuTTd7GAuhSyLtYV7DVjX0B5D375fMJQ@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000697561064cf27577" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org, =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --000000000000697561064cf27577 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Mar 12, 2026, 5:47=E2=80=AFPM Stefan Monnier via Bug reports for GN= U Emacs, the Swiss army knife of text editors <bug-gnu-emacs@HIDDEN> wrote: > >> It removes support for `read-symbol-shorthands` from `intern` and > >> friends, and instead provides new functions in `shorthands.el` > >> (`shorthands-intern`, `shorthands-unintern`, `shorthands-intern-soft`, > >> as well as functions `shorthands-of-symbol` and `shorthands-to-longhan= d` > >> to convert to/from the shorthand form) for those cases where the calle= rs > >> do want to take `read-symbol-shorthands` into account. > FWIW, +1 on addressing this semantic issue. I personally would like having language facilities for distinct namespaces, but that's been declared verboten for elisp. >> > >> [ I'm far from convinced `shorthands-unintern` is any use, but I > included > >> it for completeness's sake. ] > >> > >> If there's no objection, I intend to install it into `master` in a few > >> days (after adding etc/NEWS entry and adjusting the Texinfo doc). > > > > Please describe the effects of this, > > From the user's point of view there should hopefully be no > visible effect. For Emacs developers it means the behavior of `intern` > reverts to that of Emacs<28. > > So any code which uses `intern` where the argument is expected to be > (constructed based on) a string extracted from an ELisp-mode buffer will > need to be updated to use `shorthands-intern` instead. > Honestly, I am not clear on when/what elisp functions see the expanded shorthands versus the raw buffer text. Should the expansion happen in the reader for buffer streams, or maybe even in the primitives for creating lisp strings from buffer text? If this functionality is really required in `intern', then there is an alternative to a second argument: extend intern to support buffer streams (e.g. a list of buffer, start, and end), and only obey read-symbol-shorthands for such arguments [e.g. dispatch to the internal reader when given a stream argument]. Then functions creating symbols from elisp buffer text would bypass string creation and rely on intern to handle it. Lynn --000000000000697561064cf27577 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div><div class=3D"gmail_quote gmail_quote_container"><di= v dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 12, 2026, 5:47=E2=80=AFPM St= efan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text ed= itors <<a href=3D"mailto:bug-gnu-emacs@HIDDEN">bug-gnu-emacs@HIDDEN</a= >> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px= 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>= ;> It removes support for `read-symbol-shorthands` from `intern` and<br> >> friends, and instead provides new functions in `shorthands.el`<br> >> (`shorthands-intern`, `shorthands-unintern`, `shorthands-intern-so= ft`,<br> >> as well as functions `shorthands-of-symbol` and `shorthands-to-lon= ghand`<br> >> to convert to/from the shorthand form) for those cases where the c= allers<br> >> do want to take `read-symbol-shorthands` into account.<br></blockq= uote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto">FWIW, +1 on = addressing this semantic issue.=C2=A0 I personally would like having langua= ge facilities for distinct namespaces, but that's been declared verbote= n for elisp.=C2=A0=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"= ><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmai= l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20= 4,204);padding-left:1ex">>> <br> >> [ I'm far from convinced `shorthands-unintern` is any use, but= I included<br> >>=C2=A0 =C2=A0it for completeness's sake.=C2=A0 ]<br> >> <br> >> If there's no objection, I intend to install it into `master` = in a few<br> >> days (after adding etc/NEWS entry and adjusting the Texinfo doc).<= br> ><br> > Please describe the effects of this,<br> <br> From the user's point of view there should hopefully be no<br> visible effect.=C2=A0 For Emacs developers it means the behavior of `intern= `<br> reverts to that of Emacs<28.<br> <br> So any code which uses `intern` where the argument is expected to be<br> (constructed based on) a string extracted from an ELisp-mode buffer will<br= > need to be updated to use `shorthands-intern` instead.<br></blockquote></di= v></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D= "auto">Honestly, I am not clear on when/what elisp functions see the expand= ed shorthands versus the raw buffer text. Should the expansion happen in t= he reader for buffer streams, or maybe even in the primitives for creating = lisp strings from buffer text?</div><div dir=3D"auto"><br></div><div dir=3D= "auto">If this functionality is really required in `intern', then there= is an alternative to a second argument: extend intern to support buffer s= treams (e.g. a list of buffer, start, and end), and only obey read-symbol-s= horthands for such arguments [e.g. dispatch to the internal reader when giv= en a stream argument]. Then functions creating symbols from elisp buffer t= ext would bypass string creation and rely on intern to handle it.=C2=A0=C2= =A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir= =3D"auto">Lynn</div><div dir=3D"auto"><br></div></div> --000000000000697561064cf27577--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 14 Mar 2026 00:20:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 20:20:10 2026
Received: from localhost ([127.0.0.1]:49305 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1Cje-0007BE-Aa
for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 20:20:10 -0400
Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]:52359)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>)
id 1w1CjY-00079u-Tr
for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 20:20:03 -0400
Received: by mail-oi1-x236.google.com with SMTP id
5614622812f47-46704177508so1828800b6e.0
for <80574 <at> debbugs.gnu.org>; Fri, 13 Mar 2026 17:20:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1773447600; cv=none;
d=google.com; s=arc-20240605;
b=YEMYNysTfSq6u0m7S/9ebB+rBM0iNoU5zNilWHK3c05t0J6UPn0bbcYLJO5p9sePKt
XpHaWQsL6MzRebdi0s9Ru63V/Q6MKbMlEFAJc4sP+j4uNjhWm7VgehKdDpw8YqGLmLac
0bNyGCsvLqtRaBqkppAu7AzY7I+WBFR/jbra9fKBC5wOC7zNsk0aN1GIXMgekPD6qRuE
zXCa59hv5cRxSrcEfn8VLbifQFWV8ETPtIH8YN8YzzgCaExdjWuB1Sek4fdDN1G3IMAD
Ma1HzA+0YhYLHXZXXGUbbbPlpN3gX/JpoPnq2343uZg0xTT24WJXV9au0ydl88MzZhMo
qZTw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com;
s=arc-20240605;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:dkim-signature;
bh=dXNNuRLVTLbGMru6ZiISqiRODCshznqlTVDqqwcjki8=;
fh=CBp7N/3T/k2pnT6si0zga03KPLIFO5qoOGssXMfZlwA=;
b=VMh5Qb09C1pCyR928+vjdDiwyQ3D4f5E2kKiTUPKGlOUqoi5Fx4TUKuInb6IRf9Xnp
F02rSon4cHwAZ1O6trygFGPDgismtpthjt/2FCXJdrAcLM4w0V21cGnsSpUH/n1wknDP
VID5wnIyjq0DGWVnTSXfVcP9JI3p50RK/9MGrMJUrwWSmwsgN6AnZGLgKQSQjGbgGhOu
Vs342tUxD9IhmOQLIAiCA6/a/M+51mjFmxJtSjPzghPGfvY423ip1i0/ofpM3z/IqkpX
JBluYE4Vkvv2V/5Zxd9ddUIb3jywZd+NJzdRoVz1QUIlJh4PBO053QHBTz4Andk/SLX9
LfOw==; darn=debbugs.gnu.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1773447600; x=1774052400; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=dXNNuRLVTLbGMru6ZiISqiRODCshznqlTVDqqwcjki8=;
b=lRe4y7Dy8dKh2UDHf+VrBepZOtjdo91IckguxaFcxzSZedXaL/dcu9VFLk1DCg7AdN
RhagwoIwBsZsTd4IP+1ICEZr3jGLMMIWih2IVy+m5oDicupVeogEZ41bLPd+XxF3Q2rL
OanGjorfvrB9aUBY+krGB5aC7G1/UedHCjDbpG3t856HUlBoAV1IhI55+3E3c1SJUGxg
pBm9T/ic8LfaKy0zTcIHp5aVdPiL04txWK+kKA7xyX3BELAEuSIPSWAKhtrH5tCdqI4G
Zj6JfqoSg+E1KdY74Kofzb8jU6qXAQuOKJ/aJMBnI728CM7yrpKvwPtkoi3GPgBze1LM
EQsQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1773447600; x=1774052400;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=dXNNuRLVTLbGMru6ZiISqiRODCshznqlTVDqqwcjki8=;
b=rC4G/shoaAHvYWwnpGUQagVpj44J3MeLy0NQeMQ2TXj3iPYWoqLcyxqBr/WB2MI7po
3oJqq6B2gHclAWT8WAjlFxYNgJlIAkzULzNlV/IBJ9GOU0Ow9CinMD2/C1hFNL7MW8j9
94OJmigOhZ6dEHwYtyvDroP0p391ZjUOpNMkDzHQHik8nUXvdSsM1d0KVlUe3a8k+/2R
uLe89Ku2Lbos8LXH3s/s+uuqo1kCgidshHBWtPPQWYUTLjXvflxpxCrjvHTqDsGpzV1u
9f/iuzuukJP58NPAANfaoe9WljJ7TwzK3XufPNNOpFbAHNeM4n/ZEPFYpLAtVuyjbMCu
5JNQ==
X-Forwarded-Encrypted: i=1;
AJvYcCVs1QL5tFPE6gek9l3LHlG2xto5f4MLOFywIsKnaQfUadvsUKnzC1LOmk8J6DolecHFEXkXTA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yy/Z0IvKMbmMB0/eh0mYWWGulmV4wP62ikLQnHfTo24Oex6trD4
hgyA+Yb9XrFmdH9BBqwnVqrAXtJhy7pUOJeAB8ovqOqkSN+yponFQA10ebCYGhZ6nsZsc48eWGZ
5xszVQZrQm3IFppv3CZ21nO2kfvZrXoI=
X-Gm-Gg: ATEYQzwerM/8HpgspSqHiunz7m9pJgPduvnb/RP4UWNvjJcdTUTxfUJPq/Ux1jzqOcd
lzko1UP0jdEeU28SA0Zr2DWuTfvKVBfe3KmCTHqUEB2+4HN8jZtPtlw0DbClrX+v8sBS3dS1Elr
WaRkDWa6/avQtc2Y06pR+AZWWWejymP7IVV0JHnwe6OW3cnjISI1JhLNKxr1DTXhBn6mdFvvNwK
fkM3qi8ocQhwdj3TAEJPnrhrqzsco+LATspMgKl+JhCi9zALg66b5DxTB6/v7xd0spwQ/fA2brf
98eBhfsKKV9JU98K0mLRhgjrvg60tMUbIIzaFjp3yLHPK8rmSbVZkGOcYhqgSYJ7bbU=
X-Received: by 2002:a05:6808:bcf:b0:467:2418:ced9 with SMTP id
5614622812f47-4675766a398mr2558111b6e.50.1773447599742; Fri, 13 Mar 2026
17:19:59 -0700 (PDT)
MIME-Version: 1.0
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN>
<jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN>
<jwvikazydsx.fsf-monnier+emacs@HIDDEN>
<CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN>
<jwvbjgrnwak.fsf-monnier+emacs@HIDDEN>
In-Reply-To: <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN>
From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
Date: Sat, 14 Mar 2026 00:19:49 +0000
X-Gm-Features: AaiRm53qWOJo0DObP5HWrZPL7qpjQ_wyTHQZd5fTdJkJj3EU4Go8lc8VALS37XQ
Message-ID: <CALDnm506NW_CAvNug0HYx=dVPJS74h4ET07FP3-sFuddvK7FFQ@HIDDEN>
Subject: Re: bug#80574: 31.0.50;
`intern` should not depend on the current-buffer
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000035e121064cf0f26e"
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80574
Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
--00000000000035e121064cf0f26e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Mar 13, 2026, 23:40 Stefan Monnier <monnier@HIDDEN>
wrote:.
> - When `read-symbol-shorthands` is erroneously obeyed, in contrast,
> Emacs may erroneously use *any* symbol whatsoever instead of the
> intended one.
>
"shorthand" is also an arbitrary name you just came up with. If used
unintended is just as likely to point to some nefarious effect as a wrongly
linked symbol.
(coded with shorthands or not) to do other work
> > inside Emacs
>
> No, `read-symbols-shorthands` can be set file-locally in any
> file whatsoever.
>
So can all manner of silly settings. We all know Emacs gives you ample
material to shoot yourself in the foot.
> 2. That Elisp file has shorthands configured as file local variables and
> > you've not chosen to ignore that value.
>
> That's the default configuration.
>
> > 3. You use, from within that buffer, some editing facility that uses
> > 'intern' for non-Elisp reflection purposes and which does so with the
> Elisp
> > buffer current
> > 4. The shorthands the author of that file chose
>
> Lessee:
>
> % cat ~/tmp/foo.txt
> Some foo
> Local Variables:
> read-symbol-shorthands: (("vc-cvs-registered" . "message"))
> End:
> % /usr/bin/emacs -Q --batch ~/tmp/foo.txt
>
Ok, so how is that different from having an absurd (eval (shoot-rocket)) in
the local variables of that same txt file? Is it because of the
safe-variable-p predicate?? Then it's trivial to fix that, no need to go to
your "extreme" (by comparison) measures. Shorthands ONLY make sense for
Elisp files :) simple as that.
In fact I've already supplied a patch elsewhere that makes shorthands
always unsafe and prompt the user.
Problem solved?
Jo=C3=A3o
>
--00000000000035e121064cf0f26e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><=
div class=3D"gmail_quote gmail_quote_container" dir=3D"auto"><div dir=3D"lt=
r" class=3D"gmail_attr">On Fri, Mar 13, 2026, 23:40 Stefan Monnier <<a h=
ref=3D"mailto:monnier@HIDDEN">monnier@HIDDEN</a>> wr=
ote:.</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- When `read-symbol-shorthands` is erroneously obeyed, in contrast,<br>
=C2=A0 Emacs may erroneously use *any* symbol whatsoever instead of the<br>
=C2=A0 intended one.<br></blockquote></div><div dir=3D"auto"><br></div><div=
dir=3D"auto">"shorthand" is also an arbitrary name you just came=
up with. If used unintended is just as likely to point to some nefarious e=
ffect as a wrongly linked symbol.</div><div dir=3D"auto"><br></div><div cla=
ss=3D"gmail_quote gmail_quote_container" dir=3D"auto"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">(coded with shorthands or not) to do other wor=
k<br>
> inside Emacs<br>
<br>
No, `read-symbols-shorthands` can be set file-locally in any<br>
file whatsoever.<br></blockquote></div><div dir=3D"auto"><br></div><div cla=
ss=3D"gmail_quote gmail_quote_container" dir=3D"auto"><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex"></blockquote></div><div dir=3D"auto">So can al=
l manner of silly settings. We all know Emacs gives you ample material to s=
hoot yourself in the foot.</div><div dir=3D"auto"><br></div><div class=3D"g=
mail_quote gmail_quote_container" dir=3D"auto"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">
> 2. That Elisp file has shorthands configured as file local variables a=
nd<br>
> you've not chosen to ignore that value.<br>
<br>
That's the default configuration.<br>
<br>
> 3. You use, from within that buffer, some editing facility that uses<b=
r>
> 'intern' for non-Elisp reflection purposes and which does so w=
ith the Elisp<br>
> buffer current<br>
> 4. The shorthands the author of that file chose<br>
<br>
Lessee:<br>
<br>
=C2=A0 =C2=A0 % cat ~/tmp/foo.txt<br>
=C2=A0 =C2=A0 Some foo<br>
=C2=A0 =C2=A0 Local Variables:<br>
=C2=A0 =C2=A0 read-symbol-shorthands: (("vc-cvs-registered" . &qu=
ot;message"))<br>
=C2=A0 =C2=A0 End:<br>
=C2=A0 =C2=A0 % /usr/bin/emacs -Q --batch ~/tmp/foo.txt<br></blockquote></d=
iv><div dir=3D"auto"><br></div><div dir=3D"auto">Ok, so how is that differe=
nt from having an absurd (eval (shoot-rocket)) in the local variables of th=
at same txt file? Is it because of the safe-variable-p predicate?? Then it&=
#39;s trivial to fix that, no need to go to your "extreme" (by co=
mparison) measures. Shorthands ONLY make sense for Elisp files :) simple as=
that.</div><div dir=3D"auto"><br></div><div dir=3D"auto">In fact I've =
already supplied a patch elsewhere that makes shorthands always unsafe and =
prompt the user.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Problem=
solved?</div><div dir=3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o</div>=
<div class=3D"gmail_quote gmail_quote_container" dir=3D"auto"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px soli=
d rgb(204,204,204);padding-left:1ex">
</blockquote></div></div>
--00000000000035e121064cf0f26e--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 23:40:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 19:40:37 2026
Received: from localhost ([127.0.0.1]:49150 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w1C7R-0006bl-8X
for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 19:40:37 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22826)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w1C7O-0006b1-Go
for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 19:40:35 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1CE38441831;
Fri, 13 Mar 2026 19:40:29 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773445227;
bh=88dT8Y8108W4uiOuRgg/4EPajCELuaurJxFsbCYOrsc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=LGvxKjjITWa3VxMnGL6HhJlfvV3TlgkTtAL1pdm4tjM4KEiNILVHy4JdUXtQOY+4R
E9C2h2fRO8nmNuFXXoGj/Ad1JfKbxJaO9uR/1f8F03OOwGIc7Qa6MaaEP5jflyzDEx
XyH0zCh59MSP5LCh+6LdijEYiY/KbM6vNxNPlLyNTP/IN3r0DMqJgOG1jt+Q2d6Trq
Nc7cIdJwJym0TvIGxUVUdqxihT9PKmZ77/owxxUIpSlQ77H5kALsW6EBeSbRfZsFLQ
1YihWfppTOAiRpBo6NWUMG4UN7iy21jUB4QdNPqwKXWDUc1ZLr0WksS67fpTt2uJTR
UnMTmYGzasuSA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D74BA44180C;
Fri, 13 Mar 2026 19:40:27 -0400 (EDT)
Received: from alfajor (modemcable075.61-73-45.static.videotron.ca
[45.73.61.75])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B57941206A7;
Fri, 13 Mar 2026 19:40:27 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN>
Message-ID: <jwvbjgrnwak.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN>
<jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN>
<jwvikazydsx.fsf-monnier+emacs@HIDDEN>
<CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN>
Date: Fri, 13 Mar 2026 19:40:27 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
>> > How do you know that those "bug from the future" will come in those
>> > forms "doens't have support for read-symbol-shorthand" or "behaves
>> > erratically". For all we know, _not_ finding a legit symbol shorthand
>> > tomorrow after your change might just as well mean the difference
>> > between life and death.
>> It's possible, of course. My crystal ball says it's extremely
>> unlikely, tho.
> Give it a good wipe, and it'll probably tell you both categories are
> equally likely/unlikely.
It's squeaky clean, yet it's still very much thinks it's
extremely unlikely. Here's why the probability of a "life and death"
problem is so different between the two risks:
- When `read-symbol-shorthands` is erroneously ignored, Emacs
will incorrectly use the literal symbol name (let's call it
"shorthand") instead of its intended longhand form.
- When `read-symbol-shorthands` is erroneously obeyed, in contrast,
Emacs may erroneously use *any* symbol whatsoever instead of the
intended one.
>> The immediate consequence is that the returned symbol is a different one
>> from the intended one, and the potential breakage can be arbitrary
>> depending on what is done with that symbol, [...]
> Unless I'm very mistaken, this can only happen if:
> 1. You are visiting an Elisp file. This does not happen at all if you're
> only _using_ Elisp programs (coded with shorthands or not) to do other work
> inside Emacs
No, `read-symbols-shorthands` can be set file-locally in any
file whatsoever.
> 2. That Elisp file has shorthands configured as file local variables and
> you've not chosen to ignore that value.
That's the default configuration.
> 3. You use, from within that buffer, some editing facility that uses
> 'intern' for non-Elisp reflection purposes and which does so with the Elisp
> buffer current
> 4. The shorthands the author of that file chose are particularly poor and
> easily clash with equally poorly chosen symbol names of the facilities of 3.
[...]
> I've been looking for ways to intentionally abuse it and I haven't found
> one. Have you?? The examples you've supplied so far (eshell, pcomplete)
> don't add up.
Lessee:
% cat ~/tmp/foo.txt
Some foo
Local Variables:
read-symbol-shorthands: (("vc-cvs-registered" . "message"))
End:
% /usr/bin/emacs -Q --batch ~/tmp/foo.txt
=== Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 23:28:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 19:28:21 2026 Received: from localhost ([127.0.0.1]:49105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1BvZ-0004Vm-1z for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 19:28:21 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40159) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1BvW-0004Ui-AO for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 19:28:19 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E2D23441831; Fri, 13 Mar 2026 19:28:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773444490; bh=78VKg69HbKwmAr4dZTkLKn9thQ26Ahf7KgISPjiqIqc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Q3ZqLLrhEuXG8Zch9APmm8m/bxNCKp0YQS7Mmr4cPg02iItI+2aaM/4hPDAe1bUMu QYGPIhpj9qWS3nH+YSTmZQoX56M/FuenssVQPM8+G6R59hwmq1qQTD3yksP5rRPzO2 GFrnXJ9EHbIEzJY2WWU2oEKEYBeCT3xALAM62LhCPNrPYRljsaVFKBhZHW39Qt8uq+ S8GpASOKafyqTjwU6WEq3QvSKZ20zqOzQeWeWVeq2BwIAOXMT/uIC2U8bKfVmjTYds nZ1hpxn0ySvzzE0EcFoEF7+kKsCguNlRmVwb1f8cQddG51WdyWvdKreNY+Z3I5Tmcz sZEud88K4IF2w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id BC7F7440CC0; Fri, 13 Mar 2026 19:28:10 -0400 (EDT) Received: from alfajor (modemcable075.61-73-45.static.videotron.ca [45.73.61.75]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8A077120BDB; Fri, 13 Mar 2026 19:28:10 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <868qbvd9nr.fsf@HIDDEN> Message-ID: <jwvh5qjnwhw.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> <868qbvd9nr.fsf@HIDDEN> Date: Fri, 13 Mar 2026 19:28:09 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> The functions themselves, no, but the overall behavior, maybe. >> Or maybe in some cases yes, and in other cases it will be subtly fixed. > So it sounds like we have no way of knowing when and how to fix the > cases where we really do need to obey read-symbol-shorthands in > functions that call intern internally. We have a simple way: wait for people to complain that "shorthands don't work for <FOO>" and either the problem will date back to before Emacs-31 (e.g. using `find-function`), or it will be no harder to fix than replacing adding a call to `shorthands-to-longhand`. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 18:48:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 14:48:45 2026 Received: from localhost ([127.0.0.1]:47396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w17Yy-00018x-JS for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 14:48:45 -0400 Received: from mail-oo1-xc2e.google.com ([2607:f8b0:4864:20::c2e]:46341) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w17Yw-00018a-R0 for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 14:48:43 -0400 Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-67bd4e63606so850935eaf.1 for <80574 <at> debbugs.gnu.org>; Fri, 13 Mar 2026 11:48:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773427722; cv=none; d=google.com; s=arc-20240605; b=OkHCWdhKLRCTQ9+ZMHdTR5SsYGg3wVWVT0GXGORoKSi6s1we8WVI3TMnWwB0Zjtoim NbqfUq2jeNivC67e7Tqn1SYCeTUVenXtZVzZr4oVPnX1g+PjV4vE/vvPFM/cWiU3fI45 AWRaNbxEQdh575OXWJQmBa6you41s6Z7+4vYiwDu7eSX0qvXKGeuKzQVpAvrZI3NtOB8 Bg0KmiTL0/J5pZfdi0FoCqVSFFEyRb7KFVq4pAMGr4lsHDrqS2cynv/teNMmBwRFqKuF ftyILxtMMruY5n9RRsIMBG1Nnkc77jyBAf+AIbVm+WQqgD82Gv9GZYdyLPAlSysp4bPA 11og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=zp3kD5VJktGWI/DTf3ip3kDz9DYE7ziWu+4HJDw15Z0=; fh=4D4jMalqWzDyuzSm4WReyY09G7yKWMfzRNlYVFxxxs4=; b=a23WdL8OcO1LwoQz5GKz8+qMwlK/14Ey1nHx6c4pmY8tOyk1Azko7CDdJY/5breWkN 5HU3tscf4cXfL7aupoj96zyiqKkeiq1euG2LrUJqcRh1XQ85DP+V0ZqVkM5Ii6lsHpTO 6w/9+Ds4lzauMWhrlGWHak8YaUT73m+jDAalQqQb/V+LH6ssXfnBQ6J7oW3/K1YSDjKU oR7zH3qCZDx5VCNdIho0Vt5/OE/80l4+5p4VZU73qNspp4hLfhAL+iBYBnwf7HFy76WG abnoTHQRb2B3mzuBGasMHfQewitf6PveQvUP4RMwK5GuxZBUcK+tCDr9cRXo0S06yjG4 eHEw==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773427722; x=1774032522; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zp3kD5VJktGWI/DTf3ip3kDz9DYE7ziWu+4HJDw15Z0=; b=e815qEhd4/i8Wczo+/kltWi3lq3IK00O3wTRSxrQUrM/sR5rpBjhGbpvtIG4vcbJE+ xDN2wnRE9WS1amAP3n12dqjJTVMLdwgipRAR+R2r4KDpj799T2icmns4ICMUdfgaREbL PvAXyg9dPnsOnR0r7e8pblsxV9HDQ4giSLfpIGliWI2ascGy5BtSqpYcMqX+RltwEFQ/ Tk49vBh/idYPb2GvwG6/NJDXWpuZtwyHszy8Hv/UFYqetVAPu9w6GJnQf4NtTjXCXabG YFf2K9jNqK745pRteQQmKc1pTrrAa3qLr5loaN9pGGDjzDnPSpbybNWsuXnNvZ0eeV/G gnEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773427722; x=1774032522; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zp3kD5VJktGWI/DTf3ip3kDz9DYE7ziWu+4HJDw15Z0=; b=jnPigpGrJAO5L5oQKTqCehTvRPZa0A7uOtRpBlvp3hWKWpYw05+4F56Mm7nvRQxgvu xB5ST8hJXzpib5kLFbfrFX+NiOO05EwHWXcryK9PU1NqCaaRHS6xkTmVoLX8OMqNdaC1 cFh2ZQbVCO0Yd2apJJqP9J4g/h4g3Q6hUjXWHkt2YufWBG4s02qLjqK7rtP7kbESOfg+ veEE8ddyK9DedIC91PytxNt8mGQMe2H1orG82dXlhclr6Lh3QKzBcVzO8dyxUK90E42W 2OuDK2NEl+k6h41BV26dLXDpXARY/wSwniCEGfJaXM32Vyci8X+tgF9yeJeSHAkv1oKP 64qA== X-Forwarded-Encrypted: i=1; AJvYcCUC/yMyv6dBI3bqO80IgP1wqL0G5/b1XuNXz8+Ugp114j+LP3SKDCy1POiQJSAg3ncX/NkQ7Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxnaMtiUOzUxGJ791qj1dV90wSdcVZIL/oQ/HIQjZjhLYQpDLkH VD1Wi8etcGjEIm46hQ1kcNnjJgm/6eb8u4f/aHTD/hyrf3hwlxn1yt9uYi5/6l+7sgMaMEIxDDt rXK/1tncAZzir+MwlSomZuAHlzysb6NqJ3A== X-Gm-Gg: ATEYQzwH+MiCj8WF9dfMNMx57toFnWCSUMziNFhqYI8JldAVooceoAXFb6FuJPiRf/G KTY1/Qbem9u4DMRKhVYaTCzgprAwQKJgEU98kV5pw+Zx/NsXuSzuHlI40LT9ytrTx+VzfUktfJl gfkXpVPxSPnqaUaUNGHiUxkuNi1QOphAeVZk9REfV0HNNeCuagHzd6KIGL276MVjRSDNBcgXL2E tEaeOAFpbw1nTXuUg1stTA2duyTOfgHP9MqxydEssrNVn1JCfue6p9JXqtE+Vx8ck3oL+GVa1Vu D1m+xRhU2+R28sEj/OLKeUROIuw31iXBOcnG1VWNDONsoBWBV6D8kSkAw3ozFwfpZeoIU/14zl6 jHw== X-Received: by 2002:a05:6820:1349:b0:67b:c304:64bb with SMTP id 006d021491bc7-67bda9b41d6mr2832933eaf.19.1773427721704; Fri, 13 Mar 2026 11:48:41 -0700 (PDT) MIME-Version: 1.0 References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> <jwvikazydsx.fsf-monnier+emacs@HIDDEN> In-Reply-To: <jwvikazydsx.fsf-monnier+emacs@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 13 Mar 2026 18:48:31 +0000 X-Gm-Features: AaiRm518UR3FK8sajXKPmg1SgSlnZGjjFTFRkNc08PAUH6goNfr5JOsYudbwuj4 Message-ID: <CALDnm51xt3FonAXyfv+FCWaHNe8wKuf26tCnVJu9qasp2YYeHQ@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000631709064cec51f1" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --000000000000631709064cec51f1 Content-Type: text/plain; charset="UTF-8" On Fri, Mar 13, 2026, 18:15 Stefan Monnier <monnier@HIDDEN> wrote: > > How do you know that those "bug from the future" will come in those > > forms "doens't have support for read-symbol-shorthand" or "behaves > > erratically". For all we know, _not_ finding a legit symbol shorthand > > tomorrow after your change might just as well mean the difference > > between life and death. > > It's possible, of course. My crystal ball says it's extremely > unlikely, tho. > Give it a good wipe, and it'll probably tell you both categories are equally likely/unlikely. > The only difference is that we're almost sure you'll introduce > > breakage, whereas we've not not seen in 3 major Emacs versions the > > breakage you're trying to fix. > > The breakage is unlikely to appear by accident, maybe, but just like > buffer-overflows it could have dramatic effects if abused on purpose. > I've been looking for ways to intentionally abuse it and I haven't found one. Have you?? The examples you've supplied so far (eshell, pcomplete) don't add up. > Furthermore I'm not sure at all that that breakage's > > size -- which by your own admission is already very small -- is what you > > think it is: your "Eshell" example was a false positive after all. Even > > the 'pcomplete.el' alarm seems a bit over the top: I'm not sure > > 'pcomplete.el' is ever run or useful in Elisp buffers. > > You can set `read-symbol-shorthands` in any buffer, not only in > elisp-mode buffers, so any major mode that uses pcomplete in file buffers > (e.g. org-mode) can be affected. > What?? Who/what does that?? If people/packages are doing that, then all bets are off. It's completely useless and the moral equivalent to, say, redefining some primitive function to some nonsensical gibberish. Shorthands are ONLY meant as file-local variables and ONLY for Elisp buffers. Not even dir-local makes any sense. It will not work. > - change all smelly, non Elisp-reflective 'intern' uses in the Emacs.git > > tree to have explicit obarray parameters. > > - harden read-symbol-shorthands safe-local-variable predicates > > - change only proven source of non Elisp-reflective intern that can run > in an actual > > Elisp buffer -- 'vc.el' -- to use generic functions or use a separate > > obarray. I've already given some patches. > > All of these require changes in the cases where the problem manifests > itself. I prefer a "safe by default" choice where none of those > dangerous use-cases need to be changed (or even found for that matter), > Considered by itself, there is merit to this. I understand your argument. But in my view that merit is greatly diminished, almost to nothing, because 1. as far as we can actually see the risks are almost non-existing and because 2. it has so many undesirable side effects, like breaking other things, complexifying the API and encouraging poor uses of intern. AFAIK `read` has virtually never passed to `intern` the literal string > found in the buffer. It has always pre-processed it (mostly for > backslash escapes). Adding shorthand expansion to that pre-processing > seems to fit very naturally into the decades long relationship between > `read` and `intern`. > I don't understand what you mean by this. Sure, built-in 'read' uses implementation tricks to lookup shorthands to save memory and effiency, but it uses 'oblookup_considering_shorthands' which is almost verbatim what 'Fintern' also does. So right now, 'read' ing a form from a stream is indistinguishable from hand coding an equivalent reader in Elisp that uses intern. You will break that link. > --000000000000631709064cec51f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto">On Fri, Mar 13, 2026, 18:15 Stefan Monn= ier <<a href=3D"mailto:monnier@HIDDEN">monnier@HIDDEN= a</a>> wrote:</div><div class=3D"gmail_quote gmail_quote_container" dir= =3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> How do you= know that those "bug from the future" will come in those<br> > forms "doens't have support for read-symbol-shorthand" o= r "behaves<br> > erratically".=C2=A0 For all we know, _not_ finding a legit symbol= shorthand<br> > tomorrow after your change might just as well mean the difference<br> > between life and death.<br> <br> It's possible, of course.=C2=A0 My crystal ball says it's extremely= <br> unlikely, tho.=C2=A0<br></blockquote></div><div dir=3D"auto"><br></div><div= dir=3D"auto">Give it a good wipe, and it'll probably tell you both cat= egories are equally likely/unlikely.</div><div dir=3D"auto"><br></div><div = class=3D"gmail_quote gmail_quote_container" dir=3D"auto"><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"> > The only difference is that we're almost sure you'll introduce= <br> > breakage, whereas we've not not seen in 3 major Emacs versions the= <br> > breakage you're trying to fix.<br> <br> The breakage is unlikely to appear by accident, maybe, but just like<br> buffer-overflows it could have dramatic effects if abused on purpose.<br></= blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">I've bee= n looking for ways to intentionally abuse it and I haven't found one. H= ave you?? The examples you've supplied so far (eshell, pcomplete) don&#= 39;t add up.</div><div dir=3D"auto"><br></div><div class=3D"gmail_quote gma= il_quote_container" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D= "margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= ft:1ex"> > Furthermore I'm not sure at all that that breakage's<br> > size -- which by your own admission is already very small -- is what y= ou<br> > think it is: your "Eshell" example was a false positive afte= r all.=C2=A0 Even<br> > the 'pcomplete.el' alarm seems a bit over the top: I'm not= sure<br> > 'pcomplete.el' is ever run or useful in Elisp buffers.<br> <br> You can set `read-symbol-shorthands` in any buffer, not only in<br> elisp-mode buffers, so any major mode that uses pcomplete in file buffers<b= r> (e.g. org-mode) can be affected.<br></blockquote></div><div dir=3D"auto"><b= r></div><div dir=3D"auto">What?? Who/what does that?? If people/packages ar= e doing that, then all bets are off. It's completely useless and the mo= ral equivalent to, say, redefining some primitive function to some nonsensi= cal gibberish. Shorthands are ONLY meant as file-local variables and ONLY f= or Elisp buffers. Not even dir-local makes any sense. It will not work.</di= v><div dir=3D"auto"><br></div><div class=3D"gmail_quote gmail_quote_contain= er" dir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px = 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > - change all smelly, non Elisp-reflective 'intern' uses in the= Emacs.git<br> >=C2=A0 =C2=A0tree to have explicit obarray parameters.<br> > - harden read-symbol-shorthands safe-local-variable predicates<br> > - change only proven source of non Elisp-reflective intern that can ru= n in an actual<br> >=C2=A0 =C2=A0Elisp buffer -- 'vc.el' -- to use generic function= s or use a separate<br> >=C2=A0 =C2=A0obarray.=C2=A0 I've already given some patches.<br> <br> All of these require changes in the cases where the problem manifests<br> itself.=C2=A0 I prefer a "safe by default" choice where none of t= hose<br> dangerous use-cases need to be changed (or even found for that matter),<br> </blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto">Considered= by itself, there is merit to this. I understand your argument. But in my v= iew that merit is greatly diminished, almost to nothing, because 1. as far = as we can actually see the risks are almost non-existing and because 2. it = has so many undesirable side effects, like breaking other things, complexif= ying the API and encouraging poor uses of intern.</div><div dir=3D"auto"><b= r></div><div class=3D"gmail_quote gmail_quote_container" dir=3D"auto"><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex"> AFAIK `read` has virtually never passed to `intern` the literal string<br> found in the buffer.=C2=A0 It has always pre-processed it (mostly for<br> backslash escapes).=C2=A0 Adding shorthand expansion to that pre-processing= <br> seems to fit very naturally into the decades long relationship between<br> `read` and `intern`.<br></blockquote></div><div dir=3D"auto"><br></div><div= dir=3D"auto">I don't understand what you mean by this. Sure, built-in = 'read' uses implementation tricks to lookup shorthands to save memo= ry and effiency, but it uses 'oblookup_considering_shorthands' whic= h is almost verbatim what 'Fintern' also does. So right now, 'r= ead' ing a form from a stream is indistinguishable from hand coding an = equivalent reader in Elisp that uses intern. You will break that link.</div= ><div class=3D"gmail_quote gmail_quote_container" dir=3D"auto"><blockquote = class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol= id rgb(204,204,204);padding-left:1ex"> </blockquote></div></div> --000000000000631709064cec51f1--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 18:26:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 14:26:47 2026 Received: from localhost ([127.0.0.1]:47264 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w17Di-0005wc-S1 for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 14:26:47 -0400 Received: from mail-oo1-xc2a.google.com ([2607:f8b0:4864:20::c2a]:52669) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w17De-0005vg-Lr for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 14:26:45 -0400 Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-679b072ed3aso1274636eaf.1 for <80574 <at> debbugs.gnu.org>; Fri, 13 Mar 2026 11:26:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773426401; cv=none; d=google.com; s=arc-20240605; b=iFwb/jN9quE+P40hJxEzOQDspR8EYrf5d/LTuA4jViDM4v/t4YtULkJnVDMHNqfjt3 dcnJgDGukrDXKklSh/CCRY5J+pM54tuiZHFyeTDxQyEKgCnpMmBeHMcMfw2WLYhShsHk lh0vNI5/xFrPyZfETEWzKlITFOPWqq4TIZE3nm+oiJWutOCDnqL1E9B9aplDeWR1TnCu jphC4AqPZ7keFEciNjIIph++KMWa6+EBFZ+/mp9AspvwyCqBkDmH7ILLV9CaZ/d3n20S I3BwxvJmGaCW//5MFjK00JjMFHldlIxQ9DT5wzOWBa+d79OeY84+0Pgh5XWbLHa9t+Vq UdhQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=vazFcPmShmeSDNCuqUetwnB5X5aLuPQ/kUhHloOI6Xw=; fh=dqAjbcWDAwYCl0GWEgYt8Yu2dChymhkAsCD0wyUpVgg=; b=Smk9zOScr4L2LEowfiVXVXzW2/zONCaQJAyt8Oim0UBZkBCSzW2g6qOgq+B7AKoBjY FZ5HdqUuLZ01LDJZdwJNxpv4C04EzdJjqc1xIvEq/vvgqQsBPMkBr3+wMqzCRe6ywKGf 5LY8A9fkEeefFVCqnSTplypyHpPw6SLDuj0iC/hS1/LzW9wWQHpOPnQuomLjbBzlATDl 3W48JRlx/20rKzHp/izUygQuPjXmQ/rC/K4vX2oBjVBfrQBG/IYzUKUWxHIqWt02QS9m 0SYZ0HBDeiIBp1QPXdOjsW/Ixk+hqKxyZFQUsljRZUMfgqyfScJ0QDITivXLBYpuaSY3 +7Lg==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773426401; x=1774031201; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vazFcPmShmeSDNCuqUetwnB5X5aLuPQ/kUhHloOI6Xw=; b=maAL54ct9/fyD//rJPYtqMgRxUfzW7y5ga6A9C7wf563ltaZ6ACKMCdzVh1k8iZUfk Cm47POJQfaIOWtncDbhY3X3fZBgmAKoYQJyXnJh79MySvk0GtAeOegkdPOnBW5kHIW+d Qmablxrvxs7QTxCS5DzhVuVTNiayQaWNhWPmiptjszUp6j+gW0jAI0Dav1ven/TJAnvJ hzSRllmctjU0I/KcXdl0cNzWfdbvgM6C2QPsm3yKrbAw0QkqG9CAntocehVzCRGsu0nd o6vg1i+vd3E73GgtwmioGQ4DJFyM4cbOjK40ZW4luhu8XcG3VGbbj3SZPNIDA/TVYfDY UYdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773426401; x=1774031201; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=vazFcPmShmeSDNCuqUetwnB5X5aLuPQ/kUhHloOI6Xw=; b=sYmqY7j0qbLqTruXWNtlLtcoon1zldV4HaXwZAA5J/ydd6RM6oWHcVr3UqOJ11Si1u 7k0P8MYSELiiVhaeGhiZn/kiU0nUUbSyUBeY9L+v1DS7Rz/HtkZ1yYClZU6+JzdW3ZxU 1mmuDau4AFlg0jeERbvw6LTUqMbKSiqDVpN8v/qLiqQF0gy9v28R9Jy697ina+fww2q7 x0KIPl64Xg8Y/1F2TMv92HhkkUtIvctAfO/uloNlQE7qheZD3XDx2sIjokOSMXQGIClz bSk4w/aBHBH8t6OVuYj4iinNe0kj6NSdCOgP6QSYFdNbECWKV/erAaSAbsY3P5BVHMb1 Xmig== X-Forwarded-Encrypted: i=1; AJvYcCVwuWRqEUJALtKs9+8xmxqXJmt89rZz77Qo51Om9Ph723RjjH7tvgW3l8+kCLqigkAe+axTKA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzhOJMm0ItqaVtXnQO44k4vEvUQOxmuRh6LyT6NWkd14ODqbi5r NmZHA4+MAGmxzmp8nsBFStAD9OaoxUQiRSJhCBehAeUWleXRJ6FoG1VVTFCAL3lCiYcIr1ObYOs hKW+CUytbO6j9L24zY9PoGlbez7SrjUc= X-Gm-Gg: ATEYQzwpRuQh5ErmTW/CfnyISnOtzQk8iznFAHHk6gX3wLuKP7GOoESfRGAsftd9eZA 9KDkwg9adJOhlC1pKWG5I5CdWnyFxOhgX40HIeXj9HxrYkc3NylAIUv4QcwI8ihNicQMMKWXdKb 3xLdiVOlkUQhQFKgSBFW6lIRkx5KPMl0VXIIGIqoyFLNGEfOYmmSAwcC5niwSQHlRaByFElFdFF KSPpfGZASIpHpF2ilmsTsCpcGHIVz24bWZaTO6ETyvr1gh78K0YYeCQh6d+AVKiU5F9hqh1gmcv IbDVH1Mnzjj0yJ6JC3Ua1JYTE6bl9eOP7WpGPRHqECdNBbJTIerHHWiGWUq2ULOY/+/kld2RtFY FLg== X-Received: by 2002:a05:6820:1a0a:b0:67b:a8f8:f69e with SMTP id 006d021491bc7-67bda9c0bdamr2788520eaf.29.1773426401280; Fri, 13 Mar 2026 11:26:41 -0700 (PDT) MIME-Version: 1.0 References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> In-Reply-To: <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Fri, 13 Mar 2026 18:26:30 +0000 X-Gm-Features: AaiRm52f_ko_Fw8xXFVaSKoAg5yJG_SsWzocxTJh742JHcZVlwOzpSqz7nui4Fo Message-ID: <CALDnm500VfR_Pm0eRk6vWwxf=z8Np2MUyfCfXkbHOLSOEvS2LQ@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000af0637064cec02ed" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --000000000000af0637064cec02ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 13, 2026, 15:00 Stefan Monnier <monnier@HIDDEN> wrote= : > >> A lot of existing ELisp code which uses `intern` was written before > >> Emacs-28 and passes it an argument that is not constructed from the > >> contents of an ELisp-mode buffer. I'm thinking of code like eshell > >> computing `eshell/COMMAND`. > >> That kind of code has been "broken" by the new `read-symbol-shorthands= `. > > "Broken" how? what are the symptoms of that breakage? > > The immediate consequence is that the returned symbol is a different one > from the intended one, and the potential breakage can be arbitrary > depending on what is done with that symbol, e.g. it could be just using > another variable's value and burp with a type error, or calling another > function than the intended one, or load another file than the > intended one, or ... > All of this is true, but I think we should put it into context. Unless I'm very mistaken, this can only happen if: 1. You are visiting an Elisp file. This does not happen at all if you're only _using_ Elisp programs (coded with shorthands or not) to do other work inside Emacs 2. That Elisp file has shorthands configured as file local variables and you've not chosen to ignore that value. 3. You use, from within that buffer, some editing facility that uses 'intern' for non-Elisp reflection purposes and which does so with the Elisp buffer current 4. The shorthands the author of that file chose are particularly poor and easily clash with equally poorly chosen symbol names of the facilities of 3= . Now, we still don't know of any facility/package that fits 3. I suspect vc.el could be a candidate, but I'm not sure. Eshell and pcomplete were initially cited as examples, but after looking at them more closely they seem very unlikely candidates. Pcomplete was deprecated in Emacs 27 anyway. All of this probably explains why we've seen 0 bug reports about this. I don't think it's worth trading possible but extremely unlikely breakage for new forms of likely breakage. Furthermore, even after your changes, just by the nature of shorthands, it is much, much more likely that if you choose shorthands poorly, legitimate shorthand-aware automated macroexpansion of locally defined macros (say, triggered by flymake or by smart completion tricks) will trigger the aforementioned bizarre effects. IOW if you select a shorthand that maps "list" to "launch-missile", you're always going to have a bad time, regardless of any API changes you can think of. (But we also have 0 reports about this, probably because shorthands are an advanced Elisp feature and at least non-malicious programmers know what they're doing). Jo=C3=A3o --000000000000af0637064cec02ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">On Fri, Mar= 13, 2026, 15:00 Stefan Monnier <<a href=3D"mailto:monnier@HIDDEN= .ca">monnier@HIDDEN</a>> wrote:</div><div class=3D"gmail_quote= gmail_quote_container" dir=3D"auto"><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin= g-left:1ex">>> A lot of existing ELisp code which uses `intern` was w= ritten before<br> >> Emacs-28 and passes it an argument that is not constructed from th= e<br> >> contents of an ELisp-mode buffer.=C2=A0 I'm thinking of code l= ike eshell<br> >> computing `eshell/COMMAND`.<br> >> That kind of code has been "broken" by the new `read-sym= bol-shorthands`.<br> > "Broken" how? what are the symptoms of that breakage?<br> <br> The immediate consequence is that the returned symbol is a different one<br= > from the intended one, and the potential breakage can be arbitrary<br> depending on what is done with that symbol, e.g. it could be just using<br> another variable's value and burp with a type error, or calling another= <br> function than the intended one, or load another file than the<br> intended one, or ...<br></blockquote></div><div dir=3D"auto"><br></div><div= dir=3D"auto">All of this is true, but I think we should put it into contex= t.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Unless I'm = very mistaken, this can only happen if:</div><div dir=3D"auto"><br></div><d= iv dir=3D"auto">1. You are visiting an Elisp file. This does not happen at = all if you're only _using_ Elisp programs (coded with shorthands or not= ) to do other work inside Emacs=C2=A0</div><div dir=3D"auto">2. That Elisp = file has shorthands configured as file local variables and you've not c= hosen to ignore that value.</div><div dir=3D"auto">3. You use, from within = that buffer, some editing facility that uses 'intern' for non-Elisp= reflection purposes and which does so with the Elisp buffer current</div><= div dir=3D"auto">4. The shorthands the author of that file chose are partic= ularly poor and easily clash with equally poorly chosen symbol names of the= facilities of 3.</div><div dir=3D"auto"><br></div><div dir=3D"auto">Now, w= e still don't know of any facility/package that fits 3. I suspect vc.el= could be a candidate, but I'm not sure. Eshell and pcomplete were init= ially cited as examples, but after looking at them more closely they seem v= ery unlikely candidates. Pcomplete was deprecated in Emacs 27 anyway.=C2=A0= </div><div dir=3D"auto"><br></div><div dir=3D"auto">All of this probably ex= plains why we've seen 0 bug reports about this.=C2=A0</div><div dir=3D"= auto"><br></div><div dir=3D"auto">I don't think it's worth trading = possible but extremely unlikely breakage for new forms of likely breakage.<= /div><div dir=3D"auto"><br></div><div dir=3D"auto">Furthermore, even after = your changes, just by the nature of shorthands, it is much, much more likel= y that if you choose shorthands poorly, legitimate shorthand-aware automate= d macroexpansion of=C2=A0 locally defined macros (say, triggered by flymake= or by smart completion tricks) will trigger=C2=A0 the aforementioned bizar= re effects. IOW if you select a shorthand that maps "list" to &qu= ot;launch-missile", you're always going to have a bad time, regard= less of any API changes you can think of.</div><div dir=3D"auto"><br></div>= <div dir=3D"auto">(But we also have 0 reports about this, probably because = shorthands are an advanced Elisp feature and at least non-malicious program= mers know what they're doing).</div><div dir=3D"auto"><br></div><div di= r=3D"auto">Jo=C3=A3o</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br= ></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"= auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><di= v dir=3D"auto"><br></div><div class=3D"gmail_quote gmail_quote_container" d= ir=3D"auto"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0= .8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote></div></div> --000000000000af0637064cec02ed--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 18:15:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 14:15:22 2026 Received: from localhost ([127.0.0.1]:47213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w172e-00040J-Ng for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 14:15:22 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37018) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w172b-0003ul-8t for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 14:15:18 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3FF29100034; Fri, 13 Mar 2026 14:15:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773425710; bh=QyKAPayxl29IWyPLXUPlgOSSG+zKCWXQs84ry9HvV5I=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ZyKQS2Fs4Wtd4ypHD0zlIIJfh1FoOnLUuGTzn7TlLqpISph23ZC31Lh1ZmfhiWFMg 35oixoPEBwwXHSsEO36kmrS5/rN834wAJL4szjWM9U9qi1UZhSqPuQiBVXSHmLF5fR 0lhLl/9iATKheIWGIM8HAuOzNMepWaWcjQmBsuEAEX41qsv0VVIdXDiUS+2AFfnMW+ xmpCikfyEaRYwrGbR9hNCLah18J5fVtNbInFVvPrsjLNOIoDny3HNs0XZtRL4g5mFt E3Z2umv84usrT5/sGSzqyb31nBLyWEoBbS0oCSknvdMhcPbNcjmFZm89rhbNSCUrWN oSvs/sTm887sQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 552F9100029; Fri, 13 Mar 2026 14:15:10 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4A5BF1206A7; Fri, 13 Mar 2026 14:15:10 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <877brgvvzn.fsf@HIDDEN> Message-ID: <jwvikazydsx.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> <877brgvvzn.fsf@HIDDEN> Date: Fri, 13 Mar 2026 14:14:58 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.163 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > How do you know that those "bug from the future" will come in those > forms "doens't have support for read-symbol-shorthand" or "behaves > erratically". For all we know, _not_ finding a legit symbol shorthand > tomorrow after your change might just as well mean the difference > between life and death. It's possible, of course. My crystal ball says it's extremely unlikely, tho. > The only difference is that we're almost sure you'll introduce > breakage, whereas we've not not seen in 3 major Emacs versions the > breakage you're trying to fix. The breakage is unlikely to appear by accident, maybe, but just like buffer-overflows it could have dramatic effects if abused on purpose. > Furthermore I'm not sure at all that that breakage's > size -- which by your own admission is already very small -- is what you > think it is: your "Eshell" example was a false positive after all. Even > the 'pcomplete.el' alarm seems a bit over the top: I'm not sure > 'pcomplete.el' is ever run or useful in Elisp buffers. You can set `read-symbol-shorthands` in any buffer, not only in elisp-mode buffers, so any major mode that uses pcomplete in file buffers (e.g. org-mode) can be affected. > - change all smelly, non Elisp-reflective 'intern' uses in the Emacs.git > tree to have explicit obarray parameters. > - harden read-symbol-shorthands safe-local-variable predicates > - change only proven source of non Elisp-reflective intern that can run in an actual > Elisp buffer -- 'vc.el' -- to use generic functions or use a separate > obarray. I've already given some patches. All of these require changes in the cases where the problem manifests itself. I prefer a "safe by default" choice where none of those dangerous use-cases need to be changed (or even found for that matter), and instead we have to find&change only those cases which benefit from `read-symbol-shorthands`. > Do these things, speeding up completion and general Emacs use in the > process, before breaking a fundamental Lisp property that has related > 'read' and 'intern' for decades. AFAIK `read` has virtually never passed to `intern` the literal string found in the buffer. It has always pre-processed it (mostly for backslash escapes). Adding shorthand expansion to that pre-processing seems to fit very naturally into the decades long relationship between `read` and `intern`. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 15:36:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 11:36:02 2026 Received: from localhost ([127.0.0.1]:46328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w14YT-0002AK-TY for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 11:36:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58024) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w14YR-00029K-IP for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 11:36:00 -0400 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 <eliz@HIDDEN>) id 1w14YM-0004nJ-6k; Fri, 13 Mar 2026 11:35:54 -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=WmF7PqOjXTz1AtqKjKXmBGLtlWwm5z4/cnd8uNo+NOE=; b=JsWNKboN6eRI qyjtxMZSCLja36Ot7QTmsCwlfW/hrC0datv5QJaM/27/S/IfcsElKyffbboK0Zmj2oQ/sCMzPQMaG 0R6qOxOK3nKjqMOpEFfHNYOi/osVTpquCGeOVBxJ/FfI9eJuK/VKLFy0CltFq1xe08g3FnL9YHrqy nMKSZASBSRUYgO4crt3MQnKQkavlrSPP/IEbi/tU8VquW/CeqVnedZhA0/c5iIvjdvdMhkflAUqIU R24SVPkr+UcJK1yQUDQIpVnLO0TjdfJp+k3vHWFk4rH1r4kjLpJ9T75/whhmiOC23Vse2/jW/EynX ixYdYPiABiraLnxwkBB/FA==; Date: Fri, 13 Mar 2026 17:35:52 +0200 Message-Id: <868qbvd9nr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Fri, 13 Mar 2026 11:00:12 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org > Date: Fri, 13 Mar 2026 11:00:12 -0400 > > > E.g., we have several C functions that intern strings, > > see font.c and xfaces.c. How can they know where did those string > > come from and, if they came from some buffer, whether the buffer > > specifies read-symbol-shorthands? > > They can't, which is why having `intern` blindly obey the current > `read-symbol-shorthands` is a mistake in that case. > > > Won't those functions be subtly broken by your change? > > The functions themselves, no, but the overall behavior, maybe. > Or maybe in some cases yes, and in other cases it will be subtly fixed. So it sounds like we have no way of knowing when and how to fix the cases where we really do need to obey read-symbol-shorthands in functions that call intern internally. I think we should have such a mechanism, and without it the changes you propose are incomplete and basically a time bomb. Would it be possible to do better?
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 15:00:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 11:00:34 2026 Received: from localhost ([127.0.0.1]:46268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w1409-0007c5-LN for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 11:00:34 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7688) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w1407-0007b9-5f for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 11:00:31 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 67F39440F51; Fri, 13 Mar 2026 11:00:25 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773414023; bh=IRIb5Ge8vcZenZ8FVKCpWD4D5Ro3rPpjy7BSZqws1oo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=EPUPHZWLYDK0pB9N3Rl+Eafm4YZtcsl8ZltnB7gkdpi6+lIr9aLItRNYgh6uJ79va Z5MxnQ784kVDsmqiSwog+NIwyCE7qWMAbJxgWROODWUVqFMUYaZTG2KXqcDSQ1DMCY Untm966r4gM+a5jya+9/lQKBd+Lstfpo8QQsRml6vpH96GGo31984rtxqDCZr6ZdOY nVh1Tv2U7KDZWR1usXo95Gi1osYpoI2N0ry5PtOK1WpMM83BRaj/IzvdNS/G3lfMp8 vVktnqaTL8MMFUtTpcYzIhtQNPG1vMgcUSW9+2g5TTF0LZJcr8aFlabYBMndE4bWih lUprRPCoBIcdg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C3E01440B58; Fri, 13 Mar 2026 11:00:23 -0400 (EDT) Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B10C0120B3D; Fri, 13 Mar 2026 11:00:23 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86sea4c4no.fsf@HIDDEN> Message-ID: <jwvo6kryeew.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <86sea4c4no.fsf@HIDDEN> Date: Fri, 13 Mar 2026 11:00:12 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.054 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> A lot of existing ELisp code which uses `intern` was written before >> Emacs-28 and passes it an argument that is not constructed from the >> contents of an ELisp-mode buffer. I'm thinking of code like eshell >> computing `eshell/COMMAND`. >> That kind of code has been "broken" by the new `read-symbol-shorthands`. > "Broken" how? what are the symptoms of that breakage? The immediate consequence is that the returned symbol is a different one from the intended one, and the potential breakage can be arbitrary depending on what is done with that symbol, e.g. it could be just using another variable's value and burp with a type error, or calling another function than the intended one, or load another file than the intended one, or ... The symptoms can be anything, which is the reason why I prefer fixing this breakage even if it replaces it with another kind of breakage (where code fails to obey `read-symbol-shorthands`), because that one is usually a lot more predictable/expected. >> The value of `read-symbol-shorthands` should apply to ELisp symbols >> extracted from the buffer that has that value and nowhere else. >> So, you should use the `shorthands-*` variant if the string you pass is >> one that was found in a buffer that has that same >> `read-symbol-shorthands` value. And you should straight `intern` if the >> string you pass was constructed from names that don't come from a buffer >> or that come from a buffer unrelated to ELisp code. > > Hm... but how can a given function know whether a symbol came from > such a buffer? If it doesn't know, that means it doesn't know if `read-symbol-shorthands` should be applied (or even *which* value of `read-symbol-shorthands` should be applied), so the only sane choice is to not obey `read-symbol-shorthands` in that code and push the responsibility to the caller to call `shorthands-to-longhand` if/when needed. > E.g., we have several C functions that intern strings, > see font.c and xfaces.c. How can they know where did those string > come from and, if they came from some buffer, whether the buffer > specifies read-symbol-shorthands? They can't, which is why having `intern` blindly obey the current `read-symbol-shorthands` is a mistake in that case. > Won't those functions be subtly broken by your change? The functions themselves, no, but the overall behavior, maybe. Or maybe in some cases yes, and in other cases it will be subtly fixed. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 12:09:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 08:09:25 2026 Received: from localhost ([127.0.0.1]:44796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w11KX-0002IW-96 for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 08:09:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51762) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w11KU-0002H8-Lw for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 08:09:23 -0400 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 <eliz@HIDDEN>) id 1w11KP-0007c0-0O; Fri, 13 Mar 2026 08:09:17 -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=eS8RYj1slSdgKGptgggkFJ4cIBjjlVgi7rcRze5cocc=; b=TQCaF31GUm2b 81R7S2svdub0eKl9KsjboT92vZR1Ljwytk9mhwDmM4d+2H1hh1BvmNyoJqywL7pOUBFa5WNNeGWg3 Aw4AU0lHJVW+U0/Qa+/gFMwqocJsyidHXzUpTC1AVdiFC3dMb+Idz8aDU0MyIBQRXZqbndPhdfr7a QSCl3T/ZSY8xrVxviPaBLwPAjCUBWasDgrV+/HthxCU3OUNcTxZ7yeAKSqmeE/JlXXS6QOTALwUoz wU9n+bBAWE1fAyhargdUAfv++hWFxKaFtaESNPz29c0rh0lu9d41Bv+hAC4W4ArL6vOM/WC8OWAHq t9vQtPs3LwN2+LPsTNg73A==; Date: Fri, 13 Mar 2026 14:09:15 +0200 Message-Id: <86sea4c4no.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Thu, 12 Mar 2026 17:46:27 -0400) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: joaotavora@HIDDEN, 80574 <at> debbugs.gnu.org > Date: Thu, 12 Mar 2026 17:46:27 -0400 > > >From the user's point of view there should hopefully be no > visible effect. For Emacs developers it means the behavior of `intern` > reverts to that of Emacs<28. > > So any code which uses `intern` where the argument is expected to be > (constructed based on) a string extracted from an ELisp-mode buffer will > need to be updated to use `shorthands-intern` instead. Hmm... bother. > > and preferably also the rationale. > > A lot of existing ELisp code which uses `intern` was written before > Emacs-28 and passes it an argument that is not constructed from the > contents of an ELisp-mode buffer. I'm thinking of code like eshell > computing `eshell/COMMAND`. > That kind of code has been "broken" by the new `read-symbol-shorthands`. "Broken" how? what are the symptoms of that breakage? > > In particular, I wonder when Lisp programs should call > > intern/intern-soft and when their shorthands-* variants? > > The value of `read-symbol-shorthands` should apply to ELisp symbols > extracted from the buffer that has that value and nowhere else. > So, you should use the `shorthands-*` variant if the string you pass is > one that was found in a buffer that has that same > `read-symbol-shorthands` value. And you should straight `intern` if the > string you pass was constructed from names that don't come from a buffer > or that come from a buffer unrelated to ELisp code. Hm... but how can a given function know whether a symbol came from such a buffer? E.g., we have several C functions that intern strings, see font.c and xfaces.c. How can they know where did those string come from and, if they came from some buffer, whether the buffer specifies read-symbol-shorthands? Won't those functions be subtly broken by your change?
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 10:56:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 06:56:15 2026 Received: from localhost ([127.0.0.1]:44586 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w10Bh-0005ef-Bk for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 06:56:15 -0400 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:54619) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w10Bc-0005df-UB for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 06:56:10 -0400 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-48539d21b76so14382985e9.1 for <80574 <at> debbugs.gnu.org>; Fri, 13 Mar 2026 03:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773399367; x=1774004167; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ZpZLHV9d/FV8MF/0HAeOv/SnBxj6YHcbtkijHCPEQj0=; b=RwE5T3IjinguZ7NbCr4pv91eijC95G0vevdrB2AG+DDHU0RmwaKJ/pHyWma3JZ3LtW jyT94Zq2NeHe7rJazTRe86Ns+HWd5ItIuqvK0aFF8UXzJ3+X+4kgE9MtoWXvMoaGSfCY qIch5phS7FZVVvABwEmIJw1Z0oLT2WMf+GvVGhU/lwSqrB9mnsVNdOaewQSwX5ctzYfP taBiHBFWhI11uPfduQSX592VHPOE8KP+y8GtF8qhuPiwrRaQyKYhVtv34wtXafyorOci DC8e1tGSuFgTDuNyHShwSe08GuwLX+Gxw3yhMbQKdSsFqtpPVBhE9bpAuoaaazN6koLo sThA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773399367; x=1774004167; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZpZLHV9d/FV8MF/0HAeOv/SnBxj6YHcbtkijHCPEQj0=; b=sh5bvjhKi7fBX8L97EAuD3C894IXNLnDtDLT6qtahTi1n+dVealfeJ0dP3eLXyuxLB 73eDRmz96fvvcJRzYKyhqLaYXmZnmQXFtnG5oQqrv8mQ9lsa6K38Jgl5gVZqNjEy355/ HJ2yurtcFeyDB1XT1VM+CO7x0ktJvJaw+ygZ3lKtGKTfyPiiYUfwVaqhQ3V0684l7NDw GaS8UTsa0PpmdF7cNpilNrGNRzNs2+LAmbweBUWsp/8b7ODSo+xw/oQddNNvd2ZCxlTz idt8X3mN1Qs+X57ygfxVhKL8dDR+Ym3QrxxIs0q4QCN4r32CJYD/3HhlcRg6BJX6+ylp i5Vg== X-Forwarded-Encrypted: i=1; AJvYcCUcE1iNbtVX3Wn+SCsIgtnD037veKnK2nCnpHe00CAk8UBTXOs0C6J299RqHdYPyN0g6+mmlg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwmoX80s1lILWbJ5VVoocWVyeZ1ti9+/N1gt2LAbux8aHaipmk7 k9s7Vnzc08HKLSEu55hux0+gZUTO5tRRT3GRPHhtQHqP/x7+smpf+pztqoY7gA== X-Gm-Gg: ATEYQzyvVYCy++wtqgqg98DzUDcj5jEqOfCXJQ0yEA4gdEM1W6ExbdwNteLQ9Dnk9xT mpwpCOgEm6WjTVCEUFdp7ASHGboWk8CJLsZA5PkRp7gptF+k/aGFbCkdOVn69KvlmFPa3e05xDN ezd71EyO8Puu1Tufzkn798vZb86WdLvldgy4yEkpOt2NqliCvF2/fy4k21tfvxc1gM7bh10GcwI 5dXmvvozOyznAuB0w0nRr04qclygSJQZ4nKgsMfv+y2SJqWuLY+4eWxnU4jdQKlL/0YH/0oaWFd quQcZxWER9sejyGubIyMPVx+NQsmVECswSMB2oUKEIRzBqoXRPXwaL554qdvuy0qNo86PIIjnEf e/7lE2ZvVzVgcGySintPes5dytvxuItfuVz7WwQfsgHf/EGUhofRt6LqiTqqu8J3CqO4rUg64Ds 7oaL4QrA1ui7gYN7nTRAXbuMPDHJGQoh+OErubfHW7c6IH8AKvHEOWji4xUPcEkGs+lYRtJLazf Vg70Kt+vE8p0lx8J3x3XDZrbFM= X-Received: by 2002:a05:600c:a15:b0:485:34a2:919e with SMTP id 5b1f17b1804b1-48556710fd5mr44331445e9.33.1773399366883; Fri, 13 Mar 2026 03:56:06 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4855638cebcsm41787895e9.0.2026.03.13.03.56.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Mar 2026 03:56:06 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwv7brgl764.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> <jwv7brgl764.fsf-monnier+emacs@HIDDEN> Date: Fri, 13 Mar 2026 10:56:12 +0000 Message-ID: <877brgvvzn.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: >> Take for example, a package like >> https://github.com/mishoo/elisp-reader.el. If I'm not mistaken, it >> might well be broken by your changes, since it relies on this symmetry, >> even though it probably works in Emacs < 28 and shorthand-aware Emacs >= =3D >> 28 just as well. > > I think there's an important qualitative difference between "FOO doesn't > have support for `read-symbol-shorthands`" and "FOO behaves erratically > in corner cases because of some unrelated setting of > `read-symbol-shorthands`". > I favor the first breakage because it is more conservative and because the > failures are easier to diagnose and understand. IOW, we stay on firmer > and safer ground. How do you know that those "bug from the future" will come in those forms "doens't have support for read-symbol-shorthand" or "behaves erratically". For all we know, _not_ finding a legit symbol shorthand tomorrow after your change might just as well mean the difference between life and death. The only difference is that we're almost sure you'll introduce breakage, whereas we've not not seen in 3 major Emacs versions the breakage you're trying to fix. Furthermore I'm not sure at all that that breakage's size -- which by your own admission is already very small -- is what you think it is: your "Eshell" example was a false positive after all. Even the 'pcomplete.el' alarm seems a bit over the top: I'm not sure 'pcomplete.el' is ever run or useful in Elisp buffers. >> So instead of sanctioning/perpetuating this harmful pattern, > > The fact is that such code is out there and no LLM will fix it for us > tomorrow, because most of the work of fixing it is not technical but > one of finding & convincing authors and synchronizing changes. Clearly doesn't seem to be a problem for you, since you have elided every practical suggestion this author has given. Sigh, here they are again: - change all smelly, non Elisp-reflective 'intern' uses in the Emacs.git tree to have explicit obarray parameters. - harden read-symbol-shorthands safe-local-variable predicates - change only proven source of non Elisp-reflective intern that can run in an actual Elisp buffer -- 'vc.el' -- to use generic functions or use a separate obarray. I've already given some patches. Do these things, speeding up completion and general Emacs use in the process, before breaking a fundamental Lisp property that has related 'read' and 'intern' for decades. Jo=C3=A3o =20=20
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 04:01:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Mar 13 00:01:52 2026 Received: from localhost ([127.0.0.1]:42256 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0tig-0002mu-3m for submit <at> debbugs.gnu.org; Fri, 13 Mar 2026 00:01:52 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29296) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w0tib-0002lB-DE for 80574 <at> debbugs.gnu.org; Fri, 13 Mar 2026 00:01:46 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D171F10013E; Fri, 13 Mar 2026 00:01:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773374497; bh=Atlep9JCRB4GcttvPFaUJa7tATONnGJcgEzACr3kG9Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JS5fTmSsfFdv+hekTzyUgAtBYC356bqBfYt4BkmXUIX2DiUhHUNMPKo4wJhcpNz7C kYpGqqp3Rnhj0yCSPPNeIoYqIFi//zXjaLiA5pQF/8IIgqF8j3jDOrmWglkqLT5efu DZlAirMNWza+5CGyFn75EB3EWFrGRDQHQjDSXUg9eduz/GrDUiHIVxVYtSS4fyM7Hl ExqmSufrNN2UeFOPWtQpa0srzjjEdv8TyaOBMK8JrABbFtFf2ts9tTuAi5QOXfr+hb SIxoS91LArMlM0+Qmrv4ATPAXz/9+AdIyIzBdomn8z1mQdY0ELdGkD/oPkRbsz2zyF b8fNA4ZSSTawA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8D74410002E; Fri, 13 Mar 2026 00:01:37 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5F56E1204AE; Fri, 13 Mar 2026 00:01:37 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <87pl588sce.fsf@HIDDEN> Message-ID: <jwv7brgl764.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> <87pl588sce.fsf@HIDDEN> Date: Fri, 13 Mar 2026 00:01:25 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.110 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > Take for example, a package like > https://github.com/mishoo/elisp-reader.el. If I'm not mistaken, it > might well be broken by your changes, since it relies on this symmetry, > even though it probably works in Emacs < 28 and shorthand-aware Emacs >= > 28 just as well. I think there's an important qualitative difference between "FOO doesn't have support for `read-symbol-shorthands`" and "FOO behaves erratically in corner cases because of some unrelated setting of `read-symbol-shorthands`". I favor the first breakage because it is more conservative and because the failures are easier to diagnose and understand. IOW, we stay on firmer and safer ground. > So instead of sanctioning/perpetuating this harmful pattern, The fact is that such code is out there and no LLM will fix it for us tomorrow, because most of the work of fixing it is not technical but one of finding & convincing authors and synchronizing changes. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 13 Mar 2026 00:51:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 12 20:51:19 2026
Received: from localhost ([127.0.0.1]:41027 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w0qkG-0005HS-8k
for submit <at> debbugs.gnu.org; Thu, 12 Mar 2026 20:51:19 -0400
Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:57455)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>)
id 1w0qkB-0005GH-3s
for 80574 <at> debbugs.gnu.org; Thu, 12 Mar 2026 20:51:14 -0400
Received: by mail-wr1-x42c.google.com with SMTP id
ffacd0b85a97d-439c56e822eso1641056f8f.2
for <80574 <at> debbugs.gnu.org>; Thu, 12 Mar 2026 17:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1773363069; x=1773967869; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=5MDlQinBub//4eyN+WFUzJNOlPf05ii3GqeJkhbpchk=;
b=Vyz05QM1Sq1D2KRgrHcKNN/ewZYuTlLZzElYAKPwx0sTryKNVTDjdUHkLRxWydeZ3D
b8aiGqOV/0rzG3PzY5cnDK/5W90ZWFWjYvdDlWjX5CPee8MpZknBBqwLyLzG+DWphmXA
NW/YOziO77n3ORN2E3aXqyH59Phhebyf49FwQI9y/X26AZFz/Im97d06IWk+qAnDDzKF
6/4qhRQgn9K3NksWNSJIzGDJcRjUHowN0iN1KgM8AANJ2Z2ait2R+CAxd7A9jre9E6WU
43Tbz5wQI/kDwZSQj7nhnkh2+nEHoZLUgvaANTlC8S9wngOSO198dSTYLAjpxrk12XEp
v6SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20251104; t=1773363069; x=1773967869;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=5MDlQinBub//4eyN+WFUzJNOlPf05ii3GqeJkhbpchk=;
b=q4qk8BpHpoMyEOm9cg3mjOR8/4XebiTraJdpbSImH+cmMk/ml2Ur8wtVsNlUz38S89
I2VpST5+QBBuSyZXp902jQx1cd7gfEZGdFyQIig1f/OcnYdt3WHn2D7s9yNQjyuUNv8T
yKZTOP9vDSn0QvKxbusvlBwgEcvUp1BUd791fpfk6zS9o0+3mlUurtque4F0XvsKhlP2
7sqmU5ecUgDT/T80+5tx4d0y1iP+flHpAE061cSWLut5XDtBeWswWVlZwkeqWC2mdWLN
eapgUZKjnI3Zq1QcnlYIsTCn9Y1SdBA8TXckE33D5GOeWtobdt5kfY14rZq697X9HIR0
JQ6g==
X-Forwarded-Encrypted: i=1;
AJvYcCUyZD9qZ89BUXB+hC4a7jO5c6MqnVUXl0FPOJEU5tKIie0beKSUjJaFDZf/R6HIIVxnQFIuKg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YymIu/VGcDLGTOPubJi5L5UD5StueXQ5HktXTzbwEOgW8jLrWls
lovLDgWhD6pH2enfQxXNqHaQ5Yv9hhgg+cK9M5NhmcjSLrC46IGTMn1JWrmzpQ==
X-Gm-Gg: ATEYQzxsfIKCHqfdYs6u4XwbDBliPvbZqif8F7k08tbURFj0itfMK6vFs09VZdKDimF
B0VzED1WoKcwNBtVI5nWWaBM1pt4j3UgmaS1YKPZpjSHYCkth8jOYEj/u8DrJEgwte28tcwdcNu
LO/jT982m5bjgmEn/DAP1Jv5FUlrPCHYaCcZ9/9yzc55cHw59LhuraeyDCDKGgkr146Wvyo35vv
56t5Ry+1S+rwWBvM8W+uwNTzwY01kYBvd8DbdIvfSlyNMkEccAhc3c8vY8QnjTI5xJgW1dXG1sU
fzdecw9tc7R+NLf2lQLGffk7yzaFtMMSyWkb8DtQjCOiMMkyIaudlMP/x5380Gd/B3ZzDDB6eFr
Ug96boIMjuwst8zUfKA5FPXT7SEiUMKtJnIPuI/j9BSw6g21SFNkt6zELkNHYK+R3PZQcwcaDzL
JUgfauVk+EjWESLnpP+a0c7svTO8rK5TZ58E7uSQLrHbqb5Kbq9ZBgK4YZ9H7vz7yRbQrzC6lGw
2KLRUojj00NUqtPrbfqIA9Rykk=
X-Received: by 2002:a05:6000:601:b0:43a:3cc:83e9 with SMTP id
ffacd0b85a97d-43a04d7b3aamr2954548f8f.4.1773363069105;
Thu, 12 Mar 2026 17:51:09 -0700 (PDT)
Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-439fe20bb90sm13358026f8f.19.2026.03.12.17.51.07
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 12 Mar 2026 17:51:08 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN>
<jwv4imkpwfs.fsf-monnier+emacs@HIDDEN>
Date: Fri, 13 Mar 2026 00:51:13 +0000
Message-ID: <87pl588sce.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80574
Cc: Eli Zaretskii <eliz@HIDDEN>, 80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Stefan Monnier <monnier@HIDDEN> writes:
> From the user's point of view there should hopefully be no
> visible effect. For Emacs developers it means the behavior of `intern`
> reverts to that of Emacs<28.
That's true, but now create an assymetry which was never there before.
In Emacs < 28 and _also_ in Emacs >=3D 28, there was always (like in every
Lisp implementation I know) the fundamental symmetry that the built-in
'read' behaves just as if you write a custom reader manually with stream
manipulation functions and 'intern'.
Take for example, a package like
https://github.com/mishoo/elisp-reader.el. If I'm not mistaken, it
might well be broken by your changes, since it relies on this symmetry,
even though it probably works in Emacs < 28 and shorthand-aware Emacs >=3D
28 just as well.
> like Eshell computing `eshell/COMMAND`. That kind of code has been
> "broken" by the new `read-symbol-shorthands`.
Even between quotes, "broken" it still a stretch... I'm not 100% sure,
but I'm not sure "eshell/COMMAND" can be looked up with an
shorthand-enabled Elisp buffer current, because Eshell things run in the
Eshell buffer, right?
Surely, there _are_ such potential cases (at least the functions in 'vc'
sound like plausible candidates), which do run in Elisp files and could
bump into such conflicts, but as you say it's very rare. And more
importantly, whose fault is it? You say it's shorthand support, but I
say it's a mix of that code's misuse of the obarray, misuse of
shorthands, and just facts of Elisp's one-global-namespace life.
> It's difficult to find such code because the breakage almost never shows
> up (e.g. for the above you'd need to run the code in a buffer that has
> set a `read-symbol-shorthands` prefix of something like "esh" which is
> very rare).
...is it more likely than having an arbitrary Elisp program accidentally
overwrite "eshell/cd" and clash directly with eshell's (ab)use of the
Elisp global obarray? Perhaps, but comparing tiny risks to minute ones
doesn't make a very strong case.
It is certainly nothing compared to the much more common case of having
a haphazardly chosen shorthand prefix such as, say, "def->default",
basically break all the code in a given Elisp file (because basic things
like "defun" will be misread). That's just part of the risk of not
using shorthands correctly. That's why the manual recommends "def-" or
"def//" as a prefix, not "def". When I implemented this, I chose not to
enforce particular shapes of prefixes because I wasn't sure people would
prefer "foo-" over "foo:" or "foo/". In hindsight, I could have
explicitly prevented or at least strongly discouraged using just "foo"
with no punctuation. You could still do that, if you think it's worth
it.
What I'm saying is that the more I think about it, the more I arrive at
the conclusion that the risks you are trying to mitigate are somewhat
irrelevant in practice.
> And you should straight `intern` if the
> string you pass was constructed from names that don't come from a buffer
> or that come from a buffer unrelated to ELisp code.
I disagree strongly here. These programs shouldn't use 'intern' at all,
they're just creating noise in the obarray for symbols that don't need
to be there: they are not meant to be called directly from Elisp
programs, looked up with C-h f, invoked as commands, etc. The global
obarray should be chiefly for these things.
And it isn't just cosmetics. Interning junk into the obarray severely
slows down completion (see attached benchmark script) and other obarray
users.
So instead of sanctioning/perpetuating this harmful pattern, it's better
to change this code to use separate obarrays or hash tables instead (or
some more sophisticated dispatching mechanism like generic functions).
I've already provided some patches for vc-*.el. For pcomplete stuff, it
is more complicated, but I'm working on a patch that interns all its
definitions into a separate obarray.
Jo=C3=A3o
=20
--=-=-=
Content-Type: text/plain
Content-Disposition: inline; filename=bench-completion.el
Content-Description: bench completion
;;; bench-completion.el --- Benchmark completion-all-completions on obarray -*- lexical-binding: t -*-
;; Run with:
;; src/emacs --batch -Q -l bench-completion.el
(defun bench-completion (label n)
"Benchmark completion-all-completions with PRED=fboundp and STRING=\"\"."
(garbage-collect)
(pcase-let ((`(,total ,gc-runs ,gc-time)
(benchmark-run n
(completion-all-completions "" obarray #'fboundp 0))))
(message "%s: %d runs in %.4fs (%.4f ms/run); %d GCs totalling %.4fs"
label n total (* 1000 (/ total n)) gc-runs gc-time)))
(defun intern-dummy-functions (count)
"Intern COUNT dummy function symbols into obarray."
(message "Interning %d dummy functions..." count)
(dotimes (i count)
(let ((sym (intern (format "dummy-bench-fn-%d" i))))
(fset sym (lambda () nil))))
(message "Done interning."))
;;; Run benchmarks
(let ((runs 10))
(message "=== Baseline obarray (approx %d symbols) ===" (length (apropos-internal "" #'fboundp)))
(bench-completion "baseline" runs)
(intern-dummy-functions 200000)
(message "=== After interning 200k dummy fns (approx %d symbols) ===" (length (apropos-internal "" #'fboundp)))
(bench-completion "200k-fns" runs))
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 12 Mar 2026 21:46:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 12 17:46:39 2026 Received: from localhost ([127.0.0.1]:39663 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0nra-0001Yi-HZ for submit <at> debbugs.gnu.org; Thu, 12 Mar 2026 17:46:39 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8462) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w0nrX-0001Xi-JT for 80574 <at> debbugs.gnu.org; Thu, 12 Mar 2026 17:46:36 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 30F59442BF4; Thu, 12 Mar 2026 17:46:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773351988; bh=YFdj3KsdTGI6Z1VwOq+3y5BbDS4n18chzWPywFxhmYI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QUQmQJZRFoIwCV6xDI30nTcdNYCVNF4RLbVNSEHFlDZgFjOc4QJrm7WGUh0w7Wdtn yWpW0LyzhMgVkQ4qnrcenIIiRefnkp38PSG+RzI2Rx4MOtvkAS29my6Zl2Lo0NLw3V vLzrGW7/YUzQoNJYTImTyqd/bw+eQysGNc3GgjdE3cqEAyR2RBNDqiePdEe2OWdigg 2jMuPHLGXfjUaJ+l/v+0JbqPOpEjWiNQTv+g9I8aCvFMFXof/dAErX5VwApj3Cv+ng XNWJuiFtKYjvK6bNu/V62anLMhSOKCL7xI3tsb5lBOJenwpJJ36uKLNVVbhxkeGmJc eMFccBPPf2q3g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E56B7442BF0; Thu, 12 Mar 2026 17:46:28 -0400 (EDT) Received: from alfajor (unknown [23.233.149.155]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C9C56120CF7; Thu, 12 Mar 2026 17:46:28 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <86qzppebr9.fsf@HIDDEN> Message-ID: <jwv4imkpwfs.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <86qzppebr9.fsf@HIDDEN> Date: Thu, 12 Mar 2026 17:46:27 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.199 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> It removes support for `read-symbol-shorthands` from `intern` and >> friends, and instead provides new functions in `shorthands.el` >> (`shorthands-intern`, `shorthands-unintern`, `shorthands-intern-soft`, >> as well as functions `shorthands-of-symbol` and `shorthands-to-longhand` >> to convert to/from the shorthand form) for those cases where the callers >> do want to take `read-symbol-shorthands` into account. >> >> [ I'm far from convinced `shorthands-unintern` is any use, but I included >> it for completeness's sake. ] >> >> If there's no objection, I intend to install it into `master` in a few >> days (after adding etc/NEWS entry and adjusting the Texinfo doc). > > Please describe the effects of this, From the user's point of view there should hopefully be no visible effect. For Emacs developers it means the behavior of `intern` reverts to that of Emacs<28. So any code which uses `intern` where the argument is expected to be (constructed based on) a string extracted from an ELisp-mode buffer will need to be updated to use `shorthands-intern` instead. > and preferably also the rationale. A lot of existing ELisp code which uses `intern` was written before Emacs-28 and passes it an argument that is not constructed from the contents of an ELisp-mode buffer. I'm thinking of code like eshell computing `eshell/COMMAND`. That kind of code has been "broken" by the new `read-symbol-shorthands`. It's difficult to find such code because the breakage almost never shows up (e.g. for the above you'd need to run the code in a buffer that has set a `read-symbol-shorthands` prefix of something like "esh" which is very rare). So I think the change was a mistake in Emacs-28 and my patch reverts it to be safer because it's much easier to notice "how this thing doesn't understand the new shorthands feature" and ask for a fix. > In particular, I wonder when Lisp programs should call > intern/intern-soft and when their shorthands-* variants? The value of `read-symbol-shorthands` should apply to ELisp symbols extracted from the buffer that has that value and nowhere else. So, you should use the `shorthands-*` variant if the string you pass is one that was found in a buffer that has that same `read-symbol-shorthands` value. And you should straight `intern` if the string you pass was constructed from names that don't come from a buffer or that come from a buffer unrelated to ELisp code. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 12 Mar 2026 10:22:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 12 06:22:51 2026
Received: from localhost ([127.0.0.1]:33489 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w0dBn-0005rO-MU
for submit <at> debbugs.gnu.org; Thu, 12 Mar 2026 06:22:50 -0400
Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:44231)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>)
id 1w0dBj-0005qT-Hs
for 80574 <at> debbugs.gnu.org; Thu, 12 Mar 2026 06:22:45 -0400
Received: by mail-wm1-x32d.google.com with SMTP id
5b1f17b1804b1-4853c3c2fe7so4282645e9.0
for <80574 <at> debbugs.gnu.org>; Thu, 12 Mar 2026 03:22:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1773310961; x=1773915761; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=vRS0cYi2AZi9i72Vh5+Me2wBc1scsSUr/TLn03UbNHw=;
b=Ne1olYazclexV7jKvDqkPNmA2kW97sdTE6ne5HzAmJi8dCRZvyw2KSaCGh/sEpsNZ6
5BgoEWTbjJv2TnFLf0nm9z+MxXjOArYc5biMTcUnvGW5COew4dBvpOIOPsrMSAU842XI
aZGRcKb4+P6fUVkbSdeLXX8/jUo2Jh9TyMrqqNzSccekx7mvRX0+UEYf2U/QWa+X6TRG
b3jseSlD0J8uoZEZpU5m0I7UAykO9+kVPYIC8te9ppb6HteoGgC2yQyjeunLzq/owBsB
RRctUzvNeCdIiylLvIAk6ceu3y/7wz682m7620iypu11jAvrPx5nD16+Vo+IaMgMxCfx
3H3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1773310961; x=1773915761;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=vRS0cYi2AZi9i72Vh5+Me2wBc1scsSUr/TLn03UbNHw=;
b=SpTHgAA/OWbKpUw8jyQ1cfKpyJBQapQod+C4fTjkagJcrEFq7stxiosUXAtN+1DePz
zo/Zv/JqUgnLWuhjaImIKIhA1r8Nlx4Ot8okBEucmqD2JI7319ANLOK55DQDs0X2HcZq
6cuPO6UmfBbBRmDvnMnJqd0Zk7DuCoOhdXBV+XoVdi5zTDI1pIiZz+uPRF8WJAxSvHNw
k3+6z9KMSc6/dV09GfncXE+JIglg15YYVcsTVMNZRO8CuZmY4Vhkq4gvK5m5DG3ov6JK
VQ3fCAKfjp35hwxTNDiLYFgbjCZcv0Ue0gW0DhG/2Ihw5/FEp3txtH7GZWrJMsYzRrNM
qsbw==
X-Gm-Message-State: AOJu0YyXD8QNWDA8ucm9nRpj/dTu9vrJM9vL//aNs3TyH55oxFJfLBmx
k7H/vtginCohf3HazfmfipLQtNdUeq4eeL2rcPdM6mXcFEJyVAcp1O36sYq8JQ==
X-Gm-Gg: ATEYQzxljDrW8UDiGHPjMsMIdvoWvZZuJKrizZOnfICQAS+dY12atG/W6/7i3eus9+o
6nqLw1o6EEUWId75CXSnF5ut/oTwKJ9D+DEEDoXJHcCfrBoE9OLZLnOF0T1LdBDxKnvyLmWD6+I
sxm3jcfbhU5L178CGSxs9lJXUJJPIExdcjrfzsc0GyD2UixuVHeDpCepgOyaDrcCXVgeC3ZL59V
bHrreLpV8UtzusFk5fUS8n1spaERQBL3loP37qZ9x5vT0UrXlkbYPFoXBK1QF9t5BU4KqENk1GI
ATGnsHiakpMAkkPWqOezBG+NL6NgRKREwyMf+1ABLT1+HM32hfC0qvXmBIZduLhJRcon/3sJSsP
fG5HrgdwfPzkKNPADLj1weVHkrLsp3p8Ez2fJ0AE2ZC3uOMOGO752K0lugLBqH4zRxo/MtxBaqe
TOsybUytwtkaVk8nCnlKhxoTgSnGXd5SGOmJFMePy3b8IKVQTzTL94tHoZ0HLqWp9GeQnDoEhAA
DJJ/iQTqhyHoGyUdduct0e1E2I=
X-Received: by 2002:a05:600c:1da1:b0:485:3fe6:21f5 with SMTP id
5b1f17b1804b1-4854b0be6bamr104902565e9.10.1773310960617;
Thu, 12 Mar 2026 03:22:40 -0700 (PDT)
Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-4854a2eea84sm70348215e9.1.2026.03.12.03.22.39
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 12 Mar 2026 03:22:40 -0700 (PDT)
From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <jwv8qbxu7lc.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
<jwveclpu8dp.fsf-monnier+emacs@HIDDEN>
<CALDnm52fPCfSo7LDHLB-7HZkpaukLuv_+DoDaeNa9+vdQVb+pQ@HIDDEN>
<jwv8qbxu7lc.fsf-monnier+emacs@HIDDEN>
Date: Thu, 12 Mar 2026 10:22:46 +0000
Message-ID: <87wlzh8hzd.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80574
Cc: 80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
Stefan Monnier <monnier@HIDDEN> writes:
>> Have you tested completion, eldoc, font-lock, xref, C-h f, o, v, etc? Not
>> sure I'm forgetting anything...
>
> Seemed to work as well as before, yes (haven't tried to fix the lack of s=
upport
> for shorthands in the `C-h f/o/v` links to the source).
OK, so here's my feedback. Without having looked at the patch it seems
clear you've bisectioned the uses of intern and intern-soft in Emacs.git
into two groups:
1) Elisp tooling uses, where you do want to be aware of file-local
shorthands.
2) Non-elisp tooling uses, where intern is used for hash table
replacement purposes, like to make pseudo-generic functinos. As I've
argued before, these are code smells.
IMHO this is the hardest part of the job done.=20=20
So the current approach of changing the calls of 1 "sanctions" the
smells of 2, in a way. But there are as of now no known reports of
breakage related to either 1 or 2, (i.e. this is a preventive patch).
I think there's no good reason to assume that the possible 1-related
tooling-related breakage you now want to introduce with your
shorthand-intern patch is any less likely/serious than the any
hypothesized 2-related smell-related breakage already out there.
So why not replace all the uses of 2 with the form of 'intern' that
takes 'obarray' as an explicit second argument where shorthands are not
considered, as you previously proposed?
This would be a more entensive patch, but trivially so (always pass
'obarray' to any intern calls) but with less changes to the
documentation, and in my opinion much in line with what 'intern' should
be used for, which is to reflect on Elisp language constructs.
Furthermore, and moving forward, replacing the code-smell uses of
'intern' with cleaner, faster, more well documented generic functions or
hash tables is a chiefly mechanical exercise that in this age of LLMs is
relatively cheap. After my sig, find some patches for vc/*.el files
done in 10 minutes by a popular LLM. They look mostly good to me.
Jo=C3=A3o
commit 731e33fbaa2b0d790c3208055c298bd4d1d9fcb0
Author: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
Date: Thu Mar 12 10:01:14 2026 +0000
Replace vc--error-regexp-alist pseudo-generic dispatch (bug#80574)
=20=20=20=20
Replace the 'vc-make-backend-sym'+'boundp'+'symbol-value' pattern
for looking up 'vc-BACKEND-error-regexp-alist' with proper
'cl-defgeneric' and 'cl-defmethod' forms. Also promote 'cl-lib'
from 'eval-when-compile' to a runtime require in vc-dispatcher.el,
since functions like 'cl-print-string-length' and 'cl-prin1' are
already used at runtime there.
=20=20=20=20
* lisp/vc/vc-dispatcher.el: Require 'cl-lib' at runtime.
(vc--error-regexp-alist): New cl-defgeneric.
(vc-compilation-mode): Use 'vc--error-regexp-alist' via
'condition-case' instead of 'vc-make-backend-sym'.
=20=20=20=20
* lisp/vc/vc-git.el (vc--error-regexp-alist): New cl-defmethod
specializing on '(eql Git)'.
=20=20=20=20
* lisp/vc/vc-hg.el (vc--error-regexp-alist): New cl-defmethod
specializing on '(eql Hg)'.
=20=20=20=20
* lisp/vc/vc-bzr.el (vc--error-regexp-alist): New cl-defmethod
specializing on '(eql Bzr)'.
diff --git a/lisp/vc/vc-bzr.el b/lisp/vc/vc-bzr.el
index 1be1f6db7f4..aced3f09105 100644
--- a/lisp/vc/vc-bzr.el
+++ b/lisp/vc/vc-bzr.el
@@ -348,6 +348,9 @@ vc-bzr-error-regexp-alist
("^Using saved parent location: \\(.+\\)" 1 nil nil 0))
"Value of `compilation-error-regexp-alist' in *vc-bzr* buffers.")
=20
+(cl-defmethod vc--error-regexp-alist ((_backend (eql Bzr)))
+ vc-bzr-error-regexp-alist)
+
;; To be called via vc-pull from vc.el, which requires vc-dispatcher.
(declare-function vc-exec-after "vc-dispatcher" (code &optional okstatus p=
roc))
(declare-function vc-set-async-update "vc-dispatcher" (process-buffer))
diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el
index f8118b1babc..fd51f7cdee2 100644
--- a/lisp/vc/vc-dispatcher.el
+++ b/lisp/vc/vc-dispatcher.el
@@ -106,10 +106,13 @@
=20
;;; Code:
=20
+(require 'cl-lib)
(eval-when-compile
- (require 'cl-lib)
(require 'cl-print))
=20
+(cl-defgeneric vc--error-regexp-alist (backend)
+ "Return the error-regexp alist for BACKEND, or nil if none.")
+
;; General customization
=20
(defcustom vc-logentry-check-hook nil
@@ -665,9 +668,9 @@ vc-compilation-mode
Sets `compilation-error-regexp-alist' in accordance with the VC backend."
(delay-mode-hooks
(let* ((error-regexp-alist
- (vc-make-backend-sym backend 'error-regexp-alist))
- (error-regexp-alist (and (boundp error-regexp-alist)
- (symbol-value error-regexp-alist))))
+ (condition-case nil
+ (vc--error-regexp-alist backend)
+ (cl-no-applicable-method nil))))
(let ((compilation-error-regexp-alist error-regexp-alist))
(compilation-mode)
(setq mode-name "VC-Compilation"
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index bc9ebec8c8d..36347801ea8 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -1654,6 +1654,9 @@ vc-git-error-regexp-alist
'(("^ \\(.+\\)\\> *|" 1 nil nil 0))
"Value of `compilation-error-regexp-alist' in *vc-git* buffers.")
=20
+(cl-defmethod vc--error-regexp-alist ((_backend (eql Git)))
+ vc-git-error-regexp-alist)
+
;; To be called via vc-pull from vc.el, which requires vc-dispatcher.
(declare-function vc-compilation-mode "vc-dispatcher" (backend))
(defvar compilation-directory)
diff --git a/lisp/vc/vc-hg.el b/lisp/vc/vc-hg.el
index d671caa23db..a88cde8e33f 100644
--- a/lisp/vc/vc-hg.el
+++ b/lisp/vc/vc-hg.el
@@ -1589,6 +1589,9 @@ vc-hg-error-regexp-alist
'(("^M \\(.+\\)" 1 nil nil 0))
"Value of `compilation-error-regexp-alist' in *vc-hg* buffers.")
=20
+(cl-defmethod vc--error-regexp-alist ((_backend (eql Hg)))
+ vc-hg-error-regexp-alist)
+
(autoload 'vc-do-async-command "vc-dispatcher")
(autoload 'log-view-get-marked "log-view")
(defvar compilation-directory)
commit aaed0703edfe247cb257c4ff515ac929b94d5b92
Author: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
Date: Thu Mar 12 09:51:41 2026 +0000
Replace vc-dir pseudo-generic dispatch with cl-defgeneric (bug#80574)
=20=20=20=20
Replace the 'intern-soft'+'funcall' dispatch on 'vc-dir-%s-mode'
with a proper 'cl-defgeneric'. Since the original used 'intern-soft'
to silently do nothing for backends without a mode, the call site
catches 'cl-no-applicable-method' to preserve that semantics.
=20=20=20=20
* lisp/vc/vc-dir.el (vc-dir--activate-backend): New cl-defgeneric.
(vc-dir): Call 'vc-dir--activate-backend' via 'condition-case'
instead of 'intern-soft'+'funcall'.
=20=20=20=20
* lisp/vc/vc-git.el (vc-dir--activate-backend): New cl-defmethod
specializing on '(eql Git)', replacing the implicit 'vc-dir-git-mode'
activation via the old 'vc-dir-%s-mode' naming convention.
diff --git a/lisp/vc/vc-dir.el b/lisp/vc/vc-dir.el
index 87f4a55850c..92c2604e870 100644
--- a/lisp/vc/vc-dir.el
+++ b/lisp/vc/vc-dir.el
@@ -48,6 +48,11 @@
=20
(declare-function fileloop-continue "fileloop")
=20
+(cl-defgeneric vc-dir--activate-backend (backend)
+ "Activate backend-specific features in a `vc-dir-mode' buffer.
+Called after `vc-dir-mode' is set up. Backends that provide
+extra UI (e.g. a minor mode) should specialize this.")
+
(defcustom vc-dir-mode-hook nil
"Normal hook run by `vc-dir-mode'.
See `run-hooks'."
@@ -1660,11 +1665,10 @@ vc-dir
;; FIXME: find a better way to pass the backend to `vc-dir-mode'.
(let ((use-vc-backend backend))
(vc-dir-mode)
- ;; Activate the backend-specific minor mode, if any.
- (when-let* ((minor-mode
- (intern-soft (format "vc-dir-%s-mode"
- (downcase (symbol-name backend))))=
))
- (funcall minor-mode 1)))))
+ ;; Activate any backend-specific features.
+ (condition-case nil
+ (vc-dir--activate-backend backend)
+ (cl-no-applicable-method nil)))))
=20
(defun vc-default-dir-extra-headers (_backend _dir)
;; Be loud by default to remind people to add code to display
diff --git a/lisp/vc/vc-git.el b/lisp/vc/vc-git.el
index b238afcd127..bc9ebec8c8d 100644
--- a/lisp/vc/vc-git.el
+++ b/lisp/vc/vc-git.el
@@ -3035,6 +3035,9 @@ vc-dir-git-mode
\"Stash\" section at the head of the buffer."
:lighter " Git")
=20
+(cl-defmethod vc-dir--activate-backend ((_backend (eql Git)))
+ (vc-dir-git-mode 1))
+
(provide 'vc-git)
=20
;;; vc-git.el ends here
commit 37ef75a84ef85ad0a56a29d37e259b7154e2d30e
Author: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
Date: Thu Mar 12 09:42:39 2026 +0000
Replace ediff pseudo-generic dispatch with cl-defgeneric (bug#80574)
=20=20=20=20
Replace two pseudo-generic functions that dispatched via
'(funcall (intern (format "ediff-%S-{internal,merge-internal}"
ediff-version-control-package)))' with proper 'cl-defgeneric'
and 'cl-defmethod' forms.
=20=20=20=20
* lisp/vc/ediff-vers.el: Require 'cl-generic'.
(ediff-vc-internal, ediff-rcs-internal): Replace with
cl-defgeneric 'ediff--vc' and cl-defmethod specializations
on '(eql vc)' and '(eql rcs)'.
(ediff-vc-merge-internal, ediff-rcs-merge-internal): Replace with
cl-defgeneric 'ediff--vc-merge' and cl-defmethod specializations
on '(eql vc)' and '(eql rcs)'.
=20=20=20=20
* lisp/vc/ediff.el: Declare 'ediff--vc' and 'ediff--vc-merge'.
(ediff-merge-revisions, ediff-merge-revisions-with-ancestor)
(ediff-revision): Call 'ediff--vc-merge' and 'ediff--vc' directly
instead of via 'funcall'+'intern'+'format'.
diff --git a/lisp/vc/ediff-vers.el b/lisp/vc/ediff-vers.el
index b11c700ece8..6d548e23f56 100644
--- a/lisp/vc/ediff-vers.el
+++ b/lisp/vc/ediff-vers.el
@@ -25,6 +25,7 @@
;;; Code:
=20
(eval-when-compile (require 'ediff-init))
+(require 'cl-generic)
=20
(defvar rcs-default-co-switches)
=20
@@ -60,7 +61,12 @@ ediff-vc-latest-version
=20
(defvar vc-find-revision-no-save)
=20
-(defun ediff-vc-internal (rev1 rev2 &optional startup-hooks)
+(cl-defgeneric ediff--vc (pkg rev1 rev2 startup-hooks)
+ "Run Ediff on revisions REV1 and REV2 of the current buffer's file.
+PKG is the version control package symbol, e.g., `vc' or `rcs'.
+STARTUP-HOOKS is a list of functions called after setting up Ediff buffers=
.")
+
+(cl-defmethod ediff--vc ((_pkg (eql vc)) rev1 rev2 startup-hooks)
;; Run Ediff on versions of the current buffer.
;; If REV1 is "", use the latest version of the current buffer's file.
;; If REV2 is "" then compare current buffer with REV1.
@@ -120,7 +126,7 @@ ediff-rcs-get-output-buffer
(erase-buffer))
buf))
=20
-(defun ediff-rcs-internal (rev1 rev2 &optional startup-hooks)
+(cl-defmethod ediff--vc ((_pkg (eql rcs)) rev1 rev2 startup-hooks)
;; Run Ediff on versions of the current buffer.
;; If REV2 is "" then use current buffer.
(let (rev2buf rev1buf)
@@ -132,13 +138,19 @@ ediff-rcs-internal
=20
;; rcs.el doesn't create temp version files, so we don't have to delete
;; anything in startup hooks to ediff-buffers
- (ediff-buffers rev1buf rev2buf startup-hooks 'ediff-revision)
- ))
+ (ediff-buffers rev1buf rev2buf startup-hooks 'ediff-revision)))
=20
;;; Merge with Version Control
=20
-(defun ediff-vc-merge-internal (rev1 rev2 ancestor-rev
- &optional startup-hooks merge-buffer-file)
+(cl-defgeneric ediff--vc-merge (pkg rev1 rev2 ancestor-rev
+ startup-hooks merge-buffer-file)
+ "Merge revisions REV1 and REV2 of the current buffer's file using PKG.
+PKG is the version control package symbol, e.g., `vc' or `rcs'.
+If ANCESTOR-REV is non-nil, merge with that ancestor revision.
+STARTUP-HOOKS and MERGE-BUFFER-FILE are passed to the merge function.")
+
+(cl-defmethod ediff--vc-merge ((_pkg (eql vc)) rev1 rev2 ancestor-rev
+ startup-hooks merge-buffer-file)
;; If ANCESTOR-REV non-nil, merge with ancestor
(let ((vc-find-revision-no-save t)
buf1 buf2 ancestor-buf)
@@ -162,12 +174,10 @@ ediff-vc-merge-internal
buf1 buf2 ancestor-buf
startup-hooks 'ediff-merge-revisions-with-ancestor merge-buffer-file)
(ediff-merge-buffers
- buf1 buf2 startup-hooks 'ediff-merge-revisions merge-buffer-file))
- ))
+ buf1 buf2 startup-hooks 'ediff-merge-revisions merge-buffer-file))))
=20
-(defun ediff-rcs-merge-internal (rev1 rev2 ancestor-rev
- &optional
- startup-hooks merge-buffer-file)
+(cl-defmethod ediff--vc-merge ((_pkg (eql rcs)) rev1 rev2 ancestor-rev
+ startup-hooks merge-buffer-file)
;; If ANCESTOR-REV non-nil, merge with ancestor
(let (buf1 buf2 ancestor-buf)
(save-window-excursion
diff --git a/lisp/vc/ediff.el b/lisp/vc/ediff.el
index 2f472435105..44e8a32b95a 100644
--- a/lisp/vc/ediff.el
+++ b/lisp/vc/ediff.el
@@ -109,6 +109,11 @@ ediff-version
(require 'ediff-init)
(require 'ediff-mult) ; required because of the registry stuff
=20
+(declare-function ediff--vc "ediff-vers"
+ (pkg rev1 rev2 startup-hooks))
+(declare-function ediff--vc-merge "ediff-vers"
+ (pkg rev1 rev2 ancestor-rev startup-hooks merge-buffer-f=
ile))
+
(defgroup ediff nil
"Comprehensive visual interface to `diff' and `patch'."
:tag "Ediff"
@@ -1357,9 +1362,8 @@ ediff-merge-revisions
"current buffer"))))
(ediff-load-version-control)
;; ancestor-revision=3Dnil
- (funcall
- (intern (format "ediff-%S-merge-internal" ediff-version-control-packa=
ge))
- rev1 rev2 nil startup-hooks merge-buffer-file)))
+ (ediff--vc-merge ediff-version-control-package
+ rev1 rev2 nil startup-hooks merge-buffer-file)))
=20
=20
;;;###autoload
@@ -1401,9 +1405,8 @@ ediff-merge-revisions-with-ancestor
"current buffer")
"'s base revision"))))
(ediff-load-version-control)
- (funcall
- (intern (format "ediff-%S-merge-internal" ediff-version-control-packa=
ge))
- rev1 rev2 ancestor-rev startup-hooks merge-buffer-file)))
+ (ediff--vc-merge ediff-version-control-package
+ rev1 rev2 ancestor-rev startup-hooks merge-buffer-fil=
e)))
=20
;;; Apply patch
(defvar ediff-last-dir-patch)
@@ -1508,10 +1511,7 @@ ediff-revision
(concat (file-name-nondirectory file)
"'s current state"))))
(ediff-load-version-control)
- (funcall
- (intern (format "ediff-%S-internal" ediff-version-control-package))
- rev1 rev2 startup-hooks)
- ))
+ (ediff--vc ediff-version-control-package rev1 rev2 startup-hooks)))
=20
=20
;;;###autoload
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 12 Mar 2026 07:41:12 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 12 03:41:12 2026 Received: from localhost ([127.0.0.1]:60716 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0afO-0005B9-Lx for submit <at> debbugs.gnu.org; Thu, 12 Mar 2026 03:41:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41612) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1w0afL-00059g-FT for 80574 <at> debbugs.gnu.org; Thu, 12 Mar 2026 03:41:08 -0400 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 <eliz@HIDDEN>) id 1w0afF-0005cw-GD; Thu, 12 Mar 2026 03:41:01 -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=WYS3yh3t75KzwB8ymX+/b0mqc3z3wi7MlFqZrJFnXDY=; b=D6tWwhet/496 GN4ssVtkXtxyLcvkwyXbYukHjQX2RaDnozFzN/CbTNaFlrC54lRqV3hVhTNV0Fflt4An9j5xdu+ou FetUJoJE0gosAY2MmW+9qJQnq2l/T6Jq6JWyo9x44HYACzZDxnigGXyg23Hp+bWEvyJMv9CMmqKRe FgDSaJQl0bLJbTG9HqXkrMMCD1P0l9qkeuu1m+JLdzYbtFistrWjcILcSHp6i7+X76c20bjDD41KI oSqfM0/q2hZDVQqIb5DLU0SkqM2xVhVjwafVQnEF/sAVG1dOntQgT90i5AYCgsZKRW/ucSq8hvUh9 u8m1Q0vNMVAk1SrLtr9dEg==; Date: Thu, 12 Mar 2026 09:40:42 +0200 Message-Id: <86qzppebr9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org, joaotavora@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Wed, 11 Mar 2026 21:55:03 -0400 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > See below a proposed patch. > > It removes support for `read-symbol-shorthands` from `intern` and > friends, and instead provides new functions in `shorthands.el` > (`shorthands-intern`, `shorthands-unintern`, `shorthands-intern-soft`, > as well as functions `shorthands-of-symbol` and `shorthands-to-longhand` > to convert to/from the shorthand form) for those cases where the callers > do want to take `read-symbol-shorthands` into account. > > [ I'm far from convinced `shorthands-unintern` is any use, but I included > it for completeness's sake. ] > > If there's no objection, I intend to install it into `master` in a few > days (after adding etc/NEWS entry and adjusting the Texinfo doc). Please describe the effects of this, and preferably also the rationale. It's not easy to discuss such a change without a good understanding of its effects. And the Subject line talks about something which sounds tangential at best. In particular, I wonder when Lisp programs should call intern/intern-soft and when their shorthands-* variants?
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 12 Mar 2026 02:05:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 22:05:08 2026 Received: from localhost ([127.0.0.1]:57356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0VQC-0006s9-6C for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 22:05:08 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16593) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1w0VQ9-0006qg-4R for 80574 <at> debbugs.gnu.org; Wed, 11 Mar 2026 22:05:05 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 737BE442B80; Wed, 11 Mar 2026 22:04:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773281098; bh=qks8Z5vUqbGZigS71PintXqogFN43mKsOzP2078HeAA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mw+bGtjTG5FfelwE9EgrcqRKQNv/FsGhJmwb2xmiNPjhkHR3h6kVutnzlp8GHZULZ OpeawjOIYr0OzHr/OJv2FrbTw6s2Z5cD1bxtIZOHSgUqm6H+IDJE4VWZufB9RdFIbK H8EV7hB/NuAYfGGi2aehNWqQE+4Z5mvJcsErHCsqrwqTJPbSlr5Yx51FEiIxRgnrV2 y1N3OLgsugV++RYXaqRMCYWXZBMQI1uk7Mnk+G7HVJinBBqZA4PiQLF4/7n4zqNKta zt01zxZqhFhbEaeU9j4imIXu6AM6gPYQE9ZRds5pySTBX1RLVv1XOrI1mMnI5l8Jxk dsmXdqY8/FoqQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 62AB3442B71; Wed, 11 Mar 2026 22:04:58 -0400 (EDT) Received: from alfajor (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 37E86120497; Wed, 11 Mar 2026 22:04:58 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <CALDnm52fPCfSo7LDHLB-7HZkpaukLuv_+DoDaeNa9+vdQVb+pQ@HIDDEN> Message-ID: <jwv8qbxu7lc.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> <CALDnm52fPCfSo7LDHLB-7HZkpaukLuv_+DoDaeNa9+vdQVb+pQ@HIDDEN> Date: Wed, 11 Mar 2026 22:04:57 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.080 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > Have you tested completion, eldoc, font-lock, xref, C-h f, o, v, etc? Not > sure I'm forgetting anything... Seemed to work as well as before, yes (haven't tried to fix the lack of support for shorthands in the `C-h f/o/v` links to the source). === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 12 Mar 2026 01:59:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 21:59:45 2026 Received: from localhost ([127.0.0.1]:57286 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1w0VKy-00060O-Fk for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 21:59:45 -0400 Received: from mail-oa1-x33.google.com ([2001:4860:4864:20::33]:61817) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1w0VKw-0005zu-7S for 80574 <at> debbugs.gnu.org; Wed, 11 Mar 2026 21:59:43 -0400 Received: by mail-oa1-x33.google.com with SMTP id 586e51a60fabf-41576c5c01cso345146fac.3 for <80574 <at> debbugs.gnu.org>; Wed, 11 Mar 2026 18:59:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1773280781; cv=none; d=google.com; s=arc-20240605; b=h7jeqNZjOnYX20smv1HIPj26WbrIfJqprJ8NhNhOGizuy5UfcY6hR7tZeXuKFLNqT/ E3/Kx++iBtsuYvGdALwrP0m/yfmpBchKy7b0myQ3uEEQwZtHxSqVvukQujkWW0oMzIYY l+IF6kLkVX8qJeRyklMsFFzDE2odKQO7655USRgMp3NCPiL3Td3Qw2vVU00J3rW/whVp MzIz6Om6kTGnd4m+nqZPvOZZcHvrOrxmXreFoQtXf+vtHRjaNlB59qExd5loThKie1mO bQqAOVO/Ph5Zz6eyeZZC4EDV/u9Aeawg0aTsKXX+C1Pfy+W84YzI2/fPscAS2pjYek1j Dr4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=IhAUqVV1emP1yww0bIa3woaNj0gvPUk3Brto0s6gU50=; fh=aYnkDSEJUwrvYj2fkyqW6mo6HB5+zSMX+/KrXbhYjjw=; b=V5SPTKGzDbb4CLaeGdWkV5redArcVT5iSUs81UcVaLgufntHB5SaGPWMx7kgAERVox JXRITuJPXxD5EdLjomPyR2Vq5qMMfVofyDGDAA/0a5We8+o7KW2J70yaoYlzg11bPXkB f4iUOaWD6mXeIxAHil6xe6zUc25cXedxkzWoNF7SuyBGwb+tDaZICTkjmvDXSZ3ujXkv z4QZ2JmPCXxXdDQvD0Bl3YcQFvNnIAeWvVX81n+GE247RnHi4fFlUJY+PqHP7S0sJA5F zB0PbRm0CyAbC/IFZv+O9aR4ECcKPsWxPlzrYWnnkoE7RLUrBDllocotS5XhvNXxRxP7 /UcA==; darn=debbugs.gnu.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773280781; x=1773885581; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IhAUqVV1emP1yww0bIa3woaNj0gvPUk3Brto0s6gU50=; b=fKDJUyPPVgRprziZRsPp1SeKhFDHXwoaS3jBK8tasZIhen1nwVgqWz/3BkJBmKMndT lTIorSyfnyuJZtPmrqyyzSkybN2O3DIgsmuvLlkDymH1MTiZ04e0eNhw9Iu538qnVxHM RB2CQ7LIMrXdk+rQKZhm5Jl3z8VW+DS9U3aTFV28db36wUClpAUOf2xxBuefOUjzUZra sE9Tp3Fhk6X+qBif6SF+mjQZniqmuGrafcmxf6cuyFgsVxld/MSwmMsfS8OQKdG6sM+p 61OkZdLLH6lhXcfnPckEkW3V13H/cAqe9cZLK5OysUDsV4RxSgl2g+Dw0e6W5nZLQFAI 4nnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773280781; x=1773885581; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IhAUqVV1emP1yww0bIa3woaNj0gvPUk3Brto0s6gU50=; b=Tldc3yvNa9U+QNB/AN5e0Jq7OJVr8a8zmQWBhsNkoc1FMOmk0r3A7c0+pe/SCf1tSG 5PofBazuUtnErtISN1Yg0wkSpTStLkp+Rt18YvelWHTWYvm9zy2122xRA2a7W/yDnFJy LKlohaimhQIbMe2Vc3p0RmdQygnK9K6W/sU/YesFGnJWAw58FCvrAkh26+Nar7B8Ipuw JesOPFqAdi5rpQ9YlE78TQePMf2WI3S3N9T0FsOayQfN6SGWEQBe0nj8QVh2FPq/Sz3o RxXye3AqCleJ6vy4BDBpp+mFioiXk405BM8nF20rjzXQOfGo+1hEQVyfqEgHPNIJKiOA JrAw== X-Gm-Message-State: AOJu0Yw/XFVnqjsmx8Eb/AyW66pYQ+rpmb5ykXZPQozp5D8Yzu7rindM 4GKeoabcd5B2+R4SWvOIw2Q73VY4kqXtX8p6rIOOwQUZ1KI2maUEw82wkiAcyWrZz7jkHx/9owG tgMl6QY6mayMq7BdOeUuSIef7fL9EK/c= X-Gm-Gg: ATEYQzyW70byqCJDZRMEYcZFrs3VZzTGbI4yp5maVPVuRjYpThBhWFWiN6D1oF+B/DB 61LDsxnFT4adARiaAj8LMuz/sDkPxYNViXE4hZbroDFaH7/hmuy13ev+6vspNbpQjyU+EcKb1Rq vVjPpiBRJwnwIKeDSSt2REmTVpsYdhAq9bCuhlu/cRnY60oRmrpGixwvVHr9LJPadMoufvtt62w 8Furmgge+SO+k3L4P/GgnYvp731Zmj3qzGWtW/fivYqmhJgvmrGFL86wf02N9vmxAzYJ7XxbmkE qnQlzV520cef7GdIVibzh41VTDmFbe0D1mCVZKTd9P8OhcbsvVpQJIkbPMC/LBsfQUM= X-Received: by 2002:a05:6871:7c12:b0:404:1250:1c1f with SMTP id 586e51a60fabf-4177c6ec5d9mr2689959fac.5.1773280781187; Wed, 11 Mar 2026 18:59:41 -0700 (PDT) MIME-Version: 1.0 References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN> <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> In-Reply-To: <jwveclpu8dp.fsf-monnier+emacs@HIDDEN> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> Date: Thu, 12 Mar 2026 01:59:30 +0000 X-Gm-Features: AaiRm53sO7WXNzJm4dtafL4KrNIRRo2BNCxe6M6ODIALLrgcb5_OGOiEiL4lhnI Message-ID: <CALDnm52fPCfSo7LDHLB-7HZkpaukLuv_+DoDaeNa9+vdQVb+pQ@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer To: Stefan Monnier <monnier@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000000cc139064cca1bc4" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) --0000000000000cc139064cca1bc4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Have you tested completion, eldoc, font-lock, xref, C-h f, o, v, etc? Not sure I'm forgetting anything... Jo=C3=A3o On Thu, Mar 12, 2026, 01:55 Stefan Monnier <monnier@HIDDEN> wrote= : > See below a proposed patch. > > It removes support for `read-symbol-shorthands` from `intern` and > friends, and instead provides new functions in `shorthands.el` > (`shorthands-intern`, `shorthands-unintern`, `shorthands-intern-soft`, > as well as functions `shorthands-of-symbol` and `shorthands-to-longhand` > to convert to/from the shorthand form) for those cases where the callers > do want to take `read-symbol-shorthands` into account. > > [ I'm far from convinced `shorthands-unintern` is any use, but I included > it for completeness's sake. ] > > If there's no objection, I intend to install it into `master` in a few > days (after adding etc/NEWS entry and adjusting the Texinfo doc). > > > =3D=3D=3D Stefan > --0000000000000cc139064cca1bc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Have you tested completion, eldoc, font-lock, xref, = C-h f, o, v, etc? Not sure I'm forgetting anything...</div><div><br></d= iv><div data-smartmail=3D"gmail_signature">Jo=C3=A3o</div></div><br><div cl= ass=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_a= ttr">On Thu, Mar 12, 2026, 01:55 Stefan Monnier <<a href=3D"mailto:monni= er@HIDDEN">monnier@HIDDEN</a>> wrote:<br></div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:= 1px solid rgb(204,204,204);padding-left:1ex">See below a proposed patch.<br= > <br> It removes support for `read-symbol-shorthands` from `intern` and<br> friends, and instead provides new functions in `shorthands.el`<br> (`shorthands-intern`, `shorthands-unintern`, `shorthands-intern-soft`,<br> as well as functions `shorthands-of-symbol` and `shorthands-to-longhand`<br= > to convert to/from the shorthand form) for those cases where the callers<br= > do want to take `read-symbol-shorthands` into account.<br> <br> [ I'm far from convinced `shorthands-unintern` is any use, but I includ= ed<br> =C2=A0 it for completeness's sake.=C2=A0 ]<br> <br> If there's no objection, I intend to install it into `master` in a few<= br> days (after adding etc/NEWS entry and adjusting the Texinfo doc).<br> <br> <br> =3D=3D=3D Stefan<br> </blockquote></div> --0000000000000cc139064cca1bc4--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 12 Mar 2026 01:55:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Mar 11 21:55:25 2026
Received: from localhost ([127.0.0.1]:57220 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1w0VGl-0005Mq-1J
for submit <at> debbugs.gnu.org; Wed, 11 Mar 2026 21:55:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36732)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1w0VGg-0005LG-6g
for 80574 <at> debbugs.gnu.org; Wed, 11 Mar 2026 21:55:20 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8987681A62;
Wed, 11 Mar 2026 21:55:11 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773280504;
bh=coQmhzc8B3vCu7+p9FTsRXtptpJKUS3VfHUilkDcpXI=;
h=From:To:Subject:In-Reply-To:References:Date:From;
b=DQIE00F8rNS0FepIkp0bNTZI3citVNmkJBwOy9FkMvQHupmBq4HE777ByuhbbCnoc
Jv/gsoFQ0fzcepL0feN4pvZKByclj+DOvkre9p2H33lgynAHYuL8UAkKZ1zEVw2Puk
niAz3l7A4Gs4OTU1DVkzs0xVV1C7fOvrcuS80/r9FeMhggsz0QCPLWpahqaiVC5w/z
/UxWo4NRXe5uZfCl5tT+SCdwaypY/4C4nyanYDlTT2qHJ97ZKdusN7uZzj6ZPk5IJH
OY+Q6TtIQUkVPVygi3GW3uqaw5beHFkIydtosmEtoP409YNr78W4Zzp6DKEhD9nBAa
0tYnb/1AMgigw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9424481C24;
Wed, 11 Mar 2026 21:55:04 -0400 (EDT)
Received: from alfajor (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5AE6F120840;
Wed, 11 Mar 2026 21:55:04 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>,
80574 <at> debbugs.gnu.org
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
Message-ID: <jwveclpu8dp.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
<jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN>
<jwvikb4zcte.fsf-monnier+emacs@HIDDEN>
<CALDnm53rduhtqmY7YCaVBvOuS7G9+m7i0F+ZGX4iE+HAf2WHcQ@HIDDEN>
Date: Wed, 11 Mar 2026 21:55:03 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.249 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
--=-=-=
Content-Type: text/plain
See below a proposed patch.
It removes support for `read-symbol-shorthands` from `intern` and
friends, and instead provides new functions in `shorthands.el`
(`shorthands-intern`, `shorthands-unintern`, `shorthands-intern-soft`,
as well as functions `shorthands-of-symbol` and `shorthands-to-longhand`
to convert to/from the shorthand form) for those cases where the callers
do want to take `read-symbol-shorthands` into account.
[ I'm far from convinced `shorthands-unintern` is any use, but I included
it for completeness's sake. ]
If there's no objection, I intend to install it into `master` in a few
days (after adding etc/NEWS entry and adjusting the Texinfo doc).
=== Stefan
--=-=-=
Content-Type: text/x-diff; charset=utf-8
Content-Disposition: inline;
filename=0001-intern-Don-t-obey-read-symbol-shorthands-any-more-bu.patch
Content-Transfer-Encoding: quoted-printable
From 5b867d89873ca90cdc7d597b31977f20fb923cd1 Mon Sep 17 00:00:00 2001
From: Stefan Monnier <monnier@HIDDEN>
Date: Wed, 11 Mar 2026 21:46:10 -0400
Subject: [PATCH] (intern): Don't obey `read-symbol-shorthands` any more
(bug#80574)
* src/lread.c (Fintern, Fintern_soft, Funintern): Don't obey
`read-symbol-shorthands` any more.
* lisp/emacs-lisp/shorthands.el (shorthands-of-symbol): New function,
adapted from `elisp--completion-local-symbols`.
(shorthands-to-longhand, shorthands-intern, shorthands-intern-soft)
(shorthands-unintern): New functions.
(shorthands-font-lock-shorthands): Use `shorthands-intern-soft`.
* lisp/progmodes/elisp-mode.el (elisp-context-menu)
(elisp--company-doc-buffer, elisp--company-doc-string)
(elisp--company-location, elisp--company-kind)
(elisp--company-deprecated, xref-backend-definitions)
(elisp--xref-find-definitions, eval-sexp-add-defvars)
(elisp--current-symbol): Use `shorthands-intern(-soft)`.
(elisp--completion-local-symbols): Delete function.
(elisp--completion-local-symbols): Use `shorthands-of-symbol`.
(elisp--shorthand-aware-boundp): Adjust to the new property used by
`shorthands-of-symbol`.
(elisp-completion-at-point): Use that property as well.
Use `shorthands-intern(-soft)`.
* lisp/minibuffer.el (completion-shorthand-try-completion):
Simplify using `shorthands-to-longhand`.
* test/src/lread-tests.el (lread-unintern):
Use `shorthands-(un)intern(-soft)`.
---
lisp/emacs-lisp/shorthands.el | 58 +++++++++++++++++++++++++++++-
lisp/minibuffer.el | 24 ++++---------
lisp/progmodes/elisp-mode.el | 67 +++++++++++++++--------------------
src/lread.c | 43 +++-------------------
test/src/lread-tests.el | 48 ++++++++++++-------------
5 files changed, 119 insertions(+), 121 deletions(-)
diff --git a/lisp/emacs-lisp/shorthands.el b/lisp/emacs-lisp/shorthands.el
index 9c668bb3720..ca2ae13d571 100644
--- a/lisp/emacs-lisp/shorthands.el
+++ b/lisp/emacs-lisp/shorthands.el
@@ -29,6 +29,62 @@
(require 'files)
(require 'mule)
=20
+(defun shorthands-of-symbol (s)
+ "Return a fresh list of shorthand alternative spellings of S.
+S can be either a string or a symbol.
+Returns a list of uninterned symbols with a `shorthand-longhand' property.
+Uses `read-symbol-shorthands'."
+ (let ((retval ())
+ (full-name (if (symbolp s) (symbol-name s) s)))
+ (dolist (mapping read-symbol-shorthands)
+ (let ((shorthand (car mapping))
+ (longhand (cdr mapping)))
+ (when (string-prefix-p longhand full-name)
+ (let ((sym (make-symbol
+ (concat shorthand
+ (substring full-name
+ (length longhand))))))
+ (put sym 'shorthands-longhand s)
+ (push sym retval)
+ retval))))
+ (nreverse retval)))
+
+(defun shorthands-to-longhand (string)
+ "Return the longhand form of STRING according to `read-symbol-shorthands=
'.
+Returns a string. If no shorthand applies, returns STRING."
+ (let ((mappings read-symbol-shorthands))
+ (while (and mappings (not (string-prefix-p (caar mappings) string)))
+ (setq mappings (cdr mappings)))
+ (if mappings
+ (concat (cdar mappings) (substring string (length (caar mappings))=
))
+ string)))
+
+(defun shorthands-intern (string &optional ob)
+ "`intern' STRING into the obarray OB, obeying `read-symbol-shorthands'."
+ (message "interning %S =3D> %S"
+ string
+ (shorthands-to-longhand string))
+ (intern (shorthands-to-longhand string) ob))
+
+(defun shorthands-intern-soft (string &optional ob)
+ "Return the interned symbol of name STRING in the obarray OB, if any.
+If not found, return nil.
+Contrary to `intern-soft', this obeys `read-symbol-shorthands'."
+ (message "interning-soft %S =3D> %S"
+ string
+ (shorthands-to-longhand string))
+ (intern-soft (shorthands-to-longhand string) ob))
+
+(defun shorthands-unintern (string ob)
+ "`unintern's the symbol of shorthand name STRING in obarray OB.
+Obeys `read-symbol-shorthands'."
+ (unless (obarrayp ob)
+ (signal 'wrong-type-argument (list #'obarrayp ob)))
+ (message "uninterning %S =3D> %S"
+ string
+ (shorthands-to-longhand string))
+ (unintern (shorthands-to-longhand string) ob))
+
(defun hack-read-symbol-shorthands ()
"Compute `read-symbol-shorthands' from Local Variables section."
;; FIXME: relies on the `hack-local-variables--find-variables'
@@ -65,7 +121,7 @@ shorthands-font-lock-shorthands
(print-name (match-string 1))
(probe (and (not (memq existing '(font-lock-comment-face
font-lock-string-face)))
- (intern-soft print-name)))
+ (shorthands-intern-soft print-name)))
(symbol-name (and probe (symbol-name probe)))
(prefix (and symbol-name
(not (string-equal print-name symbol-name))
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 1ac83134dbe..bff214c0dc6 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -5069,24 +5069,12 @@ completion-initials-try-completion
=20
(defun completion-shorthand-try-completion (string table pred point)
"Try completion with `read-symbol-shorthands' of original buffer."
- (cl-loop with expanded
- for (short . long) in
- (with-current-buffer minibuffer--original-buffer
- read-symbol-shorthands)
- for probe =3D
- (and (> point (length short))
- (string-prefix-p short string)
- (try-completion (setq expanded
- (concat long
- (substring
- string
- (length short))))
- table pred))
- when probe
- do (message "Shorthand expansion")
- and return (cons expanded (max (length long)
- (+ (- point (length short))
- (length long))))))
+ (let ((expanded (shorthands-to-longhand string)))
+ (when (and (not (equal expanded string))
+ (try-completion expanded table pred))
+ (message "Shorthand expansion")
+ (cons expanded (+ (- point (length string))
+ (length expanded))))))
=20
(defun completion-shorthand-all-completions (_string _table _pred _point)
;; no-op: For now, we don't want shorthands to list all the possible
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index bb58e7d382a..c2015c78216 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -160,7 +160,8 @@ elisp-context-menu
'middle-separator)
=20
(let* ((string (thing-at-mouse click 'symbol t))
- (symbol (when (stringp string) (intern string)))
+ ;; FIXME: Why don't we know if we receive a string or a symbol?
+ (symbol (when (stringp string) (shorthands-intern string)))
(title (cond
((not (symbolp symbol)) nil)
((and (facep symbol) (not (fboundp symbol)))
@@ -963,7 +964,7 @@ elisp--form-quoted-p
;; the *Completions* buffer.
=20
(defun elisp--company-doc-buffer (str)
- (let ((symbol (intern-soft str)))
+ (let ((symbol (shorthands-intern-soft str)))
;; FIXME: we really don't want to "display-buffer and then undo it".
(save-window-excursion
;; Make sure we don't display it in another frame, otherwise
@@ -980,7 +981,7 @@ elisp--company-doc-buffer
(help-buffer))))))
=20
(defun elisp--company-doc-string (str)
- (let* ((symbol (intern-soft str))
+ (let* ((symbol (shorthands-intern-soft str))
(doc (if (fboundp symbol)
(documentation symbol t)
(documentation-property symbol 'variable-documentation t))=
))
@@ -993,7 +994,7 @@ elisp--company-doc-string
(declare-function find-function-library "find-func" (function &optional l-=
o v))
=20
(defun elisp--company-location (str)
- (let ((sym (intern-soft str)))
+ (let ((sym (shorthands-intern-soft str)))
(cond
((fboundp sym) (find-definition-noselect sym nil))
((boundp sym) (find-definition-noselect sym 'defvar))
@@ -1010,22 +1011,6 @@ obarray-cache
Elisp obarray. If the obarray is modified by any means (such as
interning or uninterning a symbol), this variable is set to nil.")
=20
-(defun elisp--read-symbol-shorthands (s)
- "Return a fresh list of shorthand-ed alternative spellings of symbol S."
- (let ((retval ()))
- (cl-loop
- for (shorthand . longhand) in read-symbol-shorthands
- for full-name =3D (symbol-name s)
- when (string-prefix-p longhand full-name)
- do (let ((sym (make-symbol
- (concat shorthand
- (substring full-name
- (length longhand))))))
- (put sym 'elisp--longhand s)
- (push sym retval)
- retval))
- retval))
-
(defun elisp--completion-local-symbols ()
"Compute collections of all Elisp symbols for completion purposes.
The return value is compatible with the COLLECTION form described
@@ -1035,7 +1020,7 @@ elisp--completion-local-symbols
(mapatoms
(lambda (s)
(setq retval
- (cons s (nconc (elisp--read-symbol-shorthands s)
+ (cons s (nconc (shorthands-of-symbol s)
retval)))))
retval)))
(cond ((null read-symbol-shorthands) obarray)
@@ -1053,10 +1038,10 @@ elisp--completion-local-symbols
obarray-cache)))))
=20
(defun elisp--shorthand-aware-fboundp (sym)
- (fboundp (or (get sym 'elisp--longhand) sym)))
+ (fboundp (or (get sym 'shorthands-longhand) sym)))
=20
(defun elisp--shorthand-aware-boundp (sym)
- (boundp (or (get sym 'elisp--longhand) sym)))
+ (boundp (or (get sym 'shorthands-longhand) sym)))
=20
(defun elisp-completion-at-point ()
"Function used for `completion-at-point-functions' in `emacs-lisp-mode'.
@@ -1125,15 +1110,18 @@ elisp-completion-at-point
(quoted
(list nil (elisp--completion-local-symbols)
;; Don't include all symbols (bug#16646).
- :predicate (lambda (sym)
- ;; shorthand-aware
- (let ((sym (intern-soft (symbol-na=
me sym))))
- (or (boundp sym)
- (fboundp sym)
- (featurep sym)
- (symbol-plist sym))))
+ :predicate
+ (lambda (sym)
+ (let ((sym (or (get sym 'shorthands-longhand)
+ sym)))
+ (or (boundp sym)
+ (fboundp sym)
+ (featurep sym)
+ (symbol-plist sym))))
:annotation-function
- (lambda (str) (if (fboundp (intern-soft str)) "=
<f>"))
+ (lambda (str)
+ (if (fboundp (shorthands-intern-soft str))
+ " <f>"))
:company-kind #'elisp--company-kind
:company-doc-buffer #'elisp--company-doc-buffer
:company-docsig #'elisp--company-doc-string
@@ -1166,8 +1154,9 @@ elisp-completion-at-point
(if (memq (char-syntax c) '(?w ?_=
))
(let ((pt (point)))
(forward-sexp)
- (intern-soft
- (buffer-substring pt (poin=
t))))))))
+ (shorthands-intern-soft
+ (buffer-substring
+ pt (point))))))))
(error nil))))
(pcase parent
;; FIXME: Rather than hardcode special cases here,
@@ -1231,7 +1220,7 @@ elisp-completion-at-point
(cddr table-etc)))))))))
=20
(defun elisp--company-kind (str)
- (let ((sym (intern-soft str)))
+ (let ((sym (shorthands-intern-soft str)))
(cond
((or (macrop sym) (special-form-p sym)) 'keyword)
((fboundp sym) 'function)
@@ -1241,7 +1230,7 @@ elisp--company-kind
(t 'text))))
=20
(defun elisp--company-deprecated (str)
- (let ((sym (intern-soft str)))
+ (let ((sym (shorthands-intern-soft str)))
(or (get sym 'byte-obsolete-variable)
(get sym 'byte-obsolete-info))))
=20
@@ -1450,7 +1439,7 @@ xref-backend-identifier-at-point
=20
(cl-defmethod xref-backend-definitions ((_backend (eql 'elisp)) identifier)
(require 'find-func)
- (let ((sym (intern-soft identifier)))
+ (let ((sym (shorthands-intern-soft identifier)))
(when sym
(let* ((pos (get-text-property 0 'pos identifier))
(namespace (if (and pos
@@ -1555,7 +1544,7 @@ elisp--xref-find-definitions
;; `symbol' is a name for the default constructor created by
;; cl-defstruct, so return the location of the cl-defstruct.
(let* ((type-name (match-string 1 doc))
- (type-symbol (intern type-name))
+ (type-symbol (shorthands-intern type-name))
(file (find-lisp-object-file-name
type-symbol 'define-type))
(summary (format elisp--xref-format-extra
@@ -2028,7 +2017,7 @@ eval-sexp-add-defvars
(while (re-search-forward
"(def\\(?:var\\|const\\|custom\\)[ \t\n]+\\([^; '()\n\t]+\=
\)"
pos t)
- (let ((var (intern (match-string 1))))
+ (let ((var (shorthands-intern (match-string 1))))
(unless (or (special-variable-p var)
(syntax-ppss-toplevel-pos
(save-excursion
@@ -2564,7 +2553,7 @@ elisp--current-symbol
(let ((c (char-after (point))))
(and c
(memq (char-syntax c) '(?w ?_))
- (intern-soft (current-word)))))
+ (shorthands-intern-soft (current-word)))))
=20
(defun elisp-function-argstring (arglist)
"Return ARGLIST as a string enclosed by ().
diff --git a/src/lread.c b/src/lread.c
index 219d64d0282..c09e50f8cbf 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4782,27 +4782,10 @@ DEFUN ("intern", Fintern, Sintern, 1, 2, 0,
obarray =3D check_obarray (NILP (obarray) ? Vobarray : obarray);
CHECK_STRING (string);
=20
-
- char* longhand =3D NULL;
- ptrdiff_t longhand_chars =3D 0;
- ptrdiff_t longhand_bytes =3D 0;
- tem =3D oblookup_considering_shorthand (obarray, SSDATA (string),
- SCHARS (string), SBYTES (string),
- &longhand, &longhand_chars,
- &longhand_bytes);
+ tem =3D oblookup (obarray, SSDATA (string), SCHARS (string), SBYTES (str=
ing));
=20
if (!BARE_SYMBOL_P (tem))
- {
- if (longhand)
- {
- tem =3D intern_driver (make_multibyte_string (longhand, longhand_chars,
- longhand_bytes),
- obarray, tem);
- xfree (longhand);
- }
- else
- tem =3D intern_driver (string, obarray, tem);
- }
+ tem =3D intern_driver (string, obarray, tem);
return tem;
}
=20
@@ -4821,24 +4804,13 @@ DEFUN ("intern-soft", Fintern_soft, Sintern_soft, 1=
, 2, 0,
=20
if (!SYMBOLP (name))
{
- char *longhand =3D NULL;
- ptrdiff_t longhand_chars =3D 0;
- ptrdiff_t longhand_bytes =3D 0;
-
CHECK_STRING (name);
string =3D name;
- tem =3D oblookup_considering_shorthand (obarray, SSDATA (string),
- SCHARS (string), SBYTES (string),
- &longhand, &longhand_chars,
- &longhand_bytes);
- if (longhand)
- xfree (longhand);
+ tem =3D oblookup (obarray, SSDATA (string), SCHARS (string), SBYTES =
(string));
return FIXNUMP (tem) ? Qnil : tem;
}
else
{
- /* If already a symbol, we don't do shorthand-longhand translation,
- as promised in the docstring. */
Lisp_Object sym =3D maybe_remove_pos_from_symbol (name);
string =3D XSYMBOL (name)->u.s.name;
tem
@@ -4872,14 +4844,7 @@ DEFUN ("unintern", Funintern, Sunintern, 2, 2, 0,
else
{
CHECK_STRING (name);
- char *longhand =3D NULL;
- ptrdiff_t longhand_chars =3D 0;
- ptrdiff_t longhand_bytes =3D 0;
- sym =3D oblookup_considering_shorthand (obarray, SSDATA (name),
- SCHARS (name), SBYTES (name),
- &longhand, &longhand_chars,
- &longhand_bytes);
- xfree(longhand);
+ sym =3D oblookup (obarray, SSDATA (name), SCHARS (name), SBYTES (nam=
e));
if (FIXNUMP (sym))
return Qnil;
}
diff --git a/test/src/lread-tests.el b/test/src/lread-tests.el
index 50281471389..cf7ef7b266b 100644
--- a/test/src/lread-tests.el
+++ b/test/src/lread-tests.el
@@ -454,47 +454,47 @@ lread-unintern
;; with shorthand
(let* ((oa (obarray-make))
(read-symbol-shorthands '(("a=C2=B7" . "ZZ=E2=80=A2")))
- (s1 (intern "a=C2=B7abc" oa))
- (s2 (intern "a=C2=B7def" oa))
- (s3 (intern "a=C2=B7ghi" oa)))
+ (s1 (shorthands-intern "a=C2=B7abc" oa))
+ (s2 (shorthands-intern "a=C2=B7def" oa))
+ (s3 (shorthands-intern "a=C2=B7ghi" oa)))
(should (equal (oa-syms oa) (list s1 s2 s3)))
(should (equal (symbol-name s1) "ZZ=E2=80=A2abc"))
- (should (eq (intern-soft "ZZ=E2=80=A2abc" oa) s1))
- (should (eq (intern-soft "a=C2=B7abc" oa) s1))
- (should (eq (intern-soft "ZZ=E2=80=A2def" oa) s2))
- (should (eq (intern-soft "a=C2=B7def" oa) s2))
- (should (eq (intern-soft "ZZ=E2=80=A2ghi" oa) s3))
- (should (eq (intern-soft "a=C2=B7ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2abc" oa) s1))
+ (should (eq (shorthands-intern-soft "a=C2=B7abc" oa) s1))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2def" oa) s2))
+ (should (eq (shorthands-intern-soft "a=C2=B7def" oa) s2))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "a=C2=B7ghi" oa) s3))
=20
;; unintern using long name
- (should (eq (unintern "ZZ=E2=80=A2abc" oa) t))
- (should-not (intern-soft "ZZ=E2=80=A2abc" oa))
- (should-not (intern-soft "a=C2=B7abc" oa))
+ (should (eq (shorthands-unintern "ZZ=E2=80=A2abc" oa) t))
+ (should-not (shorthands-intern-soft "ZZ=E2=80=A2abc" oa))
+ (should-not (shorthands-intern-soft "a=C2=B7abc" oa))
(should (equal (oa-syms oa) (list s2 s3)))
- (should (eq (intern-soft "ZZ=E2=80=A2def" oa) s2))
- (should (eq (intern-soft "a=C2=B7def" oa) s2))
- (should (eq (intern-soft "ZZ=E2=80=A2ghi" oa) s3))
- (should (eq (intern-soft "a=C2=B7ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2def" oa) s2))
+ (should (eq (shorthands-intern-soft "a=C2=B7def" oa) s2))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "a=C2=B7ghi" oa) s3))
=20
;; unintern using short name
- (should (eq (unintern "a=C2=B7def" oa) t))
- (should-not (intern-soft "ZZ=E2=80=A2def" oa))
- (should-not (intern-soft "a=C2=B7def" oa))
+ (should (eq (shorthands-unintern "a=C2=B7def" oa) t))
+ (should-not (shorthands-intern-soft "ZZ=E2=80=A2def" oa))
+ (should-not (shorthands-intern-soft "a=C2=B7def" oa))
(should (equal (oa-syms oa) (list s3)))
- (should (eq (intern-soft "ZZ=E2=80=A2ghi" oa) s3))
- (should (eq (intern-soft "a=C2=B7ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa) s3))
+ (should (eq (shorthands-intern-soft "a=C2=B7ghi" oa) s3))
=20
;; unintern using symbol
(should (eq (unintern s3 oa) t))
- (should-not (intern-soft "ZZ=E2=80=A2ghi" oa))
- (should-not (intern-soft "a=C2=B7ghi" oa))
+ (should-not (shorthands-intern-soft "ZZ=E2=80=A2ghi" oa))
+ (should-not (shorthands-intern-soft "a=C2=B7ghi" oa))
(should (eq (oa-syms oa) nil)))
=20
;; edge case: a symbol whose true name is another's shorthand
(let* ((oa (obarray-make))
(s1 (intern "a=C2=B7abc" oa))
(read-symbol-shorthands '(("a=C2=B7" . "ZZ=E2=80=A2")))
- (s2 (intern "a=C2=B7abc" oa)))
+ (s2 (shorthands-intern "a=C2=B7abc" oa)))
(should (equal (oa-syms oa) (list s2 s1)))
(should (equal (symbol-name s1) "a=C2=B7abc"))
(should (equal (symbol-name s2) "ZZ=E2=80=A2abc"))
--=20
2.51.0
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 10 Mar 2026 01:42:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 09 21:42:13 2026 Received: from localhost ([127.0.0.1]:52784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vzm6v-0001hc-5k for submit <at> debbugs.gnu.org; Mon, 09 Mar 2026 21:42:13 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28356) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vzm6s-0001gh-8J for 80574 <at> debbugs.gnu.org; Mon, 09 Mar 2026 21:42:11 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D9B7C81DB6; Mon, 9 Mar 2026 21:42:03 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773106922; bh=R7iyU7gy2Ad3jQR5SKXOhbzwCVvt46wJwIweg6CS/HE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JR1tn0IXyvx8FSQDhzbijSRc8Gvi7vTKMsisV1sw2N/qfF0k8g2Lkgjij+/rAAIZ9 0Ej3AsMxBIjin3EBgx6RTE9gFEFcLV1R3cKSA90RyBIHO6t0lDuJFknp8dQ4nyvl44 ZpQkowk0WVDgaPbx+Q+cmTkghPixBhTbLGX5fF49ZKs1WwKC31nClU7nABFwPqOxV9 0B6lhuwcdsIWjslNL1vIwu05LJdzvWOvLQUIZ0Qu6OFdznXlpynraPOGg3Rf51LAG2 9xg7TGTlvU/XHb8ipitqCNur76Gif06K4+Lwn5L4uYwadk/6W0z5tLBJPGZkjEhMI1 fm0wH7B7pEk0Q== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C2CD8808F6; Mon, 9 Mar 2026 21:42:02 -0400 (EDT) Received: from alfajor (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9BD2212046C; Mon, 9 Mar 2026 21:42:02 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <871phsa9rz.fsf@HIDDEN> Message-ID: <jwvikb4zcte.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> <871phsa9rz.fsf@HIDDEN> Date: Mon, 09 Mar 2026 21:42:01 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.251 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) >> It's necessary but not sufficient, no. It won't fix the typical code >> that is looking for a symbol in the global obarray with a code like >> >> (intern (format "foo-%s-bar" ...)) >> >> where all the shorthands that could have been useful somewhere have >> already been expanded elsewhere and any expansion performed on account >> of the current `read-symbol-shorthands` would cause an error. > > That pattern is a code smell it itself. Make a dispatching table, use > generic functions instead. The latter is likely faster (than allocating > those strings), C-h f friendly, M-. friendly, etc... Yeah, but just because it's code which could be rewritten better now that we have generic function is not an excuse for leaving it broken by `read-symbol-shorthands`. Especially since such practices have had 30 years to spread, so it's going to take a long time until they're replaced. > Most I can give you is feedforward: don't break working code! :-) It may prove difficult. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 9 Mar 2026 23:00:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 09 19:00:21 2026 Received: from localhost ([127.0.0.1]:51429 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vzjaG-00079J-IA for submit <at> debbugs.gnu.org; Mon, 09 Mar 2026 19:00:21 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:60420) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1vzjaB-00078W-A1 for 80574 <at> debbugs.gnu.org; Mon, 09 Mar 2026 19:00:16 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-48529c325f0so23903215e9.0 for <80574 <at> debbugs.gnu.org>; Mon, 09 Mar 2026 16:00:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773097213; x=1773702013; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=KBhcvPp4LCaj+m9mfL3+LC4AzMxzK1arGGKDr7S4jAo=; b=gIGAIJHLP9KvhyCg5pByhd4+HVGC/JHrNM6CQfv9HLNwLJL0JiYgZtT4ykcNH6wY5x kzWUQ7/fAqzkwVzN1Cjgv6+Xbd83dDKpdRJpXZNY2cmUWLKvRJ17BVCIVRfSteGMC03N VhJg3oWf7Wp/XU7fBDq6thRAQdh0qBeBWHDZH9nQoeCweoNdtmeDjUJtQwaFk0/ht4JE T/TVTzmsR06MtwN9FjXXQ2kpZCox0wY/EzguKxibaiIcJ+Kza66UrDENcN1cYjugmLp8 iLBYhqhDIjiuRt64Pfwyi1H7x1k/o7dZ1/bailaFSiLCGChxRN0vRw7Zeb/+OuOIItr0 eRZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773097213; x=1773702013; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=KBhcvPp4LCaj+m9mfL3+LC4AzMxzK1arGGKDr7S4jAo=; b=Uix7fDeFPzVTUN+wTMWi1sQ2W+TvHqTKq6n7SeRzU1bBL/qG0apsn0D756mDOHyalE TQHovWV884PVmQWbL99S3t4QfMsMCVl/h4FkP1yGkhA8ux3Zu4R4VDkXqMKnzln9C6Mk QW10RrcwIry7CoQ5/1yNw4kECejc4MWQTnEx0UZgzl6gBgwxr3a+q7f14MS9nmhyFFDo h/xKk0FhZlv3I8MrOseugwzmy/jMwvA4kOoNKAscyRWohTygVdq7xROF7a+T1FKfSkQo 5hBQyAYFx9nFPlG1rtg33X2PbPvaVk8D3D4X17m9V0o3XcUs9u4EuEkLk0j3NhT79ntC x+3w== X-Gm-Message-State: AOJu0YxiQUZ90UjYoH8CGOW4VIW7x7+7kFaqXaGIxKMf89WM7P4augn7 98kVek5eG5BWK/q8eBV1clwKBTIf55C0068Jcssp2F8x/W8ZGyeHHv6aELKbmw== X-Gm-Gg: ATEYQzxNyZrpyfYTvfjmg/GdamGyOFnK7hrKf6/MTpmhexgwGz+NVytzm8dJTRKek4B X9Z5vNBhzrnngglZd1JPHL8MooLY38hfKl+jQKfb8fbS5IgLKrPLlTmG4U4x5sllcBOadqiYruM 5AZ3rJFjhKcA2iXoMJxlvN0JA+hmlanMr3w2SLhem3DLARYdTGXrE/E/SepfmSp37OHKyyiEicp MBL+txe1aqjFlNinGuFvTiSK7IapmtWj1dA4ZYTlnqnUuAE4oAejchTWAKs4j44YgkfohxiuSUN XNKNFqsX6qwmMNev+FoxNpzF2gtBEitG1E7lzh6Ed7ECdSADLh1+pBpacsTAFT5m/rDgea78ngM Ke1crN77IPcTwajy9AmMUrk6UqNWn5N07fJwPn5PfiESoM+OOELUgd945wxD2baXvPB0Me7f724 kecKRPzkElOQ+2qmgQYSmqeFSyNxjg417N++fzBD2yxlqs5yBKeTQMB+0sI7lpAxUbBJ0wnWcHC qQxE1qjFadsZDo9/gnrImv9pwI= X-Received: by 2002:a05:6000:4009:b0:439:c8a3:45f3 with SMTP id ffacd0b85a97d-439da555695mr22597152f8f.6.1773097213265; Mon, 09 Mar 2026 16:00:13 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dae36785sm28042284f8f.27.2026.03.09.16.00.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 16:00:11 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN> <jwvsea81xnd.fsf-monnier+emacs@HIDDEN> Date: Mon, 09 Mar 2026 23:00:16 +0000 Message-ID: <871phsa9rz.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: > It's necessary but not sufficient, no. It won't fix the typical code > that is looking for a symbol in the global obarray with a code like > > (intern (format "foo-%s-bar" ...)) > > where all the shorthands that could have been useful somewhere have > already been expanded elsewhere and any expansion performed on account > of the current `read-symbol-shorthands` would cause an error. That pattern is a code smell it itself. Make a dispatching table, use generic functions instead. The latter is likely faster (than allocating those strings), C-h f friendly, M-. friendly, etc... >> Just want to restate that at this point I'm just thinking out loud. I >> don't really care that much how you implement this in internals as long >> as you don't break my third party extensions (breadcrumb, beardbolt) and >> the fair number of other third party packages also using it. > > They may end up require some change. > If some version of my proposal is accepted, you'll get to try the patch > and give feedback, like everyone else. =F0=9F=99=82 Most I can give you is feedforward: don't break working code! :-) Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
Received: (at 80574) by debbugs.gnu.org; 9 Mar 2026 22:15:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 09 18:15:11 2026
Received: from localhost ([127.0.0.1]:50794 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vzisX-0001ml-Jm
for submit <at> debbugs.gnu.org; Mon, 09 Mar 2026 18:15:10 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46385)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vzisV-0001jy-2f
for 80574 <at> debbugs.gnu.org; Mon, 09 Mar 2026 18:15:07 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D2B4A81DB6;
Mon, 9 Mar 2026 18:15:00 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1773094499;
bh=7opnIXUMBqh1GxRMb8WgY7bgC79T2mGvOLFLkdvk+kg=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=l1rypl+8ZsN1tOrlw0c3jdSf3GY0TRuSonU07Dh6Uv+P0kxznsgOlBHB2jBYnKhge
mpM85Z+3lomOSKa5Ltc4DgUdqk3zxAkes90ue6VCOKK64EIls9p5zsqom62j8FOFZU
wt7lcYFJrrVetiAEjN5IxHZAGaMtofXQ8lTeOVV9tnKRo8FzjMo5w2qg8caFofIu9E
rtAOO2q7FNrhNbc7KEq0aDktCrS3G22WblNIrMNGb4fhBJTaPcfPXiawg734zSIVeb
wKKH6OMsvX9RTUnXNPI3URdIV7LIaxzhBqd5Tpgo60atXgAaLMjp/kidnTtQFKNyqE
chs5LCudLV2uQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 968A281C24;
Mon, 9 Mar 2026 18:14:59 -0400 (EDT)
Received: from alfajor (unknown [104.247.242.158])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6B0941205DF;
Mon, 9 Mar 2026 18:14:59 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN>
Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the
current-buffer
In-Reply-To: <87jyvl9usi.fsf@HIDDEN>
Message-ID: <jwvsea81xnd.fsf-monnier+emacs@HIDDEN>
References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN>
<jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> <87jyvl9usi.fsf@HIDDEN>
Date: Mon, 09 Mar 2026 18:14:58 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.254 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 80574
Cc: 80574 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.6 (-)
>> Maybe you think of obarrays as something intrinsically connected to Lisp
>> syntax, but in Emacs all the obarrays (other than the global one) are
>> used as a plain data-structure (since hash-tables appeared "only" 25
>> years ago in ELisp). A common example is the abbrev tables.
>
> No, I understand that. What I described as a code smell was envisioning
> intern having a specific argument meaning "yes by the way respect the
> same shorthands that intern does when called from read".
The argument I'm proposing would accept values of the same shape as the
possible values of `read-symbol-shorthands`. IOW, callers that want
their `intern` to pay attention to that variable (e.g. for completion in
elisp-mode or for `C-h o/v/f`) would need to be changed to pass that
var's value explicitly. AFAIK, this is fair game because these feature
*already* have to do extra gymnastic to support shorthands, so it would
just require changing that gymnastics.
E.g. it would require changing
(defun elisp--shorthand-aware-boundp (sym)
(boundp (intern-soft (symbol-name sym))))
to something like
(defun elisp--shorthand-aware-boundp (sym)
(boundp (intern-soft (symbol-name sym)
read-symbol-shorthands)))
I argue it makes the code less magical (then again, I must admit that
I currently have no idea why the current code does what we want:
how/where was `sym` interned? Why didn't `intern` obey
`read-symbol-shorthands` already at that time?).
Tho I'm thinking that an even better option might be
(defun elisp--shorthand-aware-boundp (sym)
(boundp (intern-soft
(expand-symbol-shorthands (symbol-name sym)))))
or even
(defun elisp--shorthand-aware-boundp (sym)
(boundp (intern-soft
(expand-shorthands (symbol-name sym)
read-symbol-shorthands))))
since `expand(-symbol)-shorthands` could be useful on its own.
>> `intern` is used internally by `read` (well, technically no: `read`
>> calls directly into the innards of obarrays rather than via `intern`,
>> but that's an irrelevant technical detail), but it's also used in cases
>> unrelated to `read`, which is why `intern` itself should not pay
>> attention to `read-symbol-shorthands` and it would be backward for code
>> which has nothing to do with `read` to have to bind
>> `read-symbol-shorthands` to nil.
>
> I agree in the first part and disagree in the second, because that's not
> how CL works. INTERN also pays attention to the current package when
> used for handrolling non-READ-related things.
But the tradeoffs are very different:
- With CL packages `symbol-name` still returns the string passed
to `intern`, whereas with `read-symbol-shorthands` the result can be
completely different.
- In ELisp, the obarray arg of `intern` can't be used for namespacing
(e.g. because there's no syntax for "symbol FOO in obarray BAR") it's
used only to use obarrays as a hash-table.
- CL code knows about packages and will usually/often pass an explicit pack=
age
unless they know that they want to use whichever is the current value
of `*package*`. In contrast most ELisp code was written before
`read-symbol-shorthands` was even written and there is no convenient
way nor tradition to specify which kinds of shorthands to use for
a specific call to `intern`.
>> Well, in Common-Lisp, the second argument to `intern` overrides the
>> current `*PACKAGE*`, so at least Common Lisp agrees with me that
>> `intern` should not look up `read-symbol-shorthands` when its second
>> arg` is not the default.
>
> Yes, you're right. So yes, I think this makes sense. Pass 'intern' an
> explicit obarray, and no magic happens. Is that not enough?
It's necessary but not sufficient, no. It won't fix the typical code
that is looking for a symbol in the global obarray with a code like
(intern (format "foo-%s-bar" ...))
where all the shorthands that could have been useful somewhere have
already been expanded elsewhere and any expansion performed on account
of the current `read-symbol-shorthands` would cause an error.
> Just want to restate that at this point I'm just thinking out loud. I
> don't really care that much how you implement this in internals as long
> as you don't break my third party extensions (breadcrumb, beardbolt) and
> the fair number of other third party packages also using it.
They may end up require some change.
If some version of my proposal is accepted, you'll get to try the patch
and give feedback, like everyone else. =F0=9F=99=82
=3D=3D=3D Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 9 Mar 2026 10:11:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 09 06:11:43 2026 Received: from localhost ([127.0.0.1]:43489 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vzXaQ-0001zS-WC for submit <at> debbugs.gnu.org; Mon, 09 Mar 2026 06:11:43 -0400 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:45316) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1vzXaO-0001z8-2e for 80574 <at> debbugs.gnu.org; Mon, 09 Mar 2026 06:11:41 -0400 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4852f73d0a3so13680265e9.3 for <80574 <at> debbugs.gnu.org>; Mon, 09 Mar 2026 03:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773051098; x=1773655898; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=HkBVyzBT/ihbcq38TpSCg2CNiKeYP49YD1ZaM5e8ZZ0=; b=KVq/OkCERTNg6j6uqrnqyU7T5qH1GprHJXtzaEW+ZeQJ9pkKmKdxqYug1kXETqVIt8 JPZ04aswT8NL7uDeycjtQQYcJCBqAf0JtZA9vxGVLvxmJpQCboaWY+cr41sD35wPAJhA M6n2NV3ena0u7ETFEPvuOUN/9GW+9A2jrO2IKkk5aVprKy5lJxyDeOHO81/JsYQkLKW5 56mcs0yWGnVfuc0r9hp77p6U8Iq+n8Wio5psA8VOljZI9EQKIEUVMtkwvAaxxyRUqApa 25Z1xTefquuiuFFJyFvVI1m2usV62bghdo2BxFtFvm1Lql9YSj3ofzQA5RpFBYePxD8K v5ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773051098; x=1773655898; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=HkBVyzBT/ihbcq38TpSCg2CNiKeYP49YD1ZaM5e8ZZ0=; b=TFFKLRkg8xarRh7Lw1b2Cl84aStkgeVIvp05yqFJByhcAAK2dgi3mVJRgPILq7Bx9h j/HtNUbn3XkKee1mpd9/7wnu1K4rvr7RnxQ4lhL3k42iBDP5HU2YFQLP4K4SCRUL1HxG r7UMTXNeT1lQe9ec3XdDnHGunO0WChmadXtE+5mDZ2C1CKOoaBiJ1hPQFNO1cjHwR+AJ xhwMnoHJWCR5OWHa0WUo/yagnYfsgUZM7i2shuZXNHMczJ4Nb6mBwKMFgyD3JB6Ul4O5 MF3fP1qkfp59jTAG9nthrpdmoXMdB9CtWWazJlXabrwA5NLXyX3aex8erVC5NgUvP20A Bw+w== X-Gm-Message-State: AOJu0YzoalrgVN4+bHPAaNe27TtzVWylCa1dCBIJr1ewZzpCneSVNe45 WKwX+4x+Sy8GmkT+0+xmHmRCMNPvrWPhONIG0FyIneyz7N1dohS+qd7dPRlxQQ== X-Gm-Gg: ATEYQzyhaCu1ihCNOmQS9eaqQVTlCoPgnR2TSGiDhU1o4YLewXdZT+fd/klghPEiCGC uIgdKQsloclBqUw9h7ETIMA/igw6pkcZxIv59EaqHbboC+771cn95BCM5yEDD7LQ9FMcp2TdW0T giX6mpTFBFKdKITPkemvgSDxPCAPIz0QByjJ6y1har7NnYL/DhqQifJ9faY+LhzquGiENG9AVD2 FodDZoSjr6zTreRFkBpCCBeiwTbZzYtgydnKOXWLs3y4enBLRDMoablujp6kbxzYtBbfs86jmgR GExLjZvzvFQk+5iGeYU5qDDreMpcdbhCXavseXZGbqfA6B+RmAlL04/Ys81mfI+QcMsUK7HBxDT 570kygbpxllYzwlXsEEHA4RfLUThX/JSO0sO1qifAaBQnr5JbjpJ1qCGth3wne8Qje6sLhwUHDm eooqw7Skq1ISIMKFZWbs/dbENMJv1EMxn3y2oaIhcHrZ7Zowpftxrc+ZoWK6GLZ2i+v6k2txmq2 /fsGPOasjonQ25HU+oMouBmi68= X-Received: by 2002:a05:600c:474f:b0:485:35d3:ce73 with SMTP id 5b1f17b1804b1-48535d3cf36mr81656845e9.32.1773051097868; Mon, 09 Mar 2026 03:11:37 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-485246ed174sm125666195e9.5.2026.03.09.03.11.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Mar 2026 03:11:37 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> Date: Mon, 09 Mar 2026 10:11:41 +0000 Message-ID: <87jyvl9usi.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: >> TLDR. Well as long as you don't break any of (my) code out there, I'm >> fine. But special-casing intern is a code smell if I've ever smelled on= e. > > Maybe you think of obarrays as something intrinsically connected to Lisp > syntax, but in Emacs all the obarrays (other than the global one) are > used as a plain data-structure (since hash-tables appeared "only" 25 > years ago in ELisp). A common example is the abbrev tables. No, I understand that. What I described as a code smell was envisioning intern having a specific argument meaning "yes by the way respect the same shorthands that intern does when called from read". >> It seems to me that the backward compatible way to fix whatever problems >> are happening is for 'intern' callers to opt _out_ of shorthands. And >> frankly, I don't see why that shouldn't be just: >> >> (let ((read-symbol-shorthands nil)) ...) >> >> intern. > > As the name says, `read-symbol-shorthands` is about `read`ing. > > `intern` is used internally by `read` (well, technically no: `read` > calls directly into the innards of obarrays rather than via `intern`, > but that's an irrelevant technical detail), but it's also used in cases > unrelated to `read`, which is why `intern` itself should not pay > attention to `read-symbol-shorthands` and it would be backward for code > which has nothing to do with `read` to have to bind > `read-symbol-shorthands` to nil. I agree in the first part and disagree in the second, because that's not how CL works. INTERN also pays attention to the current package when used for handrolling non-READ-related things. > As explained, ELisp uses obarrays very differently in practice than > Common Lisp, so I don't think CL is a good inspiration here. It is, see below. >> You know my advice, when in doubt, always follows CL principles. Just an >> authority argument but a pretty good one I'd say, as they really spent >> rivers of money and brainpower in the 90's meeting in person to unite >> all these these Lisps which were not just for their editor toys, but >> real industry-level stuff. > > Well, in Common-Lisp, the second argument to `intern` overrides the > current `*PACKAGE*`, so at least Common Lisp agrees with me that > `intern` should not look up `read-symbol-shorthands` when its second > arg` is not the default. Yes, you're right. So yes, I think this makes sense. Pass 'intern' an explicit obarray, and no magic happens. Is that not enough? > (Is that not enough?) Just want to restate that at this point I'm just thinking out loud. I don't really care that much how you implement this in internals as long as you don't break my third party extensions (breadcrumb, beardbolt) and the fair number of other third party packages also using it. Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 9 Mar 2026 02:11:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 08 22:11:59 2026 Received: from localhost ([127.0.0.1]:37890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vzQ6A-0000n1-HJ for submit <at> debbugs.gnu.org; Sun, 08 Mar 2026 22:11:58 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59899) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vzQ67-0000mO-UX for 80574 <at> debbugs.gnu.org; Sun, 08 Mar 2026 22:11:56 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0291481C99; Sun, 8 Mar 2026 22:11:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1773022308; bh=ngq8vufIW1BNGufd0p7H5oclu8qb7c3MCuhGtymduQs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=i8By0VwzSF65HWgUdG/b+/gd3bpW8z62J/LtuJ4rvZ3/dJGppcSPvMrxxsdMSzMxZ Cm/VxfBR6pWYQ04WbpWmm6r0RVBi0CA9l64O1GClWEc79FclwGjIUSPGxS4KzsgTZp 3svWGlcARePIImX8kSyyz7PhE7i+Pl3sf1r8o800riYTpm6idudRCIiGNW7F46tdsx hmt/QOcizg4aDlHvInWDz7qdPripOhQQQx6kQOUSSV9db7pvWOOH78X+ANY5CO3eVj eCtvdi8EEU5rF4aFWuPnbbR5+9J/+rXkNqbEMMqdrSyF8X3J6cdj9fpvkMIQw5CNZz aiHLIrl9VX7tQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DC171808A4; Sun, 8 Mar 2026 22:11:48 -0400 (EDT) Received: from alfajor (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AEB881202D3; Sun, 8 Mar 2026 22:11:48 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= <joaotavora@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <87sea9apeo.fsf@HIDDEN> Message-ID: <jwvzf4hye0f.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> <87sea9apeo.fsf@HIDDEN> Date: Sun, 08 Mar 2026 22:11:41 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.257 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) > TLDR. Well as long as you don't break any of (my) code out there, I'm > fine. But special-casing intern is a code smell if I've ever smelled one. Maybe you think of obarrays as something intrinsically connected to Lisp syntax, but in Emacs all the obarrays (other than the global one) are used as a plain data-structure (since hash-tables appeared "only" 25 years ago in ELisp). A common example is the abbrev tables. > It seems to me that the backward compatible way to fix whatever problems > are happening is for 'intern' callers to opt _out_ of shorthands. And > frankly, I don't see why that shouldn't be just: > > (let ((read-symbol-shorthands nil)) ...) > > intern. As the name says, `read-symbol-shorthands` is about `read`ing. `intern` is used internally by `read` (well, technically no: `read` calls directly into the innards of obarrays rather than via `intern`, but that's an irrelevant technical detail), but it's also used in cases unrelated to `read`, which is why `intern` itself should not pay attention to `read-symbol-shorthands` and it would be backward for code which has nothing to do with `read` to have to bind `read-symbol-shorthands` to nil. > Also I don't understand why other obarrays can't make use of > read-symbol-shorthands. Is it because Emacs always read files into > the main obarray? Yup. > Also, FWIW consider that this was loosely modelled on Common Lisp's > intern which considers the dynamic current *PACKAGE*, set at read time > with the IN-PACKAGE macro. So between regions of IN-PACKAGE in Common > Lisp files you have the same form of (INTERN "") does different things, > i.e. interns different symbols. This just works. Of course we don't > have IN-PACKAGE because reasons but the file-local > read-symbol-shorthands is more or less like a file-local IN-PACKAGE, > also considered at read-time. As explained, ELisp uses obarrays very differently in practice than Common Lisp, so I don't think CL is a good inspiration here. > You know my advice, when in doubt, always follows CL principles. Just an > authority argument but a pretty good one I'd say, as they really spent > rivers of money and brainpower in the 90's meeting in person to unite > all these these Lisps which were not just for their editor toys, but > real industry-level stuff. Well, in Common-Lisp, the second argument to `intern` overrides the current `*PACKAGE*`, so at least Common Lisp agrees with me that `intern` should not look up `read-symbol-shorthands` when its second arg` is not the default. Also, in the the examples like the `pcomplete/COMMAND` (i.e. when we use `concat+intern` to do either some kind of poor man method lookup or some kind of poor man namespacing), the current-buffer can often be "arbitrary", so the `read-symbol-shorthands` we get is accidental. In Common Lisp you'd use a separate package/obarray for that (i.e. `intern`s second arg would not be nil), so `intern` would not pay attention to `*PACKAGE*`. === Stefan
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at 80574) by debbugs.gnu.org; 8 Mar 2026 23:10:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 08 19:10:25 2026 Received: from localhost ([127.0.0.1]:35878 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vzNGT-0005aY-6j for submit <at> debbugs.gnu.org; Sun, 08 Mar 2026 19:10:25 -0400 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:56488) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <joaotavora@HIDDEN>) id 1vzNGQ-0005aB-Kr for 80574 <at> debbugs.gnu.org; Sun, 08 Mar 2026 19:10:23 -0400 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-439b9cf8cb5so6662731f8f.0 for <80574 <at> debbugs.gnu.org>; Sun, 08 Mar 2026 16:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773011421; x=1773616221; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=zFWDVgnS/tDNbGFQghVh5LiXOUFJ/aEpRDk1Y9rMYvE=; b=ksX7hdWAg7UOtV+xEyHeITR8JjrzrgmCzEYuV355O/Vt91tfitw5wx+BPxBvANk+Kz OxF90Tl+IjVUtr+PBFuz6owkUnOLHhZ7y/Q//u753zwMm0hAJjI7fED8zTst3WVRvoqT 9ORLDIAb39Imk9OT1h4RIufLCmMg2Is6CMjhxoQEQ5sUidd5u62qlqN8LXCcKiaYbe2c vxQ+x01s23+/ISH8lObN+xlLDiOglrYKr9WzOce4g445R4pbo93QRCXormDYJylF8j9r CD4sFKU3iYVaJTxNFQBhgQySmV/aD5CjkHgxHdcchXqSWNt0fRxuNbIBGtLsVxg8F8aO nIkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1773011421; x=1773616221; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zFWDVgnS/tDNbGFQghVh5LiXOUFJ/aEpRDk1Y9rMYvE=; b=SXV1EaR4geGxdExcXBiFrKr68AcqPRPt+yBBZZ44WNSYmH9Y6VOCJA52ws+6wbYqQW 2wfR/I80RtdZr1e5U0XBv9tyvjxn+ysux43ozc6bfRaRt2hxvnK+SW3euCmq9q0Ixvvj 0wI/UW9vFounwpZt3UgXbwfdZF+T4lp0wJQMOV06lmEIQSVQ4s8JIGJbIWzk/EPbsfER XFFIulezZ9p3UyCd3Qa1CKZg3lhYX9T2isNSLB+XbY7QvfINgNuIa/wVq0q0dBXj+HPp tLjj7q6nhyuODDUZmOeATWBs59mxuGbL9Obd7Vshh0hdWZZAMevvo9Z6cPzbNWEiZ3CJ DPVw== X-Gm-Message-State: AOJu0YyD3tLDH8Y9Z8b1J159sTI0hdX5hE74PF1/9opp5PVYyFYgng/X +plO31XY9sAUUGJOTvL7sLAX+iwdZE1lSbEinHq5GkpxGWolZRCo+Q+NRtV8eg== X-Gm-Gg: ATEYQzwor8jIdP2WdSgp3i1+eQVgm+oVKvFsvxz7XaD8fal7tvLWP6lQpNwiXhhj4Sk gQGn++SSz5FNzJX1NSXqg+Hkhl3YTRWKcYIBs1UKFlGU1TewOjEPxAXR6sPC9nE8g/HKnkBlyLq RTD3ZPm5x+nZN3urDlWMW6140AShjydcJO3wuiAEwGruMLGfZ458UjqyLXyZnssKfgdqVzKd/nb DmxmHIYaL+eyP1xpgIj2pGv4id3GaGTVxREfZqUngc1IS3Hg+df5QLtYr4pzfl/4gyWuIoGv40/ rxrJUccvpSOCRLw1ltw4+Ayt0myUV2578Xs+PWY3xCNUmBPgABJGqV0NlYOxbiq8f3F7CxcRKk5 ED3BSkvqnFQTkHA9iSeAfzpiJMb03TRdzvcP+FGTU4RMGC0O+AO7sq+MCfLFzwkJO5xeWldoyld sxCT9DambIeAbfaN7PoRBjWFHD4oy6Sv84hntnx5OCw7j3G6u+P71Ap59EVLQCyHE7b3a6FiT5R HQbW1FYLTduhXc8O6tv1t3MSGWWHm7aJxBu7A== X-Received: by 2002:a05:6000:230f:b0:439:b114:60c2 with SMTP id ffacd0b85a97d-439da880b2fmr16059341f8f.34.1773011420432; Sun, 08 Mar 2026 16:10:20 -0700 (PDT) Received: from krug (87-196-75-93.net.novis.pt. [87.196.75.93]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439dad8ec97sm23689166f8f.5.2026.03.08.16.10.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Mar 2026 16:10:19 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= <joaotavora@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> Subject: Re: bug#80574: 31.0.50; `intern` should not depend on the current-buffer In-Reply-To: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> References: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> Date: Sun, 08 Mar 2026 23:10:23 +0000 Message-ID: <87sea9apeo.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 80574 Cc: 80574 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Stefan Monnier <monnier@HIDDEN> writes: > I'm working on a patch,but thought I would get the discussion going in > the mean time. TLDR. Well as long as you don't break any of (my) code out there, I'm fine. But special-casing intern is a code smell if I've ever smelled one. It seems to me that the backward compatible way to fix whatever problems are happening is for 'intern' callers to opt _out_ of shorthands. And frankly, I don't see why that shouldn't be just: (let ((read-symbol-shorthands nil)) ...) intern. Also I don't understand why other obarrays can't make use of read-symbol-shorthands. Is it because Emacs always read files into the main obarray? OK I guess, but is that not a bit short sighted?=20 Also, FWIW consider that this was loosely modelled on Common Lisp's intern which considers the dynamic current *PACKAGE*, set at read time with the IN-PACKAGE macro. So between regions of IN-PACKAGE in Common Lisp files you have the same form of (INTERN "") does different things, i.e. interns different symbols. This just works. Of course we don't have IN-PACKAGE because reasons but the file-local read-symbol-shorthands is more or less like a file-local IN-PACKAGE, also considered at read-time. You know my advice, when in doubt, always follows CL principles. Just an authority argument but a pretty good one I'd say, as they really spent rivers of money and brainpower in the 90's meeting in person to unite all these these Lisps which were not just for their editor toys, but real industry-level stuff. Good luck, Jo=C3=A3o
bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 8 Mar 2026 15:56:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 08 11:56:43 2026 Received: from localhost ([127.0.0.1]:32887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vzGUj-0003Tt-PT for submit <at> debbugs.gnu.org; Sun, 08 Mar 2026 11:56:43 -0400 Received: from lists.gnu.org ([2001:470:142::17]:37442) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vzGUg-0003SB-QA for submit <at> debbugs.gnu.org; Sun, 08 Mar 2026 11:56:40 -0400 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 <monnier@HIDDEN>) id 1vzGUQ-0004H3-Di for bug-gnu-emacs@HIDDEN; Sun, 08 Mar 2026 11:56:24 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <monnier@HIDDEN>) id 1vzGUO-0000jR-Op for bug-gnu-emacs@HIDDEN; Sun, 08 Mar 2026 11:56:22 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4903C81C99 for <bug-gnu-emacs@HIDDEN>; Sun, 8 Mar 2026 11:56:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1772985378; bh=FK0I/KwAnA+F6jnmlG/aWdeA5GJxcxzTRYFfcsrsrUc=; h=From:To:Subject:Date:From; b=Up1ovIaRR4WzF9g8THVl9Enx5uaHqC53BQf15daepowe+e812dcokILOci+i7HAYz LWvZY7DZPW0qPhJBoWLuts8zHSZNO5VmFiDuwegl4BfMeZQCamyJPaCq0wObCY5w7T O5wpSDqH7kszniU2FnIZFqSE9icc2uiXSuYhlI6wrgRo1jrKiUi23FqD9eY3IuVxX1 CRGhaAXZBQzjySeeJHVB7i20AkDJHkm7jcmeHMWhmKuNVuaa8gMAO995teSbXfula+ Ri2Fxqaq+/+sFZaRmIIy/NvamQgVT5OHulo1Rwvym2Yoojt62r8T7b4W92w00k80Y/ M40zFa1JryUYg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 33D37808F6 for <bug-gnu-emacs@HIDDEN>; Sun, 8 Mar 2026 11:56:18 -0400 (EDT) Received: from pastel (unknown [104.247.242.158]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 13B84120760 for <bug-gnu-emacs@HIDDEN>; Sun, 8 Mar 2026 11:56:18 -0400 (EDT) From: Stefan Monnier <monnier@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 31.0.50; `intern` should not depend on the current-buffer Message-ID: <jwvzf4ipd78.fsf-monnier+emacs@HIDDEN> X-Debbugs-Cc: monnier@HIDDEN, =?windows-1252?B?Sm/jbyBU4XZvcmE=?= <joaotavora@HIDDEN> Date: Sun, 08 Mar 2026 11:56:10 -0400 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.258 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.819, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.903, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Package: Emacs Version: 31.0.50 Currently `intern` (and `unintern`) obey the variable `read-symbol-shorthands`, which is often set buffer-locally. I think this is a mistake that will inevitably lead to weird bugs. Some uses of `intern` need it, but most don't. Here are cases I can think of where obeying `read-symbol-shorthands` sounds clearly undesirable: - When interning into another obarray than the global obarray. - When constructing a symbol by adding some text to a prefix, e.g. to build the `FOO-mode-map` symbol from the `FOO-mode` symbol in `define-derived/minor-mode` or to find the `pcomplete/COMMAND` in Pcomplete. Here are cases I can think of where obeying `read-symbol-shorthands` can be handy (i.e. tho it could be handled before passing the string to `intern`): - `C-h o/v/f` where we may want the users to be able to type the same "ical:FOO" they found in the current buffer to jump the the vars/function's doc. - TAB completion while editing in ELisp-mode. So I think we should change `intern` so it obeys `read-symbol-shorthands` only when explicitly requested. I think a good way to do that is to ask callers that need this functionality to pass the value of `read-symbol-shorthands` they want to use, explicitly as an argument. And I suggest we do that by re-using the existing `obarray` argument, since we never need that functionality when that argument is not the default. Another option would be to change `intern` so it just never obeys `read-symbol-shorthands` and instead provide a separate function that takes a string and the value of `read-symbol-shorthands` and returns the longform version of the string (which we can then pass to `intern`). In either case that will require a few changes to the `elisp-mode.el` code for its TAB completion and to the `C-h o/v/f` completion code, but other than that, AFAICT everything else should be unaffected. I theory, the same holds for `unintern`, except that I really can't imagine a case where it would make sense for `unintern` to obey `read-symbol-shorthands` (among other things, because using `unintern` on the global obarray is virtually never the right thing to do). So for `unintern` it seems pretty clear we just want to change it so it never pays attention to `read-symbol-shorthands`. I'm working on a patch,but thought I would get the discussion going in the mean time. === Stefan
Stefan Monnier <monnier@HIDDEN>:monnier@HIDDEN, joaotavora@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.monnier@HIDDEN, joaotavora@HIDDEN, bug-gnu-emacs@HIDDEN:bug#80574; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.