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

[Gregory Heytings]

Hi Richard,

Thank you for your kind and courteous answer.  Sorry for my belated reply, 
I had to think about this a bit.

> For reference, these are the two use-cases:
>
> > > * Creating longer real names to avoid collisions. In this kind of case 
> > > the package that you load creates shorthands for itself, which rename 
> > > its symbols to longer names that won't conflict.  This is what we will 
> > > do with s.el.
> > >
> > > * Creating shorter names for convenience. In this kind of case, one 
> > > Lisp file would create shorthand prefixes for code in other files. 
> > > These prefixes might really be shorter than the symbols' documented 
> > > name.
> >
> > (4) a solution to the first use case cannot be a long term solution,
>
> We need a long term solution, and that's what this is intended to be. 
> It is a good solution because it avoids the need to convince hundreds, 
> perhaps thousands, of library authors that we are not in communication 
> with to change the way they write calls to Magnars's libraries.

I understand that it is intended to be a long-term solution, but it is 
not.  We cannot convince all these library authors to change the way they 
write calls to Magnars' libraries, yet with the chosen solution, it will 
nonetheless be necessary to adapt each Elisp file they write, by changing 
the (require 's) into a (require 'magnars-string) and by adding a 
read-symbol-shorthands local variable at the end of these files.

The proper solution to that problem, which does not require to change a 
single byte in any of these third-party Elisp files, would have been to 
create a hook that is executed on the file contents before it is processed 
by





, it can only be a temporary workaround, for example because docstrings 
are not modified with such a preprocessor-like feature.