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]

Michael Heerdegen <michael_heerdegen@web.de> writes:

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

> Actually, el-search searches expressions.  The search "pattern" is a
> description (predicate) for expressions, and it searches for matching
> expressions.  I made it so that search patterns are pcase patterns -
> while this fits perfectly, it's also the most deterring aspect for most
> people :-P

But of course, but it makes total sense that a Lisp-aware searcher would
be much more powerful like you have designed it.

Much as I applaud that, I think the grep crowd needs to be appeased with
something with a similar interface, though.  The passion I'm seeing in
some messages seems to be about knowing where a particular symbol is
referenced (understanding shorthands, of course).

> Symbols are compared with `eq', so I think the answer to the question of
> fast symbol comparison is "yes".  One surprisingly time consuming part
> in simple cases is setting up buffers (to support read and sexp-based
> scanning).

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.

Also what do you mean scanning, you mean `parse-partial-sexp` aka
syntax-ppss scanning?  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.

> IIRC, "elisp-refs" (Melpa) copied the basic approach and created
> something more lightweight but easier to use (a bit like xref I think, I
> don't use xref - not sure).  I think adding shorthand support to that
> package would also be trivial.

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

João