bug#49866: 28.0.50; gnus-summary-exit from the transient search buffer giving error

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>>
>>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>>
>>>>> Pankaj Jangid <pankaj@codeisgreat.org> writes:
>>>>>
>>>>>> I think I have isolated the cause. And the error is cause by these lines
>>>>>> in my ~/.emacs.d/init.el (only if ebdb package is installed):
>>>>>>
>>>>>> (when (package-installed-p 'ebdb)
>>>>>>   (require 'ebdb-gnus)
>>>>>>   (require 'ebdb-message))
>>>>>>
>>>>>>
>>>>>> If I remove the package ebdb then the error goes away.
>>>>>
>>>>> That's pretty weird, as EBDB doesn't mess with Gnus marks at all.
>>>>> Perhaps it is raising an error at some point, which is interrupting
>>>>> nnselect's normal buffer setup? That's a completely wild guess.
>>>>>
>>>>> Maybe try setting `ebdb-mua-auto-update-p' to nil and try again?
>>>>> Whatever damage EBDB might be doing to Gnus should be done in the auto
>>>>> update process.
>>>>>
>>>>> But again, I can't even begin to guess why this would be happening.
>>>>
>>>> more weird things happening here.
>>>>
>>>> I have ‘ebdb-mua-auto-update-p’ set to nil in my config. This was
>>>> already the case.
>>>>
>>>> But calling (describe-variable) on ‘ebdb-mua-auto-update’ shows this
>>>> error with the following steps:
>>>>
>>>> Steps:
>>>>
>>>> 1. Start emacs afresh
>>>>
>>>> 2. (setq debug-on-error t)
>>>>
>>>> 3. Launch gnus
>>>>
>>>> 4. C-h v ebdb-mua-auto-update-p RET
>>>>
>>>> Result:
>>>>
>>>> Debugger entered--Lisp error: (file-missing "Cannot open load
>>>> file" "No such file or directory" "vm-autoloads")
>>>>   require(vm-autoloads)
>>
>> Okay, after going into ebdb-vm.el and provoking the above error by
>> eval-ling the (when t ...) statement, I'm now seeing the same bug when
>> exiting search groups. In my case I'm seeing it when
>> `nnselect-push-info' is cycling over mark types, and reaches "bookmark",
>> which is of type 'tuple: the first mark of that type.
>>
>> That puts us into the (eq mark-type 'tuple) branch of the cond for the
>> first time, which is also the first time it runs:
>>
>> (map-merge
>>   'list list
>>   (alist-get type (gnus-info-marks group-info)))
>>
>> There are no bookmark marks in this group, so naturally we get the
>> no-applicable-method error for "nil".
>>
>> This does nothing to explain how this code doesn't error normally, or
>> how on earth raising a `require'-based error would change its behavior.
>
> Well I had to restart Emacs anyway in order to get a working Gnus back,
> so I just checked this now. Apparently edebugging `nnselect-push-info'
> was enough to raise the error.
>
> A little while ago I changed the `condition-case' inside `nnselect-run'
> into a `condition-case-unless-debug', because it was swallowing useful
> errors. I guess both Pankaj's `require' error and my edebugging put
> Emacs into a "debug" mode, so an error that was being swallowed was now
> raised.

And of course this is complete nonsense because none of this group
exiting code is called from within `nnselect-run' at all. I have no idea
what I was thinking. I need to stop trying to squeeze debugging sessions
into little ten-minute spaces.

Of course, now I have no theory as to why the bug is swallowed until
debugging conditions are triggered. I've attached a patch that I think
solves the root problem, but given my track record today it should be
taken with a grain of salt.

(This doesn't mean I don't still think the `condition-case' in
`nnselect-run' should be removed though!)

nnselect-update-marks.diff
Description: Text Data