From mboxrd@z Thu Jan  1 00:00:00 1970
From: cworth@cworth.org (Carl Worth)
Date: Fri, 04 Sep 2009 08:12:01 -0700
Subject: [sup-talk] Ignore killed messages in U screen
In-Reply-To: <1252074924-sup-1994@masanjin.net>
References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin>
	<1252005520-sup-9555@zyrg.net>
	<1252010283-sup-4453@yoom.home.cworth.org>
	<1252074924-sup-1994@masanjin.net>
Message-ID: <1252076900-sup-274@yoom.home.cworth.org>

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