possible strange idea about hierarchical lists

possible strange idea about hierarchical lists

[Ted Zlatanov]

This will probably not concern 99% of Gnus users.

I am subscribed to several mailing lists that overlap.  For instance,
list A contains list B, yet I get mail addressed to A and B all the
time.  I can deal with the incoming duplicates, but on reply I'd like
to do something similar to message-subscribed-regexes but with a
hierarchy.  So replies would drop list B because it's a part of list
A.

The hierarchy specification is pretty easy to do in Lisp, but the
actual parsing and address squashing are not trivial.  Has anyone
dealt with this issue before, though?

Thanks
Ted

Re: possible strange idea about hierarchical lists

[Ted Zlatanov]

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

> Ted Zlatanov <tzz@northernlight.com> writes:
>
>> The hierarchy specification is pretty easy to do in Lisp, but the
>> actual parsing and address squashing are not trivial.  Has anyone
>> dealt with this issue before, though?
>
> What do you mean by parsing?  There are functions which give you a
> list of all addresses in the To/Cc fied...

Parsing of the hierarchy specification.  It's a tree structure, with
the widest-coverage lists at the top and more specific lists at the
bottom.  I suppose it could be hacked as a 2-level list, but a tree
hierarchy is more generic.

Ted

Re: possible strange idea about hierarchical lists

[Kai Großjohann]

Ted Zlatanov <tzz@northernlight.com> writes:

> The hierarchy specification is pretty easy to do in Lisp, but the
> actual parsing and address squashing are not trivial.  Has anyone
> dealt with this issue before, though?

What do you mean by parsing?  There are functions which give you a
list of all addresses in the To/Cc fied...

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: possible strange idea about hierarchical lists

[Ted Zlatanov]

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

> Ted Zlatanov <tzz@northernlight.com> wrote:
>> Parsing of the hierarchy specification.  It's a tree structure, with
>> the widest-coverage lists at the top and more specific lists at the
>> bottom.  I suppose it could be hacked as a 2-level list, but a tree
>> hierarchy is more generic.
>
> The 2-level list is just as expressive, I think, and easier to
> implement.  Suppose A contains B, and B contains C, and you have a
> message addressed to B and C.  In order to strip out C, you'd have to
> traverse the entire tree to first find B; there's no guarantee that
> the top level will have anything interesting.
>
> Also suppose A nd D both contain B.  This is actually easier to
> express with the 2-level list; with a tree, you'd have to duplicate
> the whole subtree under B.  With a 2-level list, you just add B under
> both A and D, and the code takes care of looking for a top-level B
> with its own entries under it.

You are right.  It's faster and easier (for implementer and user) to
use a 2-level list.  But is anyone except me interested in it?

Ted

Re: possible strange idea about hierarchical lists

[Paul Jarc]

Ted Zlatanov <tzz@northernlight.com> wrote:
> Parsing of the hierarchy specification.  It's a tree structure, with
> the widest-coverage lists at the top and more specific lists at the
> bottom.  I suppose it could be hacked as a 2-level list, but a tree
> hierarchy is more generic.

The 2-level list is just as expressive, I think, and easier to
implement.  Suppose A contains B, and B contains C, and you have a
message addressed to B and C.  In order to strip out C, you'd have to
traverse the entire tree to first find B; there's no guarantee that
the top level will have anything interesting.

Also suppose A nd D both contain B.  This is actually easier to
express with the 2-level list; with a tree, you'd have to duplicate
the whole subtree under B.  With a 2-level list, you just add B under
both A and D, and the code takes care of looking for a top-level B
with its own entries under it.


paul

Re: possible strange idea about hierarchical lists

[Kai Großjohann]

Ted Zlatanov <tzz@northernlight.com> writes:

> You are right.  It's faster and easier (for implementer and user) to
> use a 2-level list.  But is anyone except me interested in it?

I think the feature is too cool to be comprehended easily.  Just go
ahead and add it, and in ten years, when people have become wiser,
they will thank you for it :-)

Or it's just me who is dimwitted and has problems seeing the
benefits...  Anyhow, some thinking about it indicates a high coolness
factor.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: possible strange idea about hierarchical lists

