Re: compat.el and Emacs unstable master branch features

[Daniel Mendler <mail@daniel-mendler.de>]

On 9/13/23 12:31, Philip Kaludercic wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:
> 
>> 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.
> 
> That sounds good!  How does this look like:

Yes, this is what I meant. I forgot to mention one additional advantage
in my last mail: If the compat.el in core is registered with package.el
as builtin with version 30, the ELPA Compat package wouldn't get pulled
in by external packages which depend on Compat version 29. The core
compat.el version should then be bumped together with the Emacs version.

Daniel