Heads-up: Emacs 26.1 RC1

Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

With the proofreading of the Emacs manual all but completed, I think
it's time to finally put RC1 of Emacs 26.1 out the door, and hopefully
release v26.1 soon after that.

This message is a heads-up for people who think there are still
significant/critical bugs we must fix before the release: please speak
up now.

If no significant issues are brought up, I think we should have our
RC1 a week from now.

I'd like to take this opportunity to thank everyone who worked on
proofreading the manual, and on polishing the emacs-26 branch in
general.

Re: Heads-up: Emacs 26.1 RC1

[Pierre Téchoueyres]

Eli Zaretskii <eliz@gnu.org> writes:

> With the proofreading of the Emacs manual all but completed, I think
> it's time to finally put RC1 of Emacs 26.1 out the door, and hopefully
> release v26.1 soon after that.
>
> This message is a heads-up for people who think there are still
> significant/critical bugs we must fix before the release: please speak
> up now.
>
> If no significant issues are brought up, I think we should have our
> RC1 a week from now.
>
> I'd like to take this opportunity to thank everyone who worked on
> proofreading the manual, and on polishing the emacs-26 branch in
> general.
>
>

I was hoping bug#29220 could be fixed before the release. But I can
understand that it's complex and I do not want to harass
Eric. Especially that I can help only by testing.

If at least the patch provided by Eric in the message
87y3m2jl3b.fsf@ericabrahamsen.net could be included would solve some
part of the problem.

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: pierre.techoueyres@free.fr (Pierre Téchoueyres)
> Cc: John Wiegley <johnw@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 19 Mar 2018 19:46:46 +0100
> 
> I was hoping bug#29220 could be fixed before the release. But I can
> understand that it's complex and I do not want to harass
> Eric. Especially that I can help only by testing.

AFAIU, there's no solution at hand for that bug yet.

> If at least the patch provided by Eric in the message
> 87y3m2jl3b.fsf@ericabrahamsen.net could be included would solve some
> part of the problem.

I cannot easily spot that message; could you please provide the URL in
the form https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135, that
uses the bug tracker?

Re: Heads-up: Emacs 26.1 RC1

[Pierre Téchoueyres]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: pierre.techoueyres@free.fr (Pierre Téchoueyres)
>> Cc: John Wiegley <johnw@gnu.org>,  emacs-devel@gnu.org
>> Date: Mon, 19 Mar 2018 19:46:46 +0100
>>
>> I was hoping bug#29220 could be fixed before the release. But I can
>> understand that it's complex and I do not want to harass
>> Eric. Especially that I can help only by testing.
>
> AFAIU, there's no solution at hand for that bug yet.
>
No, but the patch seems to mitigate the problem. I use it since Eric
posted it.  And for what it's worth, I have not encountered any
problem.

>> If at least the patch provided by Eric in the message
>> 87y3m2jl3b.fsf@ericabrahamsen.net could be included would solve some
>> part of the problem.
>
> I cannot easily spot that message; could you please provide the URL in
> the form https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135, that
> uses the bug tracker?
>

Yes sorry I will do it next time.  You have found the right message :
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: pierre.techoueyres@free.fr (Pierre Téchoueyres)
> Cc: johnw@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 19 Mar 2018 20:59:26 +0100
> 
> >> If at least the patch provided by Eric in the message
> >> 87y3m2jl3b.fsf@ericabrahamsen.net could be included would solve some
> >> part of the problem.
> >
> > I cannot easily spot that message; could you please provide the URL in
> > the form https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135, that
> > uses the bug tracker?
> >
> 
> Yes sorry I will do it next time.  You have found the right message :
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135

I'm okay with that if Eric agrees.

Re: Heads-up: Emacs 26.1 RC1

[Michael Heerdegen]

Hi Eli,

> This message is a heads-up for people who think there are still
> significant/critical bugs we must fix before the release: please speak
> up now.

How long do I have for the final "fix if-let is obsolete warnings"
patch?  I'll surely suggest it in the next few days.


Michael.

Re: Heads-up: Emacs 26.1 RC1

[Phillip Lord]

