Useful package? Compat.el

Useful package? Compat.el

[Timothy]

[-- Attachment #1.1: Type: text/plain, Size: 408 bytes --]

Hi,

I’ve recently come across an interesting looking library available on ELPA,
<https://git.sr.ht/~pkal/compat>. I’m thinking in future this could allow us to
both use newer features and also support older versions of Emacs, e.g.

Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and
newer with compat.el.

Just tossing this out as an idea :)

All the best,
Timothy

[-- Attachment #1.2: Type: text/html, Size: 2920 bytes --]

Re: Useful package? Compat.el

[Russell Adams]

On Mon, Oct 11, 2021 at 06:36:50PM +0800, Timothy wrote:
> I’ve recently come across an interesting looking library available on ELPA,
> <https://git.sr.ht/~pkal/compat>. I’m thinking in future this could allow us to
> both use newer features and also support older versions of Emacs, e.g.
>
> Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and
> newer with compat.el.

That's interesting, using a library to wrap new Emacs functionality
and implement a common replacement instead of custom work-arounds in
local code.

Do you have any examples of where this could shorten code in Org?

I believe it's a tall order to add a dependency, but if it eliminates
large chunks of backward compatibility code then maybe that's
something to consider.

Thanks.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Useful package? Compat.el

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Hi Russel,

> Do you have any examples of where this could shorten code in Org?

I don’t have any examples on hand, but Org is already rolling some compat code
for old Emacs versions, and we’ve had issues where people have accidentally used
functions which are “too new” (but a few years old, and so nobody picked it up
till someone raised an issue). I can also personally recall times when I’ve had
to refactor code to make it uglier and more verbose to avoid using newer
functions. All of this is why I’m thinking this could be an interesting idea.

> I believe it’s a tall order to add a dependency, but if it eliminates
> large chunks of backward compatibility code then maybe that’s
> something to consider.

I think the way to do this would be as a “soft” dependency, i.e. not needed for
anyone running a recent version of Emacs, but needed if you want to use Org with
an old version of Emacs. Not sure how this would best be done, but if this were
to be useful, this is how I’d imagine it working.

All the best,
Timothy

Re: Useful package? Compat.el

[Joost Kremers]

On Mon, Oct 11 2021, Timothy wrote:
> I think the way to do this would be as a “soft” dependency, i.e. not needed for
> anyone running a recent version of Emacs, but needed if you want to use Org with
> an old version of Emacs. Not sure how this would best be done, but if this were
> to be useful, this is how I’d imagine it working.

IIUC you can simply specify a dependency on `compat` and the package itself will
make sure only the necessary compatibility functions are loaded given the Emacs
version it's running in. So if you're running Emacs 28, nothing is loaded; if
you're running Emacs 27, `compat-28.1` is loaded to ensure packages written for
Emacs 28 can still be used; if you're running Emacs 26, both `compat-27.1` and
`compat-28.1` are loaded, etc.

-- 
Joost Kremers
Life has its moments

[POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Ihor Radchenko]

Timothy <tecosaur@gmail.com> writes:

> I’ve recently come across an interesting looking library available on ELPA,
> <https://git.sr.ht/~pkal/compat>. I’m thinking in future this could allow us to
> both use newer features and also support older versions of Emacs, e.g.
>
> Org 10.X is developed for Emacs 28.1 and newer, but supports Emacs 24.3 and
> newer with compat.el.
>
> Just tossing this out as an idea :)

I have recently been contacted by the current compat.el maintainer
asking if we are willing to adapt compat.el in Org.

Pros:

1. We will have less headache maintaining org-compat.el.
2. We will get an ability to use functions and macros from newer Emacs
   versions almost for free.
   
Cons:

1. If compat.el happens to lack support of some function, we will need
   to contribute to compat.el directly and synchronize Org releases with
   compat.el releases.

WDYT?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Use compat.el in Org?

[Bastien Guerry]

Hi Ihor,

Ihor Radchenko <yantar92@posteo.net> writes:

