From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: mail-add-attachment Date: Fri, 09 Sep 2011 17:49:44 -0400 Message-ID: References: <838vq60wm6.fsf@gnu.org> <837h5h69lf.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1315604995 15059 80.91.229.12 (9 Sep 2011 21:49:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2011 21:49:55 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 09 23:49:51 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 1R28xL-0007sE-46 for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2011 23:49:51 +0200 Original-Received: from localhost ([::1]:57897 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R28xK-00085d-GF for ged-emacs-devel@m.gmane.org; Fri, 09 Sep 2011 17:49:50 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:43405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R28xH-00085Y-QV for emacs-devel@gnu.org; Fri, 09 Sep 2011 17:49:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R28xH-0007sP-0B for emacs-devel@gnu.org; Fri, 09 Sep 2011 17:49:47 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:64667 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R28xF-0007s6-HZ; Fri, 09 Sep 2011 17:49:45 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKKJak64rwMJ/2dsb2JhbABCqBZ5gVIBAQQBViMFCws0EhQYDSSICbgxhm4EoC2EQQ X-IronPort-AV: E=Sophos;i="4.68,358,1312171200"; d="scan'208";a="135384615" Original-Received: from 184-175-3-9.dsl.teksavvy.com (HELO pastel.home) ([184.175.3.9]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 09 Sep 2011 17:49:44 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 55DAD589E5; Fri, 9 Sep 2011 17:49:44 -0400 (EDT) In-Reply-To: <837h5h69lf.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 09 Sep 2011 18:04:12 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:143830 Archived-At: > 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