Q: What is Sup?
A: Sup is a console-based email client for people with a lot of email.
It supports tagging, very fast full-text search, automatic contact-
- list management, and more. If you're the type of person who treats
- email as an extension of your long-term memory, Sup is for you.
+ list management, custom code insertion via a hook system, and more.
+ If you're the type of person who treats email as an extension of your
+ long-term memory, Sup is for you.
Q: What does Sup stand for?
A: "What's up?"
-Q: Sup looks a lot like a text-based Gmail.
-A: I stole a lot of their ideas. And improved upon them, of course.
+Q: Sup looks like a text-based Gmail.
+A: I stole their ideas. And improved them!
-Q: If you love Gmail so much, why not just use it?
-A: I hate ads, I hate using a mouse, and I hate non-programmability
- and non-extensibility.
+Q: Why not just use Gmail?
+A: I wrote Sup because I hate ads, I hate using a mouse, and I hate
+ non-programmability and non-extensibility.
Also, Gmail doesn't let you use a monospace font, which is just
- plain lame.
+ lame.
Also, Gmail encourages top-posting. THIS CANNOT BE TOLERATED!
A: Currently, for mbox sources, there is a batch deletion tool that
will strip out all messages marked as spam or deleted.
-Q: I got some error message about needing to run sup-sync --changed
- when I tried to read a message. What's that about?
-A: If messages have been moved, deleted, or altered in a source, Sup
- may have to rebuild its index for that source. For example, for
- mbox files, reading a single unread message changes the offsets of
- every file on disk. Rather than rescanning every time, Sup assumes
- sources don't change except by having new messages added. If that
- assumption is violated, you'll have to sync the index.
+Q: How well does Sup play with other mail clients?
+A: Not well at all. If messages have been moved, deleted, or altered
+ due to some other client, Sup will have to rebuild its index for
+ that message source. For example, for mbox files, reading a single
+ unread message changes the offsets of every file on disk. Rather
+ than rescanning every time, Sup assumes sources don't change except
+ by having new messages added. If that assumption is violated,
+ you'll have to sync the index.
Q: How do I back up my index?
-Q: How do I make a state dump?
A: Since the contents of the messages are recoverable from their
sources using sup-sync, all you need to back up is the message
state. To do this, simply run:
sup-sync [<source>+] --restored --restore <dumpfile>
where <dumpfile> was created as above.
-Q: I upgraded Ferret and the index format changed. I need to
- completely rebuild my index. How do I do this?
Q: Ferret crashed and I can't read my index. Luckily I made a state
dump. What should I do?
-A: First, you'll need a complete state dump. If you haven't made
- one, you'll need to downgrade Ferret and make a state dump as
- above. Then run these commands:
+Q: How do I rebuild the index completely?
+A: Run:
rm -rf ~/.sup/ferret # omg wtf
sup-sync --all-sources --all --restore <dumpfile>
Voila! A brand new index.
some of those messages to local mbox files.) How do I do that while
preserving message state?
A: Move the messages from the source to the target using whatever tool
- you'd like. Then (and this is the important part), run:
+ you'd like. Mutt's a good one. :) Then run:
sup-sync --changed <source1> <source2>
- If you sup-sync only one source at a time, depending on the order,
- the messages may be treated as missing and then deleted from the
- index, which means that their states will be lost when you sync the
- other source.
+ Note that if you sup-sync only one source at a time, depending on
+ the order in which you do it, the messages may be treated as
+ missing and then deleted from the index, which means that their
+ states will be lost when you sync the other source. So do them both
+ in one go.
Q: What are all these "Redwood" references I see in the code?
-A: That was Sup's original name. (Think pine, elm. Although I am a
- Mutt user, I couldn't think of a good progression there.) But it was
- taken by another project on RubyForge, and wasn't that original,
- and was too long to type anyways.
+A: That was Sup's original name. (Think pine, elm. Although I was a
+ Mutt user, I couldn't think of a good progression there.) But it
+ was taken by another project on RubyForge, and wasn't that
+ original, and was too long to type anyways.
Maybe one day I'll do a huge search-and-replace on the code, but it
doesn't seem that important at this point.
-Q: How is Sup possible?
-A: Sup is only possible through the hard work of Dave Balmain, the
- author of ferret, which is the search engine behind Sup. Ferret is
- really a first-class piece of software, and it's due to the
- tremendous amount of time and effort he's put in to it.
-
Common Problems
---------------
keyboard commands, but in the absence of any email, these will be
mostly useless. When you get bored, press 'q' to quit.
-To actually use Sup for email, we need to load messages into the
-index. The index is where Sup stores all message state (e.g. read or
-unread, any message labels), and all information necessary for
-searching and for threading messages. Sup only knows about messages in
-its index.
+To use Sup for email, we need to load messages into the index. The
+index is where Sup stores all message state (e.g. read or unread, any
+message labels), and all information necessary for searching and for
+threading messages. Sup only knows about messages in its index.
We can add messages to the index by telling Sup about the "source"
where the messages reside. Sources are things like IMAP folders, mbox
- Star an individual message, not just a thread
There's one last thing to be aware of when using Sup: how it interacts
-with other email programs. As I described at the beginning of the
-document, Sup stores data about messages in the index, but doesn't
-duplicate the message contents themselves. The messages remain on the
-source. If the index and the source every fall out of sync, e.g. due
-to another email client modifying the source, then Sup will be unable
-to operate on that source. For example, for mbox files, Sup stores a
-byte offset into the file for each message. If a message deleted from
-that file by another client, or even marked as read (yeah, mbox
-sucks), all succeeding offsets will be wrong.
+with other email programs. As I described above, Sup stores data about
+messages in the index, but doesn't duplicate the message contents
+themselves. The messages remain on the source. If the index and the
+source every fall out of sync, e.g. due to another email client
+modifying the source, then Sup will be unable to operate on that
+source. For example, for mbox files, Sup stores a byte offset into the
+file for each message. If a message deleted from that file by another
+client, or even marked as read (yeah, mbox sucks), all succeeding
+offsets will be wrong.
That's the bad news. The good news is that Sup is pretty good at being
able to detect this type of situation, and fixing it is just a matter
complication you will almost certainly run in to if you use both Sup
and another MUA on the same source, so it's good to be aware of it.
-Have fun, and let me know if you have any problems. --William
+Have fun, and let me know if you have any problems!
Appending A: sup-add and sup-sync
---------------------------------
Before you add the source, you need make three decisions. The first is
whether you want Sup to regularly poll this source for new messages.
By default it will, but if this is a source that will never have new
-messages, you can specify --unusual. Sup polls only "usual" sources.
+messages, you can specify --unusual. Sup polls only "usual" sources
+when checking for new mail (unless you manually invoke sup-sync).
The second is whether you want messages from the source to be
automatically archived. An archived message will not show up in your
all imported messages as read; the default is to preserve the
read/unread status from the source.
-sup-sync will now load all the messages from the source into the
+Sup-sync will now load all the messages from the source into the
index. Depending on the size of the source, this may take a while.
Don't panic! It's a one-time process.
-Appending B: Handling high-volume mailing lists
------------------------------------------------
+Appendix B: Handling high-volume mailing lists
+----------------------------------------------
Here's what I recommend:
1. Use procmail to filter messages from the list into a distinct source.
searching for that label.
+Appendix C: Reading blogs with Sup
+----------------------------------
+Really, blog posts should be read like emails are read---you should be
+able to mark them as unread, flag them, label them, etc. Use rss2email
+to transform RSS feeds into emails, direct them all into a source, and
+add that source to Sup. Voila!
<p>
Sup is a console-based email client for people with a lot of email.
- It supports tagging, very fast full-text search, automatic
- contact-list management, and more. If you're the type of person
- who treats your email client as an extension of your long-term memory,
- Sup is for you.
+ It supports tagging, very fast full-text search, automatic contact-
+ list management, custom code insertion via a hook system, and more.
+ If you're the type of person who treats email as an extension of your
+ long-term memory, Sup is for you.
</p>
<p>
and the <a href="Philosophy.txt">philosophical statement</a>.
</p>
+ <p> Please also read and contribute to the <a href="http://sup.rubyforge.org/wiki/wiki.pl">Sup wiki</a>, </p>
+
<h2>Status</h2>
<p>
The current version of Sup is 0.1, released 2007-07-17. This is a
- beta release. It supportsm box, mbox over ssh, IMAP, IMAPS, and Maildir. It does not support POP
- or Gmail accounts yet.
+ beta release. It supports mbox, mbox over ssh, IMAP, IMAPS, and Maildir accounts.
</p>
<p>
projects / sup / commitdiff