unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
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
Date: Thu, 30 Jun 2011 09:45:52 +0200	[thread overview]
Message-ID: <877h837oen.fsf@praet.org> (raw)
In-Reply-To: <874o37513c.fsf@yoom.home.cworth.org>

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

  reply	other threads:[~2011-06-30  7:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-29 19:42 Preventing the user shooting themself in the foot Robin Green
2011-06-29 20:37 ` Jameson Graef Rollins
2011-06-29 22:40 ` Carl Worth
2011-06-30  3:04   ` Brian May
2011-06-30  4:10     ` Jameson Graef Rollins
2011-06-30  5:40     ` Carl Worth
2011-06-30  7:45       ` Pieter Praet [this message]
2011-06-30 21:26       ` Michael Hudson-Doyle
2011-07-01 16:37         ` Jameson Graef Rollins
2011-07-01 17:17           ` Austin Clements
2011-07-01 17:11         ` Pieter Praet
2011-06-30 23:02       ` Stewart Smith
2011-06-30  6:29   ` Sebastian Spaeth
2011-07-04 20:09     ` Michal Sojka
2011-07-04 21:36 ` Dangerous space bar key (was: Preventing the user shooting themself in the foot) Matthieu Lemerre
2011-07-05  0:03   ` Jameson Graef Rollins
2011-07-05 20:23     ` Matthieu Lemerre
2011-07-06 13:25       ` Austin Clements
2011-07-07 18:49         ` Matthieu Lemerre
2011-07-07 20:40           ` Jameson Graef Rollins
2011-07-07 20:58             ` Austin Clements
2011-07-07 21:17               ` Jameson Graef Rollins
2011-07-09 17:09 ` Preventing the user shooting themself in the foot Neeum Zawan
2011-07-09 20:32   ` Daniel Schoepe
  -- strict thread matches above, loose matches on Subject: below --
2011-06-29 23:53 Austin Clements
2011-06-30  7:50 ` Pieter Praet
2011-06-30  8:51   ` Pieter Praet
2011-07-01  1:28   ` Brian May
2011-07-01 21:44     ` Pieter Praet

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=877h837oen.fsf@praet.org \
    --to=pieter@praet.org \
    --cc=brian@microcomaustralia.com.au \
    --cc=cworth@cworth.org \
    --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).