From: Pieter Praet <pieter@praet.org>
To: Carl Worth <cworth@cworth.org>,
 Brian May <brian@microcomaustralia.com.au>,
	Notmuch Mail <notmuch@notmuchmail.org>
Subject: Re: Preventing the user shooting themself in the foot
In-Reply-To: <874o37513c.fsf@yoom.home.cworth.org>
References: <86iproe86u.fsf@greenrd.plus.com>
	<87fwms45xz.fsf@yoom.home.cworth.org>
	<BANLkTi=StMS67+UwQbm8cUH3yNr_ySrN5A@mail.gmail.com>
	<874o37513c.fsf@yoom.home.cworth.org>
User-Agent: Notmuch/0.5-303-g00a1bf6 (http://notmuchmail.org) Emacs/23.1.50.1
	(x86_64-pc-linux-gnu)
Date: Thu, 30 Jun 2011 09:45:52 +0200
Message-ID: <877h837oen.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth <cworth@cworth.org> wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> 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
Non-text part: application/pgp-signature
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

100% in agreement.


Besides 1: Keybinds are way too personal to be standardized upon.

This might be of interest to some:
  http://permalink.gmane.org/gmane.comp.misc.suckless/6495

Besides 2: Emacs allows to tailor *anything and everything* to
your needs, on the spot, in realtime (reflection and all that).


Peace

-- 
Pieter