On Mon, March 19, 2018 3:59 pm, Eli Zaretskii wrote:
> With the proofreading of the Emacs manual all but completed, I think
> it's time to finally put RC1 of Emacs 26.1 out the door, and hopefully
> release v26.1 soon after that.
>
> This message is a heads-up for people who think there are still
> significant/critical bugs we must fix before the release: please speak up
> now.
>
> If no significant issues are brought up, I think we should have our
> RC1 a week from now.

Possibly worth considering this report. It's a regression from Emacs-25
caused by a fix for another bug.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30745

Probably not worth delaying for, as there is no fix and it's relative
small impact, but I thought to mention it.

Re: Heads-up: Emacs 26.1 RC1

[Noam Postavsky]

On 19 March 2018 at 17:04, Phillip Lord <phillip.lord@russet.org.uk> wrote:

> Possibly worth considering this report. It's a regression from Emacs-25
> caused by a fix for another bug.
>
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30745
>
> Probably not worth delaying for, as there is no fix and it's relative
> small impact, but I thought to mention it.

I doubt it's fixable in a way that would be safe for emacs-26 (I mean,
apart from reverting the fix for Bug#24402, but I think that would not
be a good trade).

Re: Heads-up: Emacs 26.1 RC1

[Richard Copley]

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

On 19 March 2018 at 15:59, Eli Zaretskii <eliz@gnu.org> wrote:

> This message is a heads-up for people who think there are still
> significant/critical bugs we must fix before the release: please speak
> up now.
>

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30295#11

Please try this in CSS mode:

div: {
  #87e087
}

I hope you'll agree it's bad, and makes a mockery of Tom's very welcome
improvements. It's also easy and safe to fix.

As ever I'm reluctant to provide a patch (though I do have one and I'll
certainly be using it), because I haven't assigned copyright, but I did
make concrete suggestions for a fix.

[-- Attachment #2: Type: text/html, Size: 1173 bytes --]

Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: pierre.techoueyres@free.fr (Pierre Téchoueyres)
>> Cc: johnw@gnu.org,  emacs-devel@gnu.org
>> Date: Mon, 19 Mar 2018 20:59:26 +0100
>> 
>> >> If at least the patch provided by Eric in the message
>> >> 87y3m2jl3b.fsf@ericabrahamsen.net could be included would solve some
>> >> part of the problem.
>> >
>> > I cannot easily spot that message; could you please provide the URL in
>> > the form https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135, that
>> > uses the bug tracker?
>> >
>> 
>> Yes sorry I will do it next time.  You have found the right message :
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135
>
> I'm okay with that if Eric agrees.

Yes! My apologies again for the slowness. I really wanted to get a grasp
on CEDET and how it uses eieio-persist, to avoid causing more problems,
but realistically I'm not going to get there anytime soon. Also, the
fact that Pierre's tests fail exactly the same way with Emacs 25 and
Emacs 26+fix indicate that CEDET has other issues that need resolving
first.

What I would like to do is merge the fix/eieio-persistent branch. That
has new tests from Pierre (Pierre, have you signed FSF papers?), more
tests from me, and better error reporting for the restore process. The
commits that actually "do something" are bf4f34ac7 and 1ea9947ca3189.

Is that okay? If so, what's the proper merge strategy to use?

Thanks,
Eric

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: John Wiegley <johnw@gnu.org>,  emacs-devel@gnu.org
> Date: Mon, 19 Mar 2018 22:00:13 +0100
> 
> Hi Eli,
> 
> > This message is a heads-up for people who think there are still
> > significant/critical bugs we must fix before the release: please speak
> > up now.
> 
> How long do I have for the final "fix if-let is obsolete warnings"
> patch?  I'll surely suggest it in the next few days.

A few days, as in "less than a week", would be good.

Thanks.

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Mon, 19 Mar 2018 17:11:08 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, John Wiegley <johnw@gnu.org>, Emacs developers <emacs-devel@gnu.org>
> 
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30745
> >
> > Probably not worth delaying for, as there is no fix and it's relative
> > small impact, but I thought to mention it.
> 
> I doubt it's fixable in a way that would be safe for emacs-26 (I mean,
> apart from reverting the fix for Bug#24402, but I think that would not
> be a good trade).

I agree.  Besides, this is about ERT, so fixing it is not crucial.

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Mon, 19 Mar 2018 21:33:12 +0000
> Cc: John Wiegley <johnw@gnu.org>, Emacs Development <emacs-devel@gnu.org>, Tom Tromey <tom@tromey.com>
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30295#11 
> 
> Please try this in CSS mode:
> 
> div: {
>   #87e087
> }
> 
> I hope you'll agree it's bad