[Matt Armstrong]

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

> Ted Zlatanov <tzz@northernlight.com> writes:
>
>> You are right.  It's faster and easier (for implementer and user) to
>> use a 2-level list.  But is anyone except me interested in it?
>
> I think the feature is too cool to be comprehended easily.  Just go
> ahead and add it, and in ten years, when people have become wiser,
> they will thank you for it :-)
>
> Or it's just me who is dimwitted and has problems seeing the
> benefits...  Anyhow, some thinking about it indicates a high
> coolness factor.

I don't happen to belong to any hierarchical groups, but if I did, I'd
want the feature.  ;-)


-- 
matt

Re: possible strange idea about hierarchical lists

[Ted Zlatanov]

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

> Ted Zlatanov <tzz@northernlight.com> writes:
>
>> You are right.  It's faster and easier (for implementer and user) to
>> use a 2-level list.  But is anyone except me interested in it?
>
> I think the feature is too cool to be comprehended easily.  Just go
> ahead and add it, and in ten years, when people have become wiser,
> they will thank you for it :-)

I would, if I understood Lisp well enough :(  I could probably figure
it out if someone gave me pointers - where to start looking, what
function(s) to copy or modify...  Thanks

Ted

Re: possible strange idea about hierarchical lists

[Lars Magne Ingebrigtsen]

Ted Zlatanov <tzz@northernlight.com> writes:

> I would, if I understood Lisp well enough :(  I could probably figure
> it out if someone gave me pointers - where to start looking, what
> function(s) to copy or modify...  Thanks

It's an intriguing idea.  I think the most likely place to hook
something like this in is in `message-wide-reply-to-function'.  It
should return a list of To/CC headers.  Have a look at what
`message-reply' does.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: possible strange idea about hierarchical lists

[Ted Zlatanov]

OK, after a lot of trial and error, I need some help with this.  Keep
in mind, this is my first attempt at writing Lisp beyond my .emacs
files.

The following:

(let* ((recipients '(("foo@bar" . "Name <foo@bar>") ("baz@quux" . "None <baz@quux>")))
       (s recipients)
       (gnus-hierarchical-lists '( ("foo@bar" . "baz@quux"))))
  (while gnus-hierarchical-lists
    (let* ((node (pop gnus-hierarchical-lists))
	   (parent (car node))
	   (child (cdr node)))
      (when (and (assoc parent recipients) (assoc child recipients))
	  (delq parent recipients)))))

(to be done after "Remove first duplicates" at line 4502 in
message.el, function message-get-reply-headers)

does not seem to do what I want.  What I want is, if the recipients
list has the parent and the child, to delete the parent from the
recipients (because the child is the more generic of the two).  This
should happen more than once, so now if the child is in the
gnus-hierarchical-lists list as well as a parent, then this new parent
will be removed in favor of ITS child.  I think my logic (go through
the hierarchical list, and delete all ocurrences of the parent if the
parent and the child exist) makes sense, but my Lisp is not expressing
it correctly.

e.g. ("zero" . "integers") ("integers" . "reals") applied to a list
with "zero", "integers", and "reals" in it should produce "reals"
only.  Does that make sense?

Thanks
Ted

Re: possible strange idea about hierarchical lists

[Ted Zlatanov]

Ted Zlatanov <tzz@northernlight.com> writes:

> (let* ((recipients '(("foo@bar" . "Name <foo@bar>") ("baz@quux" . "None <baz@quux>")))
>        (s recipients)
>        (gnus-hierarchical-lists '( ("foo@bar" . "baz@quux"))))
>   (while gnus-hierarchical-lists
>     (let* ((node (pop gnus-hierarchical-lists))
> 	   (parent (car node))
> 	   (child (cdr node)))
>       (when (and (assoc parent recipients) (assoc child recipients))
> 	  (delq parent recipients)))))

I should clarify - in message.el the recipients variable is already
set for you, I just set it manually so I could test the code in
isolation from the rest of Gnus.

Thanks
Ted

Re: possible strange idea about hierarchical lists

[Kai Großjohann]

Ted Zlatanov <tzz@northernlight.com> writes:

> (let* ((recipients '(("foo@bar" . "Name <foo@bar>") ("baz@quux" . "None <baz@quux>")))
>        (s recipients)
>        (gnus-hierarchical-lists '( ("foo@bar" . "baz@quux"))))
>   (while gnus-hierarchical-lists
>     (let* ((node (pop gnus-hierarchical-lists))
> 	   (parent (car node))
> 	   (child (cdr node)))
>       (when (and (assoc parent recipients) (assoc child recipients))
> 	  (delq parent recipients)))))

Does ist help to replace the delq statement with this?

    (setq recipients (delete parent recipients))

The side-effect thing does not work to delete the first element of a
list; I used delete instead of delq because (eq "x" "x") is false.

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: possible strange idea about hierarchical lists

[Paul Jarc]

Ted Zlatanov <tzz@northernlight.com> wrote:
> (let* ((recipients '(("foo@bar" . "Name <foo@bar>") ("baz@quux" . "None <baz@quux>")))
>        (s recipients)
>        (gnus-hierarchical-lists '( ("foo@bar" . "baz@quux"))))
>   (while gnus-hierarchical-lists
>     (let* ((node (pop gnus-hierarchical-lists))
> 	   (parent (car node))
> 	   (child (cdr node)))
>       (when (and (assoc parent recipients) (assoc child recipients))
> 	  (delq parent recipients)))))

How about this:
(let* ((recipients '(("foo@bar" . "Name <foo@bar>")
                     ("baz@quux" . "None <baz@quux>")))
       (plain-addrs (mapcar 'car recipients))
       (gnus-hierarchical-lists '(("baz@quux" "foo@bar")))
       sublists recip)
  (while plain-addrs
    (setq sublists (assoc (car plain-addrs) gnus-hierarchical-lists)
          plain-addrs (cdr plain-addrs))
    (when sublists
      (setq sublists (cdr sublists))
      (while sublists
        (setq recip (assoc (car sublists) recipients)
              sublists (cdr sublists))
        (if recip
            (setq recipients (delq recip recipients)))))))

Note that this is a different structure for gnus-hierarchical-lists.
An entry (A B C) means that A contains B and C.  (No further
relationship between B and C is implied.)  So if A appears in the
recipient list, then B and C will be removed from it, if present.  If
B and C have sublists of their own, they should get their own
top-level entries in gnus-hierarchical-lists.  In this case,
gnus-hierarchical-lists says that messages to baz@quux also go to
foo@bar, so foo@bar is removed from the recipient list.


paul

Re: possible strange idea about hierarchical lists

[Ted Zlatanov]

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

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

> How about this:
> (let* ((recipients '(("foo@bar" . "Name <foo@bar>")
>                      ("baz@quux" . "None <baz@quux>")))
>        (plain-addrs (mapcar 'car recipients))
>        (gnus-hierarchical-lists '(("baz@quux" "foo@bar")))
>        sublists recip)
>   (while plain-addrs
>     (setq sublists (assoc (car plain-addrs) gnus-hierarchical-lists)
>           plain-addrs (cdr plain-addrs))
>     (when sublists
>       (setq sublists (cdr sublists))
>       (while sublists
>         (setq recip (assoc (car sublists) recipients)
>               sublists (cdr sublists))
>         (if recip
>             (setq recipients (delq recip recipients)))))))
>
> Note that this is a different structure for gnus-hierarchical-lists.
> An entry (A B C) means that A contains B and C.  (No further
> relationship between B and C is implied.)  So if A appears in the
> recipient list, then B and C will be removed from it, if present.  If
> B and C have sublists of their own, they should get their own
> top-level entries in gnus-hierarchical-lists.  In this case,
> gnus-hierarchical-lists says that messages to baz@quux also go to
> foo@bar, so foo@bar is removed from the recipient list.

That looks fine to me.

Kai, sorry for not following up to your very helpful message.  I was
unable to send e-mail to the ding list for a while due to server
problems.  I think Paul's suggestion is even better to make the user's
life simple, using a list instead of a cons cell.

I tried to put a patch into message.el, naming the variables
accordingly and simplifying things a bit.  I'm not sure if the
variable should go into the message-headers or the message-sending
group; also, I'm not sure if I defined the variable correctly with
defcustom (I tried the '(repeat sexp) type but that didn't work).  I
think the functional definition, at least, is correct (because Paul
wrote it :)

I did a diff -u, renaming the original message.el to
message-original.el because I don't have access to the CVS repository
(firewall issues, don't ask) to do a diff against it.

This is my first time submitting a patch, please let me know if I did
anything wrong.  It's also my first time writing more than 4 lines of
Lisp for a single purpose.

To test, define message-hierarchical-lists to be ("foo" "bar") and
then have "foo" and "bar" in your recipient list.  "bar" should be
removed.

I couldn't test - message-get-reply-headers was not invoked, according
to debug-on-entry.  I'm kind of puzzled by this.  I must be doing
something wrong.

Also, the message-hierarchical-lists should probably be generalized to
regular expressions for both the primary and secondary lists
(message-hierarchical-lists-regexps?).  I don't need this personally,
but perhaps someone else will find it useful.  Maybe when the string
exact matching is working.

Thanks
Ted


[-- Attachment #2: patch for message.el --]
[-- Type: text/plain, Size: 1596 bytes --]

--- message-original.el	Fri Feb  1 16:07:38 2002
+++ message.el	Fri Feb  1 17:11:14 2002
@@ -1044,6 +1044,15 @@
   :type '(choice (const :tag "Always use primary" nil)
 		 regexp))
 
+(defcustom message-hierarchical-lists nil
+  "A list of hierarchical mailing list definitions.
+
+Inside each entry, the first address is the top list, everything after
+it are secondary addresses contained in the list.  The secondaries
+will be removed from the list of recipients when mail is prepared for
+delivery."
+  :group 'message-headers)
+
 (defcustom message-mail-user-agent nil
   "Like `mail-user-agent'.
 Except if it is nil, use Gnus native MUA; if it is t, use
@@ -4512,6 +4521,23 @@
       (let ((s recipients))
 	(while s
 	  (setq recipients (delq (assoc (car (pop s)) s) recipients))))
+
+      ;; remove hierarchical lists that are contained within each other,
+      ;; if message-hierarchical-lists is defined
+      (when message-hierarchical-lists
+	(let* ((plain-addrs (mapcar 'car recipients))
+	       sublists recip)
+	  (while plain-addrs
+	    (setq sublists (assoc (car plain-addrs) message-hierarchical-lists)
+		  plain-addrs (cdr plain-addrs))
+	    (when sublists
+	      (setq sublists (cdr sublists))
+	      (while sublists
+		(setq recip (assoc (car sublists) recipients)
+		      sublists (cdr sublists))
+		(if recip
+		    (setq recipients (delq recip recipients))))))))
+
       ;; Build the header alist.  Allow the user to be asked whether
       ;; or not to reply to all recipients in a wide reply.
       (setq follow-to (list (cons 'To (cdr (pop recipients)))))

Re: possible strange idea about hierarchical lists

[Paul Jarc]

Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
> To test, define message-hierarchical-lists to be ("foo" "bar") and
> then have "foo" and "bar" in your recipient list.  "bar" should be
> removed.
>
> I couldn't test - message-get-reply-headers was not invoked, according
> to debug-on-entry.  I'm kind of puzzled by this.  I must be doing
> something wrong.

That function is called only when initializing a reply/followup
buffer.  Is that what you were doing?

> Also, the message-hierarchical-lists should probably be generalized to
> regular expressions for both the primary and secondary lists
> (message-hierarchical-lists-regexps?).  I don't need this personally,
> but perhaps someone else will find it useful.

That would complicate the code; the two uses of assoc would have to be
replaced by explicit iteration and regexp comparison.  We could wait
for someone to ask for it, if it really is ever useful.


paul

[patch] hierarchical lists in message.el

[Ted Zlatanov]

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

I got the patch working and tested it today.  It worked fine for me.
It does something only when message-hierarchical-lists is defined, on
replying to a message.  Thanks again to Paul and Kai.

I am attaching the patch again; it worked against this morning's CVS
Gnus.  It being the first patch I've done for Gnus, I don't know if it
should go to the list or to someone in particular.

Paul Jarc wrote:
> Ted Zlatanov wrote:
>> Also, the message-hierarchical-lists should probably be generalized to
>> regular expressions for both the primary and secondary lists
>> (message-hierarchical-lists-regexps?).  I don't need this personally,
>> but perhaps someone else will find it useful.
>
> That would complicate the code; the two uses of assoc would have to be
> replaced by explicit iteration and regexp comparison.  We could wait
> for someone to ask for it, if it really is ever useful.

You're right, no one has been clamoring for this feature as it is.

Thanks
Ted


[-- Attachment #2: message-hierarchical-patch --]
[-- Type: text/plain, Size: 1596 bytes --]

--- message-original.el	Fri Feb  1 16:07:38 2002
+++ message.el	Fri Feb  1 17:11:14 2002
@@ -1044,6 +1044,15 @@
   :type '(choice (const :tag "Always use primary" nil)
 		 regexp))
 
+(defcustom message-hierarchical-lists nil
+  "A list of hierarchical mailing list definitions.
+
+Inside each entry, the first address is the top list, everything after
+it are secondary addresses contained in the list.  The secondaries
+will be removed from the list of recipients when mail is prepared for
+delivery."
+  :group 'message-headers)
+
 (defcustom message-mail-user-agent nil
   "Like `mail-user-agent'.
 Except if it is nil, use Gnus native MUA; if it is t, use
@@ -4512,6 +4521,23 @@
       (let ((s recipients))
 	(while s
 	  (setq recipients (delq (assoc (car (pop s)) s) recipients))))
+
+      ;; remove hierarchical lists that are contained within each other,
+      ;; if message-hierarchical-lists is defined
+      (when message-hierarchical-lists
+	(let* ((plain-addrs (mapcar 'car recipients))
+	       sublists recip)
+	  (while plain-addrs
+	    (setq sublists (assoc (car plain-addrs) message-hierarchical-lists)
+		  plain-addrs (cdr plain-addrs))
+	    (when sublists
+	      (setq sublists (cdr sublists))
+	      (while sublists
+		(setq recip (assoc (car sublists) recipients)
+		      sublists (cdr sublists))
+		(if recip
+		    (setq recipients (delq recip recipients))))))))
+
       ;; Build the header alist.  Allow the user to be asked whether
       ;; or not to reply to all recipients in a wide reply.
       (setq follow-to (list (cons 'To (cdr (pop recipients)))))

[patch] hierarchical lists in message.el

[Ted Zlatanov]

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

I got the patch working and tested it today.  It worked fine for me.
It does something only when message-hierarchical-lists is defined, on
replying to a message.  Thanks again to Paul and Kai.

I am attaching the patch again; it worked against this morning's CVS
Gnus.  It being the first patch I've done for Gnus, I don't know if it
should go to the list or to someone in particular.

Paul Jarc wrote:
> Ted Zlatanov wrote:
>> Also, the message-hierarchical-lists should probably be generalized to
>> regular expressions for both the primary and secondary lists
>> (message-hierarchical-lists-regexps?).  I don't need this personally,
>> but perhaps someone else will find it useful.
>
> That would complicate the code; the two uses of assoc would have to be
> replaced by explicit iteration and regexp comparison.  We could wait
> for someone to ask for it, if it really is ever useful.

You're right, no one has been clamoring for this feature as it is.

Thanks
Ted


[-- Attachment #2: message-hierarchical-patch --]
[-- Type: text/plain, Size: 1596 bytes --]

--- message-original.el	Fri Feb  1 16:07:38 2002
+++ message.el	Fri Feb  1 17:11:14 2002
@@ -1044,6 +1044,15 @@
   :type '(choice (const :tag "Always use primary" nil)
 		 regexp))
 
+(defcustom message-hierarchical-lists nil
+  "A list of hierarchical mailing list definitions.
+
+Inside each entry, the first address is the top list, everything after
+it are secondary addresses contained in the list.  The secondaries
+will be removed from the list of recipients when mail is prepared for
+delivery."
+  :group 'message-headers)
+
 (defcustom message-mail-user-agent nil
   "Like `mail-user-agent'.
 Except if it is nil, use Gnus native MUA; if it is t, use
@@ -4512,6 +4521,23 @@
       (let ((s recipients))
 	(while s
 	  (setq recipients (delq (assoc (car (pop s)) s) recipients))))
+
+      ;; remove hierarchical lists that are contained within each other,
+      ;; if message-hierarchical-lists is defined
+      (when message-hierarchical-lists
+	(let* ((plain-addrs (mapcar 'car recipients))
+	       sublists recip)
+	  (while plain-addrs
+	    (setq sublists (assoc (car plain-addrs) message-hierarchical-lists)
+		  plain-addrs (cdr plain-addrs))
+	    (when sublists
+	      (setq sublists (cdr sublists))
+	      (while sublists
+		(setq recip (assoc (car sublists) recipients)
+		      sublists (cdr sublists))
+		(if recip
+		    (setq recipients (delq recip recipients))))))))
+
       ;; Build the header alist.  Allow the user to be asked whether
       ;; or not to reply to all recipients in a wide reply.
       (setq follow-to (list (cons 'To (cdr (pop recipients)))))

Re: [patch] hierarchical lists in message.el

[Paul Jarc]

Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
> It being the first patch I've done for Gnus, I don't know if it
> should go to the list or to someone in particular.

This is the place for it.  Have you signed the copyright paperwork?

> +(defcustom message-hierarchical-lists nil
> +  "A list of hierarchical mailing list definitions.
> +
> +Inside each entry, the first address is the top list, everything after
> +it are secondary addresses contained in the list.  The secondaries
> +will be removed from the list of recipients when mail is prepared for
> +delivery."
> +  :group 'message-headers)

We should also say that secondaries of secondaries, and so on, will be
removed, and it probably would be good to spell out more explicitly
that this is a way for the user to express to Gnus that messages sent
to the first address are automatically delivered to the others, which
is *why* Gnus will remove the subordinates, so no one is left
wondering when this thing would be useful.  Maybe that would be better
off in the manual than in the docstring; the manual could also give an
example.  I also don't quite like the word "secondaries" (maybe
"sublists"?) but that's just a nit.

> +      ;; remove hierarchical lists that are contained within each other,
> +      ;; if message-hierarchical-lists is defined
> +      (when message-hierarchical-lists

It happens that this "when" test is not strictly necessary; the code
will have nothing to remove if m-h-l is empty.  But maybe this is
still a worthwhile optimization for the common case.


paul

Re: [patch] hierarchical lists in message.el

[Paul Jarc]

Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
> It being the first patch I've done for Gnus, I don't know if it
> should go to the list or to someone in particular.

This is the place for it.  Have you signed the copyright paperwork?

> +(defcustom message-hierarchical-lists nil
> +  "A list of hierarchical mailing list definitions.
> +
> +Inside each entry, the first address is the top list, everything after
> +it are secondary addresses contained in the list.  The secondaries
> +will be removed from the list of recipients when mail is prepared for
> +delivery."
> +  :group 'message-headers)

We should also say that secondaries of secondaries, and so on, will be
removed, and it probably would be good to spell out more explicitly
that this is a way for the user to express to Gnus that messages sent
to the first address are automatically delivered to the others, which
is *why* Gnus will remove the subordinates, so no one is left
wondering when this thing would be useful.  Maybe that would be better
off in the manual than in the docstring; the manual could also give an
example.  I also don't quite like the word "secondaries" (maybe
"sublists"?) but that's just a nit.

> +      ;; remove hierarchical lists that are contained within each other,
> +      ;; if message-hierarchical-lists is defined
> +      (when message-hierarchical-lists

It happens that this "when" test is not strictly necessary; the code
will have nothing to remove if m-h-l is empty.  But maybe this is
still a worthwhile optimization for the common case.


paul

Re: [patch] hierarchical lists in message.el

[Ted Zlatanov]

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

> Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
>> It being the first patch I've done for Gnus, I don't know if it
>> should go to the list or to someone in particular.
>
> This is the place for it.  Have you signed the copyright paperwork?

No, can someone get in touch with me?

>> +(defcustom message-hierarchical-lists nil
>> +  "A list of hierarchical mailing list definitions.
>> +
>> +Inside each entry, the first address is the top list, everything after
>> +it are secondary addresses contained in the list.  The secondaries
>> +will be removed from the list of recipients when mail is prepared for
>> +delivery."
>> +  :group 'message-headers)
>
> We should also say that secondaries of secondaries, and so on, will be
> removed, and it probably would be good to spell out more explicitly
> that this is a way for the user to express to Gnus that messages sent
> to the first address are automatically delivered to the others, which
> is *why* Gnus will remove the subordinates, so no one is left
> wondering when this thing would be useful.  Maybe that would be better
> off in the manual than in the docstring; the manual could also give an
> example.  I also don't quite like the word "secondaries" (maybe
> "sublists"?) but that's just a nit.

Detailed instructions should definitely go in the manual.  "sublists"
does sound better than "secondaries."

>> +      ;; remove hierarchical lists that are contained within each other,
>> +      ;; if message-hierarchical-lists is defined
>> +      (when message-hierarchical-lists
>
> It happens that this "when" test is not strictly necessary; the code
> will have nothing to remove if m-h-l is empty.  But maybe this is
> still a worthwhile optimization for the common case.

Yes, I think it improves the code for someone glancing through it -
they don't have to figure out the logic to see that it will do nothing
without m-h-l (code comments being the first thing no one reads :)

Thanks
Ted

Re: [patch] hierarchical lists in message.el

[Ted Zlatanov]

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

> Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
>> It being the first patch I've done for Gnus, I don't know if it
>> should go to the list or to someone in particular.
>
> This is the place for it.  Have you signed the copyright paperwork?

No, can someone get in touch with me?

>> +(defcustom message-hierarchical-lists nil
>> +  "A list of hierarchical mailing list definitions.
>> +
>> +Inside each entry, the first address is the top list, everything after
>> +it are secondary addresses contained in the list.  The secondaries
>> +will be removed from the list of recipients when mail is prepared for
>> +delivery."
>> +  :group 'message-headers)
>
> We should also say that secondaries of secondaries, and so on, will be
> removed, and it probably would be good to spell out more explicitly
> that this is a way for the user to express to Gnus that messages sent
> to the first address are automatically delivered to the others, which
> is *why* Gnus will remove the subordinates, so no one is left
> wondering when this thing would be useful.  Maybe that would be better
> off in the manual than in the docstring; the manual could also give an
> example.  I also don't quite like the word "secondaries" (maybe
> "sublists"?) but that's just a nit.

Detailed instructions should definitely go in the manual.  "sublists"
does sound better than "secondaries."

>> +      ;; remove hierarchical lists that are contained within each other,
>> +      ;; if message-hierarchical-lists is defined
>> +      (when message-hierarchical-lists
>
> It happens that this "when" test is not strictly necessary; the code
> will have nothing to remove if m-h-l is empty.  But maybe this is
> still a worthwhile optimization for the common case.

Yes, I think it improves the code for someone glancing through it -
they don't have to figure out the logic to see that it will do nothing
without m-h-l (code comments being the first thing no one reads :)

Thanks
Ted

Re: [patch] hierarchical lists in message.el

[Paul Jarc]

Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
> +(defcustom message-hierarchical-lists nil
> +  "A list of hierarchical mailing list definitions.
> +
> +Inside each entry, the first address is the top list, everything after
> +it are secondary addresses contained in the list.  The secondaries
> +will be removed from the list of recipients when mail is prepared for
> +delivery."
> +  :group 'message-headers)

I thought of another use for this.  Suppose I followup on ding to a
message from Kai.  There's no MFT in the original message, but I know
Kai reads ding, so I want my message to go only to ding.  So I can do:
(add-to-list 'message-hierarchical-lists
             '("ding@gnus.org" "kai.grossjohann@cs.uni-dortmund.de"))
So maybe the variable should be called m-h-addresses or some such
instead of m-h-lists?

(Ted, if no one's sent you the email about the paperwork, I think you
can talk to fsf-records@gnu.org to find out what information they
need, which you'd then send back to them; then they'll send you a
paper form in the mail, and you'll sign it and mail it back.  Odd that
the initial list of information they need doesn't seem to be on the
GNU web site.)


paul

Re: [patch] hierarchical lists in message.el

[Paul Jarc]

Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
> +(defcustom message-hierarchical-lists nil
> +  "A list of hierarchical mailing list definitions.
> +
> +Inside each entry, the first address is the top list, everything after
> +it are secondary addresses contained in the list.  The secondaries
> +will be removed from the list of recipients when mail is prepared for
> +delivery."
> +  :group 'message-headers)

I thought of another use for this.  Suppose I followup on ding to a
message from Kai.  There's no MFT in the original message, but I know
Kai reads ding, so I want my message to go only to ding.  So I can do:
(add-to-list 'message-hierarchical-lists
             '("ding@gnus.org" "kai.grossjohann@cs.uni-dortmund.de"))
So maybe the variable should be called m-h-addresses or some such
instead of m-h-lists?

(Ted, if no one's sent you the email about the paperwork, I think you
can talk to fsf-records@gnu.org to find out what information they
need, which you'd then send back to them; then they'll send you a
paper form in the mail, and you'll sign it and mail it back.  Odd that
the initial list of information they need doesn't seem to be on the
GNU web site.)


paul

Re: [patch] hierarchical lists in message.el

[Ted Zlatanov]

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

> I thought of another use for this.  Suppose I followup on ding to a
> message from Kai.  There's no MFT in the original message, but I know
> Kai reads ding, so I want my message to go only to ding.  So I can do:
> (add-to-list 'message-hierarchical-lists
>              '("ding@gnus.org" "kai.grossjohann@cs.uni-dortmund.de"))
> So maybe the variable should be called m-h-addresses or some such
> instead of m-h-lists?

I actually discovered that use on my own just recently as well :)

I would be OK with the renaming of the variable.

> (Ted, if no one's sent you the email about the paperwork, I think you
> can talk to fsf-records@gnu.org to find out what information they
> need, which you'd then send back to them; then they'll send you a
> paper form in the mail, and you'll sign it and mail it back.  Odd that
> the initial list of information they need doesn't seem to be on the
> GNU web site.)

The paperwork is on its way back.  I got it today.

Ted

Re: [patch] hierarchical lists in message.el

[Ted Zlatanov]

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

> I thought of another use for this.  Suppose I followup on ding to a
> message from Kai.  There's no MFT in the original message, but I know
> Kai reads ding, so I want my message to go only to ding.  So I can do:
> (add-to-list 'message-hierarchical-lists
>              '("ding@gnus.org" "kai.grossjohann@cs.uni-dortmund.de"))
> So maybe the variable should be called m-h-addresses or some such
> instead of m-h-lists?

I actually discovered that use on my own just recently as well :)

I would be OK with the renaming of the variable.

> (Ted, if no one's sent you the email about the paperwork, I think you
> can talk to fsf-records@gnu.org to find out what information they
> need, which you'd then send back to them; then they'll send you a
> paper form in the mail, and you'll sign it and mail it back.  Odd that
> the initial list of information they need doesn't seem to be on the
> GNU web site.)

The paperwork is on its way back.  I got it today.

Ted

Re: [patch] hierarchical lists in message.el

[Paul Jarc]

Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
> I would be OK with the renaming of the variable.
...
> The paperwork is on its way back.  I got it today.

Ok, I renamed the variable, tweaked the docstring, added a :type for
defcustom, and committed it.  Note that so far, it only takes effect
for replies, not original message.  Also, it overrides someone else's
MFT, so be careful using it to remove people you think are subscribed
to a list.


paul

Re: [patch] hierarchical lists in message.el

[Paul Jarc]

Ted Zlatanov <teodor.zlatanov@divine.com> wrote:
> I would be OK with the renaming of the variable.
...
> The paperwork is on its way back.  I got it today.

Ok, I renamed the variable, tweaked the docstring, added a :type for
defcustom, and committed it.  Note that so far, it only takes effect
for replies, not original message.  Also, it overrides someone else's
MFT, so be careful using it to remove people you think are subscribed
to a list.


paul