From yamaoka ＠ jpl.org Thu Apr 3 15:48:57 2008 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Thu, 03 Apr 2008 15:48:57 +0900 Subject: WL on emacs 23 References: <87ejmur5pw.wl%clemens@endorphin.org> <87ejhugpoa.wl%clemens@endorphin.org> <874parhwy1.wl%clemens@endorphin.org> Message-ID: 日本語版 >>>>> In [Wanderlust English : No.02349] Katsumi Yamaoka wrote: > こんにちは寺西さん。 > お久しぶりです。いかがですか? ぼくはまだ Emacs で遊んでいます。;-) > ときに、少なくない Wanderlust ユーザーが FLIM (もしかしたら APEL > と SEMI も) の新版がリリースされたことを知らないらしいことが露見 > しました。Wanderlust を Emacs 23 で走らせるには最新のものが必要 > なんですが。原因の一端は Wanderlust のホームページが最新の情報を > 表示していないことにあります。更新して反応していただけませんか? 念のため、メインテイナーの方(々)には APEL、FLIM および SEMI のリ リースアナウンスを wl-en メーリングリストにも送ってくださること をお願いします。 旧版の FLIM の base64 デコードの問題に加えて、最新の FLIM にさえ quoted-printable のデコードとエンコードに関する少なくとも二つの 問題があります。ひとつは伊藤和博さんがパッチとともにリポートしま した: http://news.gmane.org/group/gmane.emacs.mime.japanese/thread=669/force_load=t (quoted-printable でエンコードされた添付をファイルにセーブすると きに行末の `=' が残る。) もうひとつは Dmitri Minaev さんとぼくがリポートしました: http://news.gmane.org/group/gmane.mail.wanderlust.general.japanese/thread=5844/force_load=t 両方ともとりわけラテン・テキストを書く人たちにとって深刻です (ラ テン・テキストはデフォルトでは quoted-printable でエンコードされ ます)。個人的には次の記事に添付されているパッチ http://article.gmane.org/gmane.emacs.mime.japanese/669 そしてさらにこのメッセージのパッチを適用することをお勧めします。 Emacs 23 での quoted-printable のエンコードに着目しますが、ドラ フトバッファ (マルチバイトになっています) にある Latin-1 文字を 含んでいるテキストが、以下のようにエンコードされません: (set-language-environment 'German) (setq default-mime-charset-for-write 'iso-8859-1) (with-temp-buffer (set-buffer-multibyte t) (insert "To: whom\n" mail-header-separator "\nGrüß Gott\n") (let (mime-edit-insert-user-agent-field) (mime-edit-translate-buffer)) (buffer-string)) => "To: whom MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --text follows this line-- Gr\374\337 Gott " 動作しない根本的な原因は、以下のフォームに Emacs 22 以前のものは ("\374" . 252) を返すのに対して Emacs 23 が ("\374" . 4194300) を返すことと、quoted-printable のエンコーダが後者のようなもので は働かないことです。 (with-temp-buffer (set-buffer-multibyte t) (insert "ü") (encode-coding-region (point-min) (point-max) 'iso-8859-1) (cons (buffer-string) (char-after (point-min)))) バッファの内容のマルチバイトかユニバイトかを変更するどんな操作も あまりよろしくないと思いますが、それは許されているようです。そこ で、mel-q-ccl.el の quoted-printable エンコーダを base64 組み込 み関数ののように働かせることを提案します。 (base64-encode-string (string 4194300)) => "/A==" (base64-encode-string (string 252)) => "/A==" パッチです: -------------- next part -------------- --- mel-q-ccl.el~ 2006-06-12 15:10:02 +0000 +++ mel-q-ccl.el 2008-04-03 06:33:51 +0000 @@ -893,7 +893,13 @@ (defun quoted-printable-ccl-encode-region (start end) "Encode the region from START to END with quoted-printable encoding." (interactive "*r") - (decode-coding-region start end 'mel-ccl-quoted-printable-lf-lf-rev)) + (save-excursion + (goto-char start) + (insert (prog1 + (decode-coding-string + (string-as-unibyte (buffer-substring start end)) + 'mel-ccl-quoted-printable-lf-lf-rev) + (delete-region start end))))) (defun quoted-printable-ccl-insert-encoded-file (filename) "Encode contents of the file named as FILENAME, and insert it." -------------- next part -------------- (http://article.gmane.org/gmane.emacs.mime.japanese/672 で投稿した暫定対策の defadvice は破棄してください。) よろしくお願いします。 From yamaoka ＠ jpl.org Thu Apr 3 15:48:38 2008 From: yamaoka ＠ jpl.org (Katsumi Yamaoka) Date: Thu, 03 Apr 2008 15:48:38 +0900 Subject: WL on emacs 23 References: <87ejmur5pw.wl%clemens@endorphin.org> <87ejhugpoa.wl%clemens@endorphin.org> <874parhwy1.wl%clemens@endorphin.org> Message-ID: >>>>> In [Wanderlust English : No.02349] Katsumi Yamaoka wrote: > Hi Teranisi-san, > Long time no see. How's things? I'm still playing with Emacs. ;-) > Now, it was found out that not a few Wanderlust users don't seem > to know the new versions of FLIM (and possibly APEL and SEMI) > have been released, whereas the latest ones are needed to run > Wanderlust on Emacs 23. One end of the cause is that the > Wanderlust home page doesn't show the up-to-date information. > Could you please update it and ack? To make sure, I ask the maintainer(s) for sending the release announcements of APEL, FLIM and SEMI also to the wl-en mailing list. In addition to the base64 decoding problem in the old versions of FLIM, there are also at least two problems concerning the quoted-printable decoding and encoding even in the latest FLIM. One was reported by Kazuhiro Ito with a patch as: http://news.gmane.org/group/gmane.emacs.mime.japanese/thread=669/force_load=t (`='s in the line ends will remain when saving an attachment that has been encoded by quoted-printable to a file.) The other was by Dmitri Minaev and me as: http://news.gmane.org/group/gmane.mail.wanderlust.general.japanese/thread=5844/force_load=t Both would be serious particularly to people who write Latin text, that will be encoded by quoted-printable by default. Personally I recommend applying the patch attached in: http://article.gmane.org/gmane.emacs.mime.japanese/669 And also the patch in this message. Focusing on the quoted-printable encoding in Emacs 23, text containing Latin-1 characters in the draft buffer, which is in multibyte, will not be encoded as follows: (set-language-environment 'German) (setq default-mime-charset-for-write 'iso-8859-1) (with-temp-buffer (set-buffer-multibyte t) (insert "To: whom\n" mail-header-separator "\nGrüß Gott\n") (let (mime-edit-insert-user-agent-field) (mime-edit-translate-buffer)) (buffer-string)) => "To: whom MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --text follows this line-- Gr\374\337 Gott " The basic reason it doesn't work is that Emacs 23 returns ("\374" . 4194300) for the following form while Emacs 22 and old ones return ("\374" . 252), and the quoted-printable encoder does not work with the ones like the former. (with-temp-buffer (set-buffer-multibyte t) (insert "ü") (encode-coding-region (point-min) (point-max) 'iso-8859-1) (cons (buffer-string) (char-after (point-min)))) Although I think any operation that modifies the multibyteness of the buffer's contents is not so good, it appears to be permitted. So, I suggest making the quoted-printable encoder in mel-q-ccl.el work like the built-in base64 encoder. (base64-encode-string (string 4194300)) => "/A==" (base64-encode-string (string 252)) => "/A==" Here is a patch: -------------- next part -------------- --- mel-q-ccl.el~ 2006-06-12 15:10:02 +0000 +++ mel-q-ccl.el 2008-04-03 06:33:51 +0000 @@ -893,7 +893,13 @@ (defun quoted-printable-ccl-encode-region (start end) "Encode the region from START to END with quoted-printable encoding." (interactive "*r") - (decode-coding-region start end 'mel-ccl-quoted-printable-lf-lf-rev)) + (save-excursion + (goto-char start) + (insert (prog1 + (decode-coding-string + (string-as-unibyte (buffer-substring start end)) + 'mel-ccl-quoted-printable-lf-lf-rev) + (delete-region start end))))) (defun quoted-printable-ccl-insert-encoded-file (filename) "Encode contents of the file named as FILENAME, and insert it." -------------- next part -------------- (Please annul the workaround defadvice I posted in the message: http://article.gmane.org/gmane.emacs.mime.japanese/672) Regards,