Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master)

[Alan Mackenzie]

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 <psainty@orcon.net.nz>
> > Cc: emacs-devel <emacs-devel@gnu.org>

> > 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).