Re: rfc2047.el bug?

[Katsumi Yamaoka <yamaoka@jpl.org>]

>>>>> In <m3znhcxili.fsf@defun.localdomain>
>>>>>	Jesper Harder <harder@myrealbox.com> wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Gnus sometimes encodes a Japanese-English mixture text to the
>> line length exceeding 76 characters.  For example:

[...]

> I've checked in a fix.

Thanks!  It fixes a problem when encoding at least Japanese text.
However, the FLIM's encoder is still high quality overwhelmingly.
We can use it for Gnus as follows:

(eval-after-load "mail-parse"
  '(progn
     (defalias 'mail-encode-encoded-word-buffer
       (lambda nil
	 (require 'eword-encode)
	 (mime-encode-header-in-buffer t)))
;;     (defadvice eword-encode-text (after downcase-charset activate)
;;       "Convert charset and encoding strings to lower case."
;;       (require 'eword-decode)
;;       (if (and ad-return-value
;;		(string-match eword-encoded-word-regexp
;;			      ad-return-value))
;;	   (setq ad-return-value
;;		 (concat
;;		  (downcase (substring ad-return-value
;;				       0 (match-beginning 4)))
;;		  (substring ad-return-value
;;			     (match-beginning 4))))))
     ))

P.S.
Please don't use smtpmail.el included in the FLIM package.  It
is slightly incompatible with the Emacs version of smtpmail.el.
I've made a proposal to remove it from the package, but there's
no response from the authors.
-- 
Katsumi Yamaoka <yamaoka@jpl.org>
;; I'm now renewing the "multiple message frames" suit. :)