Hi,

I've run into an issue with compat, as used by Magit.

I have an early build of Emacs 28 at work, which for various reasons
I can't afford to rebuild again right now. It reports, per `emacs-version`,
as 28.0.50. It does not contain the functions that compat provides
for Emacs 28, but unfortunately, the way compat tests for current Emacs
version, makes it not load those compatibility patches.

Would it be possible for compat to detect pre-release versions, and attempt
to provide them? I.e. consider 28.0.50 to be older than 28.1?

--
Jacek Złydach
http://jacek.zlydach.pl

Jacek Złydach <jacek@zlydach.pl> writes:

> Hi,
>
> I've run into an issue with compat, as used by Magit.
>
> I have an early build of Emacs 28 at work, which for various reasons
> I can't afford to rebuild again right now. It reports, per `emacs-version`,
> as 28.0.50. It does not contain the functions that compat provides
> for Emacs 28, but unfortunately, the way compat tests for current Emacs
> version, makes it not load those compatibility patches.

Oh no, I am sorry and apologise for the inconvenience!

> Would it be possible for compat to detect pre-release versions, and attempt
> to provide them? I.e. consider 28.0.50 to be older than 28.1?

I could assume that any version XY is just an abbreviation for XY.1.  Do
you think that would help, or do you see issues that this could raise?

The only disadvantage I can think of right now is the slight overhead
when loading compat every time, because the byte-compiler cannot
eliminate certain definitions a priori.

> --
> Jacek Złydach
> http://jacek.zlydach.pl

P.S.  I think that the subject is a bit too general, "Emacsen" is
      usually understood to be the family of Emacs and Emacs-like
      editors, but compat only targets GNU Emacs.

On Fri, May 27, 2022, at 17:50, Philip Kaludercic wrote:

> Oh no, I am sorry and apologise for the inconvenience!

Thanks. Though I guess I kind of signed up for such things by building Emacs
from source :).

>> Would it be possible for compat to detect pre-release versions, and attempt
>> to provide them? I.e. consider 28.0.50 to be older than 28.1?
>
> I could assume that any version XY is just an abbreviation for XY.1.  Do
> you think that would help, or do you see issues that this could raise?
>
> The only disadvantage I can think of right now is the slight overhead
> when loading compat every time, because the byte-compiler cannot
> eliminate certain definitions a priori.

Assuminy XY == XY.1 could work, if there will be no XY.Z releases that
need to be handled by compat later on.

I feel it could be done in a more future-proof way, if you named the compat
files compat-XY.Z.el, instead of compat-XY.el. Eyeballing the definition
of `compat--generate-minimal', I feel this is where the problem comes from.

You're using `version<' for comparison, which is great, but see this transcript:

  ELISP> emacs-version
  "28.0.50"
  ELISP> (version< emacs-version "28.1")
  t
  ELISP> (version< emacs-version "28")
  nil

> P.S.  I think that the subject is a bit too general, "Emacsen" is
>       usually understood to be the family of Emacs and Emacs-like
>       editors, but compat only targets GNU Emacs.

Thanks for the correction. I didn't realize "Emacsen" has a broader meaning;
it's not a word I use often. In this case, I was reminded of it by your article:
https://amodernist.com/texts/emacs-compat.html
which seems to also use it to mean GNU Emacs.

-- 
Jacek Złydach
http://jacek.zlydach.pl

Jacek Złydach <jacek@zlydach.pl> writes:

> On Fri, May 27, 2022, at 17:50, Philip Kaludercic wrote:
>
>> Oh no, I am sorry and apologise for the inconvenience!
>
> Thanks. Though I guess I kind of signed up for such things by building
> Emacs
> from source :).

Perhaps, but there is no need to unnecessarily burden anyone ^^.

>>> Would it be possible for compat to detect pre-release versions, and
>>> attempt
>>> to provide them? I.e. consider 28.0.50 to be older than 28.1?
>>
>> I could assume that any version XY is just an abbreviation for XY.1.
>> Do
>> you think that would help, or do you see issues that this could raise?
>>
>> The only disadvantage I can think of right now is the slight overhead
>> when loading compat every time, because the byte-compiler cannot
>> eliminate certain definitions a priori.
>
> Assuminy XY == XY.1 could work, if there will be no XY.Z releases that
> need to be handled by compat later on.

