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" <joaotavora@gmail.com>]

On Fri, Oct 1, 2021 at 4:48 PM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> On 01.10.2021 17:40, João Távora wrote:
>
> >> Certain language designers intentionally limit the language's power due
> >> to usability considerations, keeping in mind their audience.
> >
> > What languages, what evidence for this?  Anyway, many more limit the power
> > due to performance considerations.  Counts as "usability"? I guess. IME
> > language  audiences that are interested in performance usually don't
> > care so much
> > about ergonomics and vice versa.
>
> Go would be one example. The reasoning lies largely in the field of
> usability. Their understanding of it, at least.

Yes Go, I see what you mean.  But it's been growing with new features,
like generic functions.  And has namespaces.  They didn't design it
around grep, that's for sure.  That's what I meant.

> Taking the example from the manual, the clients would be able to write
> ;; elisp-shorthands: (("snu" . "some-nice-string-utils"))
> but not
> ;; elisp-shorthands: (("sn" . "some-nice"))
> and that doesn't sound like a terrible limitation.

I agree.  We could make it a recommendation, i.e. issue a (stern)
warning when we
detect this.  Or not allow shorthands of other forms in Emacs code, ELPA, etc.

> > But
> > possible, yes.  Would you like to work on that `thing-at-pt.el` front?
>
> thing-at-pt? I'm not sure which particular task you are referring to.

thingatpt.el, sorry.  The library used by other Elisp programs when they
want to pick some text from the buffer, at point, that represents a symbol,
a string, a list.  We could have some kind of "symbol-prefix" "symbol-suffix"
or "symbol-part" for eventually telling grep to go search only for that part.

> > That's not the approach I was thinking of, but I hope to present a working
> > prototype soon, which is a better way to present ideas.
> Looking forward to it.

Just realized the default xref-backend-references uses semantic and ede...

Also realized that you do some kind of (intern (format ""...)) there.
Grep heresy!

> Simply doing
>
> (benchmark 1 '(dolist (dir load-path)
>                  (when (file-exists-p dir)
>                    (let ((files (directory-files dir t "\\.el\\'")))
>                      (dolist (file files)
>                        (unless (file-directory-p file)
>                          (with-temp-buffer
>                            (insert-file file)
>                            (read-from-string (buffer-string)))))))))
>
> Reports 2.5 seconds here.

OK, thanks, gonna start with that snippet. Love a good snippet.
Are these Emacs's files? You can read from the buffer directly.  And
you could reuse buffers.
Dunno if it makes a difference.

But even before I do, a good way to solve this is the good old speed-for-space.
aka cache.  No point in reading a file that we've read and hasn't
changed since last
time right?  mtime caches look plausible, and we could even make it so
that visited
files' buffers are also read.

My first challenge will be to check if the reader does source
tracking, or is somehow
pluggable to call a function when it reads a symbol.

João