[Patch v3 0/3] emacs: show: redesign unread/read logic

[Mark Walters]

On Wed, 07 May 2014, David Edmondson <dme at dme.org> wrote:
> On Tue, Mar 25 2014, Mark Walters wrote:
>> The third patch adds my attempt at a plausible logic. I find it works
>> very well: it usually does both what I expect and what I want.
>
> Whilst I think that the patch is well done, I don't like the resulting
> behaviour. That is a personal preference, of course. At the moment it
> doesn't seem that there is a way to accept this patch and (optionally)
> retain the existing behaviour. Do you have any thoughts on how we might
> achieve that?

Thanks for looking and for the feedback. I should emphasise to everyone
that I would like all feedback whether positive or negative!

> I don't have a strong preference for the default behaviour, though I
> suspect that something closer to the current behaviour (where a message
> is marked seen when it becomes the current message[1]) would better
> match user expectation (but this is an opinion, not something founded in
> fact).

Just for the record I will detail what happens currently and then I have
a couple questions about your suggestion.

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)

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, and not
marking it read when opening it is too (at least in many cases).  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. 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? 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