* [sup-talk] Ignore killed messages in U screen
@ 2009-08-27 15:36 Edward Z. Yang
2009-08-27 15:50 ` Ben Walton
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Edward Z. Yang @ 2009-08-27 15:36 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 18+ messages in thread* [sup-talk] Ignore killed messages in U screen
2009-08-27 15:36 [sup-talk] Ignore killed messages in U screen Edward Z. Yang
@ 2009-08-27 15:50 ` Ben Walton
2009-08-27 15:56 ` Edward Z. Yang
2009-09-03 18:47 ` William Morgan
2 siblings, 0 replies; 18+ messages in thread
From: Ben Walton @ 2009-08-27 15:50 UTC (permalink / raw)
Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
> 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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-08-27 15:36 [sup-talk] Ignore killed messages in U screen Edward Z. Yang
2009-08-27 15:50 ` Ben Walton
@ 2009-08-27 15:56 ` Edward Z. Yang
2009-09-03 19:25 ` Rich Lane
2009-09-03 18:47 ` William Morgan
2 siblings, 1 reply; 18+ messages in thread
From: Edward Z. Yang @ 2009-08-27 15:56 UTC (permalink / raw)
Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
> - SearchResultsMode.spawn_from_query "is:unread"
> + 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-08-27 15:56 ` Edward Z. Yang
@ 2009-09-03 19:25 ` Rich Lane
2009-09-03 23:06 ` Carl Worth
0 siblings, 1 reply; 18+ messages in thread
From: Rich Lane @ 2009-09-03 19:25 UTC (permalink / raw)
Excerpts from Edward Z. Yang's message of Thu Aug 27 11:56:32 -0400 2009:
> Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
> > - SearchResultsMode.spawn_from_query "is:unread"
> > + 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.
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.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-03 19:25 ` Rich Lane
@ 2009-09-03 23:06 ` Carl Worth
2009-09-04 14:41 ` William Morgan
0 siblings, 1 reply; 18+ messages in thread
From: Carl Worth @ 2009-09-03 23:06 UTC (permalink / raw)
Excerpts from Rich Lane's message of Thu Sep 03 12:25:03 -0700 2009:
> 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.
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).
Excerpts from William Morgan's message of Thu Sep 03:
> 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, 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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-03 23:06 ` Carl Worth
@ 2009-09-04 14:41 ` William Morgan
2009-09-04 15:12 ` Carl Worth
0 siblings, 1 reply; 18+ messages in thread
From: William Morgan @ 2009-09-04 14:41 UTC (permalink / raw)
Reformatted excerpts from Carl Worth's message of 2009-09-03:
> 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?
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.
> So is there a mismatch between the philosophy and the mechanics, or
> 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.
> 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.
I think the above implementation would allow this.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-04 14:41 ` William Morgan
@ 2009-09-04 15:12 ` Carl Worth
0 siblings, 0 replies; 18+ messages in thread
From: Carl Worth @ 2009-09-04 15:12 UTC (permalink / raw)
Excerpts from William Morgan's message of Fri Sep 04 07:41:49 -0700 2009:
> 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.
Good. I'm glad I'm at least understanding how things work here.
> 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.
>
> > 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.
>
> 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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-08-27 15:36 [sup-talk] Ignore killed messages in U screen Edward Z. Yang
2009-08-27 15:50 ` Ben Walton
2009-08-27 15:56 ` Edward Z. Yang
@ 2009-09-03 18:47 ` William Morgan
2009-09-03 18:57 ` Edward Z. Yang
2009-09-03 19:13 ` Ben Walton
2 siblings, 2 replies; 18+ messages in thread
From: William Morgan @ 2009-09-03 18:47 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-03 18:47 ` William Morgan
@ 2009-09-03 18:57 ` Edward Z. Yang
2009-09-03 18:58 ` William Morgan
2009-09-03 19:13 ` Ben Walton
1 sibling, 1 reply; 18+ messages in thread
From: Edward Z. Yang @ 2009-09-03 18:57 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009:
> 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.
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-03 18:57 ` Edward Z. Yang
@ 2009-09-03 18:58 ` William Morgan
2009-09-03 19:01 ` Edward Z. Yang
0 siblings, 1 reply; 18+ messages in thread
From: William Morgan @ 2009-09-03 18:58 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-03 18:58 ` William Morgan
@ 2009-09-03 19:01 ` Edward Z. Yang
2009-09-30 19:56 ` William Morgan
0 siblings, 1 reply; 18+ messages in thread
From: Edward Z. Yang @ 2009-09-03 19:01 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu Sep 03 14:58:55 -0400 2009:
> 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?
Then replies show up. :-)
Cheers,
Edward
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-03 19:01 ` Edward Z. Yang
@ 2009-09-30 19:56 ` William Morgan
2009-10-01 7:36 ` Nicolas Pouillard
0 siblings, 1 reply; 18+ messages in thread
From: William Morgan @ 2009-09-30 19:56 UTC (permalink / raw)
Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
> > What if you just delete messages in the the third condition?
>
> 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>
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-30 19:56 ` William Morgan
@ 2009-10-01 7:36 ` Nicolas Pouillard
2009-10-01 13:34 ` William Morgan
0 siblings, 1 reply; 18+ messages in thread
From: Nicolas Pouillard @ 2009-10-01 7:36 UTC (permalink / raw)
Excerpts from William Morgan's message of Wed Sep 30 21:56:55 +0200 2009:
> Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
> > > What if you just delete messages in the the third condition?
> >
> > 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.
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* [sup-talk] Ignore killed messages in U screen
2009-09-03 18:47 ` William Morgan
2009-09-03 18:57 ` Edward Z. Yang
@ 2009-09-03 19:13 ` Ben Walton
1 sibling, 0 replies; 18+ messages in thread
From: Ben Walton @ 2009-09-03 19:13 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009:
> 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.
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
--
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/20090903/e97c30e8/attachment.bin>
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2009-10-06 17:11 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-27 15:36 [sup-talk] Ignore killed messages in U screen Edward Z. Yang
2009-08-27 15:50 ` Ben Walton
2009-08-27 15:56 ` Edward Z. Yang
2009-09-03 19:25 ` Rich Lane
2009-09-03 23:06 ` Carl Worth
2009-09-04 14:41 ` William Morgan
2009-09-04 15:12 ` Carl Worth
2009-09-03 18:47 ` William Morgan
2009-09-03 18:57 ` Edward Z. Yang
2009-09-03 18:58 ` William Morgan
2009-09-03 19:01 ` Edward Z. Yang
2009-09-30 19:56 ` William Morgan
2009-10-01 7:36 ` Nicolas Pouillard
2009-10-01 13:34 ` William Morgan
2009-10-01 14:07 ` Nicolas Pouillard
2009-10-01 17:13 ` Carl Worth
2009-10-06 17:11 ` William Morgan
2009-09-03 19:13 ` Ben Walton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox