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

[Gregory Heytings]

> > > but it's the wrong tool.
> >
> > And what is/what are the "right" tool(s) for the above use case?
>
> Tools that understand the symbolic nature of the Lisp family of 
> languages. For the examplw you have since, Tools that rely on way or the 
> other really on the 'read' Lisp primitive.
>
> xref-find-definition does. xref-find-references doesn't, yet, as far as 
> i know. C-h f is fine, and so is completion-at-point.

Which means that you basically have to load all ELPA packages into your 
Emacs session to answer a question that was so far trivial to answer 
(which packages use such-and-such function or refer to this-or-that 
variable).

> Grep, as you very well note, is already flawed, not only for Lisp, but 
> for many languages. By "flawed" I mean: it is not suitable for 
> categorically answering questions e.g. about how functions relate to 
> each other (callers and callees).

It's not flawed, it's not perfect, like pretty much any other tool (and it 
has been around long enough that its users are aware of its limits). 
Even a tool that would be aware of the Lisp read primitive cannot 
categorically answer that question, for example when function names are 
created dynamically, or with (apply variable args).

> It fails even on C, for example by the mere existence of comment blocks. 
> Should comment blocks be outlawed in C?

Of course not.  And comment blocks are not a problem AFAICS, visiting the 
file will clearly show that this is not an actual call.  In C it's 
preprocessing that is a problem.  And function pointers.