Preventing the user shooting themself in the foot

2011-07-09 Thread Daniel Schoepe
On Sat, 09 Jul 2011 10:09:09 -0700, Neeum Zawan  
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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 



Preventing the user shooting themself in the foot

2011-07-09 Thread 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

2011-07-09 Thread 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. 


___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-07-09 Thread Daniel Schoepe
On Sat, 09 Jul 2011 10:09:09 -0700, Neeum Zawan mailingli...@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


pgpOXeEvUVu6B.pgp
Description: PGP signature
___
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)

2011-07-07 Thread 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)

2011-07-07 Thread 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)

2011-07-07 Thread 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)

2011-07-07 Thread 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)

2011-07-07 Thread 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)

2011-07-07 Thread 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)

2011-07-06 Thread 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)

2011-07-05 Thread 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


Preventing the user shooting themself in the foot

2011-07-04 Thread 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)

2011-07-04 Thread 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: 



Re: Preventing the user shooting themself in the foot

2011-07-04 Thread 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
___
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)

2011-07-04 Thread 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)

2011-07-04 Thread 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


Preventing the user shooting themself in the foot

2011-07-02 Thread Pieter Praet
On Fri, 1 Jul 2011 11:28:10 +1000, Brian May  wrote:
> On 30 June 2011 17:50, Pieter Praet  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 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Peace

-- 
Pieter


Preventing the user shooting themself in the foot

2011-07-01 Thread Pieter Praet
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle  wrote:
> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  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 at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Peace

-- 
Pieter


Preventing the user shooting themself in the foot

2011-07-01 Thread Austin Clements
On Fri, Jul 1, 2011 at 12:37 PM, Jameson Graef Rollins
 wrote:
> On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle  canonical.com> wrote:
>> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  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.


Preventing the user shooting themself in the foot

2011-07-01 Thread Brian May
On 30 June 2011 17:50, Pieter Praet  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 


Preventing the user shooting themself in the foot

2011-07-01 Thread Jameson Graef Rollins
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle  wrote:
> On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  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 at 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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 



Preventing the user shooting themself in the foot

2011-07-01 Thread Michael Hudson-Doyle
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  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


Preventing the user shooting themself in the foot

2011-07-01 Thread Stewart Smith
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  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

2011-07-01 Thread Michael Hudson-Doyle
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-07-01 Thread Stewart Smith
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-07-01 Thread Brian May
On 30 June 2011 17:50, Pieter Praet pie...@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 br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-07-01 Thread Jameson Graef Rollins
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle 
michael.hud...@canonical.com wrote:
 On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@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-jroll...@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.


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


Re: Preventing the user shooting themself in the foot

2011-07-01 Thread Pieter Praet
On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle 
michael.hud...@canonical.com wrote:
 On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-07-01 Thread Austin Clements
On Fri, Jul 1, 2011 at 12:37 PM, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 On Fri, 01 Jul 2011 09:26:48 +1200, Michael Hudson-Doyle 
 michael.hud...@canonical.com wrote:
 On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@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.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-07-01 Thread Pieter Praet
On Fri, 1 Jul 2011 11:28:10 +1000, Brian May br...@microcomaustralia.com.au 
wrote:
 On 30 June 2011 17:50, Pieter Praet pie...@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 br...@microcomaustralia.com.au
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

Peace

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Preventing the user shooting themself in the foot

2011-06-30 Thread Brian May
On 30 June 2011 08:40, Carl Worth  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 


Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet
On Thu, 30 Jun 2011 09:50:27 +0200, Pieter Praet  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


Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet
On Wed, 29 Jun 2011 19:53:03 -0400, Austin Clements  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"  wrote:
Non-text part: text/html
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter


Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth  wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On Thu, 30 Jun 2011 13:04:23 +1000, Brian May  microcomaustralia.com.au> wrote:
> > On 30 June 2011 08:40, Carl Worth  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 at intel.com
Non-text part: application/pgp-signature
> ___
> notmuch mailing list
> notmuch at 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 

Preventing the user shooting themself in the foot

2011-06-30 Thread Sebastian Spaeth
On Wed, 29 Jun 2011 15:40:40 -0700, Carl Worth  wrote:
> On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green  
> 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
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Re: Preventing the user shooting themself in the foot

2011-06-30 Thread Sebastian Spaeth
On Wed, 29 Jun 2011 15:40:40 -0700, Carl Worth cwo...@cworth.org wrote:
 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!
 
 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


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


Re: Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet
On Wed, 29 Jun 2011 22:40:07 -0700, Carl Worth cwo...@cworth.org wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
 On Thu, 30 Jun 2011 13:04:23 +1000, Brian May 
 br...@microcomaustralia.com.au wrote:
  On 30 June 2011 08:40, Carl Worth cwo...@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.wo...@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

2011-06-30 Thread Pieter Praet
On Wed, 29 Jun 2011 19:53:03 -0400, Austin Clements amdra...@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 cwo...@cworth.org wrote:
Non-text part: text/html
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-06-30 Thread Pieter Praet
On Thu, 30 Jun 2011 09:50:27 +0200, Pieter Praet pie...@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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Preventing the user shooting themself in the foot

2011-06-29 Thread Carl Worth
On Thu, 30 Jun 2011 13:04:23 +1000, Brian May  wrote:
> On 30 June 2011 08:40, Carl Worth  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


Preventing the user shooting themself in the foot

2011-06-29 Thread Jameson Graef Rollins
On Thu, 30 Jun 2011 13:04:23 +1000, Brian May  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.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 



Preventing the user shooting themself in the foot

2011-06-29 Thread 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!


Preventing the user shooting themself in the foot

2011-06-29 Thread Austin Clements
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"  wrote:
-- next part --
An HTML attachment was scrubbed...
URL: 



Preventing the user shooting themself in the foot

2011-06-29 Thread Carl Worth
On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green  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 at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 



Preventing the user shooting themself in the foot

2011-06-29 Thread Jameson Graef Rollins
On Wed, 29 Jun 2011 20:42:01 +0100, Robin Green  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)))
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 



Preventing the user shooting themself in the foot

2011-06-29 Thread 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!
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Preventing the user shooting themself in the foot

2011-06-29 Thread Jameson Graef Rollins
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 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)))


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


Re: Preventing the user shooting themself in the foot

2011-06-29 Thread Carl Worth
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!

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.wo...@intel.com


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


Re: Preventing the user shooting themself in the foot

2011-06-29 Thread Brian May
On 30 June 2011 08:40, Carl Worth cwo...@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 br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch