From a204a9ad984b7ac3b9cc5a04be491d3e8709a478 Mon Sep 17 00:00:00 2001 From: Robert Mast Date: Sun, 27 Jan 2013 22:58:58 +0100 Subject: [PATCH] Reply all - issue --- f6/e340e30039a95b7baf38c5dd06dddacb2293bb | 192 ++++++++++++++++++++++ 1 file changed, 192 insertions(+) create mode 100644 f6/e340e30039a95b7baf38c5dd06dddacb2293bb diff --git a/f6/e340e30039a95b7baf38c5dd06dddacb2293bb b/f6/e340e30039a95b7baf38c5dd06dddacb2293bb new file mode 100644 index 000000000..1524016b6 --- /dev/null +++ b/f6/e340e30039a95b7baf38c5dd06dddacb2293bb @@ -0,0 +1,192 @@ +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-- + -- 2.26.2