Re: Proposal: Forwards-Compatibility Library for Emacs

[Arthur Miller]

Philip Kaludercic <philipk@posteo.net> writes:


> The idea is to allow developers who don't want to break backwards
> compatibility to use newer functionality that wasn't provided in older
> versions of Emacs. This version tries to implement as much as possible
> from Emacs 24.2 onwards.
>
> By its very nature it is an intrusive package, as it defines functions,
> macros and advice outside of the "namespace", but I don't see any way
> around that if transparent compatibility is to be provided (anything
> else would just replicate dash, s, f, ...).

Is there a problem if something replicates something else? :) If it is a good
thing, we just call it a "design pattern".

> As some of the functions are lisp reimplementations of core functions,
> there exists the risk of a performance overhead. To minimize this, the
> compatibility layer is only applied necessary: Ideally someone using
> Emacs 28.1 should have a quasi-empty file, with all the definitions
> byte-compiled away.
>
> Eventually I would like to propose adding something like this to
> ELPA. It would only makes sense, as more than a few functions were
> copied verbatim or quasi-verbatim from Emacs itself.

I had a similar idea once, and I think it definitely belongs to an external
package.

If you had this as an external library, than people who use older Emacs:es could
install compat-libs as a package, and in cases where there is a compatibility
function provided, they would just load a compat library after a package is
loaded.

Say I use dired-empty-p which is introuded in Emacs 28, in "some-program". A 
user
of some-program could then:

(with-eval-after-load 'some-program
  (require 'compat-lib-28))

I am just a bit concerned about all-in approach. As I udnerstand your code, it 
is
loaded as a library, and all code is loaded at once. So there might be code that
affects files and naming, or they might be coad that affects displayign of
windows, frames or code of handling user input etc. User might not want to load
everything and change behaviour of his/her entire Emacs. This might also lead to
unnexpected problems when there are 3rd party packages that rely on the old
behaviour.

I would rather prefer if compat-lib-28.el (or whatver called), would check on
it's features it overloads.

Easy case is wiith named features. It could check if user has loaded dired, and
load it's compatibility functions for dired that were introuded in emacs 28, and
it could also put itself in with-eval-after-load statement, so that if some
feature is loaded again, it loads itself. Harder is case when library does not
export a named feature, like files.el. 

That would provide for transparent "namespace" handling as you describe in your
next paragraph.

Of course, newly introduced functions are not the problem; I am concerned with
already existing functions, which might have changed slightly how they
function. I don't know if such exists, but I am thinking that some code could be
broken or still not function, despite function being advised to '28 version'.

I think it is important to not load and advise too much. If a program uses only
function foo, than there is no need to twinkle with function bar.

Another thing I was thinking of is use of advice. Advice is global, it means it
affects all users of the function. Isn't it better to define a buffer-local
variable, stash old function in the variable, and than call this buffer-local
from the compat function. That would also require compat layer to be a minor
mode, which is why I call it a layer rather than a library. User would have to
do slightly more:

(with-eval-after-load 'some-program
  (require 'compat-lib-28)
  (compat-mode +1))

That way the risk of conflicts when function has slightly change from it's
previous version is minimized since it will run only in that buffer, affecting
(hepofully) just 'some-program.

Or something ... I don't know; those were just thoughts, maybe I am wrong about.

> There still is work to be done, before anything could be added to ELPA,
> especially providing tests to ensure that the compatibility layer is
> implemented correctly, and making sure that no functions are used that
> break the compatibility promise.

Ert tests provided in version it provides compatibility for can always be used,
when there are some? 

> So before I continue working on this, I would like to ask if there is
> any interest/there are any objections to providing such a library?

Why should there be objections? It is free to write a library and give it to the
world, right?