[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compat.el and Emacs unstable master branch features
From: |
Daniel Mendler |
Subject: |
Re: compat.el and Emacs unstable master branch features |
Date: |
Tue, 12 Sep 2023 12:27:27 +0200 |
On 9/12/23 12:02, Philip Kaludercic wrote:
> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Daniel Mendler <mail@daniel-mendler.de> writes:
>>
>>> ... Providing a public API won't work
>>> since Compat is not included in Emacs itself. A design criterion of
>>> Compat is also to keep the public API surface as small as possible.
>>
>> Maybe it is the time to consider including the compat.el API into Emacs?
>> We are getting a number of :core packages published on ELPA and
>> naturally having to solve various compatibility problems.
>
> I am a bit behind wrt Compat development. Are we talking about adding
> the `compat-call, etc. macros to the core? So basically just a
>
> (defmacro compat-call (&rest args) args)
>
> that would be overriden by compat's compat-call, as soon as that is
> loaded
Yes, if the Emacs maintainers agree I think this could be done. Take
compat.el, remove the part which requires compat-29, and copy it to
lisp/ or lisp/emacs-lisp/. As you said, if Compat (the package) is
installed it will be preferred over the core compat.el. The advantage of
this move is that core package could require compat directly without
passing a noerror argument to require. Furthermore `compat-call' and
`compat-function' would be available and wouldn't have to be copied as
is currently the case for example in erc-compat.el.
Daniel