Re: Preventing the user shooting themself in the foot

Re: Preventing the user shooting themself in the foot

[Austin Clements]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

I've spent embarrassingly little time in the emacs UI, so my opinions on
this should be taken lightly, but I feel like all of the bindings are of the
form "if W, do X and Y, otherwise do Z" and, as a result, I'm actively
afraid of what's going to happen when I hit a key. I would much prefer
bindings with simple, highly predictable behavior. I'm sure there's some
workflow for which these contextual, compound bindings are fantastic, but
other workflows wind up fighting against them.

I don't have a specific proposal in mind, but Gmail's bindings seem like a
good model to emulate (the actions, at least; I've never been too fond of
the specific key choices).
On Jun 29, 2011 6:40 PM, "Carl Worth" <cworth@cworth.org> wrote:

[-- Attachment #2: Type: text/html, Size: 897 bytes --]

Re: Preventing the user shooting themself in the foot

[Pieter Praet]

On Wed, 29 Jun 2011 19:53:03 -0400, Austin Clements <amdragon@mit.edu> wrote:
Non-text part: multipart/mixed
Non-text part: multipart/alternative
> I've spent embarrassingly little time in the emacs UI, so my opinions on
> this should be taken lightly, but I feel like all of the bindings are of the
> form "if W, do X and Y, otherwise do Z" and, as a result, I'm actively
> afraid of what's going to happen when I hit a key. I would much prefer
> bindings with simple, highly predictable behavior. I'm sure there's some
> workflow for which these contextual, compound bindings are fantastic, but
> other workflows wind up fighting against them.

Very true!

> I don't have a specific proposal in mind, but Gmail's bindings seem like a
> good model to emulate (the actions, at least; I've never been too fond of
> the specific key choices).

+1

And AFAIK, "Archive" does *not* mark a message as read in GMail.
(see previous messages suggesting the inverse)

> On Jun 29, 2011 6:40 PM, "Carl Worth" <cworth@cworth.org> wrote:
Non-text part: text/html
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

Re: Preventing the user shooting themself in the foot

[Pieter Praet]

On Thu, 30 Jun 2011 09:50:27 +0200, Pieter Praet <pieter@praet.org> wrote:
> [...]
> And AFAIK, "Archive" does *not* mark a message as read in GMail.
> (see previous messages suggesting the inverse [...]
... be implemented in Notmuch.

> [...] )

Nobody claimed the inverse was the case in GMail, so I created the wrong
impression. I should've picked my words more carefully.


Peace

-- 
Pieter

Re: Preventing the user shooting themself in the foot

[Brian May]

On 30 June 2011 17:50, Pieter Praet <pieter@praet.org> wrote:
> And AFAIK, "Archive" does *not* mark a message as read in GMail.
> (see previous messages suggesting the inverse)

gmail will mark all messages in the thread as read when looking at any
part of the thread - so in practical terms whenever I click "Archive"
the entire thread is marked as read - as I always click archive in the
message view.

Not absolutely convinced this is the best approach. I think it is
important to appreciate the differences that different implementations
have chosen.
-- 
Brian May <brian@microcomaustralia.com.au>

Re: Preventing the user shooting themself in the foot

[Pieter Praet]

On Fri, 1 Jul 2011 11:28:10 +1000, Brian May <brian@microcomaustralia.com.au> wrote:
> On 30 June 2011 17:50, Pieter Praet <pieter@praet.org> wrote:
> > And AFAIK, "Archive" does *not* mark a message as read in GMail.
> > (see previous messages suggesting the inverse)
> 
> gmail will mark all messages in the thread as read when looking at any
> part of the thread - so in practical terms whenever I click "Archive"
> the entire thread is marked as read - as I always click archive in the
> message view.
> 
> Not absolutely convinced this is the best approach. I think it is
> important to appreciate the differences that different implementations
> have chosen.

I was thinking more along the lines of archiving a message from the
Inbox (or similar) view, in which the 'unread' state does remain
preserved.

Marking all messages as read as soon as the thread is opened is a
separate issue (and *far* from sensible), but this heavy-handed approach
is probably a necessity (as opposed to being a deliberate choice) due to
the limitations of its current interface, which Notmuch thankfully
doesn't share.

> -- 
> Brian May <brian@microcomaustralia.com.au>
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Peace

-- 
Pieter

Preventing the user shooting themself in the foot

[Robin Green]

It's really dangerous to use the 'a' key in notmuch-mode in an inbox
thread which has multiple unread replies! Yes, the other unread replies
will still be tagged unread, but the user might not immediately be aware
of them. It would be really useful to have an optional warning ("More
unread messages in this thread, are you sure?") for this situation!

Re: Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 1941 bytes --]

On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green <greenrd@greenrd.org> wrote:
> It's really dangerous to use the 'a' key in notmuch-mode in an inbox
> thread which has multiple unread replies! Yes, the other unread replies
> will still be tagged unread, but the user might not immediately be aware
> of them. It would be really useful to have an optional warning ("More
> unread messages in this thread, are you sure?") for this situation!

I think that's a bit extreme, but I agree that the default behavior of
the emacs key bindings are not good, particularly in regards to
archiving messages.

I should probably just send in all of my emacs UI tweaks as patches, but
here are a couple of functions/bindings I've added to my .emacs to make
the message processing more sane.  The main new function is
notmuch-show-next-open-message-or-pop, which will jump to the next
message in the thread, or pop out of the thread if you're on the last
message.  I then use this in my tag processing functions, such as
archiving and deleting.

hth.

jamie.


(defun notmuch-show-next-open-message-or-pop ()
  "Show the next message or pop to parent search."
  (interactive)
  (let (r)
    (while (and (setq r (notmuch-show-goto-message-next))
		(not (notmuch-show-message-visible-p))))
    (if r
	(progn
	  (notmuch-show-mark-read)
	  (notmuch-show-message-adjust))
      (let ((parent-buffer notmuch-show-parent-buffer))
	(if parent-buffer
	    (progn
	      (kill-this-buffer)
	      (switch-to-buffer parent-buffer)
	      (forward-line 1)))))))

(define-key notmuch-show-mode-map "a"
  (lambda ()
    "Archive current message and advance."
    (interactive)
    (notmuch-show-remove-tag "inbox")
    (notmuch-show-next-open-message-or-pop)))

(define-key notmuch-show-mode-map "d"
  (lambda ()
    "Delete current message and advance to next message."
    (interactive)
    (notmuch-show-add-tag "delete")
    (notmuch-show-next-open-message-or-pop)))

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preventing the user shooting themself in the foot

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green <greenrd@greenrd.org> wrote:
> It's really dangerous to use the 'a' key in notmuch-mode in an inbox
> thread which has multiple unread replies! Yes, the other unread replies
> will still be tagged unread, but the user might not immediately be aware
> of them. It would be really useful to have an optional warning ("More
> unread messages in this thread, are you sure?") for this situation!

That was why I originally designed the space bar keybinding for reading
through each message in turn, (and then it archives the thread only when you
page past the last message).

The 'a' keybinding, (in turn), was designed for cases when you *know*
you don't want to read the rest of the thread.

That was the original idea behind these two, at least.  In any case,
it's doing exactly what it's defined to do.

Perhaps you're just missing a key for archiving the current message (and
advancing to the next)?

I know there are various problems with the current keybindings—and
several obviously-missing operations. And it's funny how long I've put
up with shortcomings rather than just fixing them.

I'll be glad to look at proposals for improving things.

-Carl

-- 
carl.d.worth@intel.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Preventing the user shooting themself in the foot

[Brian May]

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.

Are there any keyboard bindings to go forwards to the next message or
backwards to the last message without marking anything as archived?

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.
-- 
Brian May <brian@microcomaustralia.com.au>

Re: Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 336 bytes --]

On Thu, 30 Jun 2011 13:04:23 +1000, Brian May <brian@microcomaustralia.com.au> wrote:
> Are there any keyboard bindings to go forwards to the next message or
> backwards to the last message without marking anything as archived?

'n' and 'p'.  These are documented in the notmuch-show mode help ('?'
while in notmuch-show mode).

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preventing the user shooting themself in the foot

[Carl Worth]

[-- Attachment #1: Type: text/plain, Size: 4347 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Preventing the user shooting themself in the foot

[Pieter Praet]

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

Re: Preventing the user shooting themself in the foot

[Michael Hudson-Doyle]

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

not sure why notmuch reply is putting that there :)

> 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.

I'm come to strongly agree that this is the Right Way to process email
too, so should there be a keybinding for this last operation?  It should
tag the message (or the thread?) with, say, 'task', and then proceeded
as 'a' does.  'task' should be in the default searches you get in
the notmuch hello buffer.

I realize there is endless bikeshedding to be done on tag names and so
on and also on allowing people to choose their own workflow, but I also
think that this shouldn't stop the addition of a sensible default :)

Cheers,
mwh

Re: Preventing the user shooting themself in the foot

[Jameson Graef Rollins]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
> 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
> 
> not sure why notmuch reply is putting that there :)

