emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposal: Forwards-Compatibility Library for Emacs


From: Arthur Miller
Subject: Re: Proposal: Forwards-Compatibility Library for Emacs
Date: Tue, 21 Sep 2021 16:05:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Philip Kaludercic <philipk@posteo.net> writes:

> 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.
Yes I understand that your point wasn't to create another s.el, but I didn't
understand from your mail why would that be a bad thing :). I was just refering
to your rhetorics: what is wrong with s, dash? They do well what they do. That
does not mean that I suggest you should do another "s.el"; I was just trying to
talk about it in general. I don't 

By the way, uour library would not be "another s, dash ..." per definition
:). You don't do what they do; and  Can we talk about things in general? So I
don't see why bringing in s, dash and other in this as they were a bad thing?

>>> 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?
Because the user runs older Emacs and all the 3rd party packages that might be
affected by an advised function with possibly changed behaviour. So user can
verify it works or not and developer does not need to burden itself with
different execution paths, which in long run makes code that is easir to
understand and maintain.

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

Yes, I understood that, and the problem is not when  you provide new functions,
but when existing functions are slightly changed. As a developer it can be very
hard to know how it will affect some 3rd party package in some older
version. Developers would have to test in old versions as well etc. I would
really dislike Lisp code to look like C code we seen in Emacs src; those if-defs
are really nasty sometimes.

>> 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.
Indeed, but sounds like a labourous thing to implement. You could also do
something similar if you checked at package installation what a packages uses
and installed a compat layer, but it seems like a lot of work and an unreliable
approach. Both approaches would have to patch code in old Emacs (byte compiler
or package.el). Would be cool thing to see if you manager ot pull it off, but I
think it is a lot of work.

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

Yes of course. I am not sure if mine are very good, but, good luck, I hope you
get something that works.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]