Preventing the user shooting themself in the foot

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

Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Matthieu Lemerre]

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 take advantage of this thread to tell about another dangerous
situation I've found related to the use of the space key in show mode.

I like to use the space (and sometimes the backspace key) to read
threads back and forth, but sometimes I might read stuff to quickly and
archive a thread without wanting it. It is then complex to find it back
(especially if the thread contained a single message and I hit space
before actually reading the message, so I can't find it again).

As a workaround, I have changed the space key function
"notmuch-show-advance-and-archive" to not archive the thread if we are
at the end of the thread, but to just do nothing. Thus I have to
expicitely archive the thread when I have finished reading it, which I
find much safer.

I think the "and-archive" part of the space bar key should be at least
configurable. The patch is pretty simple but I can provide it if needed.

Note: The n and p keys are not good replacement for space/backspace.
First, because they do not remove the 'read' tag. Second, when you are
in the middle of a message, the p key go to the previous message instead
of going on top of the current one. (Actually, the behaviour of n is
fine, only p is annoying me). I think this is inconsistent with what
others mode do (e.g. C-M-u in programming modes, or C-c C-p in
org-mode), and the p key when in a message should go to the beginning of
the current message.

Matthieu

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Jameson Graef Rollins]

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

On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre <racin@free.fr> wrote:
> I like to use the space (and sometimes the backspace key) to read
> threads back and forth, but sometimes I might read stuff to quickly and
> archive a thread without wanting it. It is then complex to find it back
> (especially if the thread contained a single message and I hit space
> before actually reading the message, so I can't find it again).
> 
> As a workaround, I have changed the space key function
> "notmuch-show-advance-and-archive" to not archive the thread if we are
> at the end of the thread, but to just do nothing. Thus I have to
> expicitely archive the thread when I have finished reading it, which I
> find much safer.

I completely agree with your discomfort with the current function bound
to space.  I don't like it at all, and I similarly rebound space to be a
much more sensible function:

(defun notmuch-show-advance ()
  "Advance through messages in a thread."
  (interactive)
  (let ((end-of-this-message (notmuch-show-message-bottom)))
    (cond
     ;; Ideally we would test `end-of-this-message' against the result
     ;; of `window-end', but that doesn't account for the fact that
     ;; the end of the message might be hidden, so we have to actually
     ;; go to the end, walk back over invisible text and then see if
     ;; point is visible.
     ((save-excursion
	(goto-char (- end-of-this-message 1))
	(notmuch-show-move-past-invisible-backward)
	(> (point) (window-end)))
      ;; The bottom of this message is not visible - scroll.
      (scroll-up nil))
     ((not (= end-of-this-message (point-max)))
      ;; This is not the last message - move to the next visible one.
      (notmuch-show-next-open-message))
     )))

Notice I also made it so that this does not exit the current thread
view.

jamie.

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

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Matthieu Lemerre]

On Mon, 04 Jul 2011 17:03:51 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
Non-text part: multipart/signed
> On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre <racin@free.fr> wrote:
> > I like to use the space (and sometimes the backspace key) to read
> > threads back and forth, but sometimes I might read stuff to quickly and
> > archive a thread without wanting it. It is then complex to find it back
> > (especially if the thread contained a single message and I hit space
> > before actually reading the message, so I can't find it again).
> > 
> > As a workaround, I have changed the space key function
> > "notmuch-show-advance-and-archive" to not archive the thread if we are
> > at the end of the thread, but to just do nothing. Thus I have to
> > expicitely archive the thread when I have finished reading it, which I
> > find much safer.
> 
> I completely agree with your discomfort with the current function bound
> to space.  I don't like it at all, and I similarly rebound space to be a
> much more sensible function:

[...]

> Notice I also made it so that this does not exit the current thread
> view.

I patched notmuch to use exactly the same function... Given that we are
two people who independently requested for this behaviour, I think this
should at least be a customisable option, and imo the default should do
nothing and not archive the thread because of this dangerous
behaviour. And, hitting 'a' instead of space to go to the next thread is
the same number of keypresses...

Matthieu

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Austin Clements]