> I have recently been contacted by the current compat.el maintainer
> asking if we are willing to adapt compat.el in Org.

Very nice!

> WDYT?

As long as we keep our promise in terms of backward compatibility with
older Emacs versions, I'm all for it.

-- 
 Bastien

Re: [POLL] Use compat.el in Org?

[Tim Cross]

Bastien Guerry <bzg@gnu.org> writes:

> Hi Ihor,
>
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> I have recently been contacted by the current compat.el maintainer
>> asking if we are willing to adapt compat.el in Org.
>
> Very nice!
>
>> WDYT?
>
> As long as we keep our promise in terms of backward compatibility with
> older Emacs versions, I'm all for it.

I would agree. I would also add that even with the use of this package,
I don't think we should use it to increase the number of versions we
support as support is not as simple as dropping in a compatibility
library. These libraries come with a cost. Often, compatibility code
does not perform as well and/or is much more complicated and more likely
to have bugs. The more a version of emacs needs to rely on this library
to run org-mode, the higher the likelihood performance will be degraded
or unexpected new bugs are found.

So, use the library, but keep the existing policy of officially
supporting only the previous two major releases. If org does work with
even older versions, that is great, but not supported.

Re: [POLL] Use compat.el in Org?

[Daniel Mendler]

On 1/27/23 21:38, Tim Cross wrote:
>> As long as we keep our promise in terms of backward compatibility with
>> older Emacs versions, I'm all for it.
> 
> I would agree. I would also add that even with the use of this package,
> I don't think we should use it to increase the number of versions we
> support as support is not as simple as dropping in a compatibility
> library. 

True. The Compat package cannot fix bugs below the Elisp level or
provide APIs which cannot be backported, e.g., big integer support. If
Org relies on behavior of the Emacs display engine or the C core of a
certain Emacs version, Compat cannot help.

The advantage would be that the maintenance burden of org-compat would
be reduced. Many packages can share the backported functions by
depending on Compat, which will increase robustness and reduce the risk
of unexpected bugs. The community only has to maintain a single set of
backported functions in a single package, instead of scattering
compatibility code across many packages.

> These libraries come with a cost. Often, compatibility code
> does not perform as well and/or is much more complicated and more likely
> to have bugs. The more a version of emacs needs to rely on this library
> to run org-mode, the higher the likelihood performance will be degraded
> or unexpected new bugs are found.

To give some context about the stability aspect - many backported
compatibility functions are copied verbatim from newer Emacs versions.
Every compatibility function provided by Compat is covered by tests,
which are executed via CI on all supported Emacs versions (>= 24.4). I
make sure that no functions are backported which perform much worse such
that they would introduce performance bugs.

Daniel

Re: [POLL] Use compat.el in Org?

[Samuel Wales]

what daniel said sgtm

On 1/27/23, Daniel Mendler <mail@daniel-mendler.de> wrote:
> On 1/27/23 21:38, Tim Cross wrote:
>>> As long as we keep our promise in terms of backward compatibility with
>>> older Emacs versions, I'm all for it.
>>
>> I would agree. I would also add that even with the use of this package,
>> I don't think we should use it to increase the number of versions we
>> support as support is not as simple as dropping in a compatibility
>> library.
>
> True. The Compat package cannot fix bugs below the Elisp level or
> provide APIs which cannot be backported, e.g., big integer support. If
> Org relies on behavior of the Emacs display engine or the C core of a
> certain Emacs version, Compat cannot help.
>
> The advantage would be that the maintenance burden of org-compat would
> be reduced. Many packages can share the backported functions by
> depending on Compat, which will increase robustness and reduce the risk
> of unexpected bugs. The community only has to maintain a single set of
> backported functions in a single package, instead of scattering
> compatibility code across many packages.
>
>> These libraries come with a cost. Often, compatibility code
>> does not perform as well and/or is much more complicated and more likely
>> to have bugs. The more a version of emacs needs to rely on this library
>> to run org-mode, the higher the likelihood performance will be degraded
>> or unexpected new bugs are found.
>
> To give some context about the stability aspect - many backported
> compatibility functions are copied verbatim from newer Emacs versions.
> Every compatibility function provided by Compat is covered by tests,
> which are executed via CI on all supported Emacs versions (>= 24.4). I
> make sure that no functions are backported which perform much worse such
> that they would introduce performance bugs.
>
> Daniel
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Kyle Meyer]

Ihor Radchenko writes:

> I have recently been contacted by the current compat.el maintainer
> asking if we are willing to adapt compat.el in Org.

I'm in favor of Org using Compat.  And grepping around emacs.git, there
are already two bundled packages (erc and python) with

  (require 'compat nil 'noerror)

so I don't expect there would be objections/questions from the Emacs
side.

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Greg Minshall]

Ihor,

> Cons:
> 
> 1. If compat.el happens to lack support of some function, we will need
>    to contribute to compat.el directly and synchronize Org releases with
>    compat.el releases.

would a separate "org-compat.el" (in addition to compat.el) somehow
solve this?  (i worry about the synch'ing.)

cheers, Greg

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Ihor Radchenko]

Greg Minshall <minshall@umich.edu> writes:

>> 1. If compat.el happens to lack support of some function, we will need
>>    to contribute to compat.el directly and synchronize Org releases with
>>    compat.el releases.
>
> would a separate "org-compat.el" (in addition to compat.el) somehow
> solve this?  (i worry about the synch'ing.)

That's what we already do.
Using compat.el means that we can remove some of the functions from
org-compat.el and instead rely on compat.el where the same functions are
maintained more carefully.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Greg Minshall]

Ihor,

> >> 1. If compat.el happens to lack support of some function, we will need
> >>    to contribute to compat.el directly and synchronize Org releases with
> >>    compat.el releases.
> >
> > would a separate "org-compat.el" (in addition to compat.el) somehow
> > solve this?  (i worry about the synch'ing.)
> 
> That's what we already do.
> Using compat.el means that we can remove some of the functions from
> org-compat.el and instead rely on compat.el where the same functions are
> maintained more carefully.

i see, yes.  i'm just thinking that, for a given release CUR (like i
know anything about org-mode release procedures!)  we would use whatever
has been available in compat.el since release CUR-n (for whatever n we
use -- 2?), and supplement that, in org-compat.el, with whatever other
compatibility features *we* (org-mode) need to support releases [CUR-n
.. CUR].

(and, presumably, contribute whatever might be appropriate from
org-compat.el to compat.el, so we can prune it out from org-compat.el at
some future point in time.)

i'm *only* thinking of trying to de-couple org-mode development from
that of compat.el, in the mindset that "less cross-dependencies" ==
"less complication".  if that makes sense.

cheers, Greg

Re: [POLL] Use compat.el in Org? (was: Useful package? Compat.el)

[Daniel Mendler]

On 1/30/23 20:40, Greg Minshall wrote:
> i see, yes.  i'm just thinking that, for a given release CUR (like i
> know anything about org-mode release procedures!)  we would use whatever
> has been available in compat.el since release CUR-n (for whatever n we
> use -- 2?), and supplement that, in org-compat.el, with whatever other
> compatibility features *we* (org-mode) need to support releases [CUR-n
> .. CUR].
> 
> (and, presumably, contribute whatever might be appropriate from
> org-compat.el to compat.el, so we can prune it out from org-compat.el at
> some future point in time.)

Sounds good. But note that Compat will at some point have sufficient
coverage of the existing APIs, such that Org may not miss anything. From
then on new additions will only be made at the time of a new Emacs
release. The current Compat already supports many Emacs 29 APIs, which
is in time for the upcoming pretest. Compat won't add any APIs which are
still part of the unstable development master branch (before the branch
cut and feature freeze), which reduces the need for coordination.

If you are missing something right now, and want to introduce and use a
new backported function, e.g., something new from Emacs 29, instead of
going via the org-compat indirection, you could also make an addition
directly to Compat, a Compat release can be prepared a short while
after, and then you start using the new function in the Org development
version.

Daniel