doc/FAQ.txt in sup-0.0.6 vs doc/FAQ.txt in sup-0.0.7

- old
+ new

@@ -1,39 +1,76 @@ Sup FAQ ------- Q: What does Sup stand for? -A: It stands for "what's up?", which is more or less the question I'm - asking when I read my mail. +A: It stands for "what's up?", which is more or less the question in + mind when I fire up my mail client. Q: If you love GMail so much, why not just use it? -A: I hate using a mouse, and I hate ads, and I hate non-programmability +A: I hate ads, I hate using a mouse, and I hate non-programmability and non-extensibility. + Also, GMail encourages top-posting in a variety of ways. THIS + CANNOT BE TOLERATED! + Q: Why the console? -A: There are many advantages to the console. As any Unix user knows, a - few keystrokes can accomplish the work of a hundred mouse clicks. - Also, you don't need web browser, and you get instantaneous response - and a simple interface. - That said, a good Ajax programmer could probably replicate GMail - pretty easily using Sup as the backend. +A: Because a keystroke is with a hundred mouse clicks (as any Unix + user knows). Because you don't need web browser. Because you get + instantaneous response and a simple interface. Q: How does Sup deal with spam? A: You can manually mark messages as spam, which prevents them from - showing up in future searches, but that's all that Sup does. Spam + showing up in future searches, but that's as far as Sup goes. Spam filtering should be done by a dedicated tool like SpamAssassin. +Q: How do I delete a message? +A: Press the 'd' key. + +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: Deleting a message is an old-fashioned concept. In the modern + world, disk space is cheap enough that you should never have to + delete a message. If it's spam, save it for future analysis. + +Q: C'mon, really now! +A: Ok, at some point I plan to have a batch deletion tool that will + run through a source and delete all messages that have a 'spam' or + 'deleted' tags (and, for mbox sources, will update the offsets of + all later messages). But that doesn't exist yet. + +Q: I got some error message about needing to run sup-import --rescan + 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, even reading a 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 run sup-import --rescan. + + The alternative is to rescan every source when Sup starts + up. Because Sup is designed to work with arbitrarily large mbox + files, this would not be a good idea. + 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. 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: 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), sup-import + --rebuild both sources at once. If you do it one at a time, you may + lose message state. (Depending, actually, on which order you do it + in. But just do them both at once.) + 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. -