They shouldn't be, and I sent a patch to fix that a while ago:

id:"1307561409-5646-3-git-send-email-jrollins@finestructure.net"

But of course feel free to delete them before sending.

> I'm come to strongly agree that this is the Right Way to process email
> too, so should there be a keybinding for this last operation?  It should
> tag the message (or the thread?) with, say, 'task', and then proceeded
> as 'a' does.  'task' should be in the default searches you get in
> the notmuch hello buffer.

While I agree that Carl's method is pretty good, there is absolutely no
"Right Way" to process email; it's a completely personal, subjective
thing.  "Right Way" implies to me that other people *should* be
processing their mail that way, which I disagree with.

I'm generally against excessive unneeded configuration, but in the case
of key bindings it's definitely necessary.  Fortunately emacs is so
fundamentally flexible one can always modify the keybindings to their
hearts content.

jamie.

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]

Re: Preventing the user shooting themself in the foot

[Austin Clements]

On Fri, Jul 1, 2011 at 12:37 PM, Jameson Graef Rollins
<jrollins@finestructure.net> wrote:
> On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
>> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth <cworth@cworth.org> wrote:
>> I'm come to strongly agree that this is the Right Way to process email
>> too, so should there be a keybinding for this last operation?  It should
>> tag the message (or the thread?) with, say, 'task', and then proceeded
>> as 'a' does.  'task' should be in the default searches you get in
>> the notmuch hello buffer.
>
> While I agree that Carl's method is pretty good, there is absolutely no
> "Right Way" to process email; it's a completely personal, subjective
> thing.  "Right Way" implies to me that other people *should* be
> processing their mail that way, which I disagree with.
>
> I'm generally against excessive unneeded configuration, but in the case
> of key bindings it's definitely necessary.  Fortunately emacs is so
> fundamentally flexible one can always modify the keybindings to their
> hearts content.

