From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) Date: Fri, 01 Oct 2021 09:09:44 +0300 Message-ID: <83a6jtff87.fsf@gnu.org> References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <831r59kyhf.fsf@gnu.org> <834ka4k15m.fsf@gnu.org> <83y27gijmz.fsf@gnu.org> <8335pmgnjy.fsf@gnu.org> <604da2cb10ac61f2b8b89a02c89056be@webmail.orcon.net.nz> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37315"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, joaotavora@gmail.com, emacs-devel@gnu.org To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 01 08:11:50 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 1mWBlu-0009Xk-6l for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Oct 2021 08:11:50 +0200 Original-Received: from localhost ([::1]:59514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWBlp-0002Hs-Jm for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Oct 2021 02:11:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52264) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWBki-0001ZA-28 for emacs-devel@gnu.org; Fri, 01 Oct 2021 02:10:36 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:42868) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWBkh-0002z0-4Q; Fri, 01 Oct 2021 02:10:35 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1567 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWBkB-0005aG-CV; Fri, 01 Oct 2021 02:10:19 -0400 In-Reply-To: <604da2cb10ac61f2b8b89a02c89056be@webmail.orcon.net.nz> (message from Phil Sainty on Fri, 01 Oct 2021 11:50:14 +1300) 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:275951 Archived-At: > Date: Fri, 01 Oct 2021 11:50:14 +1300 > From: Phil Sainty > Cc: acm@muc.de, joaotavora@gmail.com, emacs-devel@gnu.org > > The *negative* impact of shorthands is limited iff the use of > shorthands is limited to targeting a small number of problem > libraries. The intent is to use this only when necessary. So yes, the use is supposed to be limited to those few cases, at least in Emacs. > This use case is purely about enabling the people who opt in to > type and see their short names when editing the source code, but > with the real/longer names being the actual text. And I'm saying that this will be a bad solution, since many features that identify symbols by name will not work with those "display-only" names that the user sees. So using something like that is a net loss for users: it "fixes" a minor readability issue, but introduces major usability issues. > We might not allow any shorthand code in Emacs itself, but if > shorthands are understood to be the in-built solution for > reading and writing short names then all kinds of third-party > code is going to start doing exactly that. A very large > proportion (I would assume a majority) of Emacs users will be > using third-party code in their configs, and hence many of > them/us will inevitably acquire shorthand code in our configs > even if it is not core Emacs code or "s.el"; and the more such > code that emerges, the more problems people will have. We cannot control what third-party code is doing. If you and others don't want that to happen in third-party packages you use, the onus is on you and others to complain to the respective developers, just like you now (prematurely) complain here, and ask them not to abuse the feature. In any case, I don't understand what this has to do with Emacs: nothing can prevent third-party packages from inventing something like shorthands and starting to use that in their own packages. The existence of shorthands in Emacs core is not a sign to anyone that the feature can be abused. We in the Emacs project development cannot be held responsible for irresponsible acts of others, it is highly unfair for you and others to hold us to such a standard! > This will affect people debugging their own configs; people > sharing code with other people; people submitting bug reports > or help requests here on the mailing lists and elsewhere. > Whether it's something they can't figure out, or a frustrating > stumbling block that they do figure out, I think it's going > to create a lot of unnecessary problems. Sorry, not our problem. If and when this happens, please take it up with people responsible for making it happen. That's not us. > I'm saying that code which does not contain shorthand symbols > is *easier* (on average, for the Emacs user base as a whole) > to deal with than code which does contain shorthand symbols, > and so let's not bless shorthands (even tacitly) as the > standard solution for anything which can be done in other ways. Nothing in Emacs is "blessed" unconditionally. Each feature has its intended use, and those who attempt to use it outside of the intended scope are responsible for the consequences. I can assure you that nothing like that will ever happen in Emacs, not on our watch.