Re: mail-add-attachment

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Andreas suggested to add autoload cookies to the corresponding Gnus
> files, but I see that both mml.el and mm-encode.el are entirely devoid
> of such cookies, so I guess there are some Gnus coding standards
> involved, which I don't want to break.

I don't have an opinion on whether autoload cookies should be placed in
those files.

>> I'd rather use a declare-function plus an explicit require call.
> You mean, require in the function body, like below?

>     (defun mail-add-attachment (file)
>       "Add FILE as a MIME attachment to the end of the message."
>       (interactive "fAttach file: ")
>>>>> (require 'mml)
>>>>> (require 'mm-encode)
>       (mml-attach-file file
> 		       (or (mm-default-file-encoding file)
> 			   "application/octet-stream") nil)
>       (setq mail-encode-mml t))

Yes.  It's not great, but it's better than manually managed autoload
cookies (which fail to include the (fn ARG1 AG2) calling
convention info, and are likely to get out of date).

>> My favorite would be to use a new require-autoload construct which
>> the byte-compiler would replace by autoloads of the functions
>> actually called (so the byte-compiler would manage the list of
>> autoloads rather than doing it by hand).
> I'll leave that project to you ;-)

Damn!

>> > +\\[mail-attach-file] insert a text file into the message.
>> > +\\[mail-add-attachment] add to the message a file as a MIME attachment.
>> I think mail-attach-file needs to be renamed to mail-insert-file.
> I thought about this, but isn't it too late to introduce incompatible
> changes on the user level?  This command is there by that name since
> 1997.  I would at most go with a new name and an alias that is
> deprecated.

Of course we'd keep an osolete alias.  But since we're making changes
anyway, I'd rather add that extra change to your patch.


        Stefan