While that's true and opens endless possibilities for power users, the
defaults need to be suited to new users.  Nobody wants to use a tool
that takes endless configuration just to get started, especially since
that's when you least know what configuration you want.  Simple
bindings with predictable behaviors that allow users to express their
own workflow, even if it requires a few more keystrokes, make better
defaults than bindings that codify a particular workflow.  As users
become more adept at a tool, this enables them to *incrementally*
capture (and refine) their workflow as more optimized bindings.

Re: Preventing the user shooting themself in the foot

[Pieter Praet]

On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle <michael.hudson@canonical.com> wrote:
> 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
> 
> not sure why notmuch reply is putting that there :)
> 
> > 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.
> 
> I'm come to strongly agree that this is the Right Way to process email
> too, so should there be a keybinding for this last operation?  It should
> tag the message (or the thread?) with, say, 'task', and then proceeded
> as 'a' does.  'task' should be in the default searches you get in
> the notmuch hello buffer.

#+BEGIN_SRC emacs-lisp
  (define-key notmuch-show-mode-map "t"
    (lambda()
      "Flag and archive currently selected message, and move to the next.
If this is the last message, move to the next thread."
      (interactive)
      (notmuch-show-add-tag "flagged")
      (notmuch-show-advance-and-archive)))
#+END_SRC

