bug#34983: 27.0.50; Gnus cannot start

[Deus Max <deusmax@gmx.com>]

On Sun, Mar 24 2019, Eric Abrahamsen wrote:

> Deus Max <deusmax@gmx.com> writes:
>
>> On Sun, Mar 24 2019, Eric Abrahamsen wrote:
>>
>>> Bastien <bzg@gnu.org> writes:
>>>
>>>> I checked out and buil Emacs from master today 24-03-2019.
>>>>
>>>> I started Gnus using my usual configuration (see
>>>> https://github.com/bzg/dotemacs/blob/master/emacs.el) and got this
>>>> error:
>>>>
>>>> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>>>>   <=(nil 6)
>>>>   gnus-get-unread-articles(nil nil)
>>>>   gnus-setup-news(nil nil nil)
>>>>   #f(compiled-function () #<bytecode 0x1556149e8b91>)()
>>>>   gnus-1(nil nil nil)
>>>>   gnus(nil)
>>>>   funcall-interactively(gnus nil)
>>>>   call-interactively(gnus record nil)
>>>>   command-execute(gnus record)
>>>>   execute-extended-command(nil "gnus" "gnus")
>>>>   funcall-interactively(execute-extended-command nil "gnus" "gnus")
>>>>   call-interactively(execute-extended-command nil nil)
>>>>   command-execute(execute-extended-command)
>>>>
>>>> Starting Gnus *without* a .newsrc.eld file, I can list local groups
>>>> from my dovecot local IMAP server, but I get another weird behavior:
>>>> after leaving the summary buffer, the group I just left is listed one
>>>> more time; if I enter the group and leave it again, I get three groups
>>>> of the same name in the group buffer, etc.
>>>>
>>>> To read Gnus using my .newsrc.eld file again, I tried to revert back
>>>> to Emacs 26.0.92 but now Emacs seems unable to read my .newsrc.eld at
>>>> all.  Is it possible that recent changes against Gnus changed the way
>>>> Gnus parses .newsrc.eld?
>>>>
>>>> Copying Eric, as he seems to have been active on Gnus recently.
>>>
>>> This is frustrating -- this was the most important part of the patch,
>>> and the part I thought I'd tested most thoroughly. At worst I think Gnus
>>> may be trying to read .newsrc.eld using the wrong encoding, so I don't
>>> think you will have lost anything permanently. (Still, I'm very sorry
>>> this is causing you Gnus outage.)
>>>
>>> First -- did you run "make bootstrap" before running this new version?
>>> Second, can you tell me if your non-ascii group names are being saved in
>>> .newsrc.eld in utf-8, or if they have literal byte sequences in them?
>>>
>> Confirm for me, non-ascii group names are now being saved in literal
>> byte sequences in them. Here's an example:
>> "nnimap+AIA:Union/\316\224\316\243-\316\243\317\211\316\274\316\261\317\204\316\265\316\257\316\277\317\205"
>>
>> Didn't have any such issues before. Compiled using "make bootstrap", 3
>> days ago (and today).
>
> Actually, I'm fairly sure that that's how Gnus has always done it, and I
> tried not to disturb that. But obviously I've done something wrong along
> the way and I think one part of Gnus is using a decoded version of the
> group name, and another part is using the encoded version.
>
> Are you seeing duplicate group names? Would you check
> (text-properties-at (line-beginning-position)) on both of the duplicated
> groups, and tell me the value of the 'gnus-group property' for both?
>
> Thanks,
> Eric

I didn't see any duplicate groups in my .newsrc.eld file.
Output on above nnimap group (with literal byte sequences) is:
(fontified t)