Subject: [sup-talk] Ignore killed messages in U screen

From: [email-masked] (Edward Z. Yang)
Date: Thu, 27 Aug 2009 11:36:28 -0400

>From e01820e5914c4fb8deb5836473aa37553e5a6234 Mon Sep 17 00:00:00 2001
From: Edward Z. Yang <ezyang at mit.edu>
Date: Wed, 26 Aug 2009 10:45:26 -0400
Subject: [PATCH] Do not display killed messages in unread screen.

Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
---
 bin/sup |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bin/sup b/bin/sup
index bbb6c17..645a9a1 100755
--- a/bin/sup
+++ b/bin/sup
@@ -263,7 +263,7 @@ begin
       next unless query && query !~ /^\s*$/
       SearchResultsMode.spawn_from_query query
     when :search_unread
-      SearchResultsMode.spawn_from_query "is:unread"
+      SearchResultsMode.spawn_from_query "is:unread !label:killed"
     when :list_labels
       labels = LabelManager.all_labels.map { |l| LabelManager.string_for l }
       user_label = bm.ask_with_completions :label, "Show threads with label (enter for listing): ", labels
-- 
1.6.4

---

From: [email-masked] (Ben Walton)
Date: Thu, 27 Aug 2009 11:50:08 -0400

> Subject: [PATCH] Do not display killed messages in unread screen.

+1 for this.
-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090827/95eba3ab/attachment.bin>

---

From: [email-masked] (Edward Z. Yang)
Date: Thu, 27 Aug 2009 11:56:32 -0400

> +      SearchResultsMode.spawn_from_query "is:unread !label:killed"

I might have one legitimate objection to this patch, which is
that searches should ignore killed tags unless explicitly told
not to.

Cheers,
Edward

---

From: [email-masked] (William Morgan)
Date: Thu, 03 Sep 2009 11:47:19 -0700

I'm not sure how I feel about this patch. The semantics of being killed
are very tied to the inbox. I'm reluctant to start spreading them to
other types of buffers.
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Edward Z. Yang)
Date: Thu, 03 Sep 2009 14:57:14 -0400

> are very tied to the inbox. I'm reluctant to start spreading them to

The reason why I request this is because I have a distinction between
unread messages in my inbox and unread messages not in my inbox and
unread messages that are killed.  The 1st is for messages that I
should read (or at least ack), the second is for mailing list messages
and the third is for "I don't actually ever want to see this again,
no really".

Cheers,
Edward

---

From: [email-masked] (William Morgan)
Date: Thu, 03 Sep 2009 11:58:55 -0700

Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
> The 1st is for messages that I should read (or at least ack), the
> second is for mailing list messages and the third is for "I don't
> actually ever want to see this again, no really".

What if you just delete messages in the the third condition?
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Edward Z. Yang)
Date: Thu, 03 Sep 2009 15:01:55 -0400

> What if you just delete messages in the the third condition?

Then replies show up. :-)

Cheers,
Edward

---

From: [email-masked] (Ben Walton)
Date: Thu, 03 Sep 2009 15:13:15 -0400

> are very tied to the inbox. I'm reluctant to start spreading them to

The 'U' key binding just drives a preset search.  This wouldn't be
spreading the special status of killed into other buffer types more
than a manual search using the same terms.

-Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090903/e97c30e8/attachment.bin>

---

From: [email-masked] (Rich Lane)
Date: Thu, 03 Sep 2009 15:25:03 -0400

> that searches should ignore killed tags unless explicitly told

By default Index#load_messages_in_thread_for does skip killed threads,
so you should already have the behavior you want without modifying the
query (unless you're using an old xapian-index version that doesn't
support killed threads). Adding a !label:killed term will actually cause
threads that are "killed" (have at least one message labeled killed) but
also have a message not labeled killed that matches the query to be
displayed, which I don't think is the behavior you're looking for.

---

From: [email-masked] (Carl Worth)
Date: Thu, 03 Sep 2009 16:06:50 -0700

> displayed, which I don't think is the behavior you're looking for.

Wow, that's surprising!

But thanks for explaining that since that's the exact behavior I've
been getting since I starting using queries with "!label:killed" in
them, (I'm trying to get views that act like filtered versions of the
inbox).

