Re: Emacs: how to remove "unread" tag while reading emails
authorJani Nikula <jani@nikula.org>
Sun, 6 Oct 2013 07:08:19 +0000 (10:08 +0300)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:57:16 +0000 (09:57 -0800)
91/376296696b895d30f04ec45110b1bfa4ecfc94 [new file with mode: 0644]

diff --git a/91/376296696b895d30f04ec45110b1bfa4ecfc94 b/91/376296696b895d30f04ec45110b1bfa4ecfc94
new file mode 100644 (file)
index 0000000..fa449e0
--- /dev/null
@@ -0,0 +1,161 @@
+Return-Path: <jani@nikula.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 451E3431FBD\r
+       for <notmuch@notmuchmail.org>; Sun,  6 Oct 2013 00:08:27 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id nZMBAZflXteQ for <notmuch@notmuchmail.org>;\r
+       Sun,  6 Oct 2013 00:08:21 -0700 (PDT)\r
+Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com\r
+       [209.85.215.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 14E05431FAF\r
+       for <notmuch@notmuchmail.org>; Sun,  6 Oct 2013 00:08:20 -0700 (PDT)\r
+Received: by mail-ea0-f174.google.com with SMTP id z15so2581990ead.33\r
+       for <notmuch@notmuchmail.org>; Sun, 06 Oct 2013 00:08:18 -0700 (PDT)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+       d=1e100.net; s=20130820;\r
+       h=x-gm-message-state:from:to:cc:subject:in-reply-to:references\r
+       :user-agent:date:message-id:mime-version:content-type;\r
+       bh=WqJBpno6Xl+2i9E/107mUwDno8J69UkXBvKq3AGss3E=;\r
+       b=Seh6qyKg0hDaEydTrcHjwPZ+KNqj0q0XPAYpwXYcRElXks3Lq4jc4/91oTKxYgUNqc\r
+       PwqoJ0dwvyN4wdJsmQ2fsNCdl+R2G5uQVpZ9wWxWeCEkUS3YPSbfx428ZPGYMzytmqih\r
+       b0q0rm6E7VKFTGFaALF7MLfMzNp3SQAFZwh0BLcbpe2ocH4DcckxGGokaTqFfsvQHPch\r
+       MnN5XwhmvkpFaiE7SsREEPHd6iRoRXha8OdZy2kuIcDQoCdn8bHdU1+Kg8+oPWSu7TGI\r
+       42iZwmZIKFgVjJwBj/tFjPanySOJLBoZb70ErnxB06ff9jczNWr3HuzxOeIZPUsv6Hx1\r
+       IAUw==\r
+X-Gm-Message-State:\r
+ ALoCoQnnFJrX/lre20CMvOuwhkCeP2he+eAe0SvoRBbW4EpnVGsH9ehILlkrR2CPWZXL/80a/yJp\r
+X-Received: by 10.14.174.131 with SMTP id x3mr144592eel.61.1381043298442;\r
+       Sun, 06 Oct 2013 00:08:18 -0700 (PDT)\r
+Received: from localhost (dsl-hkibrasgw2-58c36f-91.dhcp.inet.fi.\r
+       [88.195.111.91])\r
+       by mx.google.com with ESMTPSA id m54sm48094546eex.2.1969.12.31.16.00.00\r
+       (version=TLSv1.2 cipher=RC4-SHA bits=128/128);\r
+       Sun, 06 Oct 2013 00:08:17 -0700 (PDT)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: Austin Clements <amdragon@MIT.EDU>,\r
+       Mark Walters <markwalters1009@gmail.com>\r
+Subject: Re: Emacs: how to remove "unread" tag while reading emails\r
+In-Reply-To: <20131005162202.GJ21611@mit.edu>\r
+References: <87hadi0xse.fsf@boo.workgroup> <87pprk3whs.fsf@qmul.ac.uk>\r
+       <20131005162202.GJ21611@mit.edu>\r
+User-Agent: Notmuch/0.16+88~g563143a (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Sun, 06 Oct 2013 10:08:19 +0300\r
+Message-ID: <87vc1aho64.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sun, 06 Oct 2013 07:08:27 -0000\r
+\r
+On Sat, 05 Oct 2013, Austin Clements <amdragon@MIT.EDU> wrote:\r
+> One of the problems with the current approach, which most of these\r
+> options share, is that there's no feedback.  For example, when I enter\r
+> a thread, I have no idea if the first message was unread or not.\r
+\r
+Agreed. And this gets repeated for navigating messages within the\r
+thread. Very annoying. This should be fixed.\r
+\r
+Two other things I find annoying:\r
+\r
+* I often find myself glancing at the first few lines of the message to\r
+  decide whether I want to read it now or later (potentially never). I\r
+  still want the unread information be retained if I decide to archive\r
+  or move on to the next thread, so I often end up restoring the unread\r
+  tag. So the marking as read is too eager.\r
+\r
+* I sometimes use the arrow keys and page down/up to read through\r
+  messages, and this leaves messages unread even though I've read\r
+  them. So the marking as read is not eager enough.\r
+\r
+> I'd like a solution that either naturally doesn't have this problem,\r
+> that visually indicates that a message *was* unread, or that delays\r
+> all unread marking until you leave the thread (possibly combined with\r
+> a visual indication of what will be marked unread).  Bonus points if\r
+> it's easy to adjust what happens, such as saying "keep everything\r
+> unread" or "keep everything unread except this one".\r
+\r
+I'd like to have the visual indication.\r
+\r
+> To this end, here are my two proposals:\r
+>\r
+> A1) Mark whole thread read when you leave it (via q, X, A or friends)\r
+> and provide a binding to leave a thread without marking it read (C-x k\r
+> would do, but we should provide an explicit one; perhaps C-u prefixing\r
+> other "leave" bindings?  For once, C-u is easy to remember because u\r
+> is the first letter of unread).\r
+\r
+I think I'd like to keep this message based instead of thread\r
+based. However it's very difficult to know for sure until one actually\r
+gets to try it.\r
+\r
+I do switch between show buffers (for example, while reading a message,\r
+I need to check something from another message) and the marking as read\r
+might get lost. Also, it's not clear to me what happens if you refresh\r
+the buffer and new messages show up in the thread. Again, difficult to\r
+know in advance.\r
+\r
+\r
+My message based proposal:\r
+\r
+Don't do anything when you enter a message. This keeps the unread tag\r
+visible if it's there.\r
+\r
+Mark each message as read on actions you do when the point already is\r
+within the message: n/N/p/P/SPC/a/x/A/X/q/r/R/f (others?), arrow keys,\r
+and page up/down, *unless* the action is prefixed with C-u.\r
+\r
+Collapsed messages would never be marked as read. RET to expand would\r
+mark as read.\r
+\r
+This still does not provide visual indication of the removal of the\r
+unread tag in a way that would be always visible. But I think it's more\r
+important to know whether the message *was* unread before or not.\r
+\r
+\r
+Here's a proposal independent of the marking-as-read topic that would\r
+help with the visual indication:\r
+\r
+We currently set header-line-format (the top header in show view) to the\r
+subject of the first message. The usefulness of the header line could be\r
+improved a lot. We could make it reflect the message the point is\r
+currently on, with user configurable format not unlike\r
+notmuch-search-result-format. Including tags. And this would provide\r
+visual indication for marking as read when the message header is not\r
+visible. The header would also help in navigating long threads with long\r
+messages.\r
+\r
+> In either case, I'd like an echo message when I leave the thread\r
+> telling me what happened ("Thread marked as read", "First 3 messages\r
+> marked as read; thread archived", etc.).  These would blend especially\r
+> well with undo, because they would bundle together all read marking\r
+> into a single action that would make sense to undo ("Thread marked as\r
+> read [C-/ to undo]").\r
+\r
+This might be useful with the message based approach, although it might\r
+be too verbose, and a new annoyance...\r
+\r
+\r
+BR,\r
+Jani.\r