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.