> are very tied to the inbox. I'm reluctant to start spreading them to

William, perhaps you can take this chance to explain something to
me. I've been trying to figure out the philosophy and the mechanics of
sup labels and searching.

>From the point-of-view of a naive user it has seemed to me like the
philosophy is that threads are the primary objects so all labels apply
to a thread as a whole, and all searches return results consisting of
entire threads. And this all seems very good to me.

But the above discussion of "killed" suggests that the mechanics
aren't at all like that. But that instead, labels are applied to
individual messages, and searches match individual messages and then
construct threads from the results. Is that more or less how things
work?

So is there a mismatch between the philosophy and the mechanics, or
did I just misunderstand the philosophy?

That is, do current users of sup ever distinguish between searching
for messages with specific labels as opposed to searching for threads
that contain messages with specific labels?

If not, it seems like it would be possible for a query like
"!label:killed" to do exactly what is wanted without needing any
special treatment for killed internally. And I'd like this, because I
would sometimes want to do a similar negative filter based on my own
custom labels.

Does that make sense?

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090903/b204c976/attachment.bin>

---

From: [email-masked] (William Morgan)
Date: Fri, 04 Sep 2009 07:41:49 -0700

> construct threads from the results. Is that more or less how things

Yes. That's why killed is special; it requires work at threading time to
drop threads in which any message has a killed label, regardless of
whether that's the message that matched the query.

> did I just misunderstand the philosophy?

Not sure. Maybe both. :) The philosophy is more about the UI, IMO, than
specific implementation details (though obviosuly there's some
trickle-up).

The other way to implement this, FWIW, is to have labels automatically
spread to all messages in a thread when they're applied. I think that is
probably a better implementation, though it increases the cost at
labeling time. I've been toying with this idea in the sup server code.

> special treatment for killed internally.

I think the above implementation would allow this.
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Carl Worth)
Date: Fri, 04 Sep 2009 08:12:01 -0700

> whether that's the message that matched the query.

Good. I'm glad I'm at least understanding how things work here.

> I think the above implementation would allow this.

Yes, that would do the trick. It would require extra work both at the
time a label is attached to a message and then again at the time a new
message is associated with an existing thread. But it would give me
the behavior I want "for free" after that.

If such an implementation would be acceptable, then it would seem that
a better long-term solution would be to apply labels only to "thread
objects" and to index and search for those rather than individuals
messages (at least as far as label searching goes). Of course, I'm
talking from an entirely naive point-of-view with regard to the
implementation impact of such a change, but I would imagine it
wouldn't be trivial.

-Carl

---

From: [email-masked] (William Morgan)
Date: Wed, 30 Sep 2009 12:56:55 -0700

> Then replies show up. :-)

I am still thinking about this, BTW. I think solution will either be:
treat deleted like killed for the purposes of inbox-mode (so a thread
with at least one deleted message will just never appear in inbox-mode),
or have a combined delete-and-kill command.

FWIW, I believe Gmail will pull a thread with a deleted message back
into the inbox if someone replies.
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Nicolas Pouillard)
Date: Thu, 01 Oct 2009 09:36:00 +0200

> into the inbox if someone replies.

Yes I think so (and merely hope so).

Notice that while GMail do not have the kill thread feature, Google Wave does
have a "mute this thread" button, that will cause these threads to no longer
appear in the inbox, however you can still search for is:mute threads.

-- 
Nicolas Pouillard
http://nicolaspouillard.fr

---

From: [email-masked] (William Morgan)
Date: Thu, 01 Oct 2009 06:34:50 -0700

Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01:
> Notice that while GMail do not have the kill thread feature

I think it does (but it didn't always). They also call it "mute".
http://mail.google.com/support/bin/answer.py?hl=en&answer=47787
-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Nicolas Pouillard)
Date: Thu, 1 Oct 2009 16:07:01 +0200

> http://mail.google.com/support/bin/answer.py?hl=en&answer=47787

The name and semantics seems just great.

---

From: [email-masked] (Carl Worth)
Date: Thu, 01 Oct 2009 10:13:47 -0700

> The name and semantics seems just great.

It seems a simple, little thing. But I'm all in favor of non-violent
metaphors in the interfaces of programs I use.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/d6d54b07/attachment.bin>