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 8:03 AM <tomas@tuxteam.de> wrote:

> All those "magic action at a distance" things (and name prefix
> goes in that direction, but many things you see in contemporary
> Web frameworks do this too) make life harder for the "grep
> crowd".

Yes, of course.  So-called higher-level languages are all about
indirection. Pointers, function pointers, late binding, garbage
collectors, duck typing, namespaces,,, they all give us something and they
take something away.  Every time.

Grep is a tool, a tool to search text.  It is only able to respond to
questions about a program's source when that source is written in text
files (which it normally is) and when the programming language is
relatively poor on indirection.  Or to put it another way: the
usefulness of grep as a program-related question-answering machine is
inversely proportional to the indirection mechanisms in the language in
question and its expressive power (aka the power to say more with less).

That doesn't mean that one can't devise tools to answer questions about
programs in a way that makes _less_ assumptions about the multiple ways
in which these program's sources are encoded.

And the 'read' based tools that we're discussing in this thread are
efforts in that direction.  They will still be fallible, no doubt, but
not in the ways grep is.  And grep will still be useful.  I'll only be
slightly _less_ useful because a new language feature has increased the
number of questions that can be asked about a source.  But that is what
indirections ALWAYS do.  "What is this pointer pointing to?", "What
version of this C lib am I linking against?", "What the heck is the GC
doing", "Is this object that responds to .quack() really a duck?", etc
etc.

(Curiously, this is _exactly also_ the reason why these features are
also culpable for performance degradations, something that we're much
more trained into accepting, because we experience them less directly)

Language design never has been held back by the particular assumptions
of a search tool, popular and ubiquitous as it may be.

And it's frankly a bit bonkers to even conceive that. When I can, I _do_ put
the C brace on the function definition line so that grep tells me if
it's the definition or the declaration I'm looking at, but how crazy
would it have been to force C not to have forward declarations BECAUSE
it could hurt grep?? (as it quite obviously does!).

That's why these "modern web frameworks" are causing you "grep pain".
But programs today (and for a good number of years) and even more, the
ever complex programs in the higher-level languages of the future will
even cause you more pain!

It's the job of development tools -- with the Editor at the center -- to
help the programmer navigate these things.  Hence M$ IntelliSense, hence
SLIME, hence LSP, hence xref.el, etc, etc, etc.  Emacs is in a very good
place in this regard, to be honest.  We have incredible talent and Elisp
is a very good language, way waaayy better than JS, for example.

> Now the question: does it also find things hidden away in comments?
> This is one feature I wouldn't like to miss, as part of the "grep
> crowd".

The first iteration of the tool I'm thinking of answers questions like
what is referenced by source code, today.  It doesn't answer "what could
someday be referenced when one uncomments lines".  A symbol name stuck
in a comment probably shouldn't be there, at least not in Shorthand
form.  And anyway Shorthands don't operate on comments, so the point
may be moot.  So the answer is that it can be done, but not in this first
iteration.  I will think about it, though.

> Now I don't think this is in itself a reason to not do it. I've
> missed some kind of name space mechanism in Emacs for ages.

Of course!

> But taking the grep crowd into consideration is a nice touch; you
> might find yourself in that place some day, while wading through the
> swamps of a foreign country :-)

Yes.  The things that said here are taken into consideration ;-) And yes I
use grep.  To "wade" into your delightful image, it's like using made-up
sign language in a foreign country: it'll get you places, but you won't
be reading the classics or chatting up the bear that wants to eat you.

João