Actually, doesn't look too bad here.

> It's also easy and safe to fix.

I don't see any proposed patches in the bug report.  What did I miss?

> As ever I'm reluctant to provide a patch (though I do have one and I'll certainly be using it), because I haven't
> assigned copyright, but I did make concrete suggestions for a fix.

If someone can present a patch, I promise to review it.

Thanks.

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: pierre.techoueyres@free.fr (Pierre Téchoueyres),
>   johnw@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 20 Mar 2018 14:10:51 +0800
> 
> >> Yes sorry I will do it next time.  You have found the right message :
> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135
> >
> > I'm okay with that if Eric agrees.
> 
> Yes! My apologies again for the slowness. I really wanted to get a grasp
> on CEDET and how it uses eieio-persist, to avoid causing more problems,
> but realistically I'm not going to get there anytime soon. Also, the
> fact that Pierre's tests fail exactly the same way with Emacs 25 and
> Emacs 26+fix indicate that CEDET has other issues that need resolving
> first.
> 
> What I would like to do is merge the fix/eieio-persistent branch. That
> has new tests from Pierre (Pierre, have you signed FSF papers?), more
> tests from me, and better error reporting for the restore process. The
> commits that actually "do something" are bf4f34ac7 and 1ea9947ca3189.
> 
> Is that okay?

Ouch!  Why are you waiting so long with such a large change?

The changes in error/warning messages and in the test suite are okay
to go, but I'm worried by the 2 changes that add a condition (where
you went from (when ...) to (cond ...)).  Is this really necessary,
and what problems do they solve?

> If so, what's the proper merge strategy to use?

It's up to you.  You can either merge or rebase, we don't care (and I
don't want to get into a controversial discussion of which one is
better).

Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen]

On 03/20/18 09:16 AM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: pierre.techoueyres@free.fr (Pierre Téchoueyres),
>>   johnw@gnu.org,  emacs-devel@gnu.org
>> Date: Tue, 20 Mar 2018 14:10:51 +0800
>> 
>> >> Yes sorry I will do it next time.  You have found the right message :
>> >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29220#135
>> >
>> > I'm okay with that if Eric agrees.
>> 
>> Yes! My apologies again for the slowness. I really wanted to get a grasp
>> on CEDET and how it uses eieio-persist, to avoid causing more problems,
>> but realistically I'm not going to get there anytime soon. Also, the
>> fact that Pierre's tests fail exactly the same way with Emacs 25 and
>> Emacs 26+fix indicate that CEDET has other issues that need resolving
>> first.
>> 
>> What I would like to do is merge the fix/eieio-persistent branch. That
>> has new tests from Pierre (Pierre, have you signed FSF papers?), more
>> tests from me, and better error reporting for the restore process. The
>> commits that actually "do something" are bf4f34ac7 and 1ea9947ca3189.
>> 
>> Is that okay?
>
> Ouch!  Why are you waiting so long with such a large change?
>
> The changes in error/warning messages and in the test suite are okay
> to go, but I'm worried by the 2 changes that add a condition (where
> you went from (when ...) to (cond ...)).  Is this really necessary,
> and what problems do they solve?

I know... Mostly it took so long because of testing. The test suite
changes are there to test the new code, which directly models errors
currently in the wild, and they can't go in by themselves.

Very long story short, in Emacs 26 eieio objects went from being defined
as vectors to being defined as objects. This messed up how they are
serialized to disk using eieio-persistent. Two main consumers of
eieio-persistent (pcache and the Gnus registry) are currently broken
because of this. The `cond' statement is there to make sure that, in
these two packages, the objects are written correctly to disk.

>> If so, what's the proper merge strategy to use?
>
> It's up to you.  You can either merge or rebase, we don't care (and I
> don't want to get into a controversial discussion of which one is
> better).

I certainly don't have any opinion, I'd go with rebase, I guess.

Sorry about this,
Eric

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: pierre.techoueyres@free.fr,  johnw@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 20 Mar 2018 16:25:04 +0800
> 
> > The changes in error/warning messages and in the test suite are okay
> > to go, but I'm worried by the 2 changes that add a condition (where
> > you went from (when ...) to (cond ...)).  Is this really necessary,
> > and what problems do they solve?
> 
> I know... Mostly it took so long because of testing. The test suite
> changes are there to test the new code, which directly models errors
> currently in the wild, and they can't go in by themselves.
> 
> Very long story short, in Emacs 26 eieio objects went from being defined
> as vectors to being defined as objects. This messed up how they are
> serialized to disk using eieio-persistent. Two main consumers of
> eieio-persistent (pcache and the Gnus registry) are currently broken
> because of this. The `cond' statement is there to make sure that, in
> these two packages, the objects are written correctly to disk.

Which code/packages outside of CEDET use the affected functions?

Re: Heads-up: Emacs 26.1 RC1

[Robert Pluim]

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

Eli Zaretskii <eliz@gnu.org> writes:

> With the proofreading of the Emacs manual all but completed, I think
> it's time to finally put RC1 of Emacs 26.1 out the door, and hopefully
> release v26.1 soon after that.
>
> This message is a heads-up for people who think there are still
> significant/critical bugs we must fix before the release: please speak
> up now.

No bugs, just a minor doc-fix.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Correct-Info-link-markup.patch --]
[-- Type: text/x-diff, Size: 1864 bytes --]

From a59d3fc1a7059064518f3842140f0df2e19799a1 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Mon, 12 Mar 2018 17:43:23 +0100
Subject: [PATCH 1/2] Correct Info link markup

* lisp/gnus/gnus-agent.el (gnus-agent-auto-agentize-methods):
Correct markup for Info link.
* src/minibuf.c (Fcompleting_read): Likewise.
---
 lisp/gnus/gnus-agent.el | 2 +-
 src/minibuf.c           | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/lisp/gnus/gnus-agent.el b/lisp/gnus/gnus-agent.el
index ada148d20b..628c9430c9 100644
--- a/lisp/gnus/gnus-agent.el
+++ b/lisp/gnus/gnus-agent.el
@@ -172,7 +172,7 @@ gnus-agent-expire-unagentized-dirs
 (defcustom gnus-agent-auto-agentize-methods nil
   "Initially, all servers from these methods are agentized.
 The user may remove or add servers using the Server buffer.
-See Info nodes `(gnus)Server Buffer', `(gnus)Agent Variables'."
+See Info node `(gnus)Server Buffer' and Info node `(gnus)Agent Variables'."
   :version "22.1"
   :type '(repeat symbol)
   :group 'gnus-agent)
diff --git a/src/minibuf.c b/src/minibuf.c
index 95e62cedda..d4484efb04 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -1626,8 +1626,8 @@ COLLECTION can also be a function to do the completion itself.
 PREDICATE limits completion to a subset of COLLECTION.
 See `try-completion', `all-completions', `test-completion',
 and `completion-boundaries', for more details on completion,
-COLLECTION, and PREDICATE.  See also Info nodes `(elisp)Basic Completion'
-for the details about completion, and `(elisp)Programmed Completion' for
+COLLECTION, and PREDICATE.  See also Info node `(elisp)Basic Completion'
+for the details about completion, and Info node `(elisp)Programmed Completion' for
 expectations from COLLECTION when it's a function.
 
 REQUIRE-MATCH can take the following values:
-- 
2.16.1.72.g5be1f00a9

Re: Heads-up: Emacs 26.1 RC1

[Phillip Lord]

On Tue, March 20, 2018 7:05 am, Eli Zaretskii wrote:
>> From: Noam Postavsky <npostavs@gmail.com>
>> Date: Mon, 19 Mar 2018 17:11:08 -0400
>> Cc: Eli Zaretskii <eliz@gnu.org>, John Wiegley <johnw@gnu.org>, Emacs
>> developers <emacs-devel@gnu.org>
>>
>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30745
>>>
>>>
>>> Probably not worth delaying for, as there is no fix and it's relative
>>>  small impact, but I thought to mention it.
>>
>> I doubt it's fixable in a way that would be safe for emacs-26 (I mean,
>> apart from reverting the fix for Bug#24402, but I think that would not be
>> a good trade).
>
> I agree.  Besides, this is about ERT, so fixing it is not crucial.


Also agreed, I fear, although bugs in ERT are unfortunate if you are using
ERT as the basis for bisection. Still, it has been on this branch for a
while now and is on master, so I guess we are already in the situation.

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: John Wiegley <johnw@gnu.org>,  emacs-devel@gnu.org
> Gmane-Reply-To-List: yes
> Date: Tue, 20 Mar 2018 10:52:01 +0100
> 
> No bugs, just a minor doc-fix.

Thanks, pushed.

Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen]

On 03/20/18 11:18 AM, Eli Zaretskii wrote:
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: pierre.techoueyres@free.fr,  johnw@gnu.org,  emacs-devel@gnu.org
>> Date: Tue, 20 Mar 2018 16:25:04 +0800
>> 
>> > The changes in error/warning messages and in the test suite are okay
>> > to go, but I'm worried by the 2 changes that add a condition (where
>> > you went from (when ...) to (cond ...)).  Is this really necessary,
>> > and what problems do they solve?
>> 
>> I know... Mostly it took so long because of testing. The test suite
>> changes are there to test the new code, which directly models errors
>> currently in the wild, and they can't go in by themselves.
>> 
>> Very long story short, in Emacs 26 eieio objects went from being defined
>> as vectors to being defined as objects. This messed up how they are
>> serialized to disk using eieio-persistent. Two main consumers of
>> eieio-persistent (pcache and the Gnus registry) are currently broken
>> because of this. The `cond' statement is there to make sure that, in
>> these two packages, the objects are written correctly to disk.
>
> Which code/packages outside of CEDET use the affected functions?

Pcache is a big one, as several other packages depend on it -- though I
haven't been able to figure out exactly how many from the Melpa repo. It
currently errors loudly. The Gnus repository is another, and it is
silently corrupted. Those are the main two, and the code changes (though
they look large) are specifically targeted at those two packages. A more
general solution is in the works for 27, but this was the smallest diff
I could manage that fixes the problem.

Re: Heads-up: Emacs 26.1 RC1

[Dmitry Gutov]

On 3/21/18 1:22 AM, Eric Abrahamsen wrote:

> Pcache is a big one, as several other packages depend on it -- though I
> haven't been able to figure out exactly how many from the Melpa repo.
18, looks like: https://melpa.org/#/pcache

Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 3/21/18 1:22 AM, Eric Abrahamsen wrote:
>
>> Pcache is a big one, as several other packages depend on it -- though I
>> haven't been able to figure out exactly how many from the Melpa repo.
> 18, looks like: https://melpa.org/#/pcache

Ah, thanks, I don't know why I couldn't figure that out. That's more
than I thought...

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: pierre.techoueyres@free.fr,  johnw@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 21 Mar 2018 07:22:48 +0800
> 
> > Which code/packages outside of CEDET use the affected functions?
> 
> Pcache is a big one, as several other packages depend on it -- though I
> haven't been able to figure out exactly how many from the Melpa repo. It
> currently errors loudly. The Gnus repository is another, and it is
> silently corrupted. Those are the main two, and the code changes (though
> they look large) are specifically targeted at those two packages. A more
> general solution is in the works for 27, but this was the smallest diff
> I could manage that fixes the problem.

Then please explain in more detail why the 2nd branch of the 'cond'
you introduced is needed (the 1st just repeats the original code, so
it doesn't need any explanation).

Thanks.

Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: pierre.techoueyres@free.fr,  johnw@gnu.org,  emacs-devel@gnu.org
>> Date: Wed, 21 Mar 2018 07:22:48 +0800
>>
>> > Which code/packages outside of CEDET use the affected functions?
>>
>> Pcache is a big one, as several other packages depend on it -- though I
>> haven't been able to figure out exactly how many from the Melpa repo. It
>> currently errors loudly. The Gnus repository is another, and it is
>> silently corrupted. Those are the main two, and the code changes (though
>> they look large) are specifically targeted at those two packages. A more
>> general solution is in the works for 27, but this was the smallest diff
>> I could manage that fixes the problem.
>
> Then please explain in more detail why the 2nd branch of the 'cond'
> you introduced is needed (the 1st just repeats the original code, so
> it doesn't need any explanation).
>
> Thanks.

Backing up just a bit, I've made two changes to eieio-persistent over
the past few months, both of them already on 26. Both changes introduced
errors that need to be fixed. They are:

c59ddb2120 * Fix slot typecheck in eieio-persistent
e1cc2037a9 * Handle hash tables and vectors when reading/writing EIEIO objects

The first contained a dumb error in that valid types could be returned
as a list, but the code that consumed the return value didn't handle a
list. That mistake is fixed in this (very small) commit on the
fix/eieio-persistent branch:

1ea9947ca3 * Handle possible classtype values in eieio-persistent-read

This fix is necessary to get pcache working again.

The second commit was also necessary for pcache, as it stores eieio
objects inside hash tables. This wasn't an issue in Emacs 25, because
the hash tables were serialized with `prin1', including their values,
and objects written with `prin1' could be read with `read'. It *is* an
issue in Emacs 26, however, because those objects can no longer be read
with `read'. Commit e1cc2037a9 allows the serialization process to
descend into hash tables and handle their values correctly.

That introduced a bug for the Gnus registry, however, as *non-object*
hash table values are written with `eieio-override-prin1', which passes
lists to `eieio-list-prin1', which wraps the list in a call to `quote'.

The registry just happens to use list values in its hash tables, so they
get quoted.

The normal de-serialization process looks for quoted lists and strips
the quote (nine lines from the top of
`eieio-persistent-validate/fix-slot-value'). But the handling of hash
tables and vectors only checks for object values, not for quoted lists.
That means that each time the object is serialized to disk, another call
to `quote' is added, but never stripped, which soon makes the values
useless.

So, to finally answer your question, the new `cond' statements in
bf4f34ac7d on the fix/eieio-persistent branch simply check for a quote
and strip it, the same thing that happens to list values up at the top
of the function.

The whole process is very arbitrary and fragile, and should be reworked.
But at least, with these patches, the process is arbitrary in a way that
can be round-tripped correctly.

1ea9947ca3 on the fix/eieio-persistent branch is all that's needed to
get pcache working again. bf4f34ac7d is needed to get Gnus working, and
to make the process fully balanced between serialization and
de-serialization.

Apologies again for the last-minute mess.

Eric

Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>>> Cc: pierre.techoueyres@free.fr,  johnw@gnu.org,  emacs-devel@gnu.org
>>> Date: Wed, 21 Mar 2018 07:22:48 +0800
>>>
>>> > Which code/packages outside of CEDET use the affected functions?
>>>
>>> Pcache is a big one, as several other packages depend on it -- though I
>>> haven't been able to figure out exactly how many from the Melpa repo. It
>>> currently errors loudly. The Gnus repository is another, and it is
>>> silently corrupted. Those are the main two, and the code changes (though
>>> they look large) are specifically targeted at those two packages. A more
>>> general solution is in the works for 27, but this was the smallest diff
>>> I could manage that fixes the problem.
>>
>> Then please explain in more detail why the 2nd branch of the 'cond'
>> you introduced is needed (the 1st just repeats the original code, so
>> it doesn't need any explanation).
>>
>> Thanks.
>
> Backing up just a bit, I've made two changes to eieio-persistent over
> the past few months, both of them already on 26. Both changes introduced
> errors that need to be fixed. They are:
>
> c59ddb2120 * Fix slot typecheck in eieio-persistent
> e1cc2037a9 * Handle hash tables and vectors when reading/writing EIEIO objects
>
> The first contained a dumb error in that valid types could be returned
> as a list, but the code that consumed the return value didn't handle a
> list. That mistake is fixed in this (very small) commit on the
> fix/eieio-persistent branch:
>
> 1ea9947ca3 * Handle possible classtype values in eieio-persistent-read
>
> This fix is necessary to get pcache working again.
>
> The second commit was also necessary for pcache, as it stores eieio
> objects inside hash tables. This wasn't an issue in Emacs 25, because
> the hash tables were serialized with `prin1', including their values,
> and objects written with `prin1' could be read with `read'. It *is* an
> issue in Emacs 26, however, because those objects can no longer be read
> with `read'. Commit e1cc2037a9

bf4f34ac7d, sorry...

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: johnw@gnu.org,  emacs-devel@gnu.org,  pierre.techoueyres@free.fr
> Date: Wed, 21 Mar 2018 17:48:36 +0800
> 
> So, to finally answer your question, the new `cond' statements in
> bf4f34ac7d on the fix/eieio-persistent branch simply check for a quote
> and strip it, the same thing that happens to list values up at the top
> of the function.

OK, thanks for the explanations.  Please install your changes on the
release branch.

Re: Heads-up: Emacs 26.1 RC1

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Cc: johnw@gnu.org,  emacs-devel@gnu.org,  pierre.techoueyres@free.fr
>> Date: Wed, 21 Mar 2018 17:48:36 +0800
>> 
>> So, to finally answer your question, the new `cond' statements in
>> bf4f34ac7d on the fix/eieio-persistent branch simply check for a quote
>> and strip it, the same thing that happens to list values up at the top
>> of the function.
>
> OK, thanks for the explanations.  Please install your changes on the
> release branch.

Great! And thanks for the 11th hour review.

Re: Heads-up: Emacs 26.1 RC1

[Pierre Téchoueyres]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:
> ...
>>
>> OK, thanks for the explanations.  Please install your changes on the
>> release branch.
>
> Great! And thanks for the 11th hour review.
>
Many thanks to you both.

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> Date: Tue, 20 Mar 2018 09:03:36 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> CC: johnw@gnu.org, emacs-devel@gnu.org
> 
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: John Wiegley <johnw@gnu.org>,  emacs-devel@gnu.org
> > Date: Mon, 19 Mar 2018 22:00:13 +0100
> > 
> > Hi Eli,
> > 
> > > This message is a heads-up for people who think there are still
> > > significant/critical bugs we must fix before the release: please speak
> > > up now.
> > 
> > How long do I have for the final "fix if-let is obsolete warnings"
> > patch?  I'll surely suggest it in the next few days.
> 
> A few days, as in "less than a week", would be good.

Michael,

Any news on this?  I'm holding off RC1 until you install the fixes for
this issue.

Re: Heads-up: Emacs 26.1 RC1

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> Any news on this?  I'm holding off RC1 until you install the fixes for
> this issue.

I'll work on it in the next hours.


Michael.

Re: Heads-up: Emacs 26.1 RC1

[Michael Heerdegen]

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

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I'll work on it in the next hours.

Sorry about the procrastination.

Here is the updated patch.  Does it look ok?

Thanks,

Michael.



[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-De-obsolete-if-let-and-when-let.patch --]
[-- Type: text/x-diff, Size: 5032 bytes --]

From 441fe201ea129709ac9807b9b6b30caa45bbd293 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Sat, 10 Mar 2018 16:39:41 +0100
Subject: [PATCH] De-obsolete `if-let' and `when-let'

For the following release it is planned to make `if-let*' and
`when-let*' aliases for `if-let' and `when-let'.  For now we revert
declaring `if-let' and `when-let' obsolete and tweak the docstrings.

* lisp/emacs-lisp/subr-x.el (if-let*, when-let*): Make docstrings
refer to those of `if-let' and `when-let'.
(if-let, when-let): De-obsolete.  Rewrite documentation.
---
 etc/NEWS                  |  8 ++------
 lisp/emacs-lisp/subr-x.el | 46 ++++++++++++++++++++++++++--------------------
 2 files changed, 28 insertions(+), 26 deletions(-)

diff --git a/etc/NEWS b/etc/NEWS
index f5da6870b7..4adedfce1a 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -1305,12 +1305,8 @@ current buffer or the self-insertion takes place within a comment.
 ** The alist 'ucs-names' is now a hash table.
 
 ---
-** 'if-let' and 'when-let' are subsumed by 'if-let*' and 'when-let*'.
-The incumbent 'if-let' and 'when-let' are now marked obsolete.
-'if-let*' and 'when-let*' do not accept the single tuple special case.
-New macro 'and-let*' is an implementation of the Scheme SRFI-2 syntax
-of the same name.  'if-let*' and 'when-let*' now accept the same
-binding syntax as 'and-let*'.
+** 'if-let' and 'when-let' now support binding lists as defined by the
+SRFI-2 (Scheme Request for Implementation 2).
 
 ---
 ** 'C-up', 'C-down', 'C-left' and 'C-right' are now defined in term
diff --git a/lisp/emacs-lisp/subr-x.el b/lisp/emacs-lisp/subr-x.el
index 21dba377bf..7fab9083e8 100644
--- a/lisp/emacs-lisp/subr-x.el
+++ b/lisp/emacs-lisp/subr-x.el
@@ -123,15 +123,8 @@ internal--build-bindings
 
 (defmacro if-let* (varlist then &rest else)
   "Bind variables according to VARLIST and eval THEN or ELSE.
-Each binding is evaluated in turn, and evaluation stops if a
-binding value is nil.  If all are non-nil, the value of THEN is
-returned, or the last form in ELSE is returned.
-
-Each element of VARLIST is a list (SYMBOL VALUEFORM) which binds
-SYMBOL to the value of VALUEFORM.  An element can additionally
-be of the form (VALUEFORM), which is evaluated and checked for
-nil; i.e. SYMBOL can be omitted if only the test result is of
-interest."
+This is like `if-let' but doesn't handle a VARLIST of the form
+\(SYMBOL SOMETHING) specially."
   (declare (indent 2)
            (debug ((&rest [&or symbolp (symbolp form) (form)])
                    form body)))
@@ -144,11 +137,8 @@ if-let*
 
 (defmacro when-let* (varlist &rest body)
   "Bind variables according to VARLIST and conditionally eval BODY.
-Each binding is evaluated in turn, and evaluation stops if a
-binding value is nil.  If all are non-nil, the value of the last
-form in BODY is returned.
-
-VARLIST is the same as in `if-let*'."
+This is like `when-let' but doesn't handle a VARLIST of the form
+\(SYMBOL SOMETHING) specially."
   (declare (indent 1) (debug if-let*))
   (list 'if-let* varlist (macroexp-progn body)))
 
@@ -168,12 +158,25 @@ and-let*
 
 (defmacro if-let (spec then &rest else)
   "Bind variables according to SPEC and eval THEN or ELSE.
-Like `if-let*' except SPEC can have the form (SYMBOL VALUEFORM)."
+Each binding is evaluated in turn, and evaluation stops if a
+binding value is nil.  If all are non-nil, the value of THEN is
+returned, or the last form in ELSE is returned.
+
+Each element of SPEC is a list (SYMBOL VALUEFORM) which binds
+SYMBOL to the value of VALUEFORM.  An element can additionally be
+of the form (VALUEFORM), which is evaluated and checked for nil;
+i.e. SYMBOL can be omitted if only the test result is of
+interest.  It can also be of the form SYMBOL, then the binding of
+SYMBOL is checked for nil.
+
+As a special case, a SPEC of the form \(SYMBOL SOMETHING) is
+interpreted like \((SYMBOL SOMETHING)). This exists for backward
+compatibility with the old syntax that accepted only one
+binding."
   (declare (indent 2)
            (debug ([&or (&rest [&or symbolp (symbolp form) (form)])
                         (symbolp form)]
-                   form body))
-           (obsolete "use `if-let*' instead." "26.1"))
+                   form body)))
   (when (and (<= (length spec) 2)
              (not (listp (car spec))))
     ;; Adjust the single binding case
@@ -182,9 +185,12 @@ if-let
 
 (defmacro when-let (spec &rest body)
   "Bind variables according to SPEC and conditionally eval BODY.
-Like `when-let*' except SPEC can have the form (SYMBOL VALUEFORM)."
-  (declare (indent 1) (debug if-let)
-           (obsolete "use `when-let*' instead." "26.1"))
+Each binding is evaluated in turn, and evaluation stops if a
+binding value is nil.  If all are non-nil, the value of the last
+form in BODY is returned.
+
+The variable list SPEC is the same as in `if-let'."
+  (declare (indent 1) (debug if-let))
   (list 'if-let spec (macroexp-progn body)))
 
 (defsubst hash-table-empty-p (hash-table)
-- 
2.16.2

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: johnw@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 27 Mar 2018 02:01:43 +0200
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> > I'll work on it in the next hours.
> 
> Sorry about the procrastination.
> 
> Here is the updated patch.  Does it look ok?

Yes, thanks.

Re: Heads-up: Emacs 26.1 RC1

[Michael Heerdegen]

Eli Zaretskii <eliz@gnu.org> writes:

> > Here is the updated patch.  Does it look ok?
>
> Yes, thanks.

Fine - installed.


Michael.

Re: Heads-up: Emacs 26.1 RC1

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Tue, 27 Mar 2018 04:58:34 +0200
> Cc: johnw@gnu.org, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > Here is the updated patch.  Does it look ok?
> >
> > Yes, thanks.
> 
> Fine - installed.

Great, thanks.