On Jul 5, 2011 4:23 PM, "Matthieu Lemerre" <racin@free.fr> wrote:
> On Mon, 04 Jul 2011 17:03:51 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:
>> On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre <racin@free.fr> wrote:
>> > I like to use the space (and sometimes the backspace key) to read
>> > threads back and forth, but sometimes I might read stuff to quickly and
>> > archive a thread without wanting it. It is then complex to find it back
>> > (especially if the thread contained a single message and I hit space
>> > before actually reading the message, so I can't find it again).
>> >
>> > As a workaround, I have changed the space key function
>> > "notmuch-show-advance-and-archive" to not archive the thread if we are
>> > at the end of the thread, but to just do nothing. Thus I have to
>> > expicitely archive the thread when I have finished reading it, which I
>> > find much safer.
>>
>> I completely agree with your discomfort with the current function bound
>> to space. I don't like it at all, and I similarly rebound space to be a
>> much more sensible function:
>
> [...]
>
>> Notice I also made it so that this does not exit the current thread
>> view.
>
> I patched notmuch to use exactly the same function... Given that we are
> two people who independently requested for this behaviour, I think this
> should at least be a customisable option, and imo the default should do
> nothing and not archive the thread because of this dangerous
> behaviour. And, hitting 'a' instead of space to go to the next thread is
> the same number of keypresses...

Make that two and a half (I haven't actually replaced this function,
but only for lack of time).

Had I replaced it, though, there are two variations I would have
tried.  Have you guys considered these and, if so, any thoughts?

* Make SPC mark the *current* message read and move to the next one,
rather than moving to the next and marking it read.  This way, you're
acknowledging the message as read once you've actually read it, rather
than having notmuch mark it read before you've actually read it.
notmuch's eagerness to mark things read has always bothered me.  For
example notmuch-show-archive-thread has the side-effect of marking the
first message of the next thread read (which I may not even know
exists!).  An acknowledgement-based approach seems like it would
address problems like this (so would better visual feedback, but
that's another issue).

* At the end of the thread, return to the index view.  This way, if
you want to archive the thread, you can still just press 'a', but if
you don't, you're already set to navigate to another thread.

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Matthieu Lemerre]

On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements <amdragon@mit.edu> wrote:
> Had I replaced it, though, there are two variations I would have
> tried.  Have you guys considered these and, if so, any thoughts?
> 
> * Make SPC mark the *current* message read and move to the next one,
> rather than moving to the next and marking it read.  This way, you're
> acknowledging the message as read once you've actually read it, rather
> than having notmuch mark it read before you've actually read it.

I agree. I think it's up to the user to define whether he read the
message. In fact as a consequence, I have no use of the 'unread' tag.
 
> * At the end of the thread, return to the index view.  This way, if
> you want to archive the thread, you can still just press 'a', but if
> you don't, you're already set to navigate to another thread.

I would prefer just to do nothing (or bell) at the end of the
thread. Sometimes the end of a message is just at the end of the screen,
and I want to hit space to see the next message, so I think that
returning to the index would surprise me (as going to the next thread
does).

But this could be a third option if some people prefer that. So we would
have:
- do nothing
- archive go to the next thread
- return to the index

Matthieu

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Jameson Graef Rollins]

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

On Thu, 07 Jul 2011 20:49:35 +0200, Matthieu Lemerre <racin@free.fr> wrote:
> On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements <amdragon@mit.edu> wrote:
> > * Make SPC mark the *current* message read and move to the next one,
> > rather than moving to the next and marking it read.  This way, you're
> > acknowledging the message as read once you've actually read it, rather
> > than having notmuch mark it read before you've actually read it.
> 
> I agree. I think it's up to the user to define whether he read the
> message. In fact as a consequence, I have no use of the 'unread' tag.

I would like to argue very strongly in favor of the current behavior of
the "unread" tag (since I'm actually the one that designed it).  I want
the unread flag to always just be handled automatically, being
automatically removed when I view a message without me having to do
anything.  If users want to have tags that they manually control, they
should just define those tags in the new.tags config.

jamie.

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

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Austin Clements]

Quoth Jameson Graef Rollins on Jul 07 at  1:40 pm:
> On Thu, 07 Jul 2011 20:49:35 +0200, Matthieu Lemerre <racin@free.fr> wrote:
> > On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements <amdragon@mit.edu> wrote:
> > > * Make SPC mark the *current* message read and move to the next one,
> > > rather than moving to the next and marking it read.  This way, you're
> > > acknowledging the message as read once you've actually read it, rather
> > > than having notmuch mark it read before you've actually read it.
> > 
> > I agree. I think it's up to the user to define whether he read the
> > message. In fact as a consequence, I have no use of the 'unread' tag.
> 
> I would like to argue very strongly in favor of the current behavior of
> the "unread" tag (since I'm actually the one that designed it).  I want
> the unread flag to always just be handled automatically, being
> automatically removed when I view a message without me having to do
> anything.  If users want to have tags that they manually control, they
> should just define those tags in the new.tags config.

What I'm suggesting is no more or less automatic than the current
behavior.  It's just a slight tweak to the order in which things
happen: that SPC could remove the unread tag and then move to the next
message, rather than the other way around.  In effect, the read tag
would indicate that you've seen the bottom of the message, not just
the top.

It's also possible I would have less trouble if SPC didn't
automatically go to the next thread.  The problem I have with the
current behavior is that I often find myself accidentally marking
messages as read because notmuch showed me a message I wasn't
expecting.  This is compounded by the lack of visual feedback when
this happens (e.g., the search results don't update to indicate that
anything has changed, and even if they did, I probably wouldn't notice
that the message *had* been unread).

Re: Dangerous space bar key (was: Preventing the user shooting themself in the foot)

[Jameson Graef Rollins]

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

On Thu, 7 Jul 2011 16:58:08 -0400, Austin Clements <amdragon@MIT.EDU> wrote:
> What I'm suggesting is no more or less automatic than the current
> behavior.  It's just a slight tweak to the order in which things
> happen: that SPC could remove the unread tag and then move to the next
> message, rather than the other way around.  In effect, the read tag
> would indicate that you've seen the bottom of the message, not just
> the top.

But as it stands now, the unread tag automatically goes away as soon as
view the message when selected from notmuch-search.  Under the new
proposal I would have to hit SPC to remove the unread tag, even if the
whole message was already visible.  It would still require more work.

> It's also possible I would have less trouble if SPC didn't
> automatically go to the next thread.  The problem I have with the
> current behavior is that I often find myself accidentally marking
> messages as read because notmuch showed me a message I wasn't
> expecting.  This is compounded by the lack of visual feedback when
> this happens (e.g., the search results don't update to indicate that
> anything has changed, and even if they did, I probably wouldn't notice
> that the message *had* been unread).

I really think the problem is the current behavior of SPC.  As I and a
couple of others have already mentioned, it just not a good, intuitive
default behavior.  I suggested what I think is a much better behavior in
a previous message [0].

jamie.

[0] id:"87pqlpioew.fsf@servo.factory.finestructure.net"

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

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

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