From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/39654 Path: main.gmane.org!not-for-mail From: prj@po.cwru.edu (Paul Jarc) Newsgroups: gmane.emacs.gnus.general Subject: Re: new Mail-Followup-To patch...please take a look... Date: Tue, 23 Oct 2001 12:32:06 -0400 Organization: What did you have in mind? A short, blunt, human pyramid? Sender: owner-ding@hpc.uh.edu Message-ID: References: <87wv1m9y6j.fsf@mclinux.com> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035175331 29127 80.91.224.250 (21 Oct 2002 04:42:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:42:11 +0000 (UTC) Return-Path: Original-Received: (qmail 7034 invoked from network); 23 Oct 2001 16:34:17 -0000 Original-Received: from malifon.math.uh.edu (mail@129.7.128.13) by mastaler.com with SMTP; 23 Oct 2001 16:34:17 -0000 Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 15w4Tf-0000pD-00; Tue, 23 Oct 2001 11:32:31 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Tue, 23 Oct 2001 11:32:07 -0500 (CDT) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id LAA07548 for ; Tue, 23 Oct 2001 11:31:55 -0500 (CDT) Original-Received: (qmail 7001 invoked by alias); 23 Oct 2001 16:32:08 -0000 Original-Received: (qmail 6996 invoked from network); 23 Oct 2001 16:32:08 -0000 Original-Received: from multivac.student.cwru.edu (HELO multivac.cwru.edu) (qmail-remote@129.22.96.25) by gnus.org with SMTP; 23 Oct 2001 16:32:08 -0000 Original-Received: (qmail 29277 invoked by uid 500); 23 Oct 2001 16:32:28 -0000 Mail-Followup-To: ding@gnus.org Original-To: ding@gnus.org Mail-Copies-To: never In-Reply-To: <87wv1m9y6j.fsf@mclinux.com> (Josh Huber's message of "Tue, 23 Oct 2001 11:24:36 -0400") Original-Lines: 67 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/20.7 Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:39654 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:39654 Josh Huber wrote: > C-c C-f C-f move to Followup-To > + C-c C-f C-m move to Mail-Followup-To Missed a M-x tabify, I guess. > + ;; Generate the Mail-Followup-To header if the header is not there... > + (if (and (or message-subscribed-regexps > + message-subscribed-addresses > + message-subscribed-address-functions) > + (not (mail-fetch-field "mail-followup-to"))) > + (message-generate-headers > + `(("Mail-Followup-To" . ,(message-make-mft)))) > + ;; otherwise, delete the MFT header if the field is empty > + (when (equal "" (mail-fetch-field "mail-followup-to")) > + (message-remove-header "Mail-Followup-To"))) > ;; Let the user do all of the above. > (run-hooks 'message-header-hook)) I had hoped that MFT would be enabled by default: existing configurations would automatically get MFT when sending to any to-address or to-list address. (This would mean the 'subscribed parameter would have to be replaced with a complementary 'not-subscribed parameter, among other things.) But if that's not going to be the case, then this chunk might as well be a hook function. It'll just be one extra line needed in .gnus to enable MFT. > +(defun message-mft-helper (recipients regexps) > + `(or ,@(apply 'append Might (cons 'or (apply ...)) be clearer? See also below. > + (mapcar '(lambda (recipient) > + (mapcar '(lambda (regexp) > + (list 'string-match regexp recipient)) > + regexps)) > + recipients)))) '(lambda ...) does not get byte-compiled. (function (lambda ...)) does, and otherwise means the same thing. > + (when (eval (message-mft-helper recipients mft-regexps)) > + msg-recipients))) How about: (save-match-data (when (eval (apply 'append '(or) (mapcar (function (lambda (regexp) (mapcar (function (lambda (recipient) `(string-match ,regexp ,recipient))) recipients))) mft-regexps))) msg-recipients)) This absorbs (the equivalent of) message-mft-helper into message-make-mft, doesn't trample match-data, and might evaluate fewer string-matches on average. (It checks the first address against each regexp, then the second address, ..., instead of checking the first regexp against each address, .... I'm guessing that when there is a match, the first address is likely to match, and the first regexp is not.) paul