new Mail-Followup-To patch...please take a look...

new Mail-Followup-To patch...please take a look...

[Josh Huber]

Here's my current mail-followup-to generation patch against message.el
(at the end of the message).

I'm currently using it, and it seems to work fine (for me), but I'd
like other people to test it.

I'm configuring it this way:

;;---------------------
;; Mail-Followup-To settings
(setq gnus-parameters
      '(("^mail\\.lists\\." (subscribed . t))))

(defun jmh-find-subscribed-addresses ()
  (let ((groups (mapcar 'car (cdr gnus-newsrc-alist))))
    (delete-if nil (mapcar
		    '(lambda (group)
		       (or (gnus-group-find-parameter group 'to-address)
			   (gnus-group-find-parameter group 'to-list)))
		    (delete-if-not '(lambda (group)
				      (gnus-group-find-parameter
				       group 'subscribed))
				   groups)))))

(setq message-subscribed-addresses (jmh-find-subscribed-addresses))

(defun show-mft ()
  (let ((recipients))
    (save-excursion
      (save-restriction
	(message-narrow-to-head)
	(message-options-set-recipient)
	(or (message-make-mft) "none")))))
;;--------------------

I'd like the jmh-find-subscribed-addresses to be included in gnus as a
utility function.  Maybe I should write up some documentation for this
as well for the manual?

The show-mft is just a little utility function that tells me what the
MFT header will be when the message is sent.  (for testing)

I've also cleaned up the function for scanning through all the group
parameters and pulling out the subscription addresses a little.  I
like it much better now.

Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.131
diff -u -r6.131 message.el
--- message.el	2001/10/17 17:53:42	6.131
+++ message.el	2001/10/23 15:28:49
@@ -424,6 +424,32 @@
 		 (const use)
 		 (const ask)))
 
+(defcustom message-subscribed-address-functions nil
+  "*Specifies functions for determining list subscription.
+If nil, do not attempt to determine list subscribtion with functions.
+If non-nil, this variable contains a list of functions which return
+regular expressions to match lists.  These functions can be used in
+conjunction with `message-subscribed-regexps' and
+`message-subscribed-addresses'."
+  :group 'message-interface
+  :type '(repeat sexp))
+
+(defcustom message-subscribed-addresses nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+addresses can be used in conjuction with
+`message-subscribed-address-functions' and `message-subscribed-regexps'."
+  :group 'message-interface
+  :type '(repeat string))
+
+(defcustom message-subscribed-regexps nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+regular expressions can be used in conjuction with
+`message-subscribed-address-functions' and `message-subscribed-addresses'."
+  :group 'message-interface
+  :type '(repeat regexp))
+
 (defcustom message-sendmail-f-is-evil nil
   "*Non-nil means don't add \"-f username\" to the sendmail command line.
 Doing so would be even more evil than leaving it out."
@@ -1468,6 +1494,7 @@
   (define-key message-mode-map "\C-c\C-f\C-n" 'message-goto-newsgroups)
   (define-key message-mode-map "\C-c\C-f\C-d" 'message-goto-distribution)
   (define-key message-mode-map "\C-c\C-f\C-f" 'message-goto-followup-to)
+  (define-key message-mode-map "\C-c\C-f\C-m" 'message-goto-mail-followup-to)
   (define-key message-mode-map "\C-c\C-f\C-k" 'message-goto-keywords)
   (define-key message-mode-map "\C-c\C-f\C-u" 'message-goto-summary)
   (define-key message-mode-map "\C-c\C-b" 'message-goto-body)
@@ -1547,6 +1574,7 @@
     ["Keywords" message-goto-keywords t]
     ["Newsgroups" message-goto-newsgroups t]
     ["Followup-To" message-goto-followup-to t]
+    ["Mail-Followup-To" message-goto-mail-followup-to t]
     ["Distribution" message-goto-distribution t]
     ["Body" message-goto-body t]
     ["Signature" message-goto-signature t]))
@@ -1570,6 +1598,7 @@
 	 C-c C-f C-u  move to Summary	C-c C-f C-n  move to Newsgroups
 	 C-c C-f C-k  move to Keywords	C-c C-f C-d  move to Distribution
 	 C-c C-f C-f  move to Followup-To
+         C-c C-f C-m  move to Mail-Followup-To
 C-c C-t  `message-insert-to' (add a To header to a news followup)
 C-c C-n  `message-insert-newsgroups' (add a Newsgroup header to a news reply)
 C-c C-b  `message-goto-body' (move to beginning of message text).
@@ -1714,6 +1743,11 @@
   (interactive)
   (message-position-on-field "Followup-To" "Newsgroups"))
 
+(defun message-goto-mail-followup-to ()
+  "Move point to the Mail-Followup-To header."
+  (interactive)
+  (message-position-on-field "Mail-Followup-To" "From"))
+
 (defun message-goto-keywords ()
   "Move point to the Keywords header."
   (interactive)
@@ -2514,6 +2548,16 @@
       (let ((message-deletable-headers
 	     (if news nil message-deletable-headers)))
 	(message-generate-headers message-required-mail-headers))
+      ;; 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))
     (unwind-protect
@@ -3523,6 +3567,28 @@
   "Return the domain name."
   (or mail-host-address
       (message-make-fqdn)))
+
+(defun message-mft-helper (recipients regexps)
+  `(or ,@(apply 'append
+		(mapcar '(lambda (recipient)
+			   (mapcar '(lambda (regexp)
+				      (list 'string-match regexp recipient))
+				   regexps))
+			recipients))))
+
+(defun message-make-mft ()
+  "Return the Mail-Followup-To header."
+  (let* ((msg-recipients (message-options-get 'message-recipients))
+	 (recipients
+	  (mapcar 'mail-strip-quoted-names
+		  (message-tokenize-header msg-recipients)))
+	 (mft-regexps (apply 'append message-subscribed-regexps
+			     (mapcar 'regexp-quote
+				     message-subscribed-addresses)
+			     (mapcar '(lambda (func) (funcall func))
+				     message-subscribed-address-functions))))
+    (when (eval (message-mft-helper recipients mft-regexps))
+      msg-recipients)))
 
 (defun message-generate-headers (headers)
   "Prepare article HEADERS.

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Josh Huber <huber@alum.wpi.edu> writes:

> +			     (mapcar '(lambda (func) (funcall func))
> +				     message-subscribed-address-functions))))

This can be changed to

(mapcar 'funcall
        message-subscribed-address-functions)

(oops)

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> 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

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> Missed a M-x tabify, I guess.

Yes, thanks.

>> +      ;; 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.

Well, that's what I suggested.

I think something like:

(setq message-subscribed-addresses
      (gnus-find-subscrbied-addresses))

in the .gnus file would be an ok thing to have users do, wouldn't it?
Or, we could have that as an option in the customize menu as well...

> '(lambda ...) does not get byte-compiled.  (function (lambda ...))
> does, and otherwise means the same thing.

Okay, thanks :)

> How about:
[snip]

> 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.)

Thanks for checking my elisp.  I don't know it that well yet, but you
wrote essentially what I had wanted to write, but didn't know exactly
how to :)

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Sorry, forgot to make one comment again...

prj@po.cwru.edu (Paul Jarc) writes:

> 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.

You can have this work, by having

(setq message-subscrbied-address-functions
      'gnus-find-subscrbied-addresses)

The problem with this is, this search function appears to be expensive
enough that I wouldn't want it as a default...

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

Josh Huber <huber@alum.wpi.edu> writes:

> The problem with this is, this search function appears to be expensive
> enough that I wouldn't want it as a default...

This version is fast enough to be enabled by default, and also avoids
the cl dependencies:

(defun gnus-find-subscribed-adresses ()
  "Return a regexp matching the addresses of all subscribed mail groups.
It consists of the `to-address' or `to-list' parameter of all groups
with a non-nil `subscribed' parameter."
  (let ((addresses nil))
    (mapc (lambda (entry)
	    (let ((group (car entry)))
	      (when (gnus-group-get-parameter group 'subscribed)
		(let ((address (or (gnus-group-get-parameter group 'to-address)
				   (gnus-group-get-parameter group 'to-list))))
		  (when address
		    (setq addresses (const address addresses)))))))
	  gnus-newsrc-alist)
    (mapconcat 'regexp-quote addresses "\\|")))

However, most of the speed advantage come from
gnus-group-get-parameter instead of gnus-group-find-parameter, which
mean it won't work with topic parameters.

A quick look suggest gnus-group-find-parameter is a memory pig. I
suspect we with a little care can speed it up enough in the single
parameter case, to make is useable for our purpose.

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> 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.  [...]  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.
> 
> Well, that's what I suggested.
> 
> I think something like:
> 
> (setq message-subscribed-addresses
>       (gnus-find-subscrbied-addresses))
> 
> in the .gnus file would be an ok thing to have users do, wouldn't it?

The distance between n and n+1 is at a maximum when n=0.  If we have
to add anything at all to our individual .gnus files to enable MFT,
then I don't think it matters much if we have to add a little more
instead of a little less.  Since it's possible to do it as a hook, it
seems cleaner to do it that way, assuming we've given up on getting it
completely for free.

> The problem with this is, this search function appears to be expensive
> enough that I wouldn't want it as a default...

If it only happens once per Gnus session, that shouldn't be a problem,
I think.

message.el shouldn't explicitly use a gnus- function, and gnus*.el
would have a hard time deciding when and whether to populate
message-subscribed-addresses with the to-list and to-address
parameters.  If not for that, I think we could get MFT completely for
free.


paul

Re: new Mail-Followup-To patch...please take a look...

[Matt Armstrong]

prj@po.cwru.edu (Paul Jarc) writes:

> Josh Huber <huber@alum.wpi.edu> wrote:
>> prj@po.cwru.edu (Paul Jarc) writes:
>>> 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.  [...]  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.
>> 
>> Well, that's what I suggested.
>> 
>> I think something like:
>> 
>> (setq message-subscribed-addresses
>>       (gnus-find-subscrbied-addresses))
>> 
>> in the .gnus file would be an ok thing to have users do, wouldn't it?
> 
> The distance between n and n+1 is at a maximum when n=0.  If we have
> to add anything at all to our individual .gnus files to enable MFT,
> then I don't think it matters much if we have to add a little more
> instead of a little less.  Since it's possible to do it as a hook,
> it seems cleaner to do it that way, assuming we've given up on
> getting it completely for free.

I haven't given up on getting MFT for free (on by default).  Per's
example of using to-address and to-list for non-list addresses are an
example of a power user config.  I think providing a 'not-subscribed
parameter just for Per is okay.  ;-)

In other words, I think it is okay to assume that all to-list and
to-address parameters are "subscribed," but provide a way out for the
Gnus power users.


>> The problem with this is, this search function appears to be
>> expensive enough that I wouldn't want it as a default...
> 
> If it only happens once per Gnus session, that shouldn't be a
> problem, I think.

Caching the result is fine.

It'd be nice if changing group parameters would magically cause the
list to be regenerated.  Setting a "dirty" flag when group params have
been edited is probably easy enough.  And we could save a copy of
'gnus-parameters' and make sure the saved copy is equal to the current
value.


> message.el shouldn't explicitly use a gnus- function, and gnus*.el
> would have a hard time deciding when and whether to populate
> message-subscribed-addresses with the to-list and to-address
> parameters.  If not for that, I think we could get MFT completely
> for free.

message.el can't call into gnus or use a gnus variable, but surely
gnus could set a variable on behalf of message.el?

E.g. there'd be message-subscribed-addresses, and
message-subscribed-addresses-from-mua.  The former is a user setting,
the latter is set by the mua (perhaps buffer local).


-- 
matt

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

"Matt Armstrong" <matt@lickey.com> wrote:
> And we could save a copy of 'gnus-parameters' and make sure the
> saved copy is equal to the current value.

Or even eq.  That might trigger some unnecessary regeneration in some
odd cases, but more often, it would speed up the comparison.

> message.el can't call into gnus or use a gnus variable, but surely
> gnus could set a variable on behalf of message.el?
> 
> E.g. there'd be message-subscribed-addresses, and
> message-subscribed-addresses-from-mua.  The former is a user setting,
> the latter is set by the mua (perhaps buffer local).

If Gnus sets a separate variable, then we need yet another variable to
control whether Gnus should do that.

Here's another idea: have a gnus function which can be an entry in
message-subscribed-address-functions.  This function collects to-list
and to-address parameters and, for speed, caches them in an internal
(i.e., not for users to mess with, but still global) variable.  Now we
change the default for message-subscribed-address-functions:
(defvar message-subscribed-address-functions '(ignore))
Gnus adds its function to m-s-a-f at startup, but only if the existing
value is this default.  If the user wants to disable the Gnus
function, they set m-s-a-f to (the more intuitive) nil.

This seems perhaps too clever for its own good, but it means that the
user's setting sticks, with no extra work, which I like.


paul

Re: new Mail-Followup-To patch...please take a look...

[Davide G. M. Salvetti]

>>>>> "PJ" == Paul Jarc <prj@po.cwru.edu> writes:

PJ> '(lambda ...) does not get byte-compiled.  (function (lambda ...))
PJ> does, and otherwise means the same thing.

Ok for '(lambda).  But what's the point in writing #'(lambda ...) if
(lambda ...) already evaluates to it (being lambda a macro)?  Is that
some kind of stylistic convention, or there is really something more?

-- 
Salve, | <http://www.linux.it/~salve/>
Davide | GNU PG (GPG) Key ID: 939686D5

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> (defun gnus-find-subscribed-adresses ()
> [...]

> However, most of the speed advantage come from
> gnus-group-get-parameter instead of gnus-group-find-parameter, which
> mean it won't work with topic parameters.

Yes, and it also seems as though it doesn't work with gnus-parameters,
so i had to change it to use g-g-find-parameter.

I'm pretty sure the speed is the same at this point, but I do like
your version better.

besides this is a cool way to learn new things like...mapc and
mapconcat :)

So, would it be better to make one regex or have a list?  I wonder
what's faster?  I suspect the single regex is since the regexp engine
has probably been optimized very well.

i'll reply further down this thread about the new ideas ;)

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> Here's another idea: have a gnus function which can be an entry in
> message-subscribed-address-functions.  This function collects
> to-list and to-address parameters and, for speed, caches them in an
> internal (i.e., not for users to mess with, but still global)
> variable.  Now we change the default for
> message-subscribed-address-functions: (defvar
> message-subscribed-address-functions '(ignore)) Gnus adds its
> function to m-s-a-f at startup, but only if the existing value is
> this default.  If the user wants to disable the Gnus function, they
> set m-s-a-f to (the more intuitive) nil.

I really do like this idea -- the only downside (it's not really a
downside for me, but...) is that it's no longer available in
customize.  It's probably enough to have the -addresses and -regexps
versions in customize, since if you're screwing with the function
hooks you probably know what's going on, right? :)

So, I just was thinking of how to do this, and it's not too hard, but
where should this code go?

are we going to need to put something in the gnus startup code (gnus-1
?)

and where should these internal cache variables get defined...how
about a good location for gnus-find-subscribed-addresses?

ttyl,

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

"Davide G. M. Salvetti" <salve@debian.org> wrote:
>>>>>> "PJ" == Paul Jarc <prj@po.cwru.edu> writes:
> PJ> '(lambda ...) does not get byte-compiled.  (function (lambda ...))
> PJ> does, and otherwise means the same thing.
> 
> Ok for '(lambda).  But what's the point in writing #'(lambda ...) if
> (lambda ...) already evaluates to it (being lambda a macro)?

'(lambda ...) is equivalent to (lambda ...).  (function (lambda ...))
also returns the same value, but the byte-compiler descends into
(function ...).  (quote ...) forms are left uncompiled.  For the code
to be byte-compiled, we have to use (function ...).


paul

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Yet another revision...

This one incorporates (I think) all of the changes that people have
mentioned.  Caching, defaulting to use the to-(address|list) unless a
not-subscribed group parameter is present, automatically inserting
this caching function into message-subscribed-address-functions on
startup, etc.

the thing I really need help on is where these vars/defuns belong, and
the proper way to do what I did to automatically setup the
variable. (is modifying gnus-1 the right way?)

Also, general comments (as always :) are welcome.  especially telling
me the right way to use elisp, etc.

Index: lisp/gnus-group.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-group.el,v
retrieving revision 6.44
diff -u -r6.44 gnus-group.el
--- lisp/gnus-group.el	2001/10/14 23:12:41	6.44
+++ lisp/gnus-group.el	2001/10/24 02:01:37
@@ -2289,6 +2289,7 @@
 			  (gnus-group-prefixed-name
 			   (gnus-group-real-name (car info)) method))
 		      nil)))
+    (setq gnus-group-dirty-flag t)
     (when (and new-group
 	       (not (equal new-group group)))
       (when (gnus-group-goto-group group)
Index: lisp/gnus-start.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus-start.el,v
retrieving revision 6.30
diff -u -r6.30 gnus-start.el
--- lisp/gnus-start.el	2001/09/14 14:09:30	6.30
+++ lisp/gnus-start.el	2001/10/24 02:01:40
@@ -433,6 +433,41 @@
 ;; Byte-compiler warning.
 (defvar gnus-group-line-format)
 
+;; mail-followup-to handling...
+(defvar gnus-group-parameter-cache nil)
+(defvar gnus-subscribed-addresses nil)
+(defvar gnus-group-dirty-flag nil)
+
+(defun gnus-find-subscribed-addresses-real ()
+  "Return a regexp matching the addresses of all subscribed mail groups.
+It consists of the `to-address' or `to-list' parameter of all groups
+with a nil `not-subscribed' parameter."
+  (let ((addresses))
+    (mapc (lambda (entry)
+	    (let ((group (car entry)))
+	      (when (not (gnus-group-find-parameter group 'not-subscribed))
+		(let ((address (or
+				(gnus-group-find-parameter group 'to-address)
+				(gnus-group-find-parameter group 'to-list))))
+		  (when address
+		    (setq addresses (cons address addresses)))))))
+	  (cdr gnus-newsrc-alist))
+    (mapconcat 'regexp-quote addresses "\\|")))
+
+(defun gnus-find-subscribed-addresses ()
+  "Return a regexp matching the addresses of all subscrbied mail groups.
+This uses `gnus-group-parameter-cache' to keep track of changes to
+`gnus-parameters' and `gnus-group-dirty-flag' to keep track of interactive
+changes to group parameters."
+  (if (and (eq gnus-group-parameter-cache gnus-parameters)
+	   (not gnus-group-dirty-flag)) ; how to do this?
+      gnus-subscribed-addresses
+    (progn
+      (setq gnus-group-dirty-flag nil)
+      (setq gnus-group-parameter-cache gnus-parameters)
+      (setq gnus-subscribed-addresses
+	    (gnus-find-subscribed-addresses-real)))))
+
 ;; Suggested by Brian Edmonds <edmonds@cs.ubc.ca>.
 (defvar gnus-init-inhibit nil)
 (defun gnus-read-init-file (&optional inhibit-next)
@@ -746,6 +781,11 @@
 	  (gnus-group-first-unread-group)
 	  (gnus-configure-windows 'group)
 	  (gnus-group-set-mode-line)
+
+	  ;; set up support for generating Mail-Followup-To headers
+	  (when (equal message-subscribed-address-functions '(ignore))
+	    (setq message-subscribed-address-functions
+		  '(gnus-find-subscribed-addresses)))
 	  (gnus-run-hooks 'gnus-started-hook))))))
 
 (defun gnus-start-draft-setup ()
Index: lisp/message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.137
diff -u -r6.137 message.el
--- lisp/message.el	2001/10/20 17:27:25	6.137
+++ lisp/message.el	2001/10/24 02:01:45
@@ -424,6 +424,30 @@
 		 (const use)
 		 (const ask)))
 
+(defvar message-subscribed-address-functions '(ignore)
+  "*Specifies functions for determining list subscription.
+If nil, do not attempt to determine list subscribtion with functions.
+If non-nil, this variable contains a list of functions which return
+regular expressions to match lists.  These functions can be used in
+conjunction with `message-subscribed-regexps' and
+`message-subscribed-addresses'.")
+
+(defcustom message-subscribed-addresses nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+addresses can be used in conjuction with
+`message-subscribed-address-functions' and `message-subscribed-regexps'."
+  :group 'message-interface
+  :type '(repeat string))
+
+(defcustom message-subscribed-regexps nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+regular expressions can be used in conjuction with
+`message-subscribed-address-functions' and `message-subscribed-addresses'."
+  :group 'message-interface
+  :type '(repeat regexp))
+
 (defcustom message-sendmail-f-is-evil nil
   "*Non-nil means don't add \"-f username\" to the sendmail command line.
 Doing so would be even more evil than leaving it out."
@@ -1468,6 +1492,7 @@
   (define-key message-mode-map "\C-c\C-f\C-n" 'message-goto-newsgroups)
   (define-key message-mode-map "\C-c\C-f\C-d" 'message-goto-distribution)
   (define-key message-mode-map "\C-c\C-f\C-f" 'message-goto-followup-to)
+  (define-key message-mode-map "\C-c\C-f\C-m" 'message-goto-mail-followup-to)
   (define-key message-mode-map "\C-c\C-f\C-k" 'message-goto-keywords)
   (define-key message-mode-map "\C-c\C-f\C-u" 'message-goto-summary)
   (define-key message-mode-map "\C-c\C-b" 'message-goto-body)
@@ -1547,6 +1572,7 @@
     ["Keywords" message-goto-keywords t]
     ["Newsgroups" message-goto-newsgroups t]
     ["Followup-To" message-goto-followup-to t]
+    ["Mail-Followup-To" message-goto-mail-followup-to t]
     ["Distribution" message-goto-distribution t]
     ["Body" message-goto-body t]
     ["Signature" message-goto-signature t]))
@@ -1570,6 +1596,7 @@
 	 C-c C-f C-u  move to Summary	C-c C-f C-n  move to Newsgroups
 	 C-c C-f C-k  move to Keywords	C-c C-f C-d  move to Distribution
 	 C-c C-f C-f  move to Followup-To
+	 C-c C-f C-m  move to Mail-Followup-To
 C-c C-t  `message-insert-to' (add a To header to a news followup)
 C-c C-n  `message-insert-newsgroups' (add a Newsgroup header to a news reply)
 C-c C-b  `message-goto-body' (move to beginning of message text).
@@ -1721,6 +1748,11 @@
   (interactive)
   (message-position-on-field "Followup-To" "Newsgroups"))
 
+(defun message-goto-mail-followup-to ()
+  "Move point to the Mail-Followup-To header."
+  (interactive)
+  (message-position-on-field "Mail-Followup-To" "From"))
+
 (defun message-goto-keywords ()
   "Move point to the Keywords header."
   (interactive)
@@ -2527,6 +2559,16 @@
       (let ((message-deletable-headers
 	     (if news nil message-deletable-headers)))
 	(message-generate-headers message-required-mail-headers))
+      ;; 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))
     (unwind-protect
@@ -3536,6 +3578,29 @@
   "Return the domain name."
   (or mail-host-address
       (message-make-fqdn)))
+
+(defun message-make-mft ()
+  "Return the Mail-Followup-To header."
+  (let* ((msg-recipients (message-options-get 'message-recipients))
+	 (recipients
+	  (mapcar 'mail-strip-quoted-names
+		  (message-tokenize-header msg-recipients)))
+	 (mft-regexps (apply 'append message-subscribed-regexps
+			     (mapcar 'regexp-quote
+				     message-subscribed-addresses)
+			     (mapcar 'funcall
+				     message-subscribed-address-functions))))
+    (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))))
 
 (defun message-generate-headers (headers)
   "Prepare article HEADERS.

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

"Matt Armstrong" <matt@lickey.com> writes:

> I haven't given up on getting MFT for free (on by default).  Per's
> example of using to-address and to-list for non-list addresses are an
> example of a power user config.

I don't think so.  I don't think a user that want "a" to "just work"
in folders with personal mail is necessary any more advanced than a
user that want "a" to "just work" in folders with mailing lists.

If we want MFT to just work, maybe we should change the parameter
interface.  E.g. have a single parameter 

            mail-address

which states the main mail address associated with the folder, and
another 

            mail-type
                Unknown (default)
                Personal        use m-a for "a", don't set 
                Open List       use m-a for "a", set MFC
                Closed List     use m-a for "a" and "f", set MFC

which state what type of folder it is.

We can add more later (like Outgoing or News Gateway), if necessary.

The "to-list" and "to-address" parameters should then be recognized
for backward compatibility, but no longer be part of customize UI or
main documentation. 

Re: new Mail-Followup-To patch...please take a look...

[Davide G. M. Salvetti]

>>>>> "PJ" == Paul Jarc <prj@po.cwru.edu> writes:

PJ> '(lambda ...) is equivalent to (lambda ...).

Oh, I really thought that (lambda ...) was equivalent to (function
(lambda ...)), which in turn also has the read syntax #'(lambda ...).

I know '(lambda ...) is the read syntax for (quote (lambda ...)), which
doesn't evaluate the (lambda ...) inside (that being (quote ...)
purpose), and thus doesn't return (function (lambda ...)) like the macro
lambda should do.

Are you really sure that (lambda ...) evaluates to (quote (lambda ...))
rather than to (function (lambda ...))?

Since I was actually quite a bit confused, I tried and byte-compiled
this small file (let's call it «byte-compilation-test.el»):
<======================================================================>
(setq lambda (lambda (x) (1+ x)))

(setq qlambda '(lambda (x) (1+ x)))

(setq flambda #'(lambda (x) (1+ x)))

(defun show-me-this-fact nil
  "Just a test."
  (interactive)
  (dolist (x '(lambda qlambda flambda))
    (message
     "Function: %s.\nByte-compiled: %s."
     (symbol-name x)
     (if (byte-code-function-p (eval x)) "yes" "no"))
    (sit-for 1)))
<======================================================================>
Try it for yourself: save it, byte-compile it, and then type
«M-x load-file byte-compilation-test.elc» and «M-x show-me-this-fact».

Is there anything I don't get?  It has always been a source of
confusion, to me. :-)

Thanks.

-- 
Salve, | <http://www.linux.it/~salve/>
Davide | GNU PG (GPG) Key ID: 939686D5

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I don't think so.  I don't think a user that want "a" to "just work"
> in folders with personal mail is necessary any more advanced than a
> user that want "a" to "just work" in folders with mailing lists.

hmm, maybe.  I guess I just hadn't thought of splitting mail to that
fine resolution...

I may start now, because that sounds like a nice idea, combined with a
bbdb field to tell it where to go.

> [snip changes to to-list/to-address etc]

excellent idea.

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Samuel Padgett]

"Davide G. M. Salvetti" <salve@debian.org> writes:

>>>>>> "PJ" == Paul Jarc <prj@po.cwru.edu> writes:
> 
> PJ> '(lambda ...) is equivalent to (lambda ...).
> 
> Oh, I really thought that (lambda ...) was equivalent to (function
> (lambda ...)), which in turn also has the read syntax #'(lambda ...).

You're right.  Look at the definition of lambda, which is a macro, to
see.

> Are you really sure that (lambda ...) evaluates to (quote (lambda ...))
> rather than to (function (lambda ...))?

I believe Paul's wrong here.

Sam

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

Josh Huber <huber@alum.wpi.edu> writes:

> This one incorporates (I think) all of the changes that people have
> mentioned.  Caching, defaulting to use the to-(address|list) unless a
> not-subscribed group parameter is present, automatically inserting
> this caching function into message-subscribed-address-functions on
> startup, etc.

I disagree with most of the changes. Caches tend to get out of sync
and add complexity, much better to make the primary access functions
fast. I have a included a version which I think is "fast enough" when
byte compiled.  I have committed gnus-group-fast-parameter to CVS.

I already argued against "non-subscribed", and Emacs Lisp code should
not modify user options.  I don't know how to do the later right, but
perhaps something like how message-post-method is implemented.

Here is a fast (when byte-compiled) version of
`gnus-find-subscribed-addresses':

(defun gnus-expand-group-parameter (match value group)
  "Use MATCH to expand VALUE in GROUP."
  (with-temp-buffer
    (insert group)
    (goto-char (point-min))
    (while (re-search-forward match nil t)
      (replace-match value))
    (buffer-string)))

(defun gnus-group-fast-parameter (group symbol &optional allow-list)
  "For GROUP, return the value of SYMBOL.

You should call this in the `gnus-group-buffer' buffer.  
The function `gnus-group-find-parameter' will do that for you."
  ;; The speed trick:  No cons'ing and quit early.
  (or (let ((params (funcall gnus-group-get-parameter-function group)))
	;; Start easy, check the "real" group parameters.
	(gnus-group-parameter-value params symbol allow-list))
      ;; We didn't found it there, try `gnus-parameters'.
      (let ((result nil)
	    (head nil)
	    (tail gnus-parameters))
	;; A good old-fashioned non-cl loop.
	(while tail
	  (setq head (car tail)
		tail (cdr tail))
	  ;; The car is regexp matching for matching the group name.
	  (when (string-match (car head) group)
	    ;; The cdr is the parameters.
	    (setq result (gnus-group-parameter-value (cdr head) 
						     symbol allow-list))
	    (when result
	      ;; Expand if necessary.
	      (if (and (stringp result) (string-match "\\\\" result))
		  (setq result (gnus-expand-group-parameter (car head)
							    result group)))
	      ;; Exit the loop early.
	      tail nil)))
	;; Done.
	result)))

(defun gnus-find-subscribed-addresses ()
  "Return a regexp matching the addresses of all subscribed mail groups.
It consists of the `to-address' or `to-list' parameter of all groups
with a nil `not-subscribed' parameter."
  (save-excursion
    (set-buffer gnus-group-buffer)
    (let ((addresses))
      (mapc (lambda (entry)
	      (let ((group (car entry)))
		(when (gnus-group-fast-parameter group 'subscribed)
		  (let ((address (or
				  (gnus-group-fast-parameter group 'to-address)
				  (gnus-group-fast-parameter group 'to-list))))
		    (when address
		      (setq addresses (cons address addresses)))))))
	    (cdr gnus-newsrc-alist))
      (mapconcat 'regexp-quote addresses "\\|"))))

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Samuel Padgett <spadgett1@nc.rr.com> wrote:
> "Davide G. M. Salvetti" <salve@debian.org> writes:
>> Are you really sure that (lambda ...) evaluates to (quote (lambda ...))
>> rather than to (function (lambda ...))?
> 
> I believe Paul's wrong here.

Could be.  I've been working from the C-h f documentation of function
and lambda.  But then, what's the use of function?


paul

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Samuel Padgett <spadgett1@nc.rr.com> wrote:
>> "Davide G. M. Salvetti" <salve@debian.org> writes:
>>> Are you really sure that (lambda ...) evaluates to (quote (lambda ...))
>>> rather than to (function (lambda ...))?
>> 
>> I believe Paul's wrong here.
> 
> Could be.  I've been working from the C-h f documentation of function
> and lambda.  But then, what's the use of function?

It is older than the self-quoting nature of lambda.

I see some code use it like 

  (apply (function some-function) args)

i.e. to quote symbols with a function binding. 

I have no idea whether this results in better code though.

Re: new Mail-Followup-To patch...please take a look...

[Samuel Padgett]

prj@po.cwru.edu (Paul Jarc) writes:

> Samuel Padgett <spadgett1@nc.rr.com> wrote:
>> "Davide G. M. Salvetti" <salve@debian.org> writes:
>>> Are you really sure that (lambda ...) evaluates to (quote (lambda ...))
>>> rather than to (function (lambda ...))?
>> 
>> I believe Paul's wrong here.
> 
> Could be.  I've been working from the C-h f documentation of function
> and lambda.  But then, what's the use of function?

Well, if nothing else, it's needed for the definition of the (lambda ...)
macro.  ;-)

Sam

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> +(defvar gnus-group-dirty-flag nil)

The name's rather vague.  But if Per's functions are fast enough, then
I agree that caching is not worthwhile anyway.

> +(defun gnus-find-subscribed-addresses-real ()
> +  "Return a regexp matching the addresses of all subscribed mail groups.

Since this is used in message-subscribed-address-functions:

> +	 (mft-regexps (apply 'append message-subscribed-regexps
> +			     (mapcar 'regexp-quote
> +				     message-subscribed-addresses)
> +			     (mapcar 'funcall
> +				     message-subscribed-address-functions))))

Shouldn't it return a list of regexps (possibly just one, but still a
list)?

> +    (progn
> +      (setq gnus-group-dirty-flag nil)
> +      (setq gnus-group-parameter-cache gnus-parameters)
> +      (setq gnus-subscribed-addresses
> +	    (gnus-find-subscribed-addresses-real)))))

(Assuming caching is not discarded...)  Better to make that
gnus-atomic-progn, or to rearrange like so:
(progn
  (setq gnus-subscribed-addresses (gnus-find-subscribed-addresses-real))
  (setq gnus-group-dirty-flag nil)
  (setq gnus-group-parameter-cache gnus-parameters)
  gnus-subscribed-addresses)
  
Otherwise a C-g could come in after we've updated our flags, but
before we've recalculated the subscribed addresses, thus making our
regexp falsely seem up to date.

> +(defvar message-subscribed-address-functions '(ignore)
> +  "*Specifies functions for determining list subscription.

The structure of the return value needs to be documented, and
"specifies" seems to be unnecessary, judging by existing docstrings.
"*A list of functions, each returning a list of regular expressions
matching addresses of mailing lists the the user is subscribed to."?

> +If nil, do not attempt to determine list subscribtion with functions.
> +If non-nil, this variable contains a list of functions which return
> +regular expressions to match lists.

nil is a list; I don't think it needs to be separately documented.

> +(defun message-goto-mail-followup-to ()
> +  "Move point to the Mail-Followup-To header."
> +  (interactive)
> +  (message-position-on-field "Mail-Followup-To" "From"))
> +

This, at least (along with its key and menu bindings), can be
committed now, I think.


paul

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> E.g. have a single parameter 
> 
>             mail-address
> 
> which states the main mail address associated with the folder,

Can we make it a vector?  Some lists have widely-used aliases in
addition to the primary address; all of these should be used for MFT.
For mail-types that apply to "a" and "f", we'd just use the first
entry.

If it is a vector, then we might let it be a list of address-type
pairs, but I'm not sure that would be useful.

>             mail-type
>                 Unknown (default)
>                 Personal        use m-a for "a", don't set 
>                 Open List       use m-a for "a", set MFC
>                 Closed List     use m-a for "a" and "f", set MFC
> 
> which state what type of folder it is.

What would Unknown mean?  I.e., how would code react to it?  I think
it might be better to have no Unknown value and make, say, Open List
the default; I imagine that'd be the most common case.  Either that,
or ignore mail-address(es?) when mail-type is not set.  (Since these
are new parameters, we won't be affecting any existing configurations
with the choice of default.)

Hmm... would it be easier to just use posting styles for "a"?

> The "to-list" and "to-address" parameters should then be recognized
> for backward compatibility,

Does this mean the MFT code should do anything with them, or only the
code that already uses them?


paul

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> (defun gnus-group-fast-parameter (group symbol &optional allow-list)
>   "For GROUP, return the value of SYMBOL.
> 
> You should call this in the `gnus-group-buffer' buffer.  
> The function `gnus-group-find-parameter' will do that for you."

Is it actually necessary to be in that buffer?  I can't find any code
that depends on it.

Could we put this in gnus-group-find-parameter for when symbol is
non-nil, rather than making it a separate function?  That shouldn't
change the behavior, right?

> 	      ;; Exit the loop early.
> 	      tail nil)))

Shouldn't that be (setq tail nil)?


paul

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>> E.g. have a single parameter 
>> 
>>             mail-address
>> 
>> which states the main mail address associated with the folder,
> 
> Can we make it a vector?  Some lists have widely-used aliases in
> addition to the primary address; all of these should be used for MFT.
> For mail-types that apply to "a" and "f", we'd just use the first
> entry.
> 
> If it is a vector, then we might let it be a list of address-type
> pairs, but I'm not sure that would be useful.

I'd prefer using a list over a vector, and it should be named
mail-addresses then.

Other than that, I think it would be a good idea.  Some people have
multiple mail addresses, this would be a natural place to list them.

>>             mail-type
>>                 Unknown (default)
>>                 Personal        use m-a for "a", don't set 
>>                 Open List       use m-a for "a", set MFC
>>                 Closed List     use m-a for "a" and "f", set MFC
>> 
>> which state what type of folder it is.
> 
> What would Unknown mean?  I.e., how would code react to it?  I think
> it might be better to have no Unknown value and make, say, Open List
> the default; I imagine that'd be the most common case.  Either that,
> or ignore mail-address(es?) when mail-type is not set.  (Since these
> are new parameters, we won't be affecting any existing configurations
> with the choice of default.)

I did imagine "a" would be ignored for unknown types, but I have no
strong opinion what the default should be.  If "Open List" is most
common, then that should probably be the choice.

>> The "to-list" and "to-address" parameters should then be recognized
>> for backward compatibility,
> 
> Does this mean the MFT code should do anything with them, or only the
> code that already uses them?

If the default mail-type is open/closed list it would be more safe to
ignore them.  Otherwise, use them if it is not to much trouble to
implement.

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Is it actually necessary to be in that buffer?  I can't find any code
> that depends on it.

I don't know.

> Could we put this in gnus-group-find-parameter for when symbol is
> non-nil, rather than making it a separate function?  That shouldn't
> change the behavior, right?

I'm way ahead of you ;-)

> 
>> 	      ;; Exit the loop early.
>> 	      tail nil)))
> 
> Shouldn't that be (setq tail nil)?

Yes, fixed in cvs.

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> Can we make it a vector?
> 
> I'd prefer using a list over a vector, and it should be named
> mail-addresses then.

Group parameters can't be lists; they'd get interpreted as local
variables.


paul

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

>> +(defvar message-subscribed-address-functions '(ignore)

Why put "ignore" in the list?

>> +  "*Specifies functions for determining list subscription.

"defvar" and "*" is a strange combination.  Either use defcustom, or
drop the "*".

>> +If nil, do not attempt to determine list subscribtion with functions.
>> +If non-nil, this variable contains a list of functions which return
>> +regular expressions to match lists.
> 
> nil is a list; I don't think it needs to be separately documented.

I agree.

>> +(defun message-goto-mail-followup-to ()
>> +  "Move point to the Mail-Followup-To header."
>> +  (interactive)
>> +  (message-position-on-field "Mail-Followup-To" "From"))
>> +
> 
> This, at least (along with its key and menu bindings), can be
> committed now, I think.

Why would we ever want MFT in the messsage buffer?  To test it?

I thought it was supposed to be inserted automatically when the user
send the message.

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>>> +(defvar message-subscribed-address-functions '(ignore)
> 
> Why put "ignore" in the list?

So Gnus can differentiate between the default value and the user's
explicit nil setting.  Gnus automatically adds its function only if
the user hasn't provided a setting.

>>> +  "*Specifies functions for determining list subscription.
> 
> "defvar" and "*" is a strange combination.  Either use defcustom, or
> drop the "*".

I think it's defvar because someone thought defcustom couldn't handle
a list of functions, or the '(ignore) default.  I have next to no
knowledge of customize, so I don't know if this is true.

> Why would we ever want MFT in the messsage buffer?  To test it?
>
> I thought it was supposed to be inserted automatically when the user
> send the message.

It's inserted automatically only if the user didn't supply one
manually.  It can be used manually just like Followup-To, to direct
the thread toward a subset of the lists, etc.


paul

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

prj@po.cwru.edu (Paul Jarc) writes:

> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>> prj@po.cwru.edu (Paul Jarc) writes:
>>>> +(defvar message-subscribed-address-functions '(ignore)
>> 
>> Why put "ignore" in the list?
> 
> So Gnus can differentiate between the default value and the user's
> explicit nil setting.  Gnus automatically adds its function only if
> the user hasn't provided a setting.

Ah, I missed that.  That makes sense.

> I think it's defvar because someone thought defcustom couldn't handle
> a list of functions, or the '(ignore) default.  I have next to no
> knowledge of customize, so I don't know if this is true.

defcustom can handle anything, you don't even need supply a ":type"
argument (it defaults to "sexp").  Og a :group argument, but not doing
that is kind of rude.

It does require a value and a doc string, but if these are provided
defcustom can always where defvar can be used.

>> Why would we ever want MFT in the messsage buffer?  To test it?
>>
>> I thought it was supposed to be inserted automatically when the user
>> send the message.
> 
> It's inserted automatically only if the user didn't supply one
> manually.  It can be used manually just like Followup-To, to direct
> the thread toward a subset of the lists, etc.

That makes sense too.

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> defcustom can handle anything, you don't even need supply a ":type"
> argument (it defaults to "sexp").  Og a :group argument, but not
> doing that is kind of rude.
> 
> It does require a value and a doc string, but if these are provided
> defcustom can always where defvar can be used.

The reason I changed it to defvar was I mistakenly thought that
defcustom would overwrite the value of an already bound variable.  (oops)

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> I disagree with most of the changes.

That's fine, it was more of a this works, lets talk about it kind of
thing anyway...

> Caches tend to get out of sync and add complexity, much better to
> make the primary access functions fast. I have a included a version
> which I think is "fast enough" when byte compiled.  I have committed
> gnus-group-fast-parameter to CVS.

Agreed, and very cool.

> I already argued against "non-subscribed", and Emacs Lisp code should
> not modify user options.

I actually agree with you, but I was just putting forward the code to
get people to take a look.

> I don't know how to do the later right, but perhaps something like
> how message-post-method is implemented.

How is this implemented?

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Here's my current version.  I use the following in my .gnus.el:

(setq gnus-parameters
      '(("^mail\\.lists\\." (subscribed . t))))

(setq message-subscribed-address-functions
      '(gnus-find-subscribed-addresses))

but I do understand that people would like everything to be
automatic.  I've got so much stuff in my .gnus.el already that this
(small) addition isn't a big deal to me, but getting it for free
automatically would be nice.

Index: gnus.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus.el,v
retrieving revision 6.61
diff -u -r6.61 gnus.el
--- gnus.el	2001/10/24 17:18:46	6.61
+++ gnus.el	2001/10/25 18:53:44
@@ -2313,6 +2313,21 @@
 ;;; Gnus Utility Functions
 ;;;
 
+(defun gnus-find-subscribed-addresses ()
+  "Return a regexp matching the addresses of all subscribed mail groups.
+It consists of the `to-address' or `to-list' parameter of all groups
+with a nil `not-subscribed' parameter."
+  (let ((addresses))
+    (mapc (lambda (entry)
+	    (let ((group (car entry)))
+	      (when (gnus-group-find-parameter group 'subscribed)
+		(let ((address (or
+				(gnus-group-fast-parameter group 'to-address)
+				(gnus-group-fast-parameter group 'to-list))))
+		  (when address
+		    (setq addresses (cons address addresses)))))))
+	  (cdr gnus-newsrc-alist))
+    (list (mapconcat 'regexp-quote addresses "\\|"))))
 
 (defmacro gnus-string-or (&rest strings)
   "Return the first element of STRINGS that is a non-blank string.
Index: message.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/message.el,v
retrieving revision 6.137
diff -u -r6.137 message.el
--- message.el	2001/10/20 17:27:25	6.137
+++ message.el	2001/10/25 18:53:46
@@ -424,6 +424,32 @@
 		 (const use)
 		 (const ask)))
 
+(defcustom message-subscribed-address-functions nil
+  "*Specifies functions for determining list subscription.
+If nil, do not attempt to determine list subscribtion with functions.
+If non-nil, this variable contains a list of functions which return
+regular expressions to match lists.  These functions can be used in
+conjunction with `message-subscribed-regexps' and
+`message-subscribed-addresses'."
+  :group 'message-interface
+  :type '(repeat sexp))
+
+(defcustom message-subscribed-addresses nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+addresses can be used in conjuction with
+`message-subscribed-address-functions' and `message-subscribed-regexps'."
+  :group 'message-interface
+  :type '(repeat string))
+
+(defcustom message-subscribed-regexps nil
+  "*Specifies a list of addresses the user is subscribed to.
+If nil, do not use any predefined list subscriptions.  This list of
+regular expressions can be used in conjuction with
+`message-subscribed-address-functions' and `message-subscribed-addresses'."
+  :group 'message-interface
+  :type '(repeat regexp))
+
 (defcustom message-sendmail-f-is-evil nil
   "*Non-nil means don't add \"-f username\" to the sendmail command line.
 Doing so would be even more evil than leaving it out."
@@ -1468,6 +1494,7 @@
   (define-key message-mode-map "\C-c\C-f\C-n" 'message-goto-newsgroups)
   (define-key message-mode-map "\C-c\C-f\C-d" 'message-goto-distribution)
   (define-key message-mode-map "\C-c\C-f\C-f" 'message-goto-followup-to)
+  (define-key message-mode-map "\C-c\C-f\C-m" 'message-goto-mail-followup-to)
   (define-key message-mode-map "\C-c\C-f\C-k" 'message-goto-keywords)
   (define-key message-mode-map "\C-c\C-f\C-u" 'message-goto-summary)
   (define-key message-mode-map "\C-c\C-b" 'message-goto-body)
@@ -1547,6 +1574,7 @@
     ["Keywords" message-goto-keywords t]
     ["Newsgroups" message-goto-newsgroups t]
     ["Followup-To" message-goto-followup-to t]
+    ["Mail-Followup-To" message-goto-mail-followup-to t]
     ["Distribution" message-goto-distribution t]
     ["Body" message-goto-body t]
     ["Signature" message-goto-signature t]))
@@ -1570,6 +1598,7 @@
 	 C-c C-f C-u  move to Summary	C-c C-f C-n  move to Newsgroups
 	 C-c C-f C-k  move to Keywords	C-c C-f C-d  move to Distribution
 	 C-c C-f C-f  move to Followup-To
+	 C-c C-f C-m  move to Mail-Followup-To
 C-c C-t  `message-insert-to' (add a To header to a news followup)
 C-c C-n  `message-insert-newsgroups' (add a Newsgroup header to a news reply)
 C-c C-b  `message-goto-body' (move to beginning of message text).
@@ -1721,6 +1750,11 @@
   (interactive)
   (message-position-on-field "Followup-To" "Newsgroups"))
 
+(defun message-goto-mail-followup-to ()
+  "Move point to the Mail-Followup-To header."
+  (interactive)
+  (message-position-on-field "Mail-Followup-To" "From"))
+
 (defun message-goto-keywords ()
   "Move point to the Keywords header."
   (interactive)
@@ -2527,6 +2561,16 @@
       (let ((message-deletable-headers
 	     (if news nil message-deletable-headers)))
 	(message-generate-headers message-required-mail-headers))
+      ;; 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))
     (unwind-protect
@@ -3536,6 +3580,29 @@
   "Return the domain name."
   (or mail-host-address
       (message-make-fqdn)))
+
+(defun message-make-mft ()
+  "Return the Mail-Followup-To header."
+  (let* ((msg-recipients (message-options-get 'message-recipients))
+	 (recipients
+	  (mapcar 'mail-strip-quoted-names
+		  (message-tokenize-header msg-recipients)))
+	 (mft-regexps (apply 'append message-subscribed-regexps
+			     (mapcar 'regexp-quote
+				     message-subscribed-addresses)
+			     (mapcar 'funcall
+				     message-subscribed-address-functions))))
+    (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))))
 
 (defun message-generate-headers (headers)
   "Prepare article HEADERS.

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Kai Großjohann]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> If we want MFT to just work, maybe we should change the parameter
> interface.  E.g. have a single parameter 
> 
>             mail-address
> 
> which states the main mail address associated with the folder, and
> another 
> 
>             mail-type
>                 Unknown (default)
>                 Personal        use m-a for "a", don't set 
>                 Open List       use m-a for "a", set MFC
>                 Closed List     use m-a for "a" and "f", set MFC
> 
> which state what type of folder it is.

Way cool!

kai
-- 
Lisp is kinda like tpircstsoP

Re: new Mail-Followup-To patch...please take a look...

[Kai Großjohann]

"Davide G. M. Salvetti" <salve@debian.org> writes:

> Ok for '(lambda).  But what's the point in writing #'(lambda ...) if
> (lambda ...) already evaluates to it (being lambda a macro)?  Is that
> some kind of stylistic convention, or there is really something more?

I think that (lambda ...) doesn't work in CL; you have to use
#'(lambda ...) there.  It seems that some Emacs Lisp programmers
prefer to use CL-like notation.  Maybe they want to support the CLErik
Conspiracy.

kai
-- 
Lisp is kinda like tpircstsoP

Re: new Mail-Followup-To patch...please take a look...

[Kai Großjohann]

prj@po.cwru.edu (Paul Jarc) writes:

> I think it's defvar because someone thought defcustom couldn't handle
> a list of functions, or the '(ignore) default.

Since `ignore' is a function, (repeat function) should be a reasonable
type spec for Customize.  Thoughts?

kai
-- 
Lisp is kinda like tpircstsoP

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> prj@po.cwru.edu (Paul Jarc) writes:
> 
>> I think it's defvar because someone thought defcustom couldn't handle
>> a list of functions, or the '(ignore) default.
> 
> Since `ignore' is a function, (repeat function) should be a reasonable
> type spec for Customize.  Thoughts?

Yes.

I just don't want people not[1] to use customize when they can't think
of a good :type value.  When in doubt, just leave out :type.

Footnotes: 
[1]  Sorry for the double negation.

Re: new Mail-Followup-To patch...please take a look...

[Barry Fishman]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> "Davide G. M. Salvetti" <salve@debian.org> writes:
> 
>> Ok for '(lambda).  But what's the point in writing #'(lambda ...) if
>> (lambda ...) already evaluates to it (being lambda a macro)?  Is that
>> some kind of stylistic convention, or there is really something more?
> 
> I think that (lambda ...) doesn't work in CL; you have to use
> #'(lambda ...) there.  It seems that some Emacs Lisp programmers
> prefer to use CL-like notation.  Maybe they want to support the CLErik
> Conspiracy.

According to the CL hyperspec:

    (lambda lambda-list [[declaration* | documentation]] form*)
 ==  (function (lambda lambda-list [[declaration* | documentation]] form*))
 ==  #'(lambda lambda-list [[declaration* | documentation]] form*)

And the #' didn't seem to be needed in any of the CL systems I tried.

However, Guy Steele's "Common Lisp, The Language Second Edition",
Section 5.2 states quite explicitly the opposite.  I guess its more
recent than 1990, probably introduced by scheme people who infiltrated
an ANSI draft review by posing as MIT janitors.

Barry Fishman

Re: new Mail-Followup-To patch...please take a look...

[Florian Weimer]

"Davide G. M. Salvetti" <salve@debian.org> writes:

> Ok for '(lambda).  But what's the point in writing #'(lambda ...) if
> (lambda ...) already evaluates to it (being lambda a macro)?  Is that
> some kind of stylistic convention, or there is really something more?

There's certainly a difference between ' and #': If you quote an
expression using ', it is not byte compiled, but if you use #', it is.
There's a section in the Elisp manual ('Anonymous Functions') which
explains the difference in more detail.

Re: new Mail-Followup-To patch...please take a look...

[Florian Weimer]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

>             mail-type
>                 Unknown (default)
>                 Personal        use m-a for "a", don't set 
>                 Open List       use m-a for "a", set MFC
>                 Closed List     use m-a for "a" and "f", set MFC

This looks like a good idea.

(I'm guilty here, too, because one of my fixes didn't seem to
work. :-/)

Re: new Mail-Followup-To patch...please take a look...

[Kai Großjohann]

Barry Fishman <barry_fishman@acm.org> writes:

> However, Guy Steele's "Common Lisp, The Language Second Edition",
> Section 5.2 states quite explicitly the opposite.  I guess its more
> recent than 1990, probably introduced by scheme people who infiltrated
> an ANSI draft review by posing as MIT janitors.

He, he.  In fact, I don't know how to program CL, I just read CLtL2 ;-)

kai
-- 
Lisp is kinda like tpircstsoP

Re: new Mail-Followup-To patch...please take a look...

[Matt Armstrong]

Josh Huber <huber@alum.wpi.edu> writes:

> Here's my current version.
>
> <snip>
> +
> +(defun message-make-mft ()
> +  "Return the Mail-Followup-To header."
> +  (let* ((msg-recipients (message-options-get 'message-recipients))
> +	 (recipients
> +	  (mapcar 'mail-strip-quoted-names
> +		  (message-tokenize-header msg-recipients)))
> <snip>

Hey Josh, I've applied this patch -- really cool.  Assuming this
message gets a correct MFT header, I can say it works for me.

Anyway, I was reading http://cr.yp.to/proto/replyto.html and in
particular, this portion:

    You may want to warn the user when he views a message where he's
    not included in Mail-Followup-To. This usually indicates that the
    user has subscribed to a mailing list shown in Mail-Followup-To,
    but hasn't told you about that mailing list. Or it may indicate
    that someone is redirecting the discussion.

To implement this, we'd need a function that takes a list of
recipients and returns the list of addresses in the default MFT.
message-make-mft is almost there.  How about a message-calculate-mft
function that takes a list of addresses and returns another list.
Then message-make-mft simply calls it with the result of
(message-options-get 'message-recipients).


-- 
matt

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

"Matt Armstrong" <matt+dated+1006984700.195575@lickey.com> writes:

> Hey Josh, I've applied this patch -- really cool.  Assuming this
> message gets a correct MFT header, I can say it works for me.

Yep, Mail-Followup-To: ding@gnus.org was there.

>     You may want to warn the user when he views a message where he's
>     not included in Mail-Followup-To. This usually indicates that the
>     user has subscribed to a mailing list shown in Mail-Followup-To,
>     but hasn't told you about that mailing list. Or it may indicate
>     that someone is redirecting the discussion.

Yes, this wouldn't be hard, but when should this warning happen?
Should it be in the message buffer after a user chooses to `F'ollowup
to a message?

Warning, using Mail-Followup-To which is not addressed to an address
that you subscribe to. Continue? (y, n)

*shrug* it's a little wordy, but should that be when it happens?

ttyl,

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> "Matt Armstrong" <matt+dated+1006984700.195575@lickey.com> writes:
>> Anyway, I was reading http://cr.yp.to/proto/replyto.html and in
>> particular, this portion:
>>
>>     You may want to warn the user when he views a message where he's
>>     not included in Mail-Followup-To. This usually indicates that the
>>     user has subscribed to a mailing list shown in Mail-Followup-To,
>>     but hasn't told you about that mailing list. Or it may indicate
>>     that someone is redirecting the discussion.
>
> Yes, this wouldn't be hard, but when should this warning happen?

The excerpt above says "when he views".  When displaying a message, if
MFT exists, and none of the given addresses would cause MFT to be
generated for a response, then we can give a warning, and maybe offer
to add the address (if there's only one) to this group's parameters
(assuming the new mail-address vector parameter).  This could be used
to automatically add mailing list aliases whenever a new one shows up,
as well as the main address when the user hadn't gotten around to it
yet.

> Warning, using Mail-Followup-To which is not addressed to an address
> that you subscribe to. Continue? (y, n)

I'm not sure what "n" would mean in this case, but it doesn't seem
very useful.


paul

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

prj@po.cwru.edu (Paul Jarc) writes:

> The excerpt above says "when he views".  When displaying a message,
> if MFT exists, and none of the given addresses would cause MFT to be
> generated for a response, then we can give a warning, and maybe
> offer to add the address (if there's only one) to this group's
> parameters (assuming the new mail-address vector parameter).  This
> could be used to automatically add mailing list aliases whenever a
> new one shows up, as well as the main address when the user hadn't
> gotten around to it yet.

Yeah, this sounds like a good idea, especially when combined with the
new mail-address vector.  Are you working on this?

> I'm not sure what "n" would mean in this case, but it doesn't seem
> very useful.

Er...yeah. (oops)

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[Paul Jarc]

Josh Huber <huber@alum.wpi.edu> wrote:
> prj@po.cwru.edu (Paul Jarc) writes:
>> When displaying a message, if MFT exists, and none of the given
>> addresses would cause MFT to be generated for a response, then we
>> can give a warning, and maybe offer to add the address (if there's
>> only one) to this group's parameters (assuming the new mail-address
>> vector parameter).
>
> Yeah, this sounds like a good idea, especially when combined with the
> new mail-address vector.  Are you working on this?

Not really.  I think the first step would be to update
gnus-group-customize and all the code that uses to-list and to-address
parameters.  (to-list and to-address should still be used when
mail-address is not set, I guess.)  Then your MFT patch could be
similarly adapted, but wouldn't necessarily have to fall back to
to-list/to-address.


paul

Re: new Mail-Followup-To patch...please take a look...

[Matt Armstrong]

prj@po.cwru.edu (Paul Jarc) writes:

> Josh Huber <huber@alum.wpi.edu> wrote:
>> "Matt Armstrong" <matt+dated+1006984700.195575@lickey.com> writes:
>>> Anyway, I was reading http://cr.yp.to/proto/replyto.html and in
>>> particular, this portion:
>>>
>>>     You may want to warn the user when he views a message where
>>>     he's not included in Mail-Followup-To. This usually indicates
>>>     that the user has subscribed to a mailing list shown in
>>>     Mail-Followup-To, but hasn't told you about that mailing
>>>     list. Or it may indicate that someone is redirecting the
>>>     discussion.
>>
>> Yes, this wouldn't be hard, but when should this warning happen?
>
> The excerpt above says "when he views".

Yes, exactly.

I would put this feature low on the priority list though.



prj@po.cwru.edu (Paul Jarc) writes:

> Josh Huber <huber@alum.wpi.edu> wrote:
>> prj@po.cwru.edu (Paul Jarc) writes:
>>> When displaying a message, if MFT exists, and none of the given
>>> addresses would cause MFT to be generated for a response, then we
>>> can give a warning, and maybe offer to add the address (if there's
>>> only one) to this group's parameters (assuming the new
>>> mail-address vector parameter).
>>
>> Yeah, this sounds like a good idea, especially when combined with
>> the new mail-address vector.  Are you working on this?
>
> Not really.

I do hope we get Josh's initial message.el MFT support into Oort Gnus
soon (with appropriate peer review, of course).  It is useful without
all the group parameter stuff and can be considered separately.

I don't want to see this entry in the FAQ:

  Can Gnus generate Mail-Followup-To: headers?

  Apply the patch below.  The author disappeared before we could get
  his signed FSF papers, so we can't make this part of Gnus.  Somebody
  is free to re-write it!

-- 
matt

Re: new Mail-Followup-To patch...please take a look...

[Per Abrahamsen]

Josh Huber <huber@alum.wpi.edu> writes:

> Here's my current version.

I think this part could be put in CVS now.

Have you CVS write access?  If so, I think you should commit the
changes below (remember a ChangeLog entry though).

If not, I can do it for you.  Have you signed contribution papers?  If
not, ask ShengHuo ZHU  <zsh@cs.rochester.edu> for the papers.

If you sign a "futures" paper, you should probably ask Lars Magne
Ingebrigtsen <larsi@gnus.org> to give you cvs write access, if you
haven't got that already.

It would nice if you thought about adding documentation too.

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Have you signed contribution papers?  If not, ask ShengHuo ZHU
> <zsh@cs.rochester.edu> for the papers.

I haven't yet, but I'll send him a note about the papers.

> If you sign a "futures" paper, you should probably ask Lars Magne
> Ingebrigtsen <larsi@gnus.org> to give you cvs write access, if you
> haven't got that already.

I don't, but I'll ask.

> It would nice if you thought about adding documentation too.

Yes, I'll see if I can come up with some additions to the manual
today.

thanks,

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[ShengHuo ZHU]

Josh Huber <huber@alum.wpi.edu> writes:

> Here's my current version.  I use the following in my .gnus.el:
>
> (setq gnus-parameters
>       '(("^mail\\.lists\\." (subscribed . t))))
>
> (setq message-subscribed-address-functions
>       '(gnus-find-subscribed-addresses))
>
> but I do understand that people would like everything to be
> automatic.  I've got so much stuff in my .gnus.el already that this
> (small) addition isn't a big deal to me, but getting it for free
> automatically would be nice.

Installed.

ShengHuo

Re: new Mail-Followup-To patch...please take a look...

[Matt Armstrong]

[-- Attachment #1: Type: text/plain, Size: 619 bytes --]

ShengHuo ZHU <zsh@cs.rochester.edu> writes:

> Josh Huber <huber@alum.wpi.edu> writes:
>
>> Here's my current version.  I use the following in my .gnus.el:
>>
>> (setq gnus-parameters
>>       '(("^mail\\.lists\\." (subscribed . t))))
>>
>> (setq message-subscribed-address-functions
>>       '(gnus-find-subscribed-addresses))
>>
>> but I do understand that people would like everything to be
>> automatic.  I've got so much stuff in my .gnus.el already that this
>> (small) addition isn't a big deal to me, but getting it for free
>> automatically would be nice.
>
> Installed.

Way cool.  One small doc string fix:


[-- Attachment #2: A doc string fix patch --]
[-- Type: text/plain, Size: 1137 bytes --]

Index: ChangeLog
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/ChangeLog,v
retrieving revision 6.811
diff -u -r6.811 ChangeLog
--- ChangeLog	2001/10/31 13:55:26	6.811
+++ ChangeLog	2001/10/31 17:37:36
@@ -1,3 +1,8 @@
+2001-10-31  Matt Armstrong  <matt@lickey.com>
+
+	* gnus.el (gnus-find-subscribed-addresses): Doc fix:
+	not-subscribed -> subscribed.
+
 2001-10-31 08:00:00  ShengHuo ZHU  <zsh@cs.rochester.edu>
         From: Josh Huber <huber@alum.wpi.edu>
 
Index: gnus.el
===================================================================
RCS file: /usr/local/cvsroot/gnus/lisp/gnus.el,v
retrieving revision 6.63
diff -u -r6.63 gnus.el
--- gnus.el	2001/10/31 13:55:26	6.63
+++ gnus.el	2001/10/31 17:37:42
@@ -2316,7 +2316,7 @@
 (defun gnus-find-subscribed-addresses ()
   "Return a regexp matching the addresses of all subscribed mail groups.
 It consists of the `to-address' or `to-list' parameter of all groups
-with a nil `not-subscribed' parameter."
+with a `subscribed' parameter."
   (let ((addresses))
     (mapc (lambda (entry)
 	    (let ((group (car entry)))

[-- Attachment #3: Type: text/plain, Size: 10 bytes --]


-- 
matt

Re: new Mail-Followup-To patch...please take a look...

[Josh Huber]

"Matt Armstrong" <matt+dated+1007141338.75716a@lickey.com> writes:

> -with a nil `not-subscribed' parameter."
> +with a `subscribed' parameter."

oops, thanks for catching that.

-- 
Josh Huber

Re: new Mail-Followup-To patch...please take a look...

[ShengHuo ZHU]

"Matt Armstrong" <matt+dated+1007141338.75716a@lickey.com> writes:

> ShengHuo ZHU <zsh@cs.rochester.edu> writes:
>
>> Josh Huber <huber@alum.wpi.edu> writes:
>>
>>> Here's my current version.  I use the following in my .gnus.el:
>>>
>>> (setq gnus-parameters
>>>       '(("^mail\\.lists\\." (subscribed . t))))
>>>
>>> (setq message-subscribed-address-functions
>>>       '(gnus-find-subscribed-addresses))
>>>
>>> but I do understand that people would like everything to be
>>> automatic.  I've got so much stuff in my .gnus.el already that this
>>> (small) addition isn't a big deal to me, but getting it for free
>>> automatically would be nice.
>>
>> Installed.
>
> Way cool.  One small doc string fix:

Installed. Thanks.

ShengHuo