doc/FAQ.txt in sup-0.1 vs doc/FAQ.txt in sup-0.2

- old
+ new

@@ -2,25 +2,26 @@ ------- 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! Q: Why the console? A: Because a keystroke is worth a hundred mouse clicks, as any Unix @@ -41,21 +42,20 @@ Q: But I want to delete it for real, not just add a 'deleted' flag in the index. I want it gone from disk! 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-dump > <dumpfile> This will save all message state in a big text file, which you @@ -64,47 +64,39 @@ Q: How do I restore the message state I saved in my state dump? A: 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. Q: I want to move messages from one source to another. (E.g., my primary inbox is an IMAP server with a quota, and I want to move 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 --------------- P: I see this message from Ferret: