From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Help sought understanding shorthands wrt modules/packages Date: Sat, 12 Nov 2022 10:11:46 +0000 Message-ID: <87tu345vod.fsf@gmail.com> References: <25a8a3a6-81c8-3fbc-434d-fb1b24ae1d62@gmail.com> <83cza48lxe.fsf@gnu.org> <87cza0ihb7.fsf@gmx.de> <87o7td7qfu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16568"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 12 11:11:19 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1otnTr-0004AO-HR for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Nov 2022 11:11:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1otnTG-00088i-AD; Sat, 12 Nov 2022 05:10:42 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1otnTB-00087i-Vy for emacs-devel@gnu.org; Sat, 12 Nov 2022 05:10:38 -0500 Original-Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1otnTA-0004d7-17; Sat, 12 Nov 2022 05:10:37 -0500 Original-Received: by mail-wr1-x434.google.com with SMTP id l14so9405278wrw.2; Sat, 12 Nov 2022 02:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=SfB8FrKrqfIAB5VQjyueW9qdgT6qCpXcIxy4WK748Bg=; b=VL2LDajaVSrBbTvIdJ/HmRh8hyCVInDpEnGLW3P13J9YT9FwPaV6NsYRLQmyoGtLhd +JC92oIsWMwYpypgCi5Ik/V85NkWtgds4RM5dcntF/7swL/Ir8LsHx5g3F19YLBZe8Fe PW3YeUdfukgMRoJPNixFvFYfIiN0/GwBzBd44bXKyx1+OGfN0NEXglgs/RPAD+DxiDPb fVF7pr+mwrZkwh7KMPGMNfwzG61GqSnqoNHZTOD1vVM4el0b6PKIChUNOuKB1I/DeFUO ab7ZGE/piCYOy2wwaN6gvk346oEvskmNLsH/G5f2w+QDIh5j83QP4abiK4AGOpeFEpHl WYug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=SfB8FrKrqfIAB5VQjyueW9qdgT6qCpXcIxy4WK748Bg=; b=2DVn4mipsrHVRuYrzGc6V6Tv6sa26gNKHlWW14/3tT3Wb6FgxhR01TnCDIV5TsPEVx NI0FdBmuH8b5MDivwKoAEqv3NKxFp6MPSF1dvq2111kaFBoWqDDkmnrI8vcEno3p7HYa lLqgIYtLGVmOHfT3WM6VTrCJEV0ZZiZpb5HNJ8/VdL5EaBnjjfhF3aH0mRm/WufIbM/V MK1L0vJ+SvgTmwcBgmYyAuQDVxB0HICanKfgYfrup1q8SsY6YELp9LuS6qkWNYdKDJ/g AdGNj8cG39OehX7wuzDzI/AgxONpVgu5nGHktSyMEg9uD5/NqA1dWMaA7ZDgI9yymxSd twYA== X-Gm-Message-State: ANoB5pnV35xaeYHctafLcEK7QFVHrTL+ShFd4hmTiijSi1U2vu1h89OC 0rPPITQGMbzx9XqqDLXJOmDfUhuZHhk= X-Google-Smtp-Source: AA0mqf619WYS9LW0M4r/DZAVApWC3EPD1W670l0KqWCxfiAXff2Al8pOZ3MaYk+q6zjVT/9h0K4jbg== X-Received: by 2002:adf:fed2:0:b0:236:7778:16d3 with SMTP id q18-20020adffed2000000b00236777816d3mr3040030wrs.669.1668247832539; Sat, 12 Nov 2022 02:10:32 -0800 (PST) Original-Received: from krug (87-196-81-1.net.novis.pt. [87.196.81.1]) by smtp.gmail.com with ESMTPSA id h15-20020a05600c350f00b003cfcf9f9d62sm5752930wmq.12.2022.11.12.02.10.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 12 Nov 2022 02:10:31 -0800 (PST) In-Reply-To: (Richard Stallman's message of "Fri, 11 Nov 2022 22:35:50 -0500") Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x434.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:299638 Archived-At: Richard Stallman writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > The magnars-string.el file is meant to supersede s.el and be a > > well-behaved version of it. The s.el file, as it exists today, is a > > namespace-polluting liability, we shouldn't maintain it. > > No one would be happer than I to eliminate te usual version of s.el, > but my understanding is that that would cause a big practical problem. > > Lots of packages do (require 's), and they call those functions by the > names s-... defined in s.el. If we don't have s.el, they will break. > They can't use your proposed magnars-string.el (which I would call > stris.el), since the names it would define are wrong _for them_. I don't think you're following my plan, which was the plan all along. Here's the story from the beginning: * Once upon a time, s.el was a namespace polluting liability, and this was part of the reason why it wasn't in GNU Emacs or GNU ELPA. * s.el was a very popular kid. Many other packages foo.el and bar.el depended on it. They were also popular. But the namespacing pollution of s.el prevented us from including those in GNU ELPA, too. * Right, so we wanted to integrate s.el into Emacs core or GNU Elpa "somehow", but how could we do that? We developed shorthands for Emacs 28. * OK, but what did we do with them? We made a new file magnars-string.el which was absolutely identical to s.el but for the local read-symbol-shorthands cookie (and the provide form.) Then we submitted mangnars-string.el to Emacs core or GNU ELPA. * When foo.el and bar.el wanted to enter GNU ELPA, they just upgraded their string library from s.el to magnars-string.el, of course. * Oh no, but wasn't upgrading them so very complicated? No at all, it amounted to changing a single line, in foo.el: (require 's) to (require 'magnars-string) And adding the SAME read-symbol-shorthands cookie in the trailer of the file. ;; foo.el ends here ;; Local Variables: ;; read-symbol-shorthands: (("s-" . "magnars-string-")) ;; End: * But but, what about all the the references to s-trim and s-append in lines 1234 and 876 of foo.el? They became, magically, references to the symbols magnars-string-trim and magnars-string-append. * And that's all? They lived happily ever after? Yes, that's about it. The usual copyright stuff was changed in foo.el and bar.el, the name of the package was endelessly bikeshed, Stefan Monnier submitted many patches (mostly for pcase usage), and yes, they lived happily. Epilogue: * One night, Saint Ignucius came down to tell the world not to use s.el anymore, because a better version had appeared in GNU land. This being a world of sinners, most of it didn't listen or care. Splitters! Saint Ignucius then also asked the maintainers to stop maintaining their s.el. Let's presume they did listen. One day, some package fossil.el, which didn't listen, found a bug in its s.el dependency. Should that bug have been fixed in s.el? No, it was fixed in magnars-string.el. fossil.el was told to upgrade to magnars-string.el, because it is very easy. Now fossil.el was enlightened, too. Not so fast! fossil.el was meant to work on Emacs 27 and Emacs 6 and Emacs 500BC! No problem, that's didn't change the plan. fossil.el was upgraded to use magnars-string.el anyway. And that new fossil.el was loaded into Emacs 27 along with magnars-string.el. They loaded fine, and the presence of the read-symbol-shorthands file-local variables there didn't affect it. And fossil.el worked just fine there. The namespace was polluted with s- symbols, that's true, but the situation was no worse than before. One day, the user simply upgraded to Emacs 28, kept all his packages in the same place, and the namespace pollution simply went away. > > The usual commands C-M-x, M-x load-file, M-x > > emacs-lisp-byte-compile-and-load will all produce wrong results that I > > won't know how to fix. > > I don't follow you. I don't see why anything would produce wrong > results. If you show me a specific scenario, I might understand. If you do these actions in the s.el file, the one where the actual code is and the one you want to keep unchanged, it will just intern new s-prefixed symbols in the obarray! I.e. you won't change the renamed symbol's definition -- the one begotten by that load-with-shorthands call -- at all.