Note that I use the "flagged" tag, since this corresponds to a maildir
flag, and can be synced via IMAP.

> I realize there is endless bikeshedding to be done on tag names and so
> on and also on allowing people to choose their own workflow, but I also
> think that this shouldn't stop the addition of a sensible default :)
> 
> Cheers,
> mwh
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Peace

-- 
Pieter

Re: Preventing the user shooting themself in the foot

[Stewart Smith]

On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth <cworth@cworth.org> wrote:
> 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.

IMHO this is one of the awesome things about notmuch (and I've actively
used it to go back on conversations I previously ignored)

-- 
Stewart Smith

Re: Preventing the user shooting themself in the foot

[Sebastian Spaeth]

[-- Attachment #1: Type: text/plain, Size: 1236 bytes --]

On Wed, 29 Jun 2011 15:40:40 -0700, Carl Worth <cworth@cworth.org> wrote:
> On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green <greenrd@greenrd.org> wrote:
> > It's really dangerous to use the 'a' key in notmuch-mode in an inbox
> > thread which has multiple unread replies! Yes, the other unread replies
> > will still be tagged unread, but the user might not immediately be aware
> > of them. It would be really useful to have an optional warning ("More
> > unread messages in this thread, are you sure?") for this situation!
> 
> That was why I originally designed the space bar keybinding for reading
> through each message in turn, (and then it archives the thread only when you
> page past the last message).
> 
> The 'a' keybinding, (in turn), was designed for cases when you *know*
> you don't want to read the rest of the thread.

And that is what I use 'a' for, please don't take the single-key binding
away for this. I often glance at a thread, decide it's not interesting
for me and archive the whole thread including all unread messages.

It works perfectly for me. Adding another key for "only archive this
message" would be fine. Do people actually use the "x" keybinding? I
know I don't.

Sebastian

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Preventing the user shooting themself in the foot

[Michal Sojka]

On Thu, 30 Jun 2011, Sebastian Spaeth wrote:
> It works perfectly for me. Adding another key for "only archive this
> message" would be fine. Do people actually use the "x" keybinding? I
> know I don't.

I use 'x' a lot when I read a high-traffic mailing list and only want to
read threads with interesting subjects. I archive the other boring
threads directly from search view.

-Michal

Re: Preventing the user shooting themself in the foot

[Neeum Zawan]

Hi,

My wishes:

1. Space shouldn't archive. All too often it happens by mistake. It
   should just go to the end of the thread and stop, or return to the
   query results without archiving.

2. The unread tag should be kept as is. I find it useful (although
   admittedly mostly to resolve accidental archiving!) Regardless, even
   if that issue is fixed, I can see unread being useful.

3. One thing I *sorely* would like: Keybindings to go to the
   next/previous messages *in the query*. This would be my primary way
   of dealing with emails. If only one message in the middle of the
   thread matches the query, then I should be able to go to the next
   match with one keystroke (and no, defining a macro for "q", "n",
   "Enter" won't always work - what if two messages in a query match the
   search?) If there's a way to do this now, I'd like to know...

4. I'd also really like a way to display only messages matching a query
   (without rebuilding the thread). When viewing a message, if desired,
   a keybinding could construct just that thread. 

Re: Preventing the user shooting themself in the foot

[Daniel Schoepe]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

On Sat, 09 Jul 2011 10:09:09 -0700, Neeum Zawan <mailinglists@nawaz.org> wrote:
> 3. One thing I *sorely* would like: Keybindings to go to the
>    next/previous messages *in the query*. This would be my primary way
>    of dealing with emails. If only one message in the middle of the
>    thread matches the query, then I should be able to go to the next
>    match with one keystroke (and no, defining a macro for "q", "n",
>    "Enter" won't always work - what if two messages in a query match the
>    search?) If there's a way to do this now, I'd like to know...

'n' and 'p' already do something similar to this, since by default only
messages matching the query will be open and all the other ones closed,
when you enter a thread from a notmuch-search buffer. As 'n' and 'p'
only move between opened messages, they should effectively work like you
want them to.

Cheers,
Daniel

[-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --]