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

[Michael Heerdegen]

João Távora <joaotavora@gmail.com> writes:

> The passion I'm seeing in some messages seems to be about knowing
> where a particular symbol is referenced (understanding shorthands, of
> course).

Absolutely understandable.

> I'm going to vapourwarely say that can be optimized if you pass a
> function as the STREAM argument to `read`.  Maybe?  You'll always need a
> character buffer somehow, but perhaps you don't need to setup a big one
> expensively.

`read'ing per se is not difficult.  But (from) where do I read, and
what?  Where does the code start?  What are only comments - what's not
there as code but part of a string (e.g. docstring)?  And there may be
other stuff the file may set up (like, now, shorthands).

> Also what do you mean scanning, you mean `parse-partial-sexp` aka
> syntax-ppss scanning?

Yes.  And sure, that's necessarily a part of such an algorithm.

> That's much more expensive than `read` and used for font-lock, C-M-
> navgation and such.  A more basic, faster searcher wouldn't need that.

That's why I made it so:

There are two steps: the first step is very fast and doesn't use that.
It kicks out all candidates where it's sure that there are no matches,
just by looking at the symbols, without sexp-level parsing.

The second step is slower but only has to look at the rest (a tiny part,
most of the time).


> Interesting, and closeness to xref.el is indeed very useful.

elisp-refs is not unpopular - someone might want to have a look at it.

Michael.