[PATCH] remove message archiving from show-advance-and-archive

[PATCH] remove message archiving from show-advance-and-archive

[Jameson Rollins]

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

The function to advance through threads with the space bar is useful.
However, the current implementation also archives messages.  The idea
of archiving a message should not be intertwined with the processes of
advancing through messages to read them.  Archiving in general should
be a separate operation that one does explicitly.  This patch just
renames the advance function "notmuch-show-advance", and removes the
archiving of a thread when the end of the thread is reached.
---
 emacs/notmuch-show.el |   27 +++++++++++----------------
 1 files changed, 11 insertions(+), 16 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index f872cdf..b0c1f63 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -579,7 +579,7 @@ function is used. "
 	(define-key map "n" 'notmuch-show-next-open-message)
 	(define-key map "p" 'notmuch-show-previous-open-message)
 	(define-key map (kbd "DEL") 'notmuch-show-rewind)
-	(define-key map " " 'notmuch-show-advance-and-archive)
+	(define-key map " " 'notmuch-show-advance)
 	(define-key map (kbd "M-RET") 'notmuch-show-open-or-close-all)
 	(define-key map (kbd "RET") 'notmuch-show-toggle-message)
 	map)
@@ -601,7 +601,7 @@ which \\[notmuch-show-next-button] and
 \\[notmuch-show-previous-button] are helpful).
 
 Reading the thread sequentially is well-supported by pressing
-\\[notmuch-show-advance-and-archive]. This will scroll the
+\\[notmuch-show-advance]. This will scroll the
 current message (if necessary), advance to the next message, or
 advance to the next thread (if already on the last message of a
 thread).
@@ -611,7 +611,7 @@ more selectively, (such as '\\[notmuch-show-next-message]' and
 '\\[notmuch-show-previous-message]' to advance to messages
 without removing any tags, and '\\[notmuch-show-archive-thread]'
 to archive an entire thread without scrolling through with
-\\[notmuch-show-advance-and-archive]).
+\\[notmuch-show-advance]).
 
 You can add or remove arbitary tags from the current message with
 '\\[notmuch-show-add-tag]' or '\\[notmuch-show-remove-tag]'.
@@ -780,8 +780,8 @@ All currently available key bindings:
 
 ;; Commands typically bound to keys.
 
-(defun notmuch-show-advance-and-archive ()
-  "Advance through thread and archive.
+(defun notmuch-show-advance ()
+  "Advance through threads.
 
 This command is intended to be one of the simplest ways to
 process a thread of email. It does the following:
@@ -793,10 +793,9 @@ Otherwise, (the end of the current message is already within the
 current window), advance to the next open message.
 
 Finally, if there is no further message to advance to, and this
-last message is already read, then archive the entire current
-thread, (remove the \"inbox\" tag from each message). Also kill
-this buffer, and display the next thread from the search from
-which this thread was originally shown."
+last message is already read. Also kill this buffer, and display
+the next thread from the search from which this thread was
+originally shown."
   (interactive)
   (let ((end-of-this-message (notmuch-show-message-bottom)))
     (cond
@@ -814,14 +813,10 @@ which this thread was originally shown."
 
      ((not (= end-of-this-message (point-max)))
       ;; This is not the last message - move to the next visible one.
-      (notmuch-show-next-open-message))
-
-     (t
-      ;; This is the last message - archive the thread.
-      (notmuch-show-archive-thread)))))
+      (notmuch-show-next-open-message)))))
 
 (defun notmuch-show-rewind ()
-  "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance-and-archive]).
+  "Backup through the thread, (reverse scrolling compared to \\[notmuch-show-advance]).
 
 Specifically, if the beginning of the previous email is fewer
 than `window-height' lines from the current point, move to it
@@ -831,7 +826,7 @@ Otherwise, just scroll down a screenful of the current message.
 
 This command does not modify any message tags, (it does not undo
 any effects from previous calls to
-`notmuch-show-advance-and-archive'."
+`notmuch-show-advance'."
   (interactive)
   (let ((start-of-message (notmuch-show-message-top))
 	(start-of-window (window-start)))
-- 
1.7.1

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[David Edmondson]

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

On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> The function to advance through threads with the space bar is useful.
> However, the current implementation also archives messages.  The idea
> of archiving a message should not be intertwined with the processes of
> advancing through messages to read them.  Archiving in general should
> be a separate operation that one does explicitly.  This patch just
> renames the advance function "notmuch-show-advance", and removes the
> archiving of a thread when the end of the thread is reached.

This is great, but what if I want the current behaviour?

dme.
-- 
David Edmondson, http://dme.org

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Jameson Rollins]

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

On Wed, 09 Jun 2010 16:12:54 +0100, David Edmondson <dme@dme.org> wrote:
> On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> > The function to advance through threads with the space bar is useful.
> > However, the current implementation also archives messages.  The idea
> > of archiving a message should not be intertwined with the processes of
> > advancing through messages to read them.  Archiving in general should
> > be a separate operation that one does explicitly.  This patch just
> > renames the advance function "notmuch-show-advance", and removes the
> > archiving of a thread when the end of the thread is reached.
> 
> This is great, but what if I want the current behaviour?

Well, you could do like I do now, and write a function that does what
you want and bind it to whatever key you want.  But I really don't think
the current behavior should be the default.  The current behavior
completely mixes the meaning of "unread" and "inbox".  If there is no
difference between the meaning of those tags, then why have separate
tags for them?

I think we've done some good work in making the "unread" tag correspond
reasonably well to actually viewing a message.  We have lots of good
automatic removal of that tag when messages are viewed.  But I really
feel strongly that "unread" is the *only* tag that we should be handling
in an automated way like that.  We should really leave it to the user to
handle all other tags explicitly how they see fit.  I certainly don't
want every message I read automatically removed from my inbox.

If you feel really strongly about this in the other direction, I would
like to understand why.  If we can't resolve, then maybe a vote?

jamie.

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[David Edmondson]

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

On Wed, 09 Jun 2010 11:25:04 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> On Wed, 09 Jun 2010 16:12:54 +0100, David Edmondson <dme@dme.org> wrote:
> > On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> > > The function to advance through threads with the space bar is useful.
> > > However, the current implementation also archives messages.  The idea
> > > of archiving a message should not be intertwined with the processes of
> > > advancing through messages to read them.  Archiving in general should
> > > be a separate operation that one does explicitly.  This patch just
> > > renames the advance function "notmuch-show-advance", and removes the
> > > archiving of a thread when the end of the thread is reached.
> > 
> > This is great, but what if I want the current behaviour?
> 
> Well, you could do like I do now, and write a function that does what
> you want and bind it to whatever key you want.  But I really don't think
> the current behavior should be the default.

I'm not overly worried about the default behaviour, just with what
behaviour is easily available.

> The current behavior completely mixes the meaning of "unread" and
> "inbox".  If there is no difference between the meaning of those tags,
> then why have separate tags for them?

They are clearly different. If I read a thread with 'space' the 'unread'
tag is removed from the messages as I pass them by. I can then 'q' from
the thread and the messages are not archived ('inbox' is not removed),
but they are no longer 'unread'.

> I think we've done some good work in making the "unread" tag correspond
> reasonably well to actually viewing a message.  We have lots of good
> automatic removal of that tag when messages are viewed.  But I really
> feel strongly that "unread" is the *only* tag that we should be handling
> in an automated way like that.  We should really leave it to the user to
> handle all other tags explicitly how they see fit.  I certainly don't
> want every message I read automatically removed from my inbox.
> 
> If you feel really strongly about this in the other direction, I would
> like to understand why.  If we can't resolve, then maybe a vote?

Maybe you could submit a patch which allows a user to choose the
behaviour with a customisation variable? (Though I'd expect the value of
that variable to preserve backward compatible behaviour until Carl says
otherwise.)

dme.
-- 
David Edmondson, http://dme.org

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Jameson Rollins]

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

On Wed, 09 Jun 2010 16:36:53 +0100, David Edmondson <dme@dme.org> wrote:
> They are clearly different. If I read a thread with 'space' the 'unread'
> tag is removed from the messages as I pass them by. I can then 'q' from
> the thread and the messages are not archived ('inbox' is not removed),
> but they are no longer 'unread'.

But it's not necessarily clear that you've reached the end of a thread,
which means it's somewhat indeterministic if the "inbox" tag is removed
or not.  If users have to explicitly remove all tags other than
"unread", then this gets rid of this problem all together.

> Maybe you could submit a patch which allows a user to choose the
> behaviour with a customisation variable? (Though I'd expect the value of
> that variable to preserve backward compatible behaviour until Carl says
> otherwise.)

I actually submitted this patch because there was noise on #notmuch
about people (including from cworth) not liking the default behavior
where the "inbox" tag is removed by the advance function.

I would like to push it back the other way.  Having specific tags
modified by specific commands is something particular to individual
users.  If a user wants to do something special, they can make their own
function to do that.

jamie.

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[David Edmondson]

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

On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> I would like to push it back the other way.  Having specific tags
> modified by specific commands is something particular to individual
> users.  If a user wants to do something special, they can make their own
> function to do that.

You're advocating that no tags are automatically added or removed?

dme.
-- 
David Edmondson, http://dme.org

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Jameson Rollins]

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

On Wed, 09 Jun 2010 18:18:42 +0100, David Edmondson <dme@dme.org> wrote:
> On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> > I would like to push it back the other way.  Having specific tags
> > modified by specific commands is something particular to individual
> > users.  If a user wants to do something special, they can make their own
> > function to do that.
> 
> You're advocating that no tags are automatically added or removed?

I'm advocating that *only* the "unread" tag ever be automatically
removed in the emacs UI when doing anything other than explicitly
removing tags (eg. like just opening a message for viewing, or browsing
through a thread, etc.).  All other tags should only ever be explicitly
modified by the user.

I don't have any problem keys being bound to specific tag modification
operations, though, like having the 'd' key add the "delete" tag to a
message or thread, or the 'a' key remove the "inbox" tag, etc.

If users want to have special tag manipulation procedures to match their
needs, then they can easily build the needed functions and bind them to
whichever keys they wish.

jamie.

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[David Edmondson]

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

On Wed, 09 Jun 2010 13:29:46 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> I'm advocating that *only* the "unread" tag ever be automatically
> removed in the emacs UI when doing anything other than explicitly
> removing tags (eg. like just opening a message for viewing, or browsing
> through a thread, etc.).  All other tags should only ever be explicitly
> modified by the user.

Understood. Presumably the automatic tag addition would also remain.

> If users want to have special tag manipulation procedures to match their
> needs, then they can easily build the needed functions and bind them to
> whichever keys they wish.

In general I'd agree. The 'advance-and-archive' case is different,
because it's behaviour is bound up in the logic of the function. It's
not easy to just add that in on top with a simple key binding.

In any case, I don't care enough to argue more. Go for it.

dme.
-- 
David Edmondson, http://dme.org

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Carl Worth]

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

On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> The function to advance through threads with the space bar is useful.
> However, the current implementation also archives messages.  The idea
> of archiving a message should not be intertwined with the processes of
> advancing through messages to read them.  Archiving in general should
> be a separate operation that one does explicitly.  This patch just
> renames the advance function "notmuch-show-advance", and removes the
> archiving of a thread when the end of the thread is reached.

The other piece of the magic space bar that people have complained about
is that it intertwines advancing among messages within one thread with
advancing from one thread to the next. (And only the first operation is
reversible by backspace.)

I think we'll probably want to change that at the same time.

Meanwhile, I'm currently working on support for piping a whole thread of
messages as an mbox to a process, (mostly getting bogged down in trying
to fix mbox support in git).

For that, I think I want the current '|' binding to pipe the current
message and then a new binding ("M-|" ?) to pipe every (open) message in
the thread.

Which makes me think that other operations should work similarly. '+'
and '-' should change tags on the current message (as they do currently)
and then new "M-+" and "M--" could change tags on all (open) messages in
the thread.

That would highlight the current 'a' as out of place since it's
currently archiving every message in the thread. So I'd then fix it to
be 'a' for the current message and "M-a" for every (open) message in the
thread.

What do people think of that?

-Carl

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Carl Worth]

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

On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> I actually submitted this patch because there was noise on #notmuch
> about people (including from cworth) not liking the default behavior
> where the "inbox" tag is removed by the advance function.

For the record, I wrote the current behavior for my own use, so I've
been pretty happy with it.

But I have seen enough people complain about it that I've been convinced
that something is wrong about it. I'm not yet sure what the right answer
is. But if we at least have separate commands for separate actions, then
hopefully it wouldn't be too difficult for users to combine those
actions.

When we have one command that does several different things, then it's
much harder for users to tweak.

I suppose one option here would be a customizable variable that controls
what happens when trying to advance "past" the last message, (do
nothing, advance to next thread, archive current thread and advance to
next thread)?

-Carl

-- 
carl.d.worth@intel.com

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Dirk Hohndel]

On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth <cworth@cworth.org> wrote:
> On Wed, 9 Jun 2010 10:49:43 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> > The function to advance through threads with the space bar is useful.
> > However, the current implementation also archives messages.  The idea
> > of archiving a message should not be intertwined with the processes of
> > advancing through messages to read them.  Archiving in general should
> > be a separate operation that one does explicitly.  This patch just
> > renames the advance function "notmuch-show-advance", and removes the
> > archiving of a thread when the end of the thread is reached.
> 
> The other piece of the magic space bar that people have complained about
> is that it intertwines advancing among messages within one thread with
> advancing from one thread to the next. (And only the first operation is
> reversible by backspace.)

This has always confused me - I think I've complained about it before as
well :)
 
> I think we'll probably want to change that at the same time.
> 
> Meanwhile, I'm currently working on support for piping a whole thread of
> messages as an mbox to a process, (mostly getting bogged down in trying
> to fix mbox support in git).
> 
> For that, I think I want the current '|' binding to pipe the current
> message and then a new binding ("M-|" ?) to pipe every (open) message in
> the thread.
> 
> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
> 
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.

I really like this. It's consistent and I'm sure I'll get used to it
quickly. The only question now is "all messages in a thread" or "all
open messages in a thread". I'd vote for all.

Oh - and I really want a way to do surgery on threads. Merge threads to
fix Blackberry users breaking threads. And split threads for
hijackers... 

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: [PATCH] remove message archiving from show-advance-and-archive

[servilio]

On 9 June 2010 13:50, Carl Worth <cworth@cworth.org> wrote:
[...]
> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
>
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.
>
> What do people think of that?

+2 I think this would be awesome. I am using "-" a lot to remove the
"inbox" tag to individual messages.

Servilio

Re: [PATCH] remove message archiving from show-advance-and-archive

[servilio]

On 9 June 2010 13:54, Carl Worth <cworth@cworth.org> wrote:
[...]
> But I have seen enough people complain about it that I've been convinced
> that something is wrong about it. I'm not yet sure what the right answer
> is. But if we at least have separate commands for separate actions, then
> hopefully it wouldn't be too difficult for users to combine those
> actions.
>
> When we have one command that does several different things, then it's
> much harder for users to tweak.
>
> I suppose one option here would be a customizable variable that controls
> what happens when trying to advance "past" the last message, (do
> nothing, advance to next thread, archive current thread and advance to
> next thread)?

Or hooks. If that is not possible, I prefer small functions I can
combine when personalizing the key bindings.

Servilio

Re: [PATCH] remove message archiving from show-advance-and-archive

[Jameson Rollins]

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

On Wed, 09 Jun 2010 10:54:57 -0700, Carl Worth <cworth@cworth.org> wrote:
> On Wed, 09 Jun 2010 11:55:49 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> > I actually submitted this patch because there was noise on #notmuch
> > about people (including from cworth) not liking the default behavior
> > where the "inbox" tag is removed by the advance function.
> 
> For the record, I wrote the current behavior for my own use, so I've
> been pretty happy with it.

I'm still not understanding the usage pattern here.  Do you really want
to archive all threads after you've read them?  If so, what's the
difference between the "unread" and "inbox" tags in your work flow?

dme's response was "if I don't want the message archived, then I hit 'q'
instead of ' '".  But it seems to make more sense to me to say "if I
want the message archived, I just hit 'a'".

> I suppose one option here would be a customizable variable that controls
> what happens when trying to advance "past" the last message, (do
> nothing, advance to next thread, archive current thread and advance to
> next thread)?

We could, but I think it adds a lot of unnecessary complication.  I
wonder if there's not a better way to handle the flow that you guys are
advocating, rather than using notmuch-show-advance-and-archive.

But I have a stop-gap solution.  What if we provide both
notmuch-show-advance and notmuch-show-advance-and-archive, with the
default being notmuch-show-advance?  That way, if folks want to use the
old behavior, they can just set

(define-key notmuch-show-mode-map " " 'notmuch-show-advance-and-archive)

in their emacs config file.  If people agree on that solution, then I
can submit a revamped patch.

jamie.

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[servilio]

On 9 June 2010 14:20, Dirk Hohndel <hohndel@infradead.org> wrote:
[...]
> Oh - and I really want a way to do surgery on threads. Merge threads to
> fix Blackberry users breaking threads. And split threads for
> hijackers...

I remember this being mentioned by Carl in the list some time ago, it
would be a great feature to have.

Servilio

Re: [PATCH] remove message archiving from show-advance-and-archive

[Jameson Rollins]

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

On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth <cworth@cworth.org> wrote:
> Meanwhile, I'm currently working on support for piping a whole thread of
> messages as an mbox to a process, (mostly getting bogged down in trying
> to fix mbox support in git).
> 
> For that, I think I want the current '|' binding to pipe the current
> message and then a new binding ("M-|" ?) to pipe every (open) message in
> the thread.
> 
> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
> 
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.
> 
> What do people think of that?

I think it's definitely the right way to go.  I actually rebound my keys
to do that long ago.

jamie.

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Jameson Rollins]

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

On Wed, 09 Jun 2010 11:20:47 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
> On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth <cworth@cworth.org> wrote:
> > That would highlight the current 'a' as out of place since it's
> > currently archiving every message in the thread. So I'd then fix it to
> > be 'a' for the current message and "M-a" for every (open) message in the
> > thread.
> 
> I really like this. It's consistent and I'm sure I'll get used to it
> quickly. The only question now is "all messages in a thread" or "all
> open messages in a thread". I'd vote for all.

I actually vote for the behavior Carl suggests.  The behavior of
archiving the entire thread can be done by popping out to the search and
applying notmuch-search-archive-thread to the thread with:

(define-key notmuch-search-mode-map "a" 'notmuch-search-archive-thread)

jamie.

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Carl Worth]

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

On Wed, 09 Jun 2010 15:20:21 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> On Wed, 09 Jun 2010 11:20:47 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
> > On Wed, 09 Jun 2010 10:50:15 -0700, Carl Worth <cworth@cworth.org> wrote:
> > I really like this. It's consistent and I'm sure I'll get used to it
> > quickly. The only question now is "all messages in a thread" or "all
> > open messages in a thread". I'd vote for all.

I have situations in which I want either one. The advantage of doing
"all open messages" is that it's easy to get the "all messages" behavior
by way of an existing command that's already useful in its own right,
("open all messages").

And I think "all open messages" is actually the right default as
well. If I do a focused search and end up reading one message that
matched the search, then archiving away that message and not others that
just happen to be in the same thread.

> I actually vote for the behavior Carl suggests.  The behavior of
> archiving the entire thread can be done by popping out to the search and
> applying notmuch-search-archive-thread to the thread with:
> 
> (define-key notmuch-search-mode-map "a" 'notmuch-search-archive-thread)

Or not. ;-)

I actually want to also fix the search mode commands like this to only
operate on messages that matched the (original search).

We had behavior that limited these commands to matching messages once,
but that was broken because it re-ran the search to find the list. So
that led to behavior like:

	-inbox # archive all messages in the thread

Then if the user realized that was a mistake, trying:

	+inbox # new search now matches nothing, so no effect

Our stop-gap solution here was to re-run a search with fewer
restrictions if the first search returned an empty list.

The correct solution is to remember the list of messages that matched
the first time and always operate on those. That will fix the above
problem and also avoid the race condition that can currently happen if
notmuch new is being run asynchronously from emacs. (The race is that
the user can thing he's archiving a thread with a single message but can
actually archive many messages that arrived since the original search
because the 'a' command is re-running the search.)

-Carl

-- 
carl.d.worth@intel.com

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Michal Sojka]

On Wed, 09 Jun 2010, Carl Worth wrote:
> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.
> 
> What do people think of that?

M-a is bound to (backward-sentence) by default. I personally do not use
this shortcut, but I use M-f and M-b frequently. If these shortcuts will
be replaced by some notmuch commands following the same logic, I'd not be
happy.

-Michal

Re: [PATCH] remove message archiving from show-advance-and-archive

[Sebastian Spaeth]

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

> For that, I think I want the current '|' binding to pipe the current
> message and then a new binding ("M-|" ?) to pipe every (open) message in
> the thread.
+1 

> Which makes me think that other operations should work similarly. '+'
> and '-' should change tags on the current message (as they do currently)
> and then new "M-+" and "M--" could change tags on all (open) messages in
> the thread.
+1 

> That would highlight the current 'a' as out of place since it's
> currently archiving every message in the thread. So I'd then fix it to
> be 'a' for the current message and "M-a" for every (open) message in the
> thread.

It would indeed be out of place, but I would like to voice support for
the status-quo. In General I like to press as few keys as possible
(since I use emacs my meta keys are getting worn out quite quickly).

and I usually archive whole threads rather than single messages, so I
would vote for "a" as archive thread. Is it inconsistent? Yes. Does it
let me press fewer keys? Yes...

Anyway, I can always customize it the way I like it best :-)

Sebastian

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

Re: [PATCH] remove message archiving from show-advance-and-archive

[Sebastian Spaeth]

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

On 2010-06-09, Dirk Hohndel wrote:
> Oh - and I really want a way to do surgery on threads. Merge threads to
> fix Blackberry users breaking threads. And split threads for
> hijackers... 

Which will open other cans of worms :-)
Have fun splitting the below thread between msg 1 and 2. Where will msg
3 end up? :-) (OK, OK, *usually* you should get a reply-to header...)

Msg id1
  Blah...

Msg id2
References: id1
  Bloh...

Msg id3
References: id1 id2
  Bleh...

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