Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 82F04431FAF for ; Sun, 27 Jan 2013 14:05:57 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY-rABGG9T2R for ; Sun, 27 Jan 2013 14:05:53 -0800 (PST) X-Greylist: delayed 402 seconds by postgrey-1.32 at olra; Sun, 27 Jan 2013 14:05:53 PST Received: from srv047132.webreus.nl (srv047132.webreus.nl [46.235.47.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 7490D431FAE for ; Sun, 27 Jan 2013 14:05:53 -0800 (PST) Received: (qmail 23786 invoked from network); 27 Jan 2013 22:59:09 +0100 Received: from ip73-109-210-87.adsl2.static.versatel.nl (HELO PCvangebruike) (87.210.109.73) by srv047132.webreus.nl with SMTP; 27 Jan 2013 22:59:07 +0100 From: "Robert Mast" To: Subject: Reply all - issue Date: Sun, 27 Jan 2013 22:58:58 +0100 Message-ID: <000001cdfcd9$82500f00$86f02d00$@nl> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CDFCE1.E4147700" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac382YIPcFbBRELZQDerBAwMXRgaKA== Content-Language: nl X-Mailman-Approved-At: Sun, 27 Jan 2013 23:36:54 -0800 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 22:05:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CDFCE1.E4147700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Last week I studied many Windows-Mail User Agents with the conversation threading feature. None of them (SUP, mutt-kz(notmuch), Outlook 2010, Thunderbird with conversation thread plug in, Postbox, Evolution) could cope with the following case: In our e-mail-discussions people often choose 'reply-all' to construct a new message with the same reciepients. They clear the body and the subject, but the hidden References: and In-reply-To: stay and should be cleared as well. Result is that this new subject drowns in an old conversation-thread-drilldown and this unpredictable behavior makes conversation threading useless. This weekend I went analyzing the notmuch-source to find where I could put a fix best. I think of a fix that indexes the first dates of (stripped) subject-changes within threads, and with each first (stripped) subject change check the body on quotes of previous messages. If there is no quote to referenced mails then drop the reference and assign a new thread_id_ to the (stripped) subject. After two days of studying I think the best place with the least interference with existing code is between 'notmuch new' and starting the MUA. Then the threads are in place in XAPIAN, and new thread_id_'s can be inserted. Am I right? ------=_NextPart_000_0001_01CDFCE1.E4147700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Last week I studied many Windows-Mail User Agents with the = conversation threading feature.

None of them (SUP, = mutt-kz(notmuch), Outlook 2010, Thunderbird with conversation thread = plug in, Postbox, Evolution) could cope with the following = case:

 

In our e-mail-discussions people often choose = ‘reply-all’ to construct a new message with the same = reciepients.

They clear the body and the subject, but the hidden = References: and In-reply-To: stay and should be cleared as = well.

Result is that this new subject drowns in an old = conversation-thread-drilldown and this unpredictable behavior makes = conversation threading useless.

This weekend I went analyzing the = notmuch-source to find where I could put a fix = best.

 

I think of a fix that indexes the first dates of (stripped) = subject-changes within threads, and with each first (stripped) subject = change check the body on quotes of previous messages. If there is no = quote to referenced mails then drop the reference and assign a new = thread_id_ to the (stripped) subject.

 

After two days of studying I think = the best place with the least interference with existing code is between = ‘notmuch new’ and starting the MUA. Then the threads are in = place in XAPIAN, and new thread_id_’s can be = inserted.

 

Am I right?

 

------=_NextPart_000_0001_01CDFCE1.E4147700--