From: 5srmspw02@sneakemail.com (Guarded Identity)
Subject: [sup-talk] rethinking sup part ii
Date: Sat, 26 Jul 2008 02:32:17 -0500 [thread overview]
Message-ID: <14658-35025@sneakemail.com> (raw)
In-Reply-To: <1217001070-sup-9401@entry>
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
next prev parent reply other threads:[~2008-07-26 7:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-20 21:33 William Morgan
2008-07-20 23:28 ` Guillaume Quintard
2008-07-21 0:04 ` William Morgan
2008-07-21 5:43 ` Guillaume Quintard
2008-07-21 12:14 ` Peter Krenn
2008-07-21 15:22 ` William Morgan
2008-07-21 15:26 ` Stephen Patterson
2008-07-21 16:04 ` John Bent
2008-07-22 2:12 ` William Morgan
2008-07-23 17:40 ` Nicolas Pouillard
2008-07-23 22:26 ` William Morgan
2008-07-24 9:16 ` Nicolas Pouillard
2008-07-21 18:43 ` Lionel Ott
2008-07-23 8:45 ` Richard Heycock
2008-07-23 8:58 ` Nicolas Pouillard
2008-07-23 9:27 ` teroz
2008-07-23 21:41 ` Richard Heycock
2008-07-23 17:09 ` William Morgan
2008-07-25 12:11 ` Marcus Williams
2008-07-24 4:55 ` Guarded Identity
2008-07-24 9:21 ` Nicolas Pouillard
2008-07-25 16:00 ` William Morgan
2008-07-26 7:32 ` Guarded Identity [this message]
2008-07-25 7:18 ` William Morgan
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=14658-35025@sneakemail.com \
--to=5srmspw02@sneakemail.com \
/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