On Wed, May 07 2014, Mark Walters wrote: > A message is marked read if: > > 1) if you navigate to a message using n/p (next/prev open message) > > 2) if you navigate to it using N/P (next/prev message) regardless of > whether the message is open or closed. > > 3) if you go to it using n.s.next-matching-message (not bound by > default) whether message is open or closed. > > 4) when you enter a buffer and notmuch goes to the first open message. > > but not marked read in cases like: > > 1) opening a message > > 2) viewing or entering a message using other notmuch navigation such as > notmuch-show-advance and friends (bound to space) My experience is that this removes the 'unread' tag. > 3) viewing or entering a message using arrow keys, page-up page-down, > ctrl-v mouse clicks etc > > Personally, I think marking a closed message read is a bug, Agreed. > and not marking it read when opening it is too Agreed. > (at least in many cases). I would be happy with just these fixed (i.e. the current behaviour with those two bug fixes). My typical use is to move around a thread using Space, Backspace, n, p, N and P with RET, M-RET and C-u M-RET to manipulate open/closed state (i.e. not the normal emacs movement commands to move). > The other problem with the current approach (in my view) is that if > you try to use the navigation commands non-interactively then messages > end up being marked read, even if they are never displayed to the > user. In what cases does this happen? (Not arguing, just not fully understanding.) > Linking into the post-command-hook means that this should "just work". > > Questions: What does it mean for a message to be the current message? > Is it just point being in the message? This makes sense to me, other than perhaps "point being in an _open_ message". I don't want moving point through a closed message with C-n to remove the 'unread' tag. > Would you be happy with a message being marked read when point entered > the message? That could be done from the post-command-hook > infrastructure to fix some of the problems mentioned above. > > I think that is likely that people will disagree on how they want this > to work so I would like to try and make it customisable so I would > definitely be interested to see if I can get the behaviour you would > like from this infrastructure (or something similar). > > Best wishes > > Mark