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]

> We have two kinds of uses for shorthands.
>
> * 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.

> From a programming language design viewpoint, a single solution to cope 
with these two use cases is IMO clearly not TRT.  Because:

(1) the need for a solution to the first use case is essentially a 
consequence of the absence of a solution to the second use case (IOW, a 
few library authors have chosen to use short prefixes in their libraries 
to make them more appealing to use),

(2) the first use case is limited to very few libraries,

(3) the only way to cope with these two use cases (which are the opposite 
of each other) with a single solution is to add a preprocessor-like 
feature to the Lisp read primitive, with which any token can be changed 
into any other token, which is unnecessary for the use case that should 
become the only one in the long term (namely the second one),

(4) a solution to the first use case cannot be a long term solution, it 
can only be a temporary workaround, for example because docstrings are not 
modified with such a preprocessor-like feature.

It would IMO be better to add a proper solution for the second use case, 
together with a temporary workaround for the first use case which would 
work during one major Emacs release, to give some time to the authors of 
these few libraries to adapt their code to the new feature (IOW, to 
abandon the short prefix they use and to use the new feature instead).