[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: Mon, 18 Oct 2021 21:13:40 +0000

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.

reply via email to

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