From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie 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 17:25:56 +0000 Message-ID: References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <831r59kyhf.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15947"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Phil Sainty , joaotavora@gmail.com, 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 19:27:41 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 1mVGtJ-0003uQ-Az for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 19:27:41 +0200 Original-Received: from localhost ([::1]:36892 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mVGtI-0007Lj-6k for ged-emacs-devel@m.gmane-mx.org; Tue, 28 Sep 2021 13:27:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mVGrt-0005I6-LP for emacs-devel@gnu.org; Tue, 28 Sep 2021 13:26:13 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:15492 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mVGrq-0005tf-5P for emacs-devel@gnu.org; Tue, 28 Sep 2021 13:26:13 -0400 Original-Received: (qmail 35358 invoked by uid 3782); 28 Sep 2021 17:25:56 -0000 Original-Received: from acm.muc.de (p4fe15cfd.dip0.t-ipconnect.de [79.225.92.253]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 28 Sep 2021 19:25:56 +0200 Original-Received: (qmail 20972 invoked by uid 1000); 28 Sep 2021 17:25:56 -0000 Content-Disposition: inline In-Reply-To: <831r59kyhf.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:275712 Archived-At: Hello, Eli. On Tue, Sep 28, 2021 at 09:25:48 +0300, Eli Zaretskii wrote: > > Date: Tue, 28 Sep 2021 13:38:09 +1300 > > From: Phil Sainty > > Cc: emacs-devel > > This has probably been covered in earlier discussions (apologies for > > not being across those), but... > > Won't this break a ton of basic tooling for locating things, if the > > symbol in the file is not the actual symbol? > Those tools will need to be enhanced to support shorthands, yes. I thought that large features weren't being accepted for Emacs 28 any more? These "shorthands" are a gigantic feature which disrupt our way of developing Emacs. Can we please delay the release of Emacs 28.1 until we have these tool enhancements in place? And until that point, have a moratorium on using shorthands? I only found out about this feature today, since there has been nothing in the Subject: lines of the discussions indicating the breakage that is occurring. > And this problem is not new, we had it for a while with other Lisp > constructs where generated symbols aren't literally present in the > sources. For example, try M-. on a call to a constructor defined by > cl-defstruct. Surely that is no reason to make the situation worse? > Here's one such use case: > emacs -Q > M-x load-file RET lisp/profiler.el RET > C-x C-f lisp/profiler.el RET > C-u 10006 M-g c ;; this puts point on a call to profiler-make-calltree > M-. > The result is an error message. This happens to me quite a lot > recently, as more and more code is converted to using cl-defstruct. Recently, I made changes in the jit lock area. An essential part of that was to find all uses of the symbol jit-lock-functions. This was straightforward: $ find . -name '*.el' | xargs grep -n jit-lock-functions This returned for me _ALL_ uses of jit-lock-functions in Emacs (plus quite a few comments, too). I have done this time and time again with various symbols over the years, and surely you have, too. As shorthands spread, this won't work any more. If we must proceed with this facility, can we please delay it until there's some suitable replacement for such a use of find and grep and other similar things? > > Simplicity can be a *very* good thing, and knowing that what you see > > is in fact what you get is a benefit which shouldn't be undervalued, > > IMO. > 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? I strongly dislike cl-defstruct and add-function (as, I think, you do), and also, for different reasons, pcase. Macros which produce symbols are OK, as long as these symbols, with the same meaning, don't appear in source code. Or sometimes even if they do. I think we would largely agree on when a macro is objectionable, even if that is hard to pin down exactly. > > Is whatever we're gaining actually worth the resulting obfuscation? > Time will tell. It currently sounds like its worth it, but as with > any such feature, we could be wrong. And if we are wrong, what then? This feels like an irreversible change. Why are we not trying it out in a development branch rather than (what is shortly to become) the release branch? > > 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. The real reason is to make namespace > management easier. I don't think, on balance, it will do this. -- Alan Mackenzie (Nuremberg, Germany).