Re: Proposal: Forwards-Compatibility Library for Emacs

["João Távora" <joaotavora@gmail.com>]

Stefan Kangas <stefan@marxist.se> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Can symbol-renaming help here, perhaps?  I believe João is trying to
>> get it ready in time for Emacs 28.
>
> This sounds potentially exciting, especially with the two recent
> posts, one from Richard and one from Eli, mentioning this work.  The
> last post on emacs-devel that I can find about "symbol renaming"
> before that is from May 2020, and AFAICT it was buried in a
> sub-thread.

Yes, it was discussed in a subthread about namespacing.  I think I
outlined the main approach there, and pointed to some code once or
twice.  I had originally an Elisp-only version, but then crafted a C
version.

Symbol renaming, also known as "shorthands", is a namespacing system for
Elisp.  Like all namespacing systems, it's about referring to the same
thing by different terms.  Much like in this thread, if I write "Eli"
it's obvious who I'm referring to: I don't have to write the full "Eli
Zaretskii".  But if I write "Stefan", there is ambiguity.

Elisp shorthands were designed to disturb Elisp's existing practice of
one global obarray as little as possible, and so their implementation is
fairly short, and they work at the reader level.  As always, only one
obarray exists, and symbols are always "interned" there under their full
names.  However, the developer may setup certain shorthands so that she
can write i.e. "s-concat" in her file, while still having the symbol
interned as the proper, more hygienic, and much harder to type
"the-magnificent-string-library-concat".  This can be customized
per-file using a file-local variable not unlike lexical-binding.  There
is no difference in what kind of Elisp entity (function, variable, plain
symbol) the symbols refer to: Elisp shorthands are agnostic to that.  

I'm currently working on the documentation, which I hope to be able to
clear the most obvious/burning questions.  I ask you to hold them off
for some days to give me time to clear things up there (yes,
xref-find-definitions and eldoc are working :-) )

> Perhaps this would be a good time for a new post that explains the
> current status of this, with a quick re-cap and perhaps even some
> code?  (If there exists a branch, I can't find it.)

If you're very curious, you can find some code (and tests) in the branch
scratch/shorthand-namespacing, but that _isn't_ the latest version.
(though it _should_ be working).  Indeed I thought I had published the
most recent version to our Git repo, but it seems I haven't (which means
I must get back to my other machine as push it asap).

João