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: Sun, 03 Oct 2021 21:17:26 +0000 Message-ID: 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="22735"; mail-complaints-to="usenet@ciao.gmane.io" Cc: tomas@tuxteam.de, emacs-devel@gnu.org, joaotavora@gmail.com, Dmitry Gutov To: Richard Stallman Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 03 23:18:17 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 1mX8sC-0005fk-Ua for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Oct 2021 23:18:17 +0200 Original-Received: from localhost ([::1]:42038 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mX8sB-00040y-0F for ged-emacs-devel@m.gmane-mx.org; Sun, 03 Oct 2021 17:18:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52540) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mX8rT-0002cu-9J for emacs-devel@gnu.org; Sun, 03 Oct 2021 17:17:31 -0400 Original-Received: from heytings.org ([95.142.160.155]:35818) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mX8rR-0002Mk-D9; Sun, 03 Oct 2021 17:17:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20210101; t=1633295846; bh=RoI3mO4JqrRd3mBarr5DDcMP7Ne22sPwf0icEfgqlhU=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=gSszvEQwdePMo+pZkr1dfP1WE4dYSLIWhbVVfRi89OP/I9CjwBjDXuXcZwA1YLzri c//wla0XKfJFPVjaFe6rccQLkOSFt22xnnnYvKKKfKzN90ikvNbaXP9/3V3LM0p8ph AK5nBeMsR5lFpUKM+Qx3BEml1eJcvcpJjiWWVb5AqCoEf11owms67a/oENKFEptlxE Kc0Bj+C9RawXf0iD4R+qNVaw8yl/rcPDXw/vfwCxe9/x/sOLzHkUhHfdvAtRntW3Mq 2yV+3mJ9tux68pYspyupW1ReB83kEpJKiuJaCEHkMlARupqxHb+vr3OqSJXBQ68oEH 0TEzI3FKii0Qg== 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:276134 Archived-At: > > We have two kinds of uses for shorthands. > > * 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. > >From a programming language design viewpoint, a single solution to cope with these two use cases is IMO clearly not TRT. Because: (1) the need for a solution to the first use case is essentially a consequence of the absence of a solution to the second use case (IOW, a few library authors have chosen to use short prefixes in their libraries to make them more appealing to use), (2) the first use case is limited to very few libraries, (3) the only way to cope with these two use cases (which are the opposite of each other) with a single solution is to add a preprocessor-like feature to the Lisp read primitive, with which any token can be changed into any other token, which is unnecessary for the use case that should become the only one in the long term (namely the second one), (4) a solution to the first use case cannot be a long term solution, it can only be a temporary workaround, for example because docstrings are not modified with such a preprocessor-like feature. It would IMO be better to add a proper solution for the second use case, together with a temporary workaround for the first use case which would work during one major Emacs release, to give some time to the authors of these few libraries to adapt their code to the new feature (IOW, to abandon the short prefix they use and to use the new feature instead).