From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 428016DE01D8 for ; Sun, 28 Oct 2018 08:14:56 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: 0.149 X-Spam-Level: X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqRNjcPcHdAz for ; Sun, 28 Oct 2018 08:14:53 -0700 (PDT) Received: from smtp.gaspard.ninja (grym.ekleog.org [94.23.42.210]) by arlo.cworth.org (Postfix) with ESMTPS id 48EB86DE00EF for ; Sun, 28 Oct 2018 08:14:52 -0700 (PDT) Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id ca8bd073; Sun, 28 Oct 2018 15:14:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gaspard.ninja; h= from:to:subject:in-reply-to:references:date:message-id :mime-version:content-type; s=grym-20170528; bh=QWfagMWUM9mdayRl 2GLSQznRCF0=; b=A7eF4o5owGgiy6ppQtyUzMlx8cDWdV8pBKei1dIjPMYZBpBd qaKka+kWHeYKZYoKQp7kKcjgu9GtPYuTCHKohgAe+R5aW5xNZuFrMIL9/6xz/qmz hEKp6V4V8aOQzJ1LAHgdJqEL6GSKgN/8Nu/yySfyNbn1EvG40KRBGsDl1T4= Received: by smtp.gaspard.ninja (OpenSMTPD) with ESMTP id 5b245a3e; Sun, 28 Oct 2018 15:14:41 +0000 (UTC) Received: from localhost (llwynog [local]) by llwynog (OpenSMTPD) with ESMTPA id ed7b55df; Sun, 28 Oct 2018 15:14:39 +0000 (UTC) From: Leo Gaspard To: Gregor Zattler , notmuch@notmuchmail.org Subject: Re: Mail to self In-Reply-To: <87lg6icm5c.fsf@len.workgroup> References: <87y3ajboev.fsf@llwynog.ekleog.org> <87r2gbqhz8.fsf@tethera.net> <87va5ma5o7.fsf@llwynog.ekleog.org> <87lg6icm5c.fsf@len.workgroup> Date: Mon, 29 Oct 2018 00:14:39 +0900 Message-ID: <87k1m2umqo.fsf@llwynog.ekleog.org> MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Tue, 30 Oct 2018 09:09:17 -0700 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 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, 28 Oct 2018 15:14:56 -0000 Hi Gregor, Gregor Zattler writes: > For me, when I filtered emails in several folders and read them > with mutt (1) it was the other way around: I wished for the > possibility to mark them as read in all folders if read in one. This isn't incompatible, and I'm not wishing that notmuch stop marking as read per-message. However, I *am* wishing that when some other tool marked one of the message files as read and not the other, notmuch takes the safe route of marking the overall message as unread in its database. > But why would you tag a message (as opposed to a file) as > "unread" because it's a duplicate? Because usual folder-based applications display an unread marker with the number of unread messages near the folder, and this is a useless visual disturbance for the people for whom I administer the mail server. > If it's somehow important to you to know that a certain email > your read via notmuch is a duplicate, why not tag it as > "duplicate" instead? This is not a problem in notmuch (notmuch anyway just assumes that duplicates with the same Message-ID will never happen, which in my opinion is a bit optimistic, but I guess this design point is not going to change anyway and so am not going to argue further), but it is a problem with folder-based applications. When using a folder-based application, I don't want a Duplicates folder always popping up in my folder list with new messages until I read them, I want a Duplicates folder only to debug when things go weird and messages appear missing. > For the specific case of the duplicates folder: [...] Yes, now that I'm aware of this issue I can adapt my setup, likely by not indexing the duplicates folder indeed. However, I still think this is a big footgun, and take my missing 9 emails in the first 2 weeks of notmuch as proof of it. Just to repeat it at the end so my objective is clear: What I am wishing for is that when some tool outside of notmuch marked one of the message files as read and not the other, upon `synchronize_flags` notmuch takes the safe route of marking the overall message as unread in its database.