bug#27141: 26.0.50; mml-generate-mime-1 broken

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 01 Jun 2017 17:32:53 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: 27141@debbugs.gnu.org
> 
> On Thu, 01 Jun 2017 09:17:06 +0200, Lars Ingebrigtsen wrote:
> >> (with-temp-buffer
> >>   (set-buffer-multibyte nil)
> >>   (insert
> >>    (with-temp-buffer ;; <- unibyte
> 
> > Hm...  why is this buffer unibyte here?
> 
> Oops, for years I misunderstood that the multibyteness of a newly
> created buffer defaults to that of the current buffer.  But it's
> wrong!
> 
> (with-temp-buffer
>   (set-buffer-multibyte nil)
>   (with-temp-buffer
>     enable-multibyte-characters))
>  => t
> 
> > And if it is, won't (set-buffer-multibyte t) fix that?
> 
> No, it doesn't help.  As I wrote the first post,
> 
> > ・Insert the original mail (decoded) into a unibyte buffer
>                                               ^^^^^^^ multibyte
> >   (that with-temp-buffer of mml.el-[line:619] generates).
> > ・Detect the charset of the contents.
> > ・Encode the contents by that detected charset.
> > ・Insert the encoded contsnts into the other unibyte buffer
> >   (that with-temp-buffer of mml.el-[line:612] generates).
> > ・Run `mml-to-mime' that encodes the header of the original mail
> >   using `mail-encode-encoded-word-buffer' (an alias to
> >   `rfc2047-encode-message-header').
> 
> > rfc2047's encoder expects human readable text, however, there
> > are encoded ones as described above.

Ping!  Any news on this issue?  It currently indicated as blocking the
release of Emacs 26.1, so can we please expedite its resolution?

Thanks.