unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: Jani Nikula <jani@nikula.org>
To: Austin Clements <amdragon@MIT.EDU>,
	Mark Walters <markwalters1009@gmail.com>
Cc: notmuch@notmuchmail.org
Subject: Re: Emacs: how to remove "unread" tag while reading emails
Date: Sun, 06 Oct 2013 10:08:19 +0300	[thread overview]
Message-ID: <87vc1aho64.fsf@nikula.org> (raw)
In-Reply-To: <20131005162202.GJ21611@mit.edu>

On Sat, 05 Oct 2013, Austin Clements <amdragon@MIT.EDU> wrote:
> One of the problems with the current approach, which most of these
> options share, is that there's no feedback.  For example, when I enter
> a thread, I have no idea if the first message was unread or not.

Agreed. And this gets repeated for navigating messages within the
thread. Very annoying. This should be fixed.

Two other things I find annoying:

* I often find myself glancing at the first few lines of the message to
  decide whether I want to read it now or later (potentially never). I
  still want the unread information be retained if I decide to archive
  or move on to the next thread, so I often end up restoring the unread
  tag. So the marking as read is too eager.

* I sometimes use the arrow keys and page down/up to read through
  messages, and this leaves messages unread even though I've read
  them. So the marking as read is not eager enough.

> I'd like a solution that either naturally doesn't have this problem,
> that visually indicates that a message *was* unread, or that delays
> all unread marking until you leave the thread (possibly combined with
> a visual indication of what will be marked unread).  Bonus points if
> it's easy to adjust what happens, such as saying "keep everything
> unread" or "keep everything unread except this one".

I'd like to have the visual indication.

> To this end, here are my two proposals:
>
> A1) Mark whole thread read when you leave it (via q, X, A or friends)
> and provide a binding to leave a thread without marking it read (C-x k
> would do, but we should provide an explicit one; perhaps C-u prefixing
> other "leave" bindings?  For once, C-u is easy to remember because u
> is the first letter of unread).

I think I'd like to keep this message based instead of thread
based. However it's very difficult to know for sure until one actually
gets to try it.

I do switch between show buffers (for example, while reading a message,
I need to check something from another message) and the marking as read
might get lost. Also, it's not clear to me what happens if you refresh
the buffer and new messages show up in the thread. Again, difficult to
know in advance.


My message based proposal:

Don't do anything when you enter a message. This keeps the unread tag
visible if it's there.

Mark each message as read on actions you do when the point already is
within the message: n/N/p/P/SPC/a/x/A/X/q/r/R/f (others?), arrow keys,
and page up/down, *unless* the action is prefixed with C-u.

Collapsed messages would never be marked as read. RET to expand would
mark as read.

This still does not provide visual indication of the removal of the
unread tag in a way that would be always visible. But I think it's more
important to know whether the message *was* unread before or not.


Here's a proposal independent of the marking-as-read topic that would
help with the visual indication:

We currently set header-line-format (the top header in show view) to the
subject of the first message. The usefulness of the header line could be
improved a lot. We could make it reflect the message the point is
currently on, with user configurable format not unlike
notmuch-search-result-format. Including tags. And this would provide
visual indication for marking as read when the message header is not
visible. The header would also help in navigating long threads with long
messages.

> In either case, I'd like an echo message when I leave the thread
> telling me what happened ("Thread marked as read", "First 3 messages
> marked as read; thread archived", etc.).  These would blend especially
> well with undo, because they would bundle together all read marking
> into a single action that would make sense to undo ("Thread marked as
> read [C-/ to undo]").

This might be useful with the message based approach, although it might
be too verbose, and a new annoyance...


BR,
Jani.

      parent reply	other threads:[~2013-10-06  7:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-18 18:50 Emacs: how to remove "unread" tag while reading emails Gregor Zattler
2013-10-04 10:51 ` Jonas Hörsch
2013-10-05  9:19 ` Mark Walters
2013-10-05 16:22   ` Austin Clements
2013-10-05 16:56     ` Mark Walters
2013-10-06  7:08     ` 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=87vc1aho64.fsf@nikula.org \
    --to=jani@nikula.org \
    --cc=amdragon@MIT.EDU \
    --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).