On Monday, July 6 at 08:33 AM, quoth Noah Slater:
It's probably best to just check out the Sup documentation: http://sup.rubyforge.org/Those screenshots that might help illustrate some of the differences.
Huh. I remember trying to use it once upon a time. Apparently my ruby install was insufficient. (Did I mention that I dislike needing to install some random language translator in order to use my email client?)
Personally, the critical mutt features that I cannot live without are hooks (send/reply/message/folder/etc.) and groups. For example, being able to have mutt automatically decide whether to use a MIME or inline PGP signature based on whether any of the recipients are in the "pine" group. Sup seems to have hooks... of a sort. They're ruby scripts (i.e. they make no sense without knowing ruby).
The MIME handling of Sup seems pretty bizarre. Rather than using ancient Unix tools like mime.types and mailcap, they decided to use ruby hooks. I mean, seriously, this is how you have to specify that you want to use w3m to decode HTML attachments (according to their wiki, http://sup.rubyforge.org/wiki/wiki.pl?Hooks):
unless sibling_types.member? "text/plain"
case content_type
when "text/html"
`/usr/bin/w3m -dump -T #{content_type} '#{filename}'`
end
end
<rant>
Well, obviously! Though, unless I misunderstand the idea of the
"sibling_types" structure, that's technically wrong. You can have a
multipart message with both text/html and text/plain that is not a
multipart/alternative message (i.e. where all the parts are intended
to be displayed *together*). Why mix MIME decoding rules with
MIME-type handling? The mailcap interface makes *much* more sense that
way:
text/html; w3m -dump -T text/html %s; copiousoutput
Yes, integrating MIME-decoding rules with MIME-type handling makes
more advanced things (like changing the way you handle
multipart/alternative messages based on the sender) a bit more
straightforward, but that's no excuse for making basic decoding extra
complicated. If you need to do something "advanced" it makes more
sense to me that that should be the subject of more advanced
configuration (e.g. muck with message-hooks to alter your
alternative_order).
I suppose that's all about balance, and Sup gets away with this sort of thing by saying "this is the mail client for nerds!". But I'm an email wonk, and I feel that I shouldn't have to know the ins and outs of the various multipart MIME rules just to read my email.
</rant>
Seems like Sup makes it a first class feature, and more advanced that Mairix.
I'd be thrilled if mutt gained one or two of Sup's searching features (personally, I like my idea for an interface: http://dev.mutt.org/trac/ticket/3031).
Mairix looks nifty, but for those of us that have all of our email on an IMAP server, it's somewhat less cool (yes, I could mirror it all locally with offlineimap, but I don't want to do that---it's a lot of disk space, and makes getting out of sync too easy).
I have one inbox and one archive mailbox, much like Gmail. This is the primary use case that Sup is designed for. This means that there is no real way for me to tag messages in mutt like I would in Gmail.
What's wrong with using an X-Label header? There's a patch (http://home.uchicago.edu/~dgc/mutt/) to make it easy to add labels, and then searching for them or limiting the display to just certain labels is pretty trivial (~y foo). Granted, it could probably be extended to use IMAP keywords instead of a header, but... think about it this way: it's *easy* to make that fast.
The four things that strike me as desirable would be: * A unified view for message threads.Have you ever used Gmail? It's pretty hard to describe without you having seen or used it. Basically, a whole thread is treated as a message type thing, occupies a single line in list views, and is navigable as a single thing when viewing. You can still reply to individual messages.
I use mutt's collapse-threads feature, which behaves a lot like you're describing.
set index_format="... %?M?[%M]> &?%s"
folder-hook . 'push <collapse-all>'
* The ability to tag messages, using some custom header.
Check out the X-Label patch.
This would necessarily include options for viewing in both message view and list view modes.
I'm not sure what you mean by this... If you want to be able to show the tag name in the $index_format, that's %y, and if you want to see it in the pager, thats equally easy (either use unignore to show the x-label header, or stick %y in the $pager_format). But I don't know what you mean by "message view" and "list view".
I would also want to be able to automatically tag messages based on content.
That's more of a job for your MDA, like procmail or maildrop. Unless what you mean is you want to be able to tag multiple messages at the same time.
Even if it decided that the automatic tagging of messages should be done by procmail, mutt should provide a utility script.
Why?
formail -i 'X-Label: foo'
* The ability to include message snippets in list view. http://sup.rubyforge.org/ss1.png
Ugh. To each their own, I suppose, but I find that hideous (and very outlook-express-like).
* Integration with an external search program made a first class feature.
Such as? You said you don't like Mairix, so what sort of external search program are you thinking of?
~Kyle --Selfishness is not living as one wishes to live, it is asking others to live as one wishes to live.
-- Oscar Wilde
Attachment:
pgpFwEG8FdxXM.pgp
Description: PGP signature