From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) Date: Tue, 28 Sep 2021 08:41:29 +0100 Message-ID: <8735ppdu52.fsf@gmail.com> References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <831r59kyhf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1844"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Phil Sainty , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Sep 28 09:43:46 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 1mV7mE-0000DG-5N for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 09:43:46 +0200 Original-Received: from localhost ([::1]:54666 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mV7mC-0005DP-72 for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 03:43:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mV7k8-0003Fh-Ip for emacs-devel@gnu.org; Tue, 28 Sep 2021 03:41:36 -0400 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:41780) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mV7k3-0003OW-B0; Tue, 28 Sep 2021 03:41:36 -0400 Original-Received: by mail-wr1-x433.google.com with SMTP id w29so56194016wra.8; Tue, 28 Sep 2021 00:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=bq4s+ut4MYj8QRXhnNQ6JKEC1gspoQCGjpO4fRtPUgQ=; b=lt5AYwcG++lFPm8NPq6hBT9SOXYQC+ET5K3fPDhAVSnRQ6k11J7bz2psUpLnzSrdUL /AMuUrXgt8Q5nQHUkbIK5yg3JsyUmJdkCZQfqgbWBjqPGgNYH+kXTu/ekRxVjbooOFCD ijC36galkV5qaDduu2HY+2miA74ixwqjV0wH0SDSSNfwzzvm6V3d0M+HM8skl4spY+0A ebiqrN942606Aijhsnrog8yfDbfbZ4IX3u2ABmHddXM9BwQM4OksysRRy+0erZovbCsn iZr5SRpKqdXu8WC816l+K81eGiNNSItEcitinzYqjvjbq0Fzavn7Nf867Rr8Ing/cOkR o+5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=bq4s+ut4MYj8QRXhnNQ6JKEC1gspoQCGjpO4fRtPUgQ=; b=EjYLQ6chtihDrUksiMEoAGfzZlVMxFc23a6YeXCYIJE5XIzuWndwQx2+Exm9gVXPvJ TY3cZbX6BzNaUfO/L1SbH21uvGMyDOCShMsfh0G7ZWp/kjAEqJZsQItqO0H0yzmHWuX3 LZAEt8sKLIl7crJsct7XufdGDFfVctn1TagctUajTIPzmlykApiUoH68t731SzVI+NS/ Gn0fZq/36uldX7WsG8qZFcyZHTiGQ/2swY9o/G39B0NtGGpoNSXomRZNNNTXyjO3BayU BR13RZmbBswiSwz5D17DD+be1plJzoADP/NOf6iFj9Bz/9eHwTKuyqwpzB26trI3KuTF hLAQ== X-Gm-Message-State: AOAM533cd9IPQCfK4Srk2v1hvXHAKJPWJNntnHuk6kfq2yWMrcOMc9Qw O3pqOjmpJIdkHLBJ5F7jm3GPVlnVGOE= X-Google-Smtp-Source: ABdhPJwlT+3hOJ6MdtPTqjXlP9OgOVpTqHZ28XkV9RJlC+hvXFWDyCgn5HLkm3q2Y4MLJDCnr/6CSw== X-Received: by 2002:adf:e44c:: with SMTP id t12mr4767335wrm.49.1632814889060; Tue, 28 Sep 2021 00:41:29 -0700 (PDT) Original-Received: from krug (a83-132-177-247.cpe.netcabo.pt. [83.132.177.247]) by smtp.gmail.com with ESMTPSA id n68sm1840052wmn.13.2021.09.28.00.41.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Sep 2021 00:41:28 -0700 (PDT) In-Reply-To: <831r59kyhf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 28 Sep 2021 09:25:48 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x433.google.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:275665 Archived-At: Eli Zaretskii writes: > Those tools will need to be enhanced to support shorthands, yes. One way grep could start working more to our liking is if one is given the ability to grep by either the prefix or the name. Maybe (thing-at-point 'symbol-component) could be added. Unfortunately, it is not always so, even before Shorthands. CL packages are more structured in this regard: there's the package and the symbol name. The family and the identity are not "weakly" mangled in the symbol name. > Then I guess you dislike cl-defstruct, add-function, pcase, and other > macros and features that change how the source code looks and produce > symbols under the hood? Those are so-called anaphoric macros. For the record, the Common Lisp implementations that I used deal fine with them, because they index the macroexpanded code in a database after reading the original code with a "source tracking Lisp reader". I.e. they are not 'coupled' to the non-macroexpanded text. Then, in tools like SLIME or SLY there are tricks to know where that text has drifted in the buffer. I don't know what kind of databse is used by Xref, which is relatively recent, but I suspect it's a more naive database. Nevertheless, I'd like to note that Shorthands work well with Xref's main workhorse (M-.) probably because it uses the proper API for symbols, obarray. They also work well with Eldoc, C-h f and in-buffer Completions, to the best of my knowledge. >> Long names being "tedious" (quoting the new info manual) to read >> and write seems like an insufficient reason, IMHO. > They are not the real reason, they are just the way to explain the > feature in simple terms. For me, it's a very real reason! I added that there :-) It's tedious to type _and_ read. > The real reason is to make namespace management easier. That is also another reason I concur with (and this is why it is also written in the manual). Jo=C3=A3o