bug#35507: Gnus mojibakifies UTF-8 text/x-patch attachments from Thunderbird

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Thu 02 May 2019, Eli Zaretskii wrote:
>
>>> From: Andy Moreton <andrewjmoreton@gmail.com>
>>> Date: Thu, 02 May 2019 16:43:31 +0100
>>> 
>>> > So yes, I think Noam is right, and 'undecided' is a better alternative here.
>>> 
>>> That is arguing for the existing code, which does not work correctly.
>>
>> No, the existing code simply uses the undecoded string.
>>
>> What I argue for is to do this:
>>
>> diff --git a/lisp/gnus/mm-view.el b/lisp/gnus/mm-view.el
>> index 1e1d264b99..173ebfab48 100644
>> --- a/lisp/gnus/mm-view.el
>> +++ b/lisp/gnus/mm-view.el
>> @@ -475,7 +475,7 @@ mm-display-inline-fontify
>>  		    (charset
>>  		     (mm-decode-string text charset))
>>  		    (t
>> -		     text)))
>> +		     (mm-decode-string text 'undecided))))
>>        (let ((font-lock-verbose nil)     ; font-lock is a bit too verbose.
>>  	    (enable-local-variables nil))
>>          ;; We used to set font-lock-mode-hook to nil to avoid enabling
>
> ok, that does appear to work for the example message in the original bug
> report. Please push this change and we can find out if it causes any
> other problems.
>
>>> I am disinclined to look any further at this, as nobody else appears to
>>> be running the existing code before commenting, or testing the proposed
>>> patch.
>>
>> Please don't be offended, there's no intent to offend you here.  Your
>> efforts are greatly appreciated.  We are just discussing a small
>> change to what you were proposing, see above.
>
> I'm not offended, but I did want to encourage others to run the code and
> test the results before adding further commentary.
>
>> Or are you saying that using undecided as above doesn't do the job?
>>
>> (Sorry, I don't use Gnus, so to be able to reproduce the problem and
>> test a proposed solution I need detailed instructions, I cannot easily
>> do it myself without investing an inordinate amount of time.)
>
> The gnus-mock package on GNU ELPA may of some help for testing. However
> I have not used it myself, nor investigated if it's collection of test
> data contains a suitably malformed message.

It doesn't currently, but this is a perfect use-case for the package.
Shall I just add the up-thread message into the test data? Or can we
come up with a more-broken version of the message?