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

[Eli Zaretskii]

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

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

> 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?

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

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