Re: Proposal: Forwards-Compatibility Library for Emacs

[João Távora]

On Tue, Sep 21, 2021 at 4:02 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> The point here is to not to have any separate namespace, so that you can
> just can put core packages into ELPA without doing any rewrites.
>
> What's the concrete risk here?

It was Philip who described as "intrusive", "by its very nature",
since it relies on advice and such.  This can be seen as "dirty" in itself.
But say that the contract/promise that a given function in Emacs 28 makes
is different from the promise that the same function in Emacs 24.2 makes.
The new ELPA code doesn't have a problem, but you have potential problem
to all the other 24.2 code that expects the "old promise".  Right?

Also macros, defstructs and compile-time/run-time pain,
something-something, hand-wavy-wavy, makes my brain hurt :-)

> I'm not sure how symbol-renaming would help here?  The issue is
> providing an "official" forwards-compatibility library that would define
> all the useful library functions/macros that are added to Emacs so that
> ELPA packages can use these new functions/macros immediately.

Symbol renaming could theoretically help by having the new name,
say "overlays-at" (I think that's an example of a function that
was changed in meaning, may be wrong) be interned as
"overlays-at-in-the-emacs-28-sense".  The ELPA package author
would only write "overlays-at".  In that file the redirection would occur
when needed.  Everywhere else it would be the symbol interned
"overlays-at".

Alas, symbol renaming for older Emacsen is not in scope for my work
(at least right now), so this point may be moot.

João