From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings Newsgroups: gmane.emacs.devel Subject: Re: A read-based grep-like for symbols (el-search?) (was Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)) Date: Mon, 18 Oct 2021 21:22:55 +0000 Message-ID: <19fca5d18b32e460269b@heytings.org> References: <25d8d72022b571db5291@heytings.org> <87h7e2xsl5.fsf@gmail.com> <25d8d72022e1ea7ed022@heytings.org> <87fstl7lzw.fsf@web.de> <87a6jt7ilx.fsf@web.de> <87fstlzlaq.fsf@gmail.com> <20211001070242.GC16352@tuxteam.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NGSIRVgOSr" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40763"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 18 23:23:45 2021 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 1mca6j-000AMW-37 for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Oct 2021 23:23:45 +0200 Original-Received: from localhost ([::1]:37090 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mca6g-0002Nb-SD for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Oct 2021 17:23:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46880) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mca62-0001bb-9p for emacs-devel@gnu.org; Mon, 18 Oct 2021 17:23:02 -0400 Original-Received: from heytings.org ([95.142.160.155]:57156) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mca5x-0007IH-M5; Mon, 18 Oct 2021 17:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1634592175; bh=kYDF6Mz6Dc/IiQO89aCmopvbfAudxO8qnZmXK8AnWEA=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=gLLp6mk0n/okQbqhpNRo1z8p9j6kUadaGHtACZYX3HPbs36SErfJtVb5y9tHtsgz4 keIiBiaNTDebW4THbXatVyloN8830n7GO8dmIBZFOFI6a04+14Sd/ScCbm59kVDwtE GY+PHZhLVX3ZDSGkjOGakPShD7ijZeQgDjv4T7JEaEQT7SbuweKKPd50qVqYijkw/d yc+F5nBzKmj3CghnDyFe4WaZZaX/3fo84ZGPdfuHm5KQ5xM7RV4rknhuo6iMtZhnEA 7w8mtt0fJtCQSct39pCHKfXIG9N1dkz1/FCmPy5LswCTG2bB2rh5LA0KPoPlCZzBvk fosWdIGMWTPyA== In-Reply-To: Received-SPF: pass client-ip=95.142.160.155; envelope-from=gregory@heytings.org; helo=heytings.org 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, SPF_HELO_PASS=-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.23 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" Xref: news.gmane.io gmane.emacs.devel:277322 Archived-At: --NGSIRVgOSr Content-Type: text/plain; charset=us-ascii; format=flowed [Sorry for my previous unfinished message.] Hi Richard, Thank you for your kind and courteous answer. Sorry for my belated reply, I had to think about this a bit. > For reference, these are the two use-cases: > >>> * Creating longer real names to avoid collisions. In this kind of case >>> the package that you load creates shorthands for itself, which rename >>> its symbols to longer names that won't conflict. This is what we will >>> do with s.el. >>> >>> * Creating shorter names for convenience. In this kind of case, one >>> Lisp file would create shorthand prefixes for code in other files. >>> These prefixes might really be shorter than the symbols' documented >>> name. >> >> (4) a solution to the first use case cannot be a long term solution, > > We need a long term solution, and that's what this is intended to be. It > is a good solution because it avoids the need to convince hundreds, > perhaps thousands, of library authors that we are not in communication > with to change the way they write calls to Magnars's libraries. > I understand that it is intended to be a long-term solution, but it is not. We cannot convince all these library authors to change the way they write calls to Magnars' libraries, yet with the chosen solution, it will nonetheless be necessary to adapt each Elisp file they write, by changing the (require 's) into a (require 'magnars-string) and by adding a read-symbol-shorthands local variable at the end of these files. The proper solution to that problem, which does not require to change a single byte in any of these third-party Elisp files, would have been to create a hook that is executed on the file contents before it is processed by readevalloop, or IOW, a hook with which it would be possible to preprocess Elisp files. I attach an example function which would be put in that hook: it checks whether the file contains a (require 's) and at least one call to one of the functions defined in that library, and if so, replaces all symbols "exported" by the s.el library (and only those symbols) in the file with new ones. --NGSIRVgOSr Content-Type: text/plain; charset=us-ascii; name=magnars-strings.el Content-Transfer-Encoding: base64 Content-ID: <19fca5d18b4c0bcaeba8@heytings.org> Content-Description: Content-Disposition: attachment; filename=magnars-strings.el KGRlZnZhciBtYWduYXJzLXN0cmluZy1zeW1ib2xzICcocy10cmltIHMtdHJp bS1sZWZ0IHMtdHJpbS1yaWdodA0Kcy1jb2xsYXBzZS13aGl0ZXNwYWNlIHMt c3BsaXQgcy1zcGxpdC11cC10byBzLWxpbmVzIHMtam9pbg0Kcy1jb25jYXQg cy1wcmVwZW5kIHMtYXBwZW5kIHMtcmVwZWF0IHMtY2hvcC1zdWZmaXgNCnMt Y2hvcC1zdWZmaXhlcyBzLWNob3AtcHJlZml4IHMtY2hvcC1wcmVmaXhlcyBz LXNoYXJlZC1zdGFydA0Kcy1zaGFyZWQtZW5kIHMtY2hvbXAgcy10cnVuY2F0 ZSBzLXdvcmQtd3JhcCBzLWNlbnRlciBzLXBhZC1sZWZ0DQpzLXBhZC1yaWdo dCBzLWxlZnQgcy1yaWdodCBzLWVuZHMtd2l0aD8gcy1zdGFydHMtd2l0aD8N CnMtY29udGFpbnM/IHMtZXF1YWxzPyBzLWxlc3M/IHMtbWF0Y2hlcz8gcy1i bGFuaz8gcy1ibGFuay1zdHI/DQpzLXByZXNlbnQ/IHMtcHJlc2VuY2Ugcy1s b3dlcmNhc2U/IHMtdXBwZXJjYXNlPyBzLW1peGVkY2FzZT8NCnMtY2FwaXRh bGl6ZWQ/IHMtbnVtZXJpYz8gcy1yZXBsYWNlIHMtcmVwbGFjZS1yZWdleHAN CnMtcmVwbGFjZS1hbGwgcy1kb3duY2FzZSBzLXVwY2FzZSBzLWNhcGl0YWxp emUgcy10aXRsZWl6ZSBzLXdpdGgNCnMtaW5kZXgtb2Ygcy1yZXZlcnNlIHMt bWF0Y2gtc3RyaW5ncy1hbGwgcy1tYXRjaGVkLXBvc2l0aW9ucy1hbGwNCnMt bWF0Y2ggcy1zbGljZS1hdCBzLXNwbGl0LXdvcmRzIHMtbG93ZXItY2FtZWwt Y2FzZQ0Kcy11cHBlci1jYW1lbC1jYXNlIHMtc25ha2UtY2FzZSBzLWRhc2hl ZC13b3Jkcw0Kcy1jYXBpdGFsaXplZC13b3JkcyBzLXRpdGxlaXplZC13b3Jk cyBzLXdvcmQtaW5pdGlhbHMgcy1mb3JtYXQNCnMtbGV4LXZhbHVlLWFzLWxp c3Agcy1sZXgtZm10fGV4cGFuZCBzLWxleC1mb3JtYXQgcy1jb3VudC1tYXRj aGVzDQpzLWNvdW50LW1hdGNoZXMtYWxsIHMtd3JhcCBzLWJsYW5rLXAgcy1i bGFuay1zdHItcA0Kcy1jYXBpdGFsaXplZC1wIHMtY29udGFpbnMtcCBzLWVu ZHMtd2l0aC1wIHMtZXF1YWxzLXAgcy1sZXNzLXANCnMtbG93ZXJjYXNlLXAg cy1tYXRjaGVzLXAgcy1taXhlZGNhc2UtcCBzLW51bWVyaWMtcCBzLXByZWZp eC1wDQpzLXByZWZpeD8gcy1wcmVzZW50LXAgcy1zdGFydHMtd2l0aC1wIHMt c3VmZml4LXAgcy1zdWZmaXg/DQpzLXVwcGVyY2FzZS1wIHMtLXRydXRoeT8g cy0tYWdldCBzLS1tYXBjYXItaGVhZCkpDQoNCihkZWZ1biBjb252ZXJ0LXJl cXVpcmUtbWFnbmFycy1zdHJpbmcgKCkNCiAgKGdvdG8tY2hhciAocG9pbnQt bWluKSkNCiAgKHdoZW4gKHNlYXJjaC1mb3J3YXJkICIocmVxdWlyZSAncyki IG5pbCB0KSkNCiAgKHNldHEgZm91bmQgbmlsKQ0KICAoZG9saXN0IChzeW1i b2wgbWFnbmFycy1zdHJpbmctc3ltYm9scykNCiAgICAod2hlbiAobm90IGZv dW5kKQ0KICAgICAgKGdvdG8tY2hhciAocG9pbnQtbWluKSkNCiAgICAgIChz ZXRxIHN5bSAoc3Vic3RyaW5nIChmb3JtYXQgIiVzIiBzeW1ib2wpIDIpKQ0K ICAgICAgKHdoZW4gKHJlLXNlYXJjaC1mb3J3YXJkDQogICAgICAgICAgICAg KGNvbmNhdCAiXFxfPHMtIiAocmVnZXhwLXF1b3RlIHN5bSkgIlxcXz4iKSBu aWwgdCkNCiAgICAgICAgKHNldHEgZm91bmQgdCkpKSkNCiAgKHdoZW4gZm91 bmQNCiAgICAoZ290by1jaGFyIChwb2ludC1taW4pKQ0KICAgIChzZWFyY2gt Zm9yd2FyZCAiKHJlcXVpcmUgJ3MpIiBuaWwpDQogICAgKHJlcGxhY2UtbWF0 Y2ggIihyZXF1aXJlICdtYWduYXJzLXN0cmluZykiKQ0KICAgIChkb2xpc3Qg KHN5bWJvbCBtYWduYXJzLXN0cmluZy1zeW1ib2xzKQ0KICAgICAgKGdvdG8t Y2hhciAocG9pbnQtbWluKSkNCiAgICAgIChzZXRxIHN5bSAoc3Vic3RyaW5n IChmb3JtYXQgIiVzIiBzeW1ib2wpIDIpKQ0KICAgICAgKHdoaWxlIChyZS1z ZWFyY2gtZm9yd2FyZA0KICAgICAgICAgICAgICAoY29uY2F0ICJcXF88cy0i IChyZWdleHAtcXVvdGUgc3ltKSAiXFxfPiIpIG5pbCB0KQ0KICAgICAgICAo cmVwbGFjZS1tYXRjaCAoZm9ybWF0ICJtYWduYXJzLXN0cmluZy0lcyIgc3lt KSkpKSkpDQo= --NGSIRVgOSr--