emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorth


From: João Távora
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
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> 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ão



reply via email to

[Prev in Thread] Current Thread [Next in Thread]