bug fixes for apel-10.3 flim-1.14.3 rmail-mime-1.13.0 semi-1.14.3

[守岡 知彦 / MORIOKA Tomohiko]

Larry, thanks for your report.

>>>>> In [emacs-mime-en : No.00039] 
>>>>>	"Larry" = Larry Hunter <Larry.Hunter at uchsc.edu> wrote:

Larry> I just installed apel-10.3 flim-1.14.3 rmail-mime-1.13.0 and
Larry> semi-1.14.3 into emacs 20.7 running on linux. 

Larry> I noticed and fixed a few small problems during the
Larry> installation.

Larry> First, emu is, by default, put in the VERSION_SPECIFIC_LISPDIR.
Larry> However, the process for adding to the load path doesn't take
Larry> this into account, so the FLIM and SEMI installers complain.
Larry> The fix is to add an entry in the load path for "emu" in the
Larry> *-CFG files:

Larry> (if (boundp 'VERSION_SPECIFIC_LISPDIR)
Larry>     (progn
Larry>       (add-to-list 'load-path VERSION_SPECIFIC_LISPDIR)
Larry>       (add-to-list 'load-path (expand-file-name "emu" VERSION_SPECIFIC_LISPDIR))))

Perhaps, installers of FLIM and SEMI expect that subdirs.el is existed
in version specific site-lisp.  However I agree to add this code.


Larry> Second, the rmail-mime.el file in rmail-mime-1.13.0 still makes
Larry> use of the mime-entity-header-buffer function, which was made
Larry> obsolete in the latest release of flim.  The five occurances of
Larry> mime-entity-header-buffer in rmail-mime.el can all safely be
Larry> replaced by the function mime-entity-name.

Larry> Finally, the entries in the
Larry> mime-preview-over-to-previous-method-alist and the
Larry> mime-preview-over-to-next-method-alist for rmail-mode have an
Larry> incorrect call to save-window-excursion. Because of this, when
Larry> these functions are called, they change the RMAIL buffer, but
Larry> then return to the preview buffer, which is not the correct
Larry> behavior if rmail-enable-mime is 'ask.  Eliminating this call
Larry> to save-window-excursion fixes the bug:

Now we (at least I and Handa-san) are developing better implementation
of rmail-mime for GNU Emacs 21.  We modified RMAIL to support MIME and
that code has been merged into GNU Emacs 21.0.  New rmail-mime is
depended on the new version of RMAIL.  I think new RMAIL with new
rmail-mime can support almost same features of original RMAIL, so
heavy RMAIL users can use it in daily life.

If you are interested in it, I can provide the developing code for
you.  I has been planning to release them as a supplemental package
for GNU Emacs 21, but because of my laziness it is not released yet.
It is easy to prepare full tarball including GNU Emacs 21 or patch for
GNU Emacs 21.

By the way, the new RMAIL may work with GNU Emacs 20, but I don't try
it.

Best regards,
-- 
tomo.