GNU bug report logs - #44307
27.1; UTF-8 parts transferred as 8bit in multipart messages fail to decode

Previous Next

Packages: emacs, gnus;

Reported by: Thomas Schneider <qsx <at> chaotikum.eu>

Date: Thu, 29 Oct 2020 14:12:01 UTC

Severity: normal

Tags: fixed

Merged with 45657

Found in version 27.1

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #73 received at 44307 <at> debbugs.gnu.org (full text, mbox):

From: Alexandre Duret-Lutz <adl <at> lrde.epita.fr>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 44307 <at> debbugs.gnu.org
Subject: Re: bug#44307: 27.1; UTF-8 parts transferred as 8bit in multipart
 messages fail to decode
Date: Sun, 10 Jan 2021 15:02:27 +0100
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> What about the following patch?
>
> @@ -1351,7 +1351,8 @@ nnmaildir-request-article
> -	(nnheader-insert-file-contents nnmaildir-article-file-name))
> +	(let ((nnheader-file-coding-system nnmail-file-coding-system))
> +	  (nnheader-insert-file-contents nnmaildir-article-file-name)))

I was playing with something similar this morning:

@@ -1351,7 +1351,9 @@ nnmaildir-request-article
	(throw 'return nil))
       (with-current-buffer (or to-buffer nntp-server-buffer)
	(erase-buffer)
-	(nnheader-insert-file-contents nnmaildir-article-file-name))
+       (mm-disable-multibyte)
+	(let ((coding-system-for-read mm-text-coding-system))
+	  (nnheader-insert-file-contents nnmaildir-article-file-name)))
       (cons gname num-msgid))))

mm-text-coding-system and nnmail-file-coding-system both default
to 'raw-text.

Without (mm-disable-multibyte), the patch makes no difference to me.

The documentation for 'raw-text on
https://www.gnu.org/software/emacs/manual/html_node/emacs/Coding-Systems.html
states that 'raw-text causes enable-multibyte-characters to be set to
nil, but it's not clear when this should occur, and printing
enable-multibyte-characters after the call to
nnheader-insert-file-contents still shows t.

Adding (mm-disable-multibyte) to the patch seems help a lot, although
the first impression is much worse:

1. When a mail is first displayed (using RET or g), the article buffer
   is unibyte with all non-ascii characters displayed as backslash
   sequences.  This occurs for all mails, even QP-encoded ones.

2. When a mail is displayed for the second time (using g on the same
   article or RET to change article and come back), the display is
   *perfect*.  I.e., plain/text and plain/html parts that are encoded
   with either utf-8 or windows-1252 are correctly displayed for me.

3. Running M-x gnus-backlog-shutdown gets me back to 1. where
   all non-ascii characters are displayed as backslashes.


PS: all of this is with an updated emacs 28, including the reverted
mm-with-part change.

--
Alexandre Duret-Lutz




This bug report was last modified 4 years and 159 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.