unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Jani Nikula <jani@nikula.org>
To: Mark Walters <markwalters1009@gmail.com>, notmuch@notmuchmail.org
Subject: Re: [PATCH WIP v2 0/5] emacs: show: redesign unread/read logic
Date: Wed, 04 Dec 2013 10:01:19 +0100	[thread overview]
Message-ID: <8761r5at28.fsf@nikula.org> (raw)
In-Reply-To: <1385892147-16994-1-git-send-email-markwalters1009@gmail.com>

On Sun, 01 Dec 2013, Mark Walters <markwalters1009@gmail.com> 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.

      parent reply	other threads:[~2013-12-04  9:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-01 10:02 [PATCH WIP v2 0/5] emacs: show: redesign unread/read logic Mark Walters
2013-12-01 10:02 ` [PATCH WIP v2 1/6] emacs: show: add a function to test for unread Mark Walters
2013-12-01 10:02 ` [PATCH WIP v2 2/6] emacs: show: add some seen helpers Mark Walters
2013-12-01 10:02 ` [PATCH WIP v2 3/6] emacs: show: sync seen to read on quit and refresh Mark Walters
2013-12-01 10:02 ` [PATCH WIP v2 4/6] emacs: show: use the `seen' interface Mark Walters
2013-12-01 10:02 ` [PATCH WIP v2 5/6] emacs: show: add an update seen function to post-command-hook Mark Walters
2013-12-01 10:02 ` [PATCH WIP v2 6/6] emacs: show: make `seen' mean user viewed whole message Mark Walters
2013-12-04  9:01 ` Jani Nikula [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8761r5at28.fsf@nikula.org \
    --to=jani@nikula.org \
    --cc=markwalters1009@gmail.com \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).