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.
-