Re: temporarily modifying thread display in the index?
* David J. Weller-Fahy dave-lists-mutt-us...@weller-fahy.com [2013-01-14 21:31:13 -0500]: * Will Fiveash will.five...@oracle.com [2013-01-14 14:22 -0500]: Indeed, with hide_top_limited=yes I can limit the display of a subthread in the desired way. I'm now using this index macro: macro index _S tag-subthreadlimit~T\ntag-subthread Display only subthread with hide_top_limited=yes in my .muttrc. Thanks for posting that tip. No worries, thanks for putting up the resulting macro... I may just be using that soon. -- dave [ please don't CC me ] Yes, very useful info. I'll certainly be using that in my configuration. It never ceases to amaze me how configurable this MUA is! -- Primary Key: 4096R/1D31DC38 2011-12-03 Key Fingerprint: A4B9 E875 A18C 6E11 F46D B788 BEE6 1251 1D31 DC38
Re: temporarily modifying thread display in the index?
On Sun, Jan 13, 2013 at 12:26:46PM -0500, David J. Weller-Fahy wrote: * David J. Weller-Fahy dave-lists-mutt-us...@weller-fahy.com [2013-01-11 12:44 -0500]: * Will Fiveash will.five...@oracle.com [2013-01-11 12:35 -0500]: On Fri, Jan 11, 2013 at 12:12:01PM -0500, David J. Weller-Fahy wrote: Hrm... have you tried a combination of 'tag-subthread' and 'limit'? That is close but not exactly what I'm looking for. The indentation level of the subtree parent is such with the thread I'm looking at that the thread display is still beyond the terminal window. It would be perfect if mutt could also reset the indent level of the subtree parent to 0. Yep, sorry about the red herring: I just checked on a huge thread in another list and it is as you say. It would be useful to have an option to reset the indent level. Ah-hah! The herring was green! Try setting hide_top_limited when limiting to a tagged subthread. I think that does what you want, and with a little scripting you could wrap everything into a macro. Thanks to Marco for inspiring me to search through the manual for thread. ;) Indeed, with hide_top_limited=yes I can limit the display of a subthread in the desired way. I'm now using this index macro: macro index _S tag-subthreadlimit~T\ntag-subthread Display only subthread with hide_top_limited=yes in my .muttrc. Thanks for posting that tip. -- Will Fiveash
Re: temporarily modifying thread display in the index?
* Will Fiveash will.five...@oracle.com [2013-01-14 14:22 -0500]: Indeed, with hide_top_limited=yes I can limit the display of a subthread in the desired way. I'm now using this index macro: macro index _S tag-subthreadlimit~T\ntag-subthread Display only subthread with hide_top_limited=yes in my .muttrc. Thanks for posting that tip. No worries, thanks for putting up the resulting macro... I may just be using that soon. -- dave [ please don't CC me ] pgpJZh0Ntq7mW.pgp Description: PGP signature
Re: temporarily modifying thread display in the index?
* David J. Weller-Fahy dave-lists-mutt-us...@weller-fahy.com [2013-01-11 12:44 -0500]: * Will Fiveash will.five...@oracle.com [2013-01-11 12:35 -0500]: On Fri, Jan 11, 2013 at 12:12:01PM -0500, David J. Weller-Fahy wrote: Hrm... have you tried a combination of 'tag-subthread' and 'limit'? That is close but not exactly what I'm looking for. The indentation level of the subtree parent is such with the thread I'm looking at that the thread display is still beyond the terminal window. It would be perfect if mutt could also reset the indent level of the subtree parent to 0. Yep, sorry about the red herring: I just checked on a huge thread in another list and it is as you say. It would be useful to have an option to reset the indent level. Ah-hah! The herring was green! Try setting hide_top_limited when limiting to a tagged subthread. I think that does what you want, and with a little scripting you could wrap everything into a macro. Thanks to Marco for inspiring me to search through the manual for thread. ;) HTH, -- dave [ please don't CC me ] pgplxORXlvmdn.pgp Description: PGP signature
Re: temporarily modifying thread display in the index?
* Will Fiveash will.five...@oracle.com [2013-01-10 18:49 -0500]: What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? Hrm... have you tried a combination of 'tag-subthread' and 'limit'? Workflow would be something approximating the following. - Go to first message in subthread you want to see. - Execute tag-subthread. - Limit to pattern ~T. I just tried it on a subthread of this thread, and it worked, but I don't have another thread handy which is huge enough to give it a good workout. HTH, -- dave [ please don't CC me ] pgpCEpH9wYUcW.pgp Description: PGP signature
Re: temporarily modifying thread display in the index?
On Fri, Jan 11, 2013 at 12:12:01PM -0500, David J. Weller-Fahy wrote: * Will Fiveash will.five...@oracle.com [2013-01-10 18:49 -0500]: What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? Hrm... have you tried a combination of 'tag-subthread' and 'limit'? Workflow would be something approximating the following. - Go to first message in subthread you want to see. - Execute tag-subthread. - Limit to pattern ~T. I just tried it on a subthread of this thread, and it worked, but I don't have another thread handy which is huge enough to give it a good workout. That is close but not exactly what I'm looking for. The indentation level of the subtree parent is such with the thread I'm looking at that the thread display is still beyond the terminal window. It would be perfect if mutt could also reset the indent level of the subtree parent to 0. -- Will Fiveash
Re: temporarily modifying thread display in the index?
* Will Fiveash will.five...@oracle.com [2013-01-11 12:35 -0500]: On Fri, Jan 11, 2013 at 12:12:01PM -0500, David J. Weller-Fahy wrote: Hrm... have you tried a combination of 'tag-subthread' and 'limit'? That is close but not exactly what I'm looking for. The indentation level of the subtree parent is such with the thread I'm looking at that the thread display is still beyond the terminal window. It would be perfect if mutt could also reset the indent level of the subtree parent to 0. Yep, sorry about the red herring: I just checked on a huge thread in another list and it is as you say. It would be useful to have an option to reset the indent level. -- dave [ please don't CC me ] pgp93LFQyiQ0M.pgp Description: PGP signature
temporarily modifying thread display in the index?
Occasionally I'm involved in a very long e-mail thread such that the threading indicators are beyond the width of my terminal window. What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? If not, I'd like to see this feature added. -- Will Fiveash
Re: temporarily modifying thread display in the index?
* Will Fiveash on Thursday, January 10, 2013 at 17:47:21 -0600 Occasionally I'm involved in a very long e-mail thread such that the threading indicators are beyond the width of my terminal window. What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? If not, I'd like to see this feature added. Not what you want, but have you tried set narrow_tree -- _BAUSTELLEN_ lesen! --- http://www.blacktrash.org/baustellen
Re: temporarily modifying thread display in the index?
On Fri, Jan 11, 2013 at 12:13:06AM +, Christian Ebert wrote: set narrow_tree That is the only option that controls the width of the tree. The alternative would be some macros that to change $index_format to make the subject field wider.
Re: temporarily modifying thread display in the index?
On Thursday, 10 January 2013 at 17:47, Will Fiveash wrote: Occasionally I'm involved in a very long e-mail thread such that the threading indicators are beyond the width of my terminal window. What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? If not, I'd like to see this feature added. You could break the thread. I don't think we have a temp-break-thread command that doesn't write the changes back to the mailbox, but it might not be too hard to make. pgpuuN5RAz8Gb.pgp Description: PGP signature
Re: temporarily modifying thread display in the index?
On Thu, Jan 10, 2013 at 04:20:12PM -0800, Brendan Cully wrote: On Thursday, 10 January 2013 at 17:47, Will Fiveash wrote: Occasionally I'm involved in a very long e-mail thread such that the threading indicators are beyond the width of my terminal window. What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? If not, I'd like to see this feature added. You could break the thread. I don't think we have a temp-break-thread command that doesn't write the changes back to the mailbox, but it might not be too hard to make. I'd tried breaking the thread but with the threading options I'm using mutt automatically added the subtree to the existing main thread in a place that still hid the subtree thread display. 8^/ -- Will Fiveash Oracle Solaris Software Engineer Austin, TX, USA
Re: temporarily modifying thread display in the index?
On Fri, Jan 11, 2013 at 12:13:06AM +, Christian Ebert wrote: * Will Fiveash on Thursday, January 10, 2013 at 17:47:21 -0600 Occasionally I'm involved in a very long e-mail thread such that the threading indicators are beyond the width of my terminal window. What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? If not, I'd like to see this feature added. Not what you want, but have you tried set narrow_tree That helps, thanks. I'd still like to have an option to temporarily only display some subthread, hiding the rest of the thread so the subthread parent appears the be the parent for the whole thread. -- Will Fiveash Oracle Solaris Software Engineer Austin, TX, USA
Re: temporarily modifying thread display in the index?
On Thu, Jan 10, 2013 at 04:50:12PM -0800, Brendan Cully wrote: On Thursday, 10 January 2013 at 18:45, Will Fiveash wrote: On Thu, Jan 10, 2013 at 04:20:12PM -0800, Brendan Cully wrote: On Thursday, 10 January 2013 at 17:47, Will Fiveash wrote: Occasionally I'm involved in a very long e-mail thread such that the threading indicators are beyond the width of my terminal window. What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? If not, I'd like to see this feature added. You could break the thread. I don't think we have a temp-break-thread command that doesn't write the changes back to the mailbox, but it might not be too hard to make. I'd tried breaking the thread but with the threading options I'm using mutt automatically added the subtree to the existing main thread in a place that still hid the subtree thread display. 8^/ I guess you mean strict_threads=no. It seems like a bug to me that breaking threads doesn't break them in nonstrict mode too. Yes, I have strict_threads=no set in my .muttrc. Perhaps I will revisit that setting which I set years ago and have forgotten why (probably because some mail lists I follow have posts from broken MUAs). Perhaps it can set that to yes at this point? -- Will Fiveash Oracle Solaris Software Engineer Austin, TX, USA
Re: temporarily modifying thread display in the index?
On Thu, Jan 10, 2013 at 06:54:13PM -0600, Will Fiveash wrote: On Thu, Jan 10, 2013 at 04:50:12PM -0800, Brendan Cully wrote: On Thursday, 10 January 2013 at 18:45, Will Fiveash wrote: On Thu, Jan 10, 2013 at 04:20:12PM -0800, Brendan Cully wrote: On Thursday, 10 January 2013 at 17:47, Will Fiveash wrote: Occasionally I'm involved in a very long e-mail thread such that the threading indicators are beyond the width of my terminal window. What I'd like is a way to temporarily pull in a subthread so I can see the threading. To put it another way, make some message that's the parent of a subthread look like the parent of the entire thread causing mutt to hide the rest of the entire thread (if that makes sense). Can mutt do this? If not, I'd like to see this feature added. You could break the thread. I don't think we have a temp-break-thread command that doesn't write the changes back to the mailbox, but it might not be too hard to make. I'd tried breaking the thread but with the threading options I'm using mutt automatically added the subtree to the existing main thread in a place that still hid the subtree thread display. 8^/ I guess you mean strict_threads=no. It seems like a bug to me that breaking threads doesn't break them in nonstrict mode too. Yes, I have strict_threads=no set in my .muttrc. Perhaps I will revisit that setting which I set years ago and have forgotten why (probably because some mail lists I follow have posts from broken MUAs). Perhaps it can set that to yes at this point? BTW, I just tried setting strict_threads=yes and breaking the subthread and that was close to what I was looking for. If there could be a temp-break-thread command that could be undone when '$'yncing that would be nice. As it stands if I reply to or delete some of the messages in that broken subthread those changes will be lost because I have to quit mutt via 'x' which does not update the original mailbox. -- Will Fiveash
Re: Thread Display
On Mon, Sep 23, 2002 at 08:04:11PM -0400, PeterKorman wrote: Here are the gory details. Much of my communication is not through mailing lists. As a rule I don't go to a folder to exchange mail with a particular person. that's what I meant ... nearly nobody has one folder per person. I want to keep a record of everything I send. sure ... that's what I meant with: # default record location folder-hook . set record==sent So send gets its own folder. This is nonnegotiable. I want keep a record of everything I receive. I dont want to hand sort that stuff. that's what procmail/maildrop is for. (maildrop switches destination folders for me just fine, but that is not the kind of data I'm processing.) So all my non-newsgroup inbound goes to 1 folder. That is also non negotiable. well ... _everything_ not going to a mailing list goes to let's say =inbox ? This would simplyfy stuff a lot ... you'd need only _one_ further folder-hook: folder-hook =inbox set record==inbox so everything sent from within =inbox would be recorded to =inbox. And when replying to someone who sent a mail directly to you, it's unlikely you're in a mailinglist folder ... isn't it? -- Christian Ordig Germany
Re: Thread Display
On Tue, Sep 24, 2002 at 01:40:27PM +0200, Christian Ordig wrote: On Mon, Sep 23, 2002 at 08:04:11PM -0400, PeterKorman wrote: Here are the gory details. Much of my communication is not through mailing lists. As a rule I don't go to a folder to exchange mail with a particular person. that's what I meant ... nearly nobody has one folder per person. I want to keep a record of everything I send. sure ... that's what I meant with: # default record location folder-hook . set record==sent So send gets its own folder. This is nonnegotiable. I want keep a record of everything I receive. I dont want to hand sort that stuff. that's what procmail/maildrop is for. (maildrop switches destination folders for me just fine, but that is not the kind of data I'm processing.) So all my non-newsgroup inbound goes to 1 folder. That is also non negotiable. well ... _everything_ not going to a mailing list goes to let's say =inbox ? This would simplyfy stuff a lot ... you'd need only _one_ further folder-hook: folder-hook =inbox set record==inbox so everything sent from within =inbox would be recorded to =inbox. And when replying to someone who sent a mail directly to you, it's unlikely you're in a mailinglist folder ... isn't it? Cool! That means I can use: folder-hook =inbox set record==sent to record everything I sent. Then I can generate a unique link name via safecat and hardlink all unlinked messages in 'sent' to a link name in inbox. I could skip all the perl messageID scanning and maintain threads and a separate 'sent' record list on the fly. I like it. Thanks for the feedback. Regards, JPK -- []+ Wisdom is vindicated by all her children. +[] [] [] []+ GnuPG ECBA EA08 C3C1 251E 5FB5 D196 F8C8 F8B7 AB60 234D +[] msg31156/pgp0.pgp Description: PGP signature
Re: Thread Display
On Wed, Sep 18, 2002 at 03:48:39AM +0200, René Clerc wrote: * PeterKorman [EMAIL PROTECTED] [17-09-2002 19:21]: I think I can correctly interpret what you said in more than 1 way. So I wont try. given: 1)message to Sally 2)reply from Sally 3)reply to reply from Sally. fcc-hook will store _any_ message to Sally in the folder which you specify (probably sally). that's not really useful for conversations ... you'd need for everybody a new procmail rule ... and a fcc-hook ... and you'd end up with one folder per person ... If you configure procmail correctly, it can deliver every message _from_ Sally in that same folder. yes ... that is useful for people communicating with only 5-10 other guys ... I'd suggest the following: - sort incoming mail using procmail as you'd also do normally (everything coming to [EMAIL PROTECTED] goes to folder xyz and so on) - use folder-hooks for setting record to the same folder you're currently in - example: # default record location folder-hook . set record==sent # every mail sent from inside folder =xyz is saved to =xyz folder-hook =xyz set record==xyz - now when there comes a message to =xyz and you reply, your answer will also be stored to =xyz. Mails sent from any other folder, not having such a folder-hook are saved to =sent Any further suggestions? -- Christian Ordig Germany
Re: Thread Display
On Tue, Sep 24, 2002 at 12:42:17AM +0200, Christian Ordig wrote: On Wed, Sep 18, 2002 at 03:48:39AM +0200, René Clerc wrote: * PeterKorman [EMAIL PROTECTED] [17-09-2002 19:21]: I think I can correctly interpret what you said in more than 1 way. So I wont try. given: 1)message to Sally 2)reply from Sally 3)reply to reply from Sally. fcc-hook will store _any_ message to Sally in the folder which you specify (probably sally). that's not really useful for conversations ... you'd need for everybody a new procmail rule ... and a fcc-hook ... and you'd end up with one folder per person ... If you configure procmail correctly, it can deliver every message _from_ Sally in that same folder. yes ... that is useful for people communicating with only 5-10 other guys ... I'd suggest the following: - sort incoming mail using procmail as you'd also do normally (everything coming to [EMAIL PROTECTED] goes to folder xyz and so on) - use folder-hooks for setting record to the same folder you're currently in - example: # default record location folder-hook . set record==sent # every mail sent from inside folder =xyz is saved to =xyz folder-hook =xyz set record==xyz - now when there comes a message to =xyz and you reply, your answer will also be stored to =xyz. Mails sent from any other folder, not having such a folder-hook are saved to =sent Any further suggestions? Here is what I have: Mailing list are fine. Everything already goes out and comes in the mutt list folder via folder hooks my receive address: [EMAIL PROTECTED] the mutt mailing list sender: [EMAIL PROTECTED] I manage all my mailing lists the same way threading is terriffic. Here are the gory details. Much of my communication is not through mailing lists. As a rule I don't go to a folder to exchange mail with a particular person. I want to keep a record of everything I send. So send gets its own folder. This is nonnegotiable. I want keep a record of everything I receive. I dont want to hand sort that stuff. (maildrop switches destination folders for me just fine, but that is not the kind of data I'm processing.) So all my non-newsgroup inbound goes to 1 folder. That is also non negotiable. I haven't done it yet, but here's what I'm thinking: I'll use perl to scan my sent folder. I'll extract all of the message-ID(ish) headers into a hash whose index is the message-ID and whose data is a linked list of filenames. Now I'll scan my inbound folder for message-ID(ish) headers that match the ones in the hash I've generated (from the sent folder) and plug their filenames into the linked list data structure of the associated message-ID index. Finally, my perl hash will contain all filenames of associated with threads containing at least 2 messages, 1 of which was sent buy me. Now I create hard links to all those filenames in a third maildir directory called conversations. Am I making sense to anyone besides my self? Thanks. Regards, JPK -- []+ Wisdom is vindicated by all her children. +[] [] [] []+ GnuPG ECBA EA08 C3C1 251E 5FB5 D196 F8C8 F8B7 AB60 234D +[] msg31138/pgp0.pgp Description: PGP signature
Re: Thread Display
On Wed 18-Sep-2002 at 12:45:21AM -0400, PeterKorman wrote: I guess I need a kind of virtual folder that joins my outgoing and incoming without duplicating any data. That isn't possible with mutt I guess since I'm running on linux, with Maildir, I could brute force the solution by creating a hard link to all replies in my sent folder. Is there any caviat associated with something like this? I've done a bit of this (hardlinking files from two Maildir's into a third) without any problems - It seems to work quite well, very fast too. Though I'm not an expert on these things. -- Bruno
Thread Display
I'm set up with mutt to bcc all sent data to a local address that qmail puts in the proper Maildir subdirectory. Thatz fine for mailing list posts. But If I want to thread normal conversations, I can't see the whole converstion without bouncing between my sent directory and my inbox. I set this up before I knew about set record=~/Maildir/sent/ Is there a way to thread full (non news group) conversations without duplicating and maintaining 2 copies of every message I send? Thanks. JPK -- GnuPG: ECBA EA08 C3C1 251E 5FB5 D196 F8C8 F8B7 AB60 234D msg30975/pgp0.pgp Description: PGP signature
Re: Thread Display
Peter, please send your questions to [EMAIL PROTECTED]! * PeterKorman [EMAIL PROTECTED] [17-09-2002 18:21]: Is there a way to thread full (non news group) conversations without duplicating and maintaining 2 copies of every message I send? Thanks. I use procmail (which puts incoming mails in the correct folder) in combo with fcc-hooks (which put outgoing mails in the same folder) Is this what you meant? -- René Clerc - ([EMAIL PROTECTED]) We are not retreating - we are advancing in another direction. -General Douglas MacArthur msg30976/pgp0.pgp Description: PGP signature
Re: Thread Display
On Tue, Sep 17, 2002 at 06:43:56PM +0200, René Clerc wrote: Peter, please send your questions to [EMAIL PROTECTED]! Oops! * PeterKorman [EMAIL PROTECTED] [17-09-2002 18:21]: Is there a way to thread full (non news group) conversations without duplicating and maintaining 2 copies of every message I send? Thanks. I use procmail (which puts incoming mails in the correct folder) in combo with fcc-hooks (which put outgoing mails in the same folder) Is this what you meant? I think I can correctly interpret what you said in more than 1 way. So I wont try. given: 1)message to Sally 2)reply from Sally 3)reply to reply from Sally. My current method places messages 1 and 3 in my sent folder. Message 2 goes into my inbox. I could automatically put everything I send in both my inbox and my sent folder. That would solve the thread problem. But would duplicate each message I send to 2 places. I could automatically duplicate replies to my sent folder. That would also solve the Thread problem with a different duplication scenario. I guess I need a kind of virtual folder that joins my outgoing and incoming without duplicating any data. Does your fcc-hooks do that? Thanks. Regards, [JPK] -- GnuPG: ECBA EA08 C3C1 251E 5FB5 D196 F8C8 F8B7 AB60 234D msg30978/pgp0.pgp Description: PGP signature
Re: Thread Display
On Tue 17-Sep-2002 at 01:20:09 -0400, PeterKorman wrote: My current method places messages 1 and 3 in my sent folder. Message 2 goes into my inbox. I could automatically put everything I send in both my inbox and my sent folder. That would solve the thread problem. But would duplicate each message I send to 2 places. Personally, I have stopped using separate 'sent' and 'received' mailboxes. It is much more natural to group mail by context - ie. a separate mailbox for each job, project, relative etc.. I guess I need a kind of virtual folder that joins my outgoing and incoming without duplicating any data. That isn't possible with mutt (though I _almost_ got it working by misusing the compressed folders feature). -- Bruno
Re: Thread Display
* PeterKorman [EMAIL PROTECTED] [17-09-2002 19:21]: On Tue, Sep 17, 2002 at 06:43:56PM +0200, René Clerc wrote: I use procmail (which puts incoming mails in the correct folder) in combo with fcc-hooks (which put outgoing mails in the same folder) Is this what you meant? I think I can correctly interpret what you said in more than 1 way. So I wont try. given: 1)message to Sally 2)reply from Sally 3)reply to reply from Sally. My current method places messages 1 and 3 in my sent folder. Message 2 goes into my inbox. fcc-hook will store _any_ message to Sally in the folder which you specify (probably sally). If you configure procmail correctly, it can deliver every message _from_ Sally in that same folder. I guess I need a kind of virtual folder that joins my outgoing and incoming without duplicating any data. ? (is this what Bruno means?) Does your fcc-hooks do that? Thanks. I think so ;) Regards, [JPK] Dito, -- René Clerc - ([EMAIL PROTECTED]) A Smith and Wesson beats four aces. -Canada Bill Jones msg30995/pgp0.pgp Description: PGP signature
Re: Thread Display
On Tue, Sep 17, 2002 at 06:39:08PM +0100, Bruno Postle wrote: On Tue 17-Sep-2002 at 01:20:09 -0400, PeterKorman wrote: My current method places messages 1 and 3 in my sent folder. Message 2 goes into my inbox. I could automatically put everything I send in both my inbox and my sent folder. That would solve the thread problem. But would duplicate each message I send to 2 places. Personally, I have stopped using separate 'sent' and 'received' mailboxes. It is much more natural to group mail by context - ie. a separate mailbox for each job, project, relative etc.. I guess I need a kind of virtual folder that joins my outgoing and incoming without duplicating any data. That isn't possible with mutt (though I _almost_ got it working by misusing the compressed folders feature). -- Bruno I guess since I'm running on linux, with Maildir, I could brute force the solution by creating a hard link to all replies in my sent folder. Is there any caviat associated with something like this? Thanks. [JPK] -- GnuPG: ECBA EA08 C3C1 251E 5FB5 D196 F8C8 F8B7 AB60 234D msg31000/pgp0.pgp Description: PGP signature
