bug#49926: [PATCH] Fix NNIMAP search command in the gnus

[Eric Abrahamsen <eric@ericabrahamsen.net>]

On 08/08/21 14:29 PM, Jan Stranik wrote:
> On 08/07/21 16:06 PM, Eric Abrahamsen wrote:
>> Jan Stranik via "Bug reports for GNU Emacs, the Swiss army knife of text
>> editors" <bug-gnu-emacs@gnu.org> writes:
>>
>>> In the version 27.2 of emacs, the nnimap search commands stopped
>>> working in gnus.
>>>
>>> Good example is a command AT to find a referred
>>> thread in the summary buffer. The observed behaviour was that the
>>> search command returned no error.
>>>
>>> The problem turned out to be in the way how imap query is sent to the
>>> server. The function nnimap-make-thread-query used a format function
>>> with foramt specifier %S. For string values with formatting the string
>>> returned is in the format #("string" ....). The result was tha the
>>> query sent to the server looked like:
>>>   23:52:00 [stranik.org] 1980 UID SEARCH (OR HEADER REFERENCES
>>> #("<87pmurac3u.fsf@stranik.org>" 0 28 (ws-butler-chg chg)) HEADER
>>> Message-Id #("<87pmurac3u.fsf@stranik.org>" 0 28 (ws-butler-chg
>>> chg)))
>>>
>>> which is an invalid query.
>>>
>>> The change formats the string with %s specifier which discards text
>>> properties.
>>
>> But that also removes the quoting around the message ids -- are we sure
>> that's still valid?

(Putting debbugs back in the cc)

> You're right. Per the specification, the strings are expected to be
> either in literal or quotes syntax
> (https://datatracker.ietf.org/doc/html/rfc3501#section-4.3).
>
> Adding quotes back to make the strings to be in quoted syntax.
>
> Interestingly, dovecot seems to accept the strings without quotes as
> well.

I've found dovecot to be generally pretty permissive, though obviously
we want to stick closely to the RFCs here.

> New patch attached.

This seems fine, but just thinking out loud: is there anything else the
%S could potentially get us, here? Extra quoting of special characters?

Our other option would be to explicitly remove properties from the
strings beforehand; I'm just wondering if one approach is preferable
over another.

Eric