From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#44307: 27.1; UTF-8 parts transferred as 8bit in multipart messages fail to decode Date: Thu, 07 Jan 2021 17:10:22 +0100 Message-ID: <87ft3c3ez5.fsf@gnus.org> References: <8735zj6q6h.fsf@goulash.lrde.epita.fr> <8735zf3f46.fsf@gnus.org> <87k0srg0hz.fsf@goulash.lrde.epita.fr> <87wnwo3kd2.fsf@gnus.org> <87wnwo7muj.fsf@lrde.epita.fr> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12857"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: 44307@debbugs.gnu.org To: Alexandre Duret-Lutz Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 07 17:11:33 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxXsq-0003Df-H5 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Jan 2021 17:11:32 +0100 Original-Received: from localhost ([::1]:39798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxXsp-00080a-EH for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 07 Jan 2021 11:11:31 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57104) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxXsM-0007y3-Ms for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2021 11:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36825) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kxXsM-0002XN-24 for bug-gnu-emacs@gnu.org; Thu, 07 Jan 2021 11:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kxXsL-0000dR-SS; Thu, 07 Jan 2021 11:11:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bugs@gnus.org Resent-Date: Thu, 07 Jan 2021 16:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44307 X-GNU-PR-Package: emacs,gnus Original-Received: via spool by 44307-submit@debbugs.gnu.org id=B44307.16100358342407 (code B ref 44307); Thu, 07 Jan 2021 16:11:01 +0000 Original-Received: (at 44307) by debbugs.gnu.org; 7 Jan 2021 16:10:34 +0000 Original-Received: from localhost ([127.0.0.1]:48370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxXru-0000ck-Gi for submit@debbugs.gnu.org; Thu, 07 Jan 2021 11:10:34 -0500 Original-Received: from quimby.gnus.org ([95.216.78.240]:39336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kxXrt-0000cW-91 for 44307@debbugs.gnu.org; Thu, 07 Jan 2021 11:10:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=wySh5L0sbgUkakmJ80COkSk+wgBLHHj61EJoA93ih1Q=; b=QeMyxaVie/39H82NMBEEXUSe9j 63JyycVIHT56kAf7dASwvTT8S/Uv+hYJGUihNnPGJnrQ1aV0PGRUV9hQLe64iD7Y2imYzMelqOKHX owrpasmxOJ60Sssc8NrBQMMH0LnUsaCLWX/oGhtqJjxmRZYyvlRiYCPqqRVLf+jmHkqk=; Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kxXrk-0004w2-7d; Thu, 07 Jan 2021 17:10:26 +0100 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEU0P0OUYm+hqqnv 8O7///8wBPU6AAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UBBw8vJA+pqhkAAAG5SURBVDjLdZTbscQg CIbFNCCmAYQGEui/twVvcc7McfYhy5cfuSaldaqYNYD097jZj/5jXwS3HXgCI/+XOZUJcAN1U9kK wOXKJeARLAJ5240rYqnL1Qkyc8ElqQdIDpYCDmBUmWpXlBOovQmBlqv7A/z6lQsUPly9R+54Au2J nfkpyy6XzqC6BYvX0p/CxBswezDlZhdHDjLSq/JS8bCR0nVHgWEAriLcXn+zkosfB7ZAhNlmok/U zmFiZf9pq6VmzzzArQkLqN9c0kXJS9cSikax/cbsghwVGk011nSNmKW1SEsnUJ6gZKYAOcADZuJB BUDgpiYUoYNCtKp2AKBsKmSMzJICiPQ7ArCDONICaFfkxo3ZntG/GuNgA2ilSMuzF41BWiBxJjdq Lz15pHhNIPzsmbaooUyQSa9zfHqfPSavtsABxnNsQEpG31BPdfSvJHs/X/O+AFw80Q2KLoDVX3q2 JG9Qa8zTkrzXduVj789LQkPQq9u8uGxlerIP1CZO9B4b+IGEzW3cvBtMKZ8AAX0hC8TmXRuE8Tse CXJtHZyk77XK6GA0ZHwTbtrflD6igDGyTLELuzI/gZ6Ak5LRf9kAAAAldEVYdGRhdGU6Y3JlYXRl ADIwMjEtMDEtMDdUMTU6NDc6MzUrMDA6MDA/PWjFAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIxLTAx LTA3VDE1OjQ3OjM1KzAwOjAwTmDQeQAAAABJRU5ErkJggg== X-Now-Playing: It's Immaterial's _Life's Hard And Then You Die_: "Ed's Funky Diner" In-Reply-To: <87wnwo7muj.fsf@lrde.epita.fr> (Alexandre Duret-Lutz's message of "Thu, 07 Jan 2021 17:06:44 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:197493 Archived-At: Alexandre Duret-Lutz writes: > Question: shouldn't mm-with-part always leave the buffer in unibyte > mode? The comment at the beginning of the macro seems to suggest that, > but the new "if" does not call (mm-disable-multibyte) after inserting > the part. Hm, true. > - (insert-buffer-substring (mm-handle-buffer handle)) > + (progn > + (insert-buffer-substring (mm-handle-buffer handle)) > + (mm-disable-multibyte)) No, disabling multibyte in a non-empty buffer is always the wrong thing to do -- using encode-coding-region is probably the thing to do here. > ;; Do the decoding. > (mm-disable-multibyte) > (insert-buffer-substring (mm-handle-buffer handle)) > > this seems to fix text/plain utf-8 parts as well, however the > rendering of window-1252 parts is now broken... Yeah, that's to be expected. Could you forward a message with a windows-1252 part, too (like the previous one), and I can add it to the test cases. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no