Re: Proposal: Forwards-Compatibility Library for Emacs

[Philip Kaludercic]

Arthur Miller <arthur.miller@live.com> writes:

> 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".

Just to clarify: My point is that I *don't* want to just propose a
different dash/s/f/... library, that consists of only a few new useful
functions and macros.

>> 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))

Why would a user do this?

> 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.

The audience of this library are developers, not (non-developer)
users. The point is not to make older versions of Emacs work like 28 or
newer, but to make code that targets Emacs 28 work with older versions
(insofar this is possible).

> 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.

I agree, it might make sense to remove some of the compatibility
definitions, that just supply an additional argument. I'd argue there
are cases where it makes sense, such as assoc and the testfn argument,
but they have to be evaluated.

> 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.

A different idea might be to try an integrate the compatibility layer
into the byte-compilation process for specific files. But once again,
this wouldn't be done by the user, but a (package) developer would
request for it to be done.

>> 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? 

I know, I am currently working on writing a test suite with ert.

>> 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?

Yes, but I respect the opinion of the list and would like to add this to
ELPA, so good objections could change my mind that it is worthwhile to
implement something like this to the end.

-- 
        Philip Kaludercic