[sup-talk] Some comments on sup-0.6
luis at tieguy.org
Sat Aug 23 19:20:22 EDT 2008
Possibly of interest, Bart:
Luis (who isn't actually using sup, for many of the reasons you
listed, but remains a fascinated lurker)
On Sat, Aug 23, 2008 at 7:15 PM, Bart Schaefer
<barton.schaefer at gmail.com> wrote:
> "The goal of Sup is to become the email client of choice for nerds everywhere."
> I encountered sup a few days ago via a link on Justin Mason's blog,
> and it sounded interesting enough to try it out. There are quite a
> few things about it that I like, but there are a few things about it
> that currently are just plain show-stoppers. None of them is
> irreparable, but IMO taken together they almost disqualify it from
> being called an "email client" at this time.
> First the good stuff: I entirely approve of the choices of ideas to
> borrow from gmail, and the addition of being able to mark and coalesce
> threads is something I wish gmail would borrow back. The key bindings
> weren't too hard to figure out (and probably would have been easier if
> I'd used mutt more in the past). The expanding/collapsing views of
> threads and quoted messages work nicely most of the time. I could
> immediately see how sup could help me clean up the mess some of my
> mail stores have become, to find and conceal old stuff without
> completely losing track of it and prioritize important stuff. Great
> (At the same time, that last is what seems to be lacking in
> follow-through. See below.)
> One suggestion for an improvement on the gmail interface: Consider
> introducing a hierarchy syntax in labels. E.g., if I've got a label
> for "restaurants" I might create a label "restaurants/lunch" that
> means "first search for anything tagged restaraurants and then narrow
> by searching for anything also tagged lunch". In any UI that shows a
> list of the labels, collapse the heirarchy so that I don't have to see
> both "restaurants" and "restaurants/lunch" at the same time. This
> creates an interface familiar to users who are accustomed to having
> folders arranged hierarchically, without changing the search model
> that ultimately locates the referenced messages.
> (Is it possible to search for messages based on which source they came from?)
> Next some nits or minor problems, in no particular order ...
> The default color scheme is pretty terrible. (I did mention there'd be "nits".)
> When I widened my terminal window to try to see more of the preview
> text on the thread screen, sup didn't pick up on the size change.
> There's either no on-screen help for how one builds up a search
> expression, or it's simply too hard to find that help, and in
> particular it wasn't obvious how one searches for all messages having
> a certain label (I was expecting maybe something like gmail's
> label:Xyz syntax).
> It should be possible to create search that matches a label without
> finding other messages that happen to contain the same word (maybe it
> is possible and I just haven't figure out how yet).
> I happened to encounter a case of new mail arriving while I was using
> sup, wherein a colleague had replied to a message by editing the
> Subject such that his entire reply was there and the message body was
> empty. Sup collapsed this into the thread and hid his new subject
> behind the original subject. I had to bail out and switch over to
> alpine to figure out why he'd sent a seemingly empty message.
> OK, now the show stoppers.
> I have a LOT of IMAP folders (conservatively, hundreds), many of them
> in a shared hierarchy not under my control; sup's interface would be
> the perfect way to get a handle on these, but it would take me way too
> long to add them one by one as separate URL sources. At the moment
> sup might be described as phenomenal cosmic power in an itty-bitty
> living space.
> If you're going to have any hope of becoming the choice of nerds
> everywhere, you've got address the "play well with others" problem, at
> the very least with the IMAP INBOX, if not with other mailboxes.
> Forcing me to exit from sup and do a complete re-index whenever a
> message disappears is just not going to fly, particularly for a
> protocol that provides so many tools for keeping in sync. I know,
> this doesn't fit with the "never delete anything, just stop looking at
> it" model that sup wants to present, but in the real world even nerds
> can't store things in their inbox forever, and for it to really be THE
> email client of choice, I want to keep sup running for weeks at a time
> and never have a reason to leave the interface (except maybe to escape
> to a web browser or to drop into my editor when composing mail).
> By the same token, sup needs to be able to push deletion marks back up
> to the IMAP server and purge the mailbox. Even if you violate the
> IMAP usage model by implementing delete as some kind of move-to-trash
> operation, so that sup can keep indexing the trash, there has to be a
> way for the user to manage the size of his inbox without switching to
> some other means of accessing the server. And to really take
> advantage of sup's ability to search and classify to clean up my messy
> mail store, I need a way to permanently throw away all the spam and
> duplicate messages that have accumulated in the odd procmail-created
> corners of my folder space. It's even fine if the only way to do this
> is through IMAP or the like; sup does not need to incorporate the
> mechanics of local mailbox management.
> That's about it for impressions from a few hours of experimentation.
> I think sup shows great promise and I've joined the mailing list to
> keep track of its progress. Congratulations on what you've got so
> far, and I look forward to seeing more.
> sup-talk mailing list
> sup-talk at rubyforge.org
More information about the sup-talk