Re: subscribe vs. lists

2000-02-16 Thread Charles Cazabon

Thomas Roessler [EMAIL PROTECTED] wrote:
 
 Sorry, the new subscribe command is equivalent to what was formerly
 known as "lists".  "lists" is essentially a weaker version now which
 only affects the list-reply function.
 
 (Partially, the naming is due to the fact that I couldn't think
 about a better name than "lists" for known, but unsubscribed lists -
 "unsubscribe" would have been against the systematic of the un*
 commands.)

What about 'nonsubscribe'?

Charles
-- 

Charles Cazabon  [EMAIL PROTECTED]
Any opinions expressed are just that -- my opinions.




Re: subscribe vs. lists

2000-02-15 Thread Thomas Roessler

On 2000-02-14 15:49:21 -0800, Michael Elkins wrote:

 Not sure, I don't know what the motivate for having the
 "subscribe" command separate from the "lists" command was.

Imagine the case that you (1) know about a list but (2) aren't
subscribed to it.  Further, imagine there are discussions CCed to
you which go to this list, or there are cross-list discussions
(think cypherpunks vs. coderpunks).

On the one hand, you certainly want to be able to use list-reply on
such cross-list discussions.  On the other hand, you don't want to
add a mail-followup-to header to replies which may not go to the
list you are subscribed to - these headers, as generated
automatically, would make sure that replies certainly won't reach
you.  The same is valid for messages you send to lists you are not
subscribed to, but which are known to you.

-- 
http://www.guug.de/~roessler/




Re: subscribe vs. lists

2000-02-15 Thread Lars Hecking

 
 Not sure, I don't know what the motivate for having the "subscribe" command
 separate from the "lists" command was.

 Check out the archives for mutt-dev from last year November. tlr posted
 an explanation why the distinction between "known" and "subscribed"
 mailing lists would be useful. (I'll fwd it to you in private if you prefer).

 While this reasoning may be valid, I never liked the new subscribe
 command. I think it's a case where mutt tries to be more clever than
 the user. It doesn't even work properly in the general case (how to
 deal with ml's as of yet unknown to the user?). And, where there not
 some changes wrt generation of the m-f-t header recently, which may
 or may not affect teh usefulness of lists/subscribe?



subscribe vs. lists

2000-02-14 Thread Russell Hoover

I could swear I read on this list not too long ago that the command "subscribe"
would replace the "lists" command in the muttrc to define what mailing lists
mutt should recognize the user as being subscribed to.

I thought this change was going to take place in version 1.0.1, but AFAKCT it
hasn't.  Is this change still in the works, or has it been abandoned?

-- 
 // [EMAIL PROTECTED] //



Re: subscribe vs. lists

2000-02-14 Thread Thomas Roessler

On 2000-02-14 01:10:40 -0500, Russell Hoover wrote:

 I thought this change was going to take place in version 1.0.1,
 but AFAKCT it hasn't.  Is this change still in the works, or has
 it been abandoned?

The change will be in version 1.2.  1.0.1 is a bug-fix release of
1.0 with minimal changes, not containing any of the more interesting
changes done to the code in the meantime.

-- 
http://www.guug.de/~roessler/




Re: subscribe vs. lists

2000-02-14 Thread Michael Elkins

On Mon, Feb 14, 2000 at 11:04:19AM +0100, Thomas Roessler wrote:
 The change will be in version 1.2.  1.0.1 is a bug-fix release of
 1.0 with minimal changes, not containing any of the more interesting
 changes done to the code in the meantime.

The documentation on this subject really needs to be cleaned up before 1.2.
It's not clear what the effect of setting these is.  I missed the discussion
about this and only discovered the other day that I was not generating the
m-f-t header field.  :-)

me
-- 
pgp key available from http://www.cs.hmc.edu/~me/elkins-pgp-key.asc

 PGP signature


Re: subscribe vs. lists

2000-02-14 Thread Mikko Hänninen

Michael Elkins [EMAIL PROTECTED] wrote on Mon, 14 Feb 2000:
 The documentation on this subject really needs to be cleaned up before 1.2.
 It's not clear what the effect of setting these is.  I missed the discussion
 about this and only discovered the other day that I was not generating the
 m-f-t header field.  :-)

That's odd.  If you have a .muttrc file from 1.0 (or 1.0.1) and move to
1.1.x, then it should -- as far as I understand -- still recognise the
address as a valid list, and generate a MFT header.  However, the
contents of the header will be wrong, indicating a reply should go to
both to the list and your own address.

Hmm, is that a bug or have I misunderstood something, or what is going
on?  I'll try to remember to do some testing with the "lists" command
under 1.1.3 later to see if I can figure anything out...


Mikko
-- 
// Mikko Hänninen, aka. Wizzu  //  [EMAIL PROTECTED]  //  http://www.iki.fi/wiz/
// The Corrs list maintainer  //   net.freak  //   DALnet IRC operator /
// Interests: roleplaying, Linux, the Net, fantasy  scifi, the Corrs /
"Personally, I want my computer's memory to be more reliable than mine."  /.



Re: subscribe vs. lists

2000-02-14 Thread Michael Elkins

On Tue, Feb 15, 2000 at 01:04:05AM +0200, Mikko Hänninen wrote:
 That's odd.  If you have a .muttrc file from 1.0 (or 1.0.1) and move to
 1.1.x, then it should -- as far as I understand -- still recognise the
 address as a valid list, and generate a MFT header.  However, the
 contents of the header will be wrong, indicating a reply should go to
 both to the list and your own address.

That's definitely not what the code is doing.  I resorted to using gdb to
trace the call to mutt_set_followup_to() and it definitely only looks for
mailing lists using the "subscribe"d list, not the "lists" list.

 Hmm, is that a bug or have I misunderstood something, or what is going
 on?  I'll try to remember to do some testing with the "lists" command
 under 1.1.3 later to see if I can figure anything out...

Not sure, I don't know what the motivate for having the "subscribe" command
separate from the "lists" command was.

me
-- 
pgp key available from http://www.cs.hmc.edu/~me/elkins-pgp-key.asc

 PGP signature