From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: mail-add-attachment Date: Fri, 09 Sep 2011 18:04:12 +0300 Message-ID: <837h5h69lf.fsf@gnu.org> References: <838vq60wm6.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1315580674 3595 80.91.229.12 (9 Sep 2011 15:04:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2011 15:04:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 09 17:04:30 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R22d4-0000Fi-Dp for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2011 17:04:30 +0200 Original-Received: from localhost ([::1]:43741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R22d3-0007H1-C9 for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2011 11:04:29 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R22cx-0007FG-Ef for emacs-devel@gnu.org; Fri, 09 Sep 2011 11:04:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R22cs-0007OA-VU for emacs-devel@gnu.org; Fri, 09 Sep 2011 11:04:23 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:51816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R22cs-0007O5-OG for emacs-devel@gnu.org; Fri, 09 Sep 2011 11:04:18 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LR900F00GI61S00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 09 Sep 2011 18:04:13 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([77.126.9.62]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LR900EBZGJ1EEE0@a-mtaout20.012.net.il>; Fri, 09 Sep 2011 18:04:13 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143827 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Fri, 09 Sep 2011 10:32:19 -0400 > > > +(autoload 'mm-default-file-encoding "mm-encode" > > + "Return the default encoding for FILE.") > > I must say I don't like such manually-managed autoloads. 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'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)) > 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 ;-) > > +\\[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.