From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id C8917431FAF for ; Mon, 28 Jan 2013 07:13:33 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 wCkzBoGJO-Dn for ; Mon, 28 Jan 2013 07:13:33 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id C3DD8431FAE for ; Mon, 28 Jan 2013 07:13:32 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id j4so1402833bkw.17 for ; Mon, 28 Jan 2013 07:13:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:x-gm-message-state; bh=Zd8xAeNCq1DsVm+H8MPBCA1HQCjWmF9AF33ZVEdpQbk=; b=jBb9oQLYjn8hI4xYSrh0ZtYrg0CuICYpkryiPTBcxqJsyjkk2RjO0bT7CFdlvRcT9P niqnQyz+7zpJR91cxnhK+oVC98zPMHwSbt99NBqDT9hYmsVD744zGYGK5lnvFgM2JJ4n KBRYRzHL+QeBWSzhp6KAr4VxY5foGX+5csSajBK5paxljETN8AWI2EaR7yCJb3z6NYPt VAxReVDiwZW3qeTSfkyrLbaMMcusyTYJfZ/8fvjkIpwJm+8Z7rtCS+V+jCP3FW80raZb fUDXOVrmWKOvUKfq6qjvKmepcafXOlGny/SgBsBhRedfSXjKR38UWgSmPCIOJuVCTxjs mYKw== X-Received: by 10.204.13.25 with SMTP id z25mr505432bkz.114.1359386008694; Mon, 28 Jan 2013 07:13:28 -0800 (PST) Received: from localhost ([2001:4b98:dc0:43:216:3eff:fe1b:25f3]) by mx.google.com with ESMTPS id fs20sm4075475bkc.8.2013.01.28.07.13.26 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Mon, 28 Jan 2013 07:13:27 -0800 (PST) From: Jani Nikula To: Robert Mast , notmuch@notmuchmail.org Subject: Re: Reply all - issue In-Reply-To: <000001cdfcd9$82500f00$86f02d00$@nl> References: <000001cdfcd9$82500f00$86f02d00$@nl> User-Agent: Notmuch/0.14+259~gdee88db (http://notmuchmail.org) Emacs/23.2.1 (x86_64-pc-linux-gnu) Date: Mon, 28 Jan 2013 16:13:19 +0100 Message-ID: <87wquxjq7k.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Gm-Message-State: ALoCoQnuswafvHmLQkGJxLiy77Ick30gH97f9KxVgnporeWA6hQINQ1scazh6XbO3IW0ApuHXOWD 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: Mon, 28 Jan 2013 15:13:33 -0000 On Sun, 27 Jan 2013, Robert Mast wrote: > 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: Apparently all of them obey the RFC 2822 References: and In-Reply-To: headers for threading, and have no additional heuristics. I think it's a good thing, but YMMV. I think mutt supports manual breaking and joining of threads. The gmail web interface, OTOH, automatically breaks threads on Subject: changes too [1]. > 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. The term you're looking for is thread hijacking. One could argue the problem lies in the sender, not the recipient, and therefore should be fixed in the sender end. > 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. Doing something like this would break threading for emailed patch series [2], a very common practice in the open source world, including notmuch development [3]. Indeed, the way gmail breaks patch threads, but then joins different versions of the same patch email into new threads, is very annoying IMO. Also note that whatever you do, it should work the same way regardless of the order in which messages the thread are indexed. Regenerating the database should always end up in the same thread structure. > 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. The place you're looking for is probably _notmuch_database_link_message() in lib/database.cc. Patches, as they say, are welcome, but I believe for upstream notmuch inclusion you'd need to address the issues I pointed out above. HTH, Jani. [1] http://support.google.com/mail/bin/answer.py?hl=en&answer=5900 [2] http://git-scm.com/book/en/Distributed-Git-Contributing-to-a-Project#Public-Large-Project [3] http://notmuchmail.org/pipermail/notmuch/2013/thread.html