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:13:40 +0000 Message-ID: <19fca5d18ba8e6409bf2@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: text/plain; format=flowed; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35813"; 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:14:42 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 1mcZxy-00096i-Ls for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Oct 2021 23:14:42 +0200 Original-Received: from localhost ([::1]:34620 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mcZxw-0008U7-Lk for ged-emacs-devel@m.gmane-mx.org; Mon, 18 Oct 2021 17:14:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44520) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcZxF-0007SG-Hf for emacs-devel@gnu.org; Mon, 18 Oct 2021 17:13:57 -0400 Original-Received: from heytings.org ([95.142.160.155]:57142) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mcZx3-0003ka-Qd; Mon, 18 Oct 2021 17:13:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1634591621; bh=QiGLVz8zkxVOgeqRSEZuWJ5Rnm/rke53O5NsT/usXWw=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=wjZYaKyy6an6YJmiH5piOWsf7pA/oh1IzQWclHL6IF/VOdLDupDWtnDkaiWFL1OzA jr7FTNIVebJEfX5JFdb21ES+uK83a+XRYvWtzZ8xeGeByFlVlOqsGF70/K8VaHrOab J8ZbdPAWEVDSYkouvYu5RhKKk+55Nh3tLVBL6xlA7k2yi65Ex5yL23wZ7HcXvbq0J5 oAao3dyQzXGQg2CyjEqxCwFUDdMuc67wCmzvu3KnL2SeD9IFoU0iHAkAbKWsdMZKE2 sRp3JJ+E0HBJiXvSDeSsQchXL6x3oF28xAEaOQECyu4Y4p4FftfEXn4CZCRHFXSY8e ZIhQSKstAhLsQ== 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_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01 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:277321 Archived-At: 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 , it can only be a temporary workaround, for example because docstrings are not modified with such a preprocessor-like feature.