If there are XY.Z releases with Z > 1, this can be explicitly stated,
but to my knowledge the Emacs maintainers plan to ensure that new
features are added along with major version bumps, and to use minor
version bumps for critical bug fixes and security issues.  This is
already being done in compat-24.el

I have pushed a commit implementing this behaviour, could you check if
it fixes the issue?

> I feel it could be done in a more future-proof way, if you named the
> compat
> files compat-XY.Z.el, instead of compat-XY.el. Eyeballing the definition
> of `compat--generate-minimal', I feel this is where the problem comes
> from.

That was the initial idea, but we decided against that for more or less
aesthetic reasons.

> You're using `version<' for comparison, which is great, but see this
> transcript:
>
>   ELISP> emacs-version
>   "28.0.50"
>   ELISP> (version< emacs-version "28.1")
>   t
>   ELISP> (version< emacs-version "28")
>   nil

Version comparisons are done with version<=[0], but in this case it
seems to make no difference as there is never a version 25.0.0.

[0] https://git.sr.ht/~pkal/compat/tree/master/item/compat-macs.el#L108

>> P.S.  I think that the subject is a bit too general, "Emacsen" is
>>       usually understood to be the family of Emacs and Emacs-like
>>       editors, but compat only targets GNU Emacs.
>
> Thanks for the correction. I didn't realize "Emacsen" has a broader
> meaning;
> it's not a word I use often. In this case, I was reminded of it by
> your article:
> https://amodernist.com/texts/emacs-compat.html
> which seems to also use it to mean GNU Emacs.

You are right, and now I am that sure of what I said anymore.  Looking
at https://www.emacswiki.org/emacs/Emacsen the term "Emacsen" appears to
also be used as the plural form of "Emacs", which is also the way I used
it without thinking about it.

Philip Kaludercic <philipk@posteo.net> writes:

>>>> Would it be possible for compat to detect pre-release versions, and
>>>> attempt
>>>> to provide them? I.e. consider 28.0.50 to be older than 28.1?
>>>
>>> I could assume that any version XY is just an abbreviation for XY.1.
>>> Do
>>> you think that would help, or do you see issues that this could raise?
>>>
>>> The only disadvantage I can think of right now is the slight overhead
>>> when loading compat every time, because the byte-compiler cannot
>>> eliminate certain definitions a priori.
>>
>> Assuminy XY == XY.1 could work, if there will be no XY.Z releases that
>> need to be handled by compat later on.
>
> If there are XY.Z releases with Z > 1, this can be explicitly stated,
> but to my knowledge the Emacs maintainers plan to ensure that new
> features are added along with major version bumps, and to use minor
> version bumps for critical bug fixes and security issues.  This is
> already being done in compat-24.el
>
> I have pushed a commit implementing this behaviour, could you check if
> it fixes the issue?

ping?

Hi,

I apologize for my sudden disappearance - I was swamped by other problems.

On Fri, Jun 3, 2022, at 12:51, Philip Kaludercic wrote:
> Philip Kaludercic <philipk@posteo.net> writes:


>>> Assuminy XY == XY.1 could work, if there will be no XY.Z releases that
>>> need to be handled by compat later on.
>>
>> If there are XY.Z releases with Z > 1, this can be explicitly stated,
>> but to my knowledge the Emacs maintainers plan to ensure that new
>> features are added along with major version bumps, and to use minor
>> version bumps for critical bug fixes and security issues.

I suspected as much, but wasn't sure. Most likely, the assumption is safe.

>> I have pushed a commit implementing this behaviour, could you check if
>> it fixes the issue?
>
> ping?

I will test your update over the weekend and report the result.

-- 
Jacek Złydach
http://jacek.zlydach.pl

Hi again,

On Sat, Jun 4, 2022, at 05:17, Jacek Złydach wrote:

>>> I have pushed a commit implementing this behaviour, could you check if
>>> it fixes the issue?
>>
>> ping?
>
> I will test your update over the weekend and report the result.

