bug#34974: 27.0.50; Moving article error with duplicate suppression disabled

[Eric Abrahamsen]

On 03/24/19 17:08 PM, Basil L. Contovounesios wrote:
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> "Basil L. Contovounesios" <contovob@tcd.ie> writes:
>>
>>> With gnus-suppress-duplicates left at its default value of nil, trying
>>> to move an article with 'B m <group>' gives me the following backtrace:
>>>
>>> Debugger entered--Lisp error: (wrong-type-argument hash-table-p nil)
>>>   remhash("<redacted-message-id>" nil)
>>>   gnus-dup-unsuppress-article(1988)
>>>   gnus-summary-move-article(nil)
>>>   funcall-interactively(gnus-summary-move-article nil)
>>>   call-interactively(gnus-summary-move-article nil nil)
>>>   command-execute(gnus-summary-move-article)
>>>
>>> I'm no expert, and I haven't tried reproducing this with a minimal
>>> config, but I think gnus-summary-move-article should not call
>>> gnus-dup-unsuppress-article when gnus-suppress-duplicates is nil, right?
>>>
>>> This issue seems to have been uncovered by the switch to hash-tables in
>>> bug#33653.  Previously, gnus-dup-unsuppress-article called unintern,
>>> which would not complain when its second argument gnus-dup-hashtb was
>>> nil, even though it probably should have.
>>>
>>> Patch to follow.
>>
>> It looks like the only other call to `gnus-dup-unsuppress-articles' is
>> wrapped in a check for `gnus-suppress-duplicates' -- I suppose it would
>> be enough just to wrap this one as well?
>
> That is what the proposed patch[1] does.  Is it okay to push this to
> master?
>
> [1]: https://debbugs.gnu.org/34973#8

Already done! Our messages keep passing each other...