Daniel Mendler <mail@daniel-mendler.de> writes:
> On 9/9/23 13:35, Ihor Radchenko wrote:>>> So using Compat here has to wait until compat-30.x is released.>> >> And do I understand correctly that compat-30 will only be released after>> Emacs 30 is released? If so, it is awkward for :core packages.>> compat-30 can be released as soon as Emacs 30 has been reasonably> stabilized, e.g., when the emacs-30 branch has been frozen, or a bit> before that. We cannot release much earlier since APIs may still change> and it is probably undesired to release unfinished APIs to the public> too early. For reference, I've created the compat-29.1.1 release around> the day that Eli announced the emacs-29 branch freeze.
I understand the logic, but it does not make things less awkward.
Sometimes, Emacs core packages that are also distributed on ELPA rely on
bugfixes (changed functions) or new functions from master.
It is indeed viable to copy-paste the needed functions into the package
code, but it _feels_ like something compat.el may provide support for.
May it be possible to provide a public API in compat.el to define
compat function versions before they appear in compat.el properly?
--
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>
On 9/9/23 14:12, Ihor Radchenko wrote:
> Daniel Mendler <mail@daniel-mendler.de> writes:>> compat-30 can be released as soon as Emacs 30 has been reasonably>> stabilized, e.g., when the emacs-30 branch has been frozen, or a bit>> before that. We cannot release much earlier since APIs may still change>> and it is probably undesired to release unfinished APIs to the public>> too early. For reference, I've created the compat-29.1.1 release around>> the day that Eli announced the emacs-29 branch freeze.>> It is indeed viable to copy-paste the needed functions into the package> code, but it _feels_ like something compat.el may provide support for.>> May it be possible to provide a public API in compat.el to define> compat function versions before they appear in compat.el properly?
I see your point, but I think that Compat provides value for both
external and core packages given its current conservative approach. All
that is needed is to wait for a while after some API has been added and
Compat has been synchronized. Note that we haven't seen many API
additions in Emacs 30 so far. Compare this to compat-29.el which
provides a rich set of new APIs which are all available for external and
core packages depending on older Emacs versions.
I suggest to copy new functions temporarily to the package in question
with an fboundp check, with an additional TODO comment. We can
synchronize with Compat afterwards. 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.
Daniel
Daniel Mendler <mail@daniel-mendler.de> writes:
> I suggest to copy new functions temporarily to the package in question> with an fboundp check, with an additional TODO comment. We can> synchronize with Compat afterwards. 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.
fboundp won't work here because copy-tree is available in earlier
versions of Emacs. Since its behavior changed in 30, we could do a
version check + TODO comment?
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.
--
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: compat.el and Emacs unstable master branch features
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
Re: compat.el and Emacs unstable master branch features
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
Re: compat.el and Emacs unstable master branch features
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:
Re: compat.el and Emacs unstable master branch features
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
Re: compat.el and Emacs unstable master branch features
Daniel Mendler <mail@daniel-mendler.de> writes:
>>> 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.
Nobody raised objections. I recommend sending the patch to debbugs (M-x
submit-emacs-patch), so that it can be seen by Emacs maintainers.
--
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: compat.el and Emacs unstable master branch features
Ihor Radchenko <yantar92@posteo.net> writes:
> Daniel Mendler <mail@daniel-mendler.de> writes:>>>>> 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.>> Nobody raised objections. I recommend sending the patch to debbugs (M-x> submit-emacs-patch), so that it can be seen by Emacs maintainers.
See bug#66554.
--
Philip Kaludercic