From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.devel Subject: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) Date: Fri, 1 Oct 2021 02:44:25 +0200 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2441"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Mackenzie , Eli Zaretskii , =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= , Emacs developers To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 01 02:46:14 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 1mW6gn-0000RF-D0 for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Oct 2021 02:46:13 +0200 Original-Received: from localhost ([::1]:41148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mW6gm-0004pq-3R for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Sep 2021 20:46:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39140) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mW6fK-0003sf-5R for emacs-devel@gnu.org; Thu, 30 Sep 2021 20:44:42 -0400 Original-Received: from mail-pf1-f176.google.com ([209.85.210.176]:43905) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mW6fH-0000gj-T6; Thu, 30 Sep 2021 20:44:41 -0400 Original-Received: by mail-pf1-f176.google.com with SMTP id 187so2054581pfc.10; Thu, 30 Sep 2021 17:44:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7KVt2alyXNh59nP8E7gbAR79i5Ng3eZ5JTwZ+AXcQ+o=; b=V36H6B7NnO5V9JpmHAVbsYDrQZSvFi6KoWar4agOn92VNi9TbzhtOvVv+Jke/QX1Xx skS2eugvYz/eBrD6sjLwHyBdGh7W/z7++qkiLWgQMgX8T0gkPWS4zTJd/Jb17B2MMdoT IPlARyyP7IRZg178brBsF3wjCW7Ava5FfsHrk+zk7M/Z0RnhQrMhghpkU7sPpYa+e/a0 xNfSmqPPhNDcCQepRsJg5TFbssbkCm8Kn9AoRszdMcuD5YN/SVJjxTH62SbZlmEOyorV e+da+T+9bXlwsYb7UaVJeSq8SIVS/iBUPRUCLJB3ss6OEWRpzr5dejIyJQtf9kiJwJvh kyag== X-Gm-Message-State: AOAM531QarySi6C63xR8DeiPOfPYxZ8G7tkP7s5+GvrQLJaU1MbyXrNv BApoAo21ZiFoWHnBdc5F95yG6ph5Mr8x2J3aj3s= X-Google-Smtp-Source: ABdhPJwFTQdN8tukDeTf7jg3UIo4MEiD0/zvSo7s5TUitbj43HQdz+Di3LHp/Yy1JkTo0nDZGsJjfF40pDIwGpw9KgA= X-Received: by 2002:a63:4717:: with SMTP id u23mr7277950pga.359.1633049077714; Thu, 30 Sep 2021 17:44:37 -0700 (PDT) In-Reply-To: <604da2cb10ac61f2b8b89a02c89056be@webmail.orcon.net.nz> Received-SPF: pass client-ip=209.85.210.176; envelope-from=stefankangas@gmail.com; helo=mail-pf1-f176.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:275941 Archived-At: Phil Sainty writes: > We are now talking about the second use-case, which has nothing > to do with "s.el" (and which I'm proposing should have nothing > to do with 'shorthands'). > > In this scenario the files that lisp reads will always contain > the real symbols, so no extra lisp support is required. The > lisp reader never sees the short names (and nor does any person > who has not opted in), because they don't actually exist in the > file. > > 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. [...] > No, I'm talking about a feature (possibly already implemented by > the "nameless" library; I still need to experiment with this) > whereby people would be able to type their short symbols when > editing their source code and Emacs would recognise the > abbreviation and *automatically* (hence more like abbrev than > dabbrev) change it to the real name. This idea strikes me as better than what shorthand provides. On paper, at least. The benefit of nameless is that I don't need to read the package name. With the above I a) would not need to type the full package name, b) could do this for any external package I want, c) could configure which abbreviations are used. Basically this takes the best of shorthands and nameless, and combines it in a way that will give us all benefits of shorthands without affecting 'read' or Emacs Lisp on a fundamental level. It removes the main reason to use dash.el or s.el, which is their short prefixes. The more we discuss this, the more misgivings I have about shorthands. Something like what is described above could be a serious contender to shorthands, but we unfortunately do not have time to explore that or any other option given that shorthands is already going in so close to the release of Emacs 28. For now, it is just an idea of course, but shorthands was also mostly an idea until this week (at least publicly). On a separate note, but related to my misgivings: If this really is mostly about s.el, dash.el and f.el, I think it is problem that this is featured so prominently in the ELisp manual. To my eyes, what we have now is basically an implicit recommendation and a statement that it is unproblematic for general use. I believe there is a clear risk that users will use this feature in ways that many of us AFAIU (from reading this thread) would expressly rather avoid. Finally, I think the existence of shorthands, and the work it will cause in all of our tools, workflows, etc. means that people will be more reluctant to accept proper namespacing later. "Why do you need that, just use shorthands", or "shorthands caused X, Y and Z to break and now you want to break everything all over again". In other words, as a person who strongly disagrees with the namespace critics, I worry that shorthands will stand in the way of something more proper. Just my two cents.