Bug/feature in base64-write-decoded-region of FLIM/1.14.3

[Peter Møller Neergaard]

I am using FLIM/1.14.3 with Wanderlust/2.4.1 on a non-MULE xemacs
(version 21.1).  

I have noticed that the function base64-write-decoded-region (used by
Wanderlust's mime-preview-extract-current-entity) has a different
behavior depending on whether the internal or the external decoder is
used:

- with the external decoder there is not done any file name expansion,
  e.g., ~ is left in the file name parsed to the program (which
  typically does not file name expand itself)

- the user is not notified if there is an error from decoding, e.g.,
  if the specified file cannot be created.

In particular, if one specifies "~/foo.bar" as the filename to decode
the message to, the function will return apparently successful without
any error message, but also without generating the file foo.bar in the
user's home directory.  (Note however that of the file is small enough
to use the internal decoder, the file foo.bar will be created in the
home directory.)

It seems unsatisfactory not to get an error message when the decoding
fails due to a wrong file name.  I have thus made a patch (attached)
that solves the two problems.  I don't know if it is the best way to
solve the problem, but it works.  I will leave it to others to decide
whether to incorporate it in the distribution and figure out whether a
similar functionality should be applied elsewhere.

Best

Peter
-- 
http://cs-people.bu.edu/turtle/contact.html
``Deserves death! I daresay he does. Many that live deserve death. 
And some that die deserve life. Can you give it to them?  
Then do not be too eager to deal out death in judgement.'' -- Tolkien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mel-b-el.el.patch
Type: application/octet-stream
Size: 1613 bytes
Desc: not available
URL: <http://lists.chise.org/pipermail/emacs-mime-en/attachments/20010606/63a82d6f/attachment.obj>