WL on emacs 23

[Katsumi Yamaoka]

>>>>> 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,