Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] Ignore killed messages in U screen
Date: Thu, 03 Sep 2009 16:06:50 -0700	[thread overview]
Message-ID: <1252010283-sup-4453@yoom.home.cworth.org> (raw)
In-Reply-To: <1252005520-sup-9555@zyrg.net>

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>


  reply	other threads:[~2009-09-03 23:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-27 15:36 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1252010283-sup-4453@yoom.home.cworth.org \
    --to=cworth@cworth.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox