bug#34983: 27.0.50; Gnus cannot start

[Deus Max <deusmax@gmx.com>]

On Mon, Mar 25 2019, Eric Abrahamsen wrote:

> On 03/25/19 07:04 AM, Deus Max wrote:
>> 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)
>
> Sorry, I meant duplicate groups appearing in your *Group* buffer, not
> your.newsrc.eld file.

Yes, I have this weirdness under "Deleted Items".
On my web interface there is only the top-most group, with no subgroups
as "Greek Holidays". As for the subgroup name with the long hash
attached, I would never have created such a group name. it is an
artefact.