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 95760431FAF for ; Wed, 4 Dec 2013 01:01:44 -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 FCSty5ggHqUt for ; Wed, 4 Dec 2013 01:01:39 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id C5F9E431FAE for ; Wed, 4 Dec 2013 01:01:39 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id i17so3268342qcy.9 for ; Wed, 04 Dec 2013 01:01:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-type; bh=CpAhOFE6pk8oVkUU2EoeHeschw9EP0Pt+vGdA7dmZ60=; b=G/cbwPnX8tEV0QjAhhNNj8o8r9p5WCt/0fdluQ36FjlL3wk/rPP1biuRrerydBJbWR Jfg4Z8uSABKMnjg6lHAxwysqpMz5VufH0g/FfHmQbz4tr5joCofNJBAA5LSoDftNNtRf c1ijefOBlgLdu5a22aPgORDvLXgZC+SLGczItNe8zIfZQPa8zCmDMFUEf+z07GmjSFK2 a0CGOnhsZ1y34onmvOfTwO7gYYFYcj9XKjOD9gtIBK/qBYrOG4MGfvp7q4n83kPctyEr HiWTU2QGi7/Yxy+m01f0tqAcmeYLAVU6x6OWxY/EUTwDliKq02hzjEujqP8H5Ha4L6XD Ozrw== X-Gm-Message-State: ALoCoQl9WbyB+tzXhBYz5snfTGpSkGwezFQqzlcE2tyJ2oM2dWuLhXifYlFgheP45aqDOYJkJlGt X-Received: by 10.224.127.74 with SMTP id f10mr98428359qas.56.1386147698116; Wed, 04 Dec 2013 01:01:38 -0800 (PST) Received: from localhost ([2001:4b98:dc0:43:216:3eff:fe1b:25f3]) by mx.google.com with ESMTPSA id hb2sm15867812qeb.6.2013.12.04.01.01.37 for (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Wed, 04 Dec 2013 01:01:37 -0800 (PST) From: Jani Nikula To: Mark Walters , notmuch@notmuchmail.org Subject: Re: [PATCH WIP v2 0/5] emacs: show: redesign unread/read logic In-Reply-To: <1385892147-16994-1-git-send-email-markwalters1009@gmail.com> References: <1385892147-16994-1-git-send-email-markwalters1009@gmail.com> User-Agent: Notmuch/0.17~rc2+4~gd7b0a0a (http://notmuchmail.org) Emacs/23.2.1 (x86_64-pc-linux-gnu) Date: Wed, 04 Dec 2013 10:01:19 +0100 Message-ID: <8761r5at28.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 04 Dec 2013 09:01:44 -0000 On Sun, 01 Dec 2013, Mark Walters wrote: > This is further wip of the message at > id:1385285551-5158-1-git-send-email-markwalters1009@gmail.com > see there for some discussion of the design. > > This series is still definitely wip: one reason for posting is so > people can play with different strategies for marking read > easily. (As WIP tree's unread handling is broken and the tests need updating.) > > The series consists of three parts: the first 4 patches add the notion > of seen: this means the user has seen the message but the message has > typically not been marked read yet. The seen messages are marked read > when the user quits the show buffer unless the user quits with > prefix-arg quit. In all cases an informative message is shown. > > The fifth patch adds a psot-command-hook stub for updating the seen > status. This seems a natural place to do the update as it means > however the user navugates around the buffer (eg next-message or > page-down etc) the update gets done. > > This is intended to be an easy place for other people to try out their > own mark read strategies. > > The final patch implements something pretty close to what I would like > for marking seen/read. A message is deemed seen provided the user has > seen the top of the message, and has seen either the bottom of the > message or a point at least some customisable number of lines into the > message. The customisable number of lines can either be a fixed number > e.g. 20, or a number depending on the height of the current window > e.g. the default is 3/4 of the window height. > > The idea is a message seen if the user has seen the entire message, or > enough of it they have to have noticed it. The figure of 3/4 also > means that the notmuch commands like next-message which place the top > of the message at the top of the window automatically mark the message > seen as either the whole message or at least one window full must be > visible. > > I would be very grateful for any comments on whether this behaves as > people would expect, what they would want instead etc Hi Mark, thanks for working on this. I had tons of mail reading to catch up, so this was a good opportunity to try the patches. I'll try to be objective and constructive next, but up front, just so there's no doubt: I don't like it. I think my issues boil down to the series containing two pretty significant changes at once: how to decide if a message was read and when to apply the tag changes to reflect that. I found it confusing that messages were not being tagged -unread while I was viewing the thread. I found it even more confusing to get a message "Marked N messages read" on quitting show view with no feedback on *which* messages were read, and often the N didn't feel right either. And I think that's the problem: I wanted to see the new heuristics on deciding whether a message was read in action, but I got zero immediate feedback on it! My suggestion is to drop the delay in tag changes for now, and focus on the part that decides whether a message was read or not. Do the tag changes immediately when you consider a message "seen". I think this way we get a better feel of how well the heuristics really work, and we can make it just right. I think that's the bug in we currently have in notmuch, and delaying the tag changes doesn't contribute to fixing it. Indeed I think the delay makes it *harder* to fix. Afterwards, we could add the delayed tag changes (although hopefully as an option) if desired. And keeping that in mind, AFAICT you wouldn't need to rework your patches all that much. How does that sound? BR, Jani.