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

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  wrote:
> > On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements  
> > 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).

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

[Jameson Graef Rollins]

On Thu, 7 Jul 2011 16:58:08 -0400, Austin Clements  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 at servo.factory.finestructure.net"
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

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

[Jameson Graef Rollins]

On Thu, 07 Jul 2011 20:49:35 +0200, Matthieu Lemerre  wrote:
> On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements  
> 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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

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

[Jameson Graef Rollins]

On Thu, 07 Jul 2011 20:49:35 +0200, Matthieu Lemerre ra...@free.fr wrote:
 On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements amdra...@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.


pgpwMQ1Brm5Zr.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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 ra...@free.fr wrote:
  On Wed, 6 Jul 2011 09:25:41 -0400, Austin Clements amdra...@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).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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 ra...@free.fr wrote:
 On Mon, 04 Jul 2011 17:03:51 -0700, Jameson Graef Rollins 
 jroll...@finestructure.net wrote:
 On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre ra...@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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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 
jroll...@finestructure.net wrote:
Non-text part: multipart/signed
 On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre ra...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[Jameson Graef Rollins]

On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

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 gree...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

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

[Jameson Graef Rollins]

On Mon, 04 Jul 2011 23:36:35 +0200, Matthieu Lemerre ra...@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.


pgpK0Gv7ODCdG.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch