Re: Proposal: Forwards-Compatibility Library for Emacs

[João Távora]

Tue, Sep 21, 2021 at 5:10 PM Philip Kaludercic <philipk@posteo.net> wrote:
>
> João Távora <joaotavora@gmail.com> writes:
>
> > 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?
>
> Yes, that is why full compatibility isn't possible, but on the other
> hand, these kinds of changes are not that common to begin with.

That's true, but they do happen. Emacs is not fully 100% backward
compatible.

I don't have the biggest of pictures in my head, but for me the solution
lies in providing more and more packages as :core.  In the Eglot circle,
for example, most of the flymake.el, project.el, xref.el, jsonrpc.el
dependencies are themselves :core ELPA packages.  So Emacs 26.3
users can use Eglot with all the latest and greatest that is in trunk,

Just my 2 cents,
João