Re: Inefficiency in mm-uu.el

[Hrvoje Niksic <hniksic@srce.hr>]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > > Do you mean to automatically setup mm-uu-decode-function by
> > > searching uudecode on the system at loading time of mm-uu.el?
> > 
> > Yes.
> > 
> > > If so, please feel free to patch it.
> > 
> > Yes, if Lars will accept the patch.  I seem to recall he said
> > something about "not trusting external programs" for base64, so I
> > don't know if it applies to uuencode.  Lars?
> 
> Well, I, uhm (sorry, I'm watching _Schindler's List_ while listening
> to _Dots and Loops_ and answering mail) er, uhm, I think that having
> an external program to decode uuencoded things is probably fine.
> (Ooo.  Who knew those dastardly Germans were so *naughty*.  I'm glad we 
> have directors like Spielberg!)  External programs are a general cause 
> of breakage, especially in Emacs 20.3 -- how many bug reports have we
> had for NT-related metamail (etc.) breakages?  But I think it's fine
> to give users an opportunity to use external programs as long as it's
> not the default.

So my imaginary patch would not be accepted.

Because, we already have what you describe.  The following piece of
code in .emacs will enable the use of an external program:

    (setq mm-uu-decode-function 'uudecode-decode-region-external)

does it.  What I wanted to do is something along the lines of:

    (defvar mm-uu-decode-function (if (locate-file "uudecode" exec-path)
				      'uudecode-decode-region-external
				    'uudecode-decode-region))


P.S.
The latest XEmacs 21.2 has native base64 support.  Let us all
rejoice.  Sending flowers is optional.

P.S.
Fortunately, I *didn't* watch _Saving Private Ryan_ while typing this.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
AMAZING BUT TRUE: There is so much sand in Northern Africa that if
it were spread out it would completely cover the Sahara Desert.