Mailing List Archive

Support open source code!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: tlug: "Andrew S. Howell": Japanese Email in emacs

tlug note from "Stephen J. Turnbull" <>
>>>>> "Andrew" == Andrew S Howell <> writes:

    Andrew> I don't think this made it to the list the last time. If
    Andrew> it did, I appologize.

I haven't seen it.  ;-)

>>>>> "Andrew" == Andrew S Howell <> writes:

    Andrew> Can anyone recomend an email package to use with emacs
    Andrew> that supports Japanese and Mime?

    Andrew> I been using mh-mail and its companion in emacs for a long
    Andrew> time. It is suppposed to work with Japanese (patched), but
    Andrew> I've gotten it to work. At any rate, mh-mail has a number
    Andrew> of weak points:

I use MH 6.8.3 without the Japanese patches, mh-e 1.14, and metamail.
I'm not sure what extra Japanese support you want; this setup
occasionally gets upset when there is raw Japanese in the headers
(where it does not belong, damn it; should be MIME quoted-printable).
I've also known it to choke on MS-Exchange message IDs, but only from
the Prime Minister's office so you're probably safe.  :-)  These
problems are much rarer and less annoying (10 messages with problems
in several thousand over the last 4 months) than junk mail....

XEmacs should do a better job of handling MIME than GNU Emacs (you
should be able to get inline images, for example) but I don't know if
it supports Japanese even yet.  This was rumored for a few months ago
but I've heard nothing since.

Here is the relevant patch to mh-utils.el to get automatic use of
metamail on Japanese content (where properly indicated in a
Content-Type header).  You would need further patching, or to use a
package like metamail.el, to get general MIME support.  metamail.el is
clearly pretty old, and may have problems with newer versions of
Emacs/Mule.  Also, to get on-the-fly launching of external viewers you
will need a certain amount of fiddling with mime.types.

I guess	I should probably fix this so that *any* file with a
Content-Type header potentially gets metamail called on it, unless I
know Mule can handle it natively.

bash-2.00$ diff -U 1 /usr/local/share/emacs/19.34/lisp/mh-utils.el ~/Programs/lisp/mh-utils.el 
--- /usr/local/share/emacs/19.34/lisp/mh-utils.el  Fri Jun 28 15:56:14 1996
+++ /home/turnbull/Programs/lisp/mh-utils.el    Fri Feb 21 18:41:09 1997
@@ -304,8 +304,15 @@
               (kill-local-variable 'write-contents-hooks))
-          (if formfile
-              (mh-exec-lib-cmd-output "mhl" "-nobell" "-noclear"
-                                      (if (stringp formfile)
-                                          (list "-form" formfile))
-                                      msg-filename)
-            (insert-file-contents msg-filename))
+          ;; SJT  Mon Feb  3 19:09:22 1997
+          (cond ((and (equal (call-process "fgrep" nil nil nil
+                                         "-i" "iso-2022-jp"
+                                         msg-filename)
+                             0)
+                      (y-or-n-p "Run metamail on this message? "))
+                 (call-process "metamail" nil t nil "-x" msg-filename))
+                (formfile
+                 (mh-exec-lib-cmd-output "mhl" "-nobell" "-noclear"
+                                         (if (stringp formfile)
+                                             (list "-form" formfile))
+                                         msg-filename))
+                (t (insert-file-contents msg-filename)))
           (goto-char (point-min))

I also use procmail to sort (eg) TLUG into a separate inbox and have
patched mh-e to associate many folders with their own inboxes (I
couldn't see a way to do this by configuring MH).  I have a couple of
other minor patches (FCCs use the same algorithm to find folders that
save does, and that has been patched to use a regexp alist the way
RMail does).  Those are available on request (still under

    Andrew> File-per-message wastes disk space

But makes finding needles in haystacks with glimpse much faster.

    Andrew> Very slow when folder contain 100+ messages

I've thought about this; my current solution is to have a job that
runs every two weeks that moves everything older than two weeks into a 
subfolder called "Old".  This could be tarred and gzipped, fixing the
file-per-message thing.  It would require slight reconfiguration and
double the CPU cycles for glimpseindex.

A better solution would be patch scan(mh) to keep a cache of the
messages in a folder so that it could start quickly with a stat of
existing files and only read new or modified ones.

    Andrew> Can't see at a glance, number of unread messages in a folder

I use xlbiff to keep track of the unread messages in a folder.  It
might be worth updating xlbiff to handle multiple folders
simultaneously, as it takes up a bit of space.  It should be possible
to configure MH to keep an "unread" sequence that you could count
relatively easily.  xlbiff does not properly handle Japanese,
unfortunately.  xlbiff also needs a lot of other patches as far as I'm 
concerned.  Details on request; this post has gone on long enough.  :-)

    Andrew> For emaces, I've been using 19.33g mule. I've been waiting

"emaxen"  :-)

    Andrew> 20 to come out, which includes mule support.

    Andrew> Whatever route I go, I want something text based, as I
    Andrew> login from home a lot to read mail. Although, if I had
    Andrew> IMAP capable mail agent, I guess I could download my
    Andrew> messages to home. I'm not too sure how this works. Anyone
    Andrew> have experience with IMAP? I seem to remember seeing
    Andrew> something on it here....

Craig mentioned that he was using it.  Pine is definitely
IMAP-capable.  I detest Pine, myself (well, I detest menus, not Pine), 
but it could be used.  The protocol shouldn't be all that hard to

Also, I found that X-Windows over a 14.4kbit connection started slow
and I had to run Mosaic with autoload of images off, but text and
buttons and such weren't slow.  YMMV, but you may find it possible to
use a GUI-based system that way.  I personally just prefer text.

                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba            
Tel: +81 (298) 53-5091;  Fax: 55-3849    
a word from the sponsor will appear below
The TLUG mailing list is proudly sponsored by TWICS - Japan's First
Public-Access Internet System.  Now offering 20,000 yen/year flat
rate Internet access with no time charges.  Full line of corporate
Internet and intranet products are available.
Tel: 03-3351-5977   Fax: 03-3353-6096

Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links