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:
>
>> 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.

Andy I know you're pretty time-limited now, but what do you think about
this? I've always felt that the `condition-case' inside `nnselect-run'
was kind of dangerous, and it looks like it has been swallowing bugs.
It's not a hard bug to fix, but I'd sure like to address the bigger
issue of raising errors from `nnselect-run'. Do you have any feelings
about it?

(Pankaj, in the meantime I'll do away with the `require' statements in
ebdb-vm.el, thanks for that report.)