[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A read-based grep-like for symbols (el-search?) (was Do shorthands b

From: Gregory Heytings
Subject: 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))
Date: Sun, 03 Oct 2021 21:17:26 +0000

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]