On Thu, 30 Jun 2011 13:04:23 +1000, Brian May <brian@microcomaustralia.com.au> wrote: > On 30 June 2011 08:40, Carl Worth <cworth@cworth.org> wrote: > > The 'a' keybinding, (in turn), was designed for cases when you *know* > > you don't want to read the rest of the thread. > > ... in which case it should also mark everything as read. IMHO. I know the current behavior only catches my opinion (and only an opinion I had at one particular point in time). So I won't say this is Right, but I will at least explain what I was thinking: The "unread" tag is distinct from the "inbox" tag. Why two tags? Don't they normally change at the same time? If a key like 'a' got rid of the "unread" tag as well as the "inbox" then there would be almost no need for having two tags. The idea I had is that "inbox" is fully under explicit control by the user. The user must make an intentional decision to "archive" a message in order for that tag to be removed. Distinct from that is "unread" which is handled automatically by the mail client (as well as it can tell what you've actually read or not). So this tag is removed only implicitly, (we don't have specific commands to manipulate the "unread" tag). When the client displays a message as the "current" message it immediately removes the "unread" tag. Whenever it displays a message to the user, (as the "current" message), it removes the unread tag from that message. This means that messages can lose the "unread" tag while still remaining tagged "inbox", (you read a message, but don't archive it), and that messages can lose the "archive" tag while still remaining tagged "unread", (you archive a thread before reading all messages in the thread). The distinction ends up being useful to me. If at some point someone points me to a specific message, and when I search for it I see the "unread" tag, then this highlights to me that I never even looked at the message. > Are there any keyboard bindings to go forwards to the next message or > backwards to the last message without marking anything as archived? As mentioned by someone else, you can navigate the messages in a thread with 'n' and 'p'. One of the obviously missing keybindings is a way to easily navigate From the current thread to the next thread without archiving the current thread. We should probably add that keybinding at some point, but I want to at least point out why I didn't create it originally: The lack of a "move to next thread" binding helps encourage me to form good habits. The goal I have when processing my inbox is to get everything *out* of my inbox. I can do that by deciding one of several common things: * I have nothing to do In this case I should just archive the message immediately * I can deal with this message "on the spot" (such as a quick reply) In this case, I should deal with the message, then archive it * I can't deal with this now, but need to later This is the key scenario. The wrong thing to do is to leave the message in my inbox, (that just makes things pile up and makes my future inbox processing slow, demotivating, and unreliable). The right thing to do is to tag this message in a way that I'm sure I'll find it again when I will be equipped to deal with it. And then I can archive the message. So the right answer always involves archiving the message nearly immediately, (at most after a quick reply or so), and the keybindings encourage archiving over leaving the message in the inbox. Of course, one does have an existing keybinding for "move to next message in thread without archiving"; it just consists of three key presses: 'q', 'n', Enter At that's long enough to discourage its frequent use. So that's a bit of my philosophy and methodology. But like I said, we should probably add the obviously missing keybindings so people with other philosophies and methodologies can use the program comfortably. > Also, just something I have noticed it isn't really obvious that a > thread has replies without scrolling down, and that takes time. Would > be really good if there could be some big/highlighted visual indicator > that there are still unread messages further down. That would be good, yes. -Carl -- carl.d.worth@intel.com