Re: A read-based grep-like for symbols (el-search?) (was Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master))

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:
> On 01.10.2021 19:41, João Távora wrote:

> If analysis is implemented in Lisp, the concurrency will be limited by
> that part. Though I guess you could launch multiple Emacs instances
> and then combine their results somehow.

Yes, that's exactly what I suggested. The combination is a sort
operation, which isn't very heavy for a 1000  matches.

>> * designing a caching strategy seems fairly easy here.
> Probably doable, yes, though both harder than the approach I
> described, and almost certainly slower even with cache (which needs
> regular invalidation). And the first search in the session (without
> cache to fall back on) will likely hurt the most.

You can very well make big parts of the database when building, for
example when byte-compiling.  And you only invalidate when you change a
file.

> Anyway, good luck. I just hope you don't end up with etags-like
> approach where the user will need to built and rebuild the index
> manually every time they want it to be fresh.

No that's not the goal.  The goal is to make a proper symbolic
xref-find-references for elisp which isn't regexp based (and which takes
around 4-5 seconds here everytime, btw...  and sometimes asks me if I
want to apply local variables for a file it's visiting... bug?)

Anyway, the reason I'm reasonably confident this _can_ be done is also
because this _has_ been done, in Common Lisp implementations.  That's
were xref.el comes from, ultimately.  They use even more advanced stuff,
like macroexpansion, so they catch the make-foo of defstruct.  Some
implementations have even more advanced stuff like proper who-calls,
who-sets, who-macroexpands.  They've had it for decades!  Have a look at
SLIME or Sly and plug them to SBCL or Allegro Common Lisp, for example.

João