I ended up only having an hour free for this, and in the process of replacing compat pulled as dependency via package.el/use-packege, I've managed to get about two dozen other packages to fail to "activate", because they couldn't find "compat-28.1.1.0". That's despite the old (package.el) and new (git) packages both showing their version to be 28.1.1.1.

(It's also surprising to see so many packages already relying on compat - but on second thought, they all might be getting it transitively through transient.)

Surely I'm holding something wrong, but I'll only be able to resume testing late this week. Until then, I just keep manually unrolled bits from compat-28.el in my early-init.el :).

-- 
Jacek Złydach
http://jacek.zlydach.pl

Philip Kaludercic <philipk@posteo.net> writes:

> I have pushed a commit implementing this behaviour, could you check if
> it fixes the issue?

`compat--entwine-version' is also just "XY", so wouldn't we have to
append ".1" to that too?

Jacek Złydach <jacek@zlydach.pl> writes:

> Hi again,
>
> On Sat, Jun 4, 2022, at 05:17, Jacek Złydach wrote:
>
>>>> I have pushed a commit implementing this behaviour, could you check if
>>>> it fixes the issue?
>>>
>>> ping?
>>
>> I will test your update over the weekend and report the result.
>
> I ended up only having an hour free for this, and in the process of
> replacing compat pulled as dependency via package.el/use-packege, I've
> managed to get about two dozen other packages to fail to "activate",
> because they couldn't find "compat-28.1.1.0". That's despite the old
> (package.el) and new (git) packages both showing their version to be
> 28.1.1.1.
>
> (It's also surprising to see so many packages already relying on
> compat - but on second thought, they all might be getting it
> transitively through transient.)
>
> Surely I'm holding something wrong, but I'll only be able to resume
> testing late this week. Until then, I just keep manually unrolled bits
> from compat-28.el in my early-init.el :).

If you don't have the time, I can test it myself as well.

Jonas Bernoulli <jonas@bernoul.li> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I have pushed a commit implementing this behaviour, could you check if
>> it fixes the issue?
>
> `compat--entwine-version' is also just "XY", so wouldn't we have to
> append ".1" to that too?

This could very well be the problem, as this change was introduced
between Jacek's first message and last weekend.

Philip Kaludercic <philipk@posteo.net> writes:

> Jacek Złydach <jacek@zlydach.pl> writes:
>
>> Hi again,
>>
>> On Sat, Jun 4, 2022, at 05:17, Jacek Złydach wrote:
>>
>>>>> I have pushed a commit implementing this behaviour, could you check if
>>>>> it fixes the issue?
>>>>
>>>> ping?
>>>
>>> I will test your update over the weekend and report the result.
>>
>> I ended up only having an hour free for this, and in the process of
>> replacing compat pulled as dependency via package.el/use-packege, I've
>> managed to get about two dozen other packages to fail to "activate",
>> because they couldn't find "compat-28.1.1.0". That's despite the old
>> (package.el) and new (git) packages both showing their version to be
>> 28.1.1.1.
>>
>> (It's also surprising to see so many packages already relying on
>> compat - but on second thought, they all might be getting it
>> transitively through transient.)
>>
>> Surely I'm holding something wrong, but I'll only be able to resume
>> testing late this week. Until then, I just keep manually unrolled bits
>> from compat-28.el in my early-init.el :).
>
> If you don't have the time, I can test it myself as well.
>
> Jonas Bernoulli <jonas@bernoul.li> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> I have pushed a commit implementing this behaviour, could you check if
>>> it fixes the issue?
>>
>> `compat--entwine-version' is also just "XY", so wouldn't we have to
>> append ".1" to that too?
>
> This could very well be the problem, as this change was introduced
> between Jacek's first message and last weekend.

I've an Emacs pre-release and added a fictional function

--8<---------------cut here---------------start------------->8---
(compat-defun fictional (arg)
  "Return arg."
  arg)
--8<---------------cut here---------------end--------------->8---

to compat-28.el.  Prior to the first change that adds .1 to the version,
this function would not be loaded if I started this Emacs by running

     $ ./src/emacs -q -l path/to/compat -l compat

but with the current state of the master branch, this does work,
with or without byte compilation.

So I would consider this bug fixed, and will prepare a new release in
the next few days.