From mboxrd@z Thu Jan  1 00:00:00 1970
From: 5srmspw02@sneakemail.com (Guarded Identity)
Date: Sat, 26 Jul 2008 02:32:17 -0500
Subject: [sup-talk] rethinking sup part ii
In-Reply-To: <1217001070-sup-9401@entry>
References: <1216589569-sup-1520@entry> <18084-90829@sneakemail.com>
	<1216891009-sup-9628@ausone.inria.fr> <1217001070-sup-9401@entry>
Message-ID: <14658-35025@sneakemail.com>

Excerpts from William Morgan's message of Fri Jul 25 11:00:40 -0500 2008:
>
> Reformatted excerpts from nicolas.pouillard's message of 2008-07-24:
  >
> > Here is another big design decision, note that some labels are truly
> > message based:
> >
> >   * unread: of course
> >   * spam: to be sure that a spam message a response to a ham message
> >     don't throw away the whole thread.
> >   * starred: sometime it's there to highlight a message and sometimes
> >     to select the whole thread.
>
> What's interesting about the labels you've listed is that they all have
> special semantics, i.e. the server or the client does something special
> based on whether they're present.
>
> Do people have "user" labels that they use to distinguish individual
> messages, as opposed to individual threads?

I got away with applying the "spam" label at the thread level because I never
get any spam that's actually part of a thread; it's normally just a stand-alone
piece of mail.

I'm not sure what other people use starring for, but I just use it to highlight
things I need to reply to, and for that purpose, it works fine at a
thread-level because most threads only have one response I'm interested in
issuing.  But I guess I've seen some of those gigantic threads, so maybe
starring at the message-level /might/ be useful, but I'd not sweat it if it
wasn't possible.

Even for "unread", I get away just managing it at the thread-level, because I'm
generally marking an entire thread as read.  However, I'd imagine someone might
want to revert the unread status of part of a thread.  However, that would be a
nightmare for a large thread.  In that case, I'd probably just use the "@"
key-binding to revert labels.

So all in all, I never use message-level labels, even though I get understand
the instance in which they're needed.  The major reason for this is that the
presentation of the search is at the thread level, so it makes little sense to
think of labels at the message level.

> If not, we could have labels only on threads by having a bunch of
> boolean flags on messages: read/unread, spam/ham, starred/regular,
> draft/not-draft, etc. The search syntax would probably change for those
> features.

This is /exactly/ what I'm hoping for.  I could probably come up with other
hypothetical abstractions for indexing, but I'm happy as long as at the end of
the day I get negation in reasonably fast searches.  I know it sounds like a
feature that not everyone might use, but the more messages I put in the index,
the more I find I myself trying to make use of negation to prune searches.
Also, sometimes I like to manage Sup with scripts and having negation allows me
to do some more cool things without having to bother William with feature
requests for the odd message/label-managing tasks I have.

Hopefully you can continue brain-storming what design you want to do to support
this.  If you run into a problem, maybe we can jump into the design then.

> > Since  there  is  mandatory  requirements  for message based labels
> > and thread based  labels,  one can provide both. Perhaps a syntactic
> > distinction would be sufficient:
> >   * a case distinction: INBOX vs unread
> >   * a special mark: inbox* vs unread (here the star means the
> >     repetition on all messages of the thread).
>
> Having both would be possible too, but it seems overly complicated to
> me. I think that's my least favorite option right now.

Yeah, I was trying to think of a way to manage both, and it felt like a kludge.
Personally, I like the idea of managing as much as we can at the thread-level.

-Sukant