The archive operation should only archive open messages

The archive operation should only archive open messages

[Carl Worth]

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

One of the searches that I use most frequently, (for mail that I want to
respond to on a fairly timely basis), is

	tag:inbox and tag:to-me		[*]

Sometimes, this search will show a large mailing-list thread with only a
few messages open. Perhaps part-way through the thread, someone started
to CC me. Or perhaps my address got dropped from the CC at some
point. Either way, I am presented with a subset of the messages from the
thread, even though all of the thread's messages are in my inbox still.

That much is just fine. I'm giving priority to messages where people
thought I would be particularly interested, and that's just as it should
be.

A bad bug occurs when paging through the thread with the space
bar. After showing me these few messages, it will then proceed to
archive *all* the messages in the thread (not only those it showed
me). And I'm likely to be unaware of this since the closed (but not yet
archived) messages are not easily distinguished from messages that were
previously closed and archived.

Some people will claim (and I've even agreed) that the space bar is too
magic. But this bug also happens with an explicit command to archive the
current thread (such as hitting 'a').

I think the fix is to change these commands to only archive the messages
that are currently open. That will make these operations behave as I
expect, and I don't think will cause any unexpected or confusing
behavior. But please let me know if you disagree.

-Carl

[*] My tag:to-me is set by a script doing "notmuch tag +to-me
to:cworth@cworth.org or to:carl.d.worth@intel.com ...". I'd prefer this
to be a saved-search of course---that's one of the patches I haven't had
a chance to review yet.

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

Re: The archive operation should only archive open messages

[Jameson Rollins]

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

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth <cworth@cworth.org> wrote:
> Some people will claim (and I've even agreed) that the space bar is too
> magic. But this bug also happens with an explicit command to archive the
> current thread (such as hitting 'a').
>
> I think the fix is to change these commands to only archive the messages
> that are currently open. That will make these operations behave as I
> expect, and I don't think will cause any unexpected or confusing
> behavior. But please let me know if you disagree.

I actually *really* don't like that the space bar does this.  In fact, I
build my own notmuch-show-advance function in a notmuch-hacks.el that I
load to expressly get around this.  The only tag manipulation I want
done automatically is removal of "unread" when I visit a message.  Other
than that, I want to do all tag manipulation manually.  So I would be
thrilled is this "feature" was removed entirely, which would of course
get rid of this bug as well.

> [*] My tag:to-me is set by a script doing "notmuch tag +to-me
> to:cworth@cworth.org or to:carl.d.worth@intel.com ...". I'd prefer this
> to be a saved-search of course---that's one of the patches I haven't had
> a chance to review yet.

I've asked this in the past, but isn't this exactly what notmuch
"folders" are?  Is there a reason you don't just define this search as a
folder?

jamie.

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

Re: The archive operation should only archive open messages

[Dirk Hohndel]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth <cworth@cworth.org> wrote:
> One of the searches that I use most frequently, (for mail that I want to
> respond to on a fairly timely basis), is
> 
> 	tag:inbox and tag:to-me		[*]
> 
> Sometimes, this search will show a large mailing-list thread with only a
> few messages open. Perhaps part-way through the thread, someone started
> to CC me. Or perhaps my address got dropped from the CC at some
> point. Either way, I am presented with a subset of the messages from the
> thread, even though all of the thread's messages are in my inbox still.
> 
> That much is just fine. I'm giving priority to messages where people
> thought I would be particularly interested, and that's just as it should
> be.
> 
> A bad bug occurs when paging through the thread with the space
> bar. After showing me these few messages, it will then proceed to
> archive *all* the messages in the thread (not only those it showed
> me). And I'm likely to be unaware of this since the closed (but not yet
> archived) messages are not easily distinguished from messages that were
> previously closed and archived.
> 
> Some people will claim (and I've even agreed) that the space bar is too
> magic. But this bug also happens with an explicit command to archive the
> current thread (such as hitting 'a').
> 
> I think the fix is to change these commands to only archive the messages
> that are currently open. That will make these operations behave as I
> expect, and I don't think will cause any unexpected or confusing
> behavior. But please let me know if you disagree.

I am always confused about the behavior of 'a' - does it archive the
current message? Or the current thread? Or the current thread down to
where I am? Or (as you propose) just the open messages?

I think we really need to spend some time to crsiply define the
semantics of these commands.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: The archive operation should only archive open messages

[Jesse Rosenthal]

On Thu, 15 Apr 2010 13:41:17 -0700, Carl Worth <cworth@cworth.org> wrote:
> A bad bug occurs when paging through the thread with the space
> bar. After showing me these few messages, it will then proceed to
> archive *all* the messages in the thread (not only those it showed
> me). And I'm likely to be unaware of this since the closed (but not yet
> archived) messages are not easily distinguished from messages that were
> previously closed and archived.

This actually brings up a behavior that bites me from time to time. I
often mark messages "to-reply", and notmuch colors them red for
me. Then, when I reply to the message, it auto-removes the tag (based on
a message-mode hook I sent to the thread a while back*). I've gotten to
the point where I depend on this behavior.

However, when I have a long thread, and only one message in the inbox,
tagging the thread, of course, tags all the messages in it "to-reply."
Now, the way to do it might be to just change my habits, and only tag
while in show-mode, as opposed to search-mode. But this does seem to be
in conflict with the way I intuitively want to handle my mail, and I
imagine I'm not the only one.

Which is all just to say that I think that archiving is just a special
case of tagging/untagging, and that the issues raised here should be
considered across the larger general case.

[*] id:87pr3iygrx.fsf@jhu.edu

Re: The archive operation should only archive open messages

[Carl Worth]

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

On Thu, 15 Apr 2010 14:07:37 -0700, Dirk Hohndel <hohndel@infradead.org> wrote:
> I am always confused about the behavior of 'a' - does it archive the
> current message? Or the current thread? Or the current thread down to
> where I am? Or (as you propose) just the open messages?
> 
> I think we really need to spend some time to crsiply define the
> semantics of these commands.

I think the semantics have always been specified well, and
documented. Have you hit the '?' key to get a brief description of all
of the key bindings? Then you can also run `describe-key' ("C-h k" by
default) and then press a key to get even more thorough documentation.

If anything is not crisp enough there, please let me know and we'll fix
it right away.

I do agree that it's important for us to discuss what the ideal set of
operations is, and I don't claim that we have anything close to that in
the current implementation.

So that's why we're here talking I think. :-)

-Carl

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

Re: The archive operation should only archive open messages

[Carl Worth]

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

On Thu, 15 Apr 2010 16:59:13 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> I actually *really* don't like that the space bar does this.  In fact, I
> build my own notmuch-show-advance function in a notmuch-hacks.el that I
> load to expressly get around this.

Well we definitely do need that operation ("advance to next thread
without archiving" to complement our existing "advance to next thread
after archiving"). Any suggestions for what the keybinding should be for
that? What are you using?

And once we have that, changing space bar to only operate within the
current thread and not doing any advancing will definitely make it a lot
less magic and less confusing.

So I'm in favor of that at least.

>                                      The only tag manipulation I want
> done automatically is removal of "unread" when I visit a message.  Other
> than that, I want to do all tag manipulation manually.  So I would be
> thrilled is this "feature" was removed entirely, which would of course
> get rid of this bug as well.

The bug is still present for the explicit "archive this thread"
operation, (even if we disentangled it from any notion of advancing to
the next thread). So we'll still want to fix that.

> > [*] My tag:to-me is set by a script doing "notmuch tag +to-me
> > to:cworth@cworth.org or to:carl.d.worth@intel.com ...". I'd prefer this
> > to be a saved-search of course---that's one of the patches I haven't had
> > a chance to review yet.
> 
> I've asked this in the past, but isn't this exactly what notmuch
> "folders" are?  Is there a reason you don't just define this search as a
> folder?

I can define to-me as a folder (and I do do that). The reason I want
saved searches is that I also want to have folders such as "notmuch
to-me", "cairo to-me", etc. with common sub-expressions for what to-me
means. And if I add an email address I want to be able to update that in
1 place rather than in N different folder specification.

It's probably simpler to call these "search macros" rather than "saved
searches", because that's all the feature really is.

-Carl

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

Re: The archive operation should only archive open messages

[Carl Worth]

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

On Thu, 15 Apr 2010 17:18:30 -0400, Jesse Rosenthal <jrosenthal@jhu.edu> wrote:
> Which is all just to say that I think that archiving is just a special
> case of tagging/untagging, and that the issues raised here should be
> considered across the larger general case.

I do agree that archiving is just a special-case of
tagging/untagging. And fortunately, I think the implementation matches
that, so consistency will be natural here.

You're also making the claim that the tagging behavior should be
consistent between the search-results and thread-content views and that
makes a lot of sense.

Earlier in your message, you wrote:

> However, when I have a long thread, and only one message in the inbox,
> tagging the thread, of course, tags all the messages in it "to-reply."
> Now, the way to do it might be to just change my habits, and only tag
> while in show-mode, as opposed to search-mode. But this does seem to be
> in conflict with the way I intuitively want to handle my mail, and I
> imagine I'm not the only one.

It's funny, because for a while we did have the tag operation in the
search view affecting only the messages that actually matched the
search. The problem we ran into was that if you archived a message from
the search view and then wanted to undo that, the "+ inbox" operation
would not work, (since archiving the messages made them no longer match
the current search).

We "fixed" that by making the tag operations affect all messages in the
thread.

It occurs to me that the real bug here is that the tag operation is
re-executing the search, rather than simply acting on the set of
messages being displayed. And that's a bug we've recently discussed and
want to fix.

Once we fix that, I think we can go back to having tag operations only
affect matched messages in the search view, and I agree that this will
be extremely convenient.

-Carl


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

Re: The archive operation should only archive open messages

[Dirk Hohndel]

On Sat, 17 Apr 2010 08:28:49 -0700, Carl Worth <cworth@cworth.org> wrote:
> On Thu, 15 Apr 2010 16:59:13 -0400, Jameson Rollins <jrollins@finestructure.net> wrote:
> > I actually *really* don't like that the space bar does this.  In fact, I
> > build my own notmuch-show-advance function in a notmuch-hacks.el that I
> > load to expressly get around this.
> 
> Well we definitely do need that operation ("advance to next thread
> without archiving" to complement our existing "advance to next thread
> after archiving"). Any suggestions for what the keybinding should be for
> that? What are you using?

I have been going back and forth about which key to use... My current
favorite is 'k'eep. It kind of mirrors nicely with 'a'rchive.
 
> And once we have that, changing space bar to only operate within the
> current thread and not doing any advancing will definitely make it a lot
> less magic and less confusing.

Yes, please.

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center

Re: The archive operation should only archive open messages

[racin]

----- "Carl Worth" <cworth@cworth.org> a écrit :

> Once we fix that, I think we can go back to having tag operations
> only
> affect matched messages in the search view, and I agree that this
> will
> be extremely convenient.
> 

What about using prefixes to each command, the way Gnus does it*? For instance, 'd' should tag
the matched messages, "D" or all messages in the thread. Same for show mode: for instance 'd' for all matched messages
, "D" for all messages in the thread, and "C-d" for the current message only.

Matthieu

* All Gnus key chains that begin with "T" affect the current thread.