]> git.cworth.org Git - sup/commitdiff
general updates
authorwmorgan <wmorgan@5c8cc53c-5e98-4d25-b20a-d8db53a31250>
Tue, 26 Dec 2006 17:33:18 +0000 (17:33 +0000)
committerwmorgan <wmorgan@5c8cc53c-5e98-4d25-b20a-d8db53a31250>
Tue, 26 Dec 2006 17:33:18 +0000 (17:33 +0000)
git-svn-id: svn://rubyforge.org/var/svn/sup/trunk@96 5c8cc53c-5e98-4d25-b20a-d8db53a31250

doc/FAQ.txt
doc/Philosophy.txt
doc/TODO

index 3912a2ad0d27833782aef377075555a3fe8afd55..874e32b2a36811ebee48985473dbb7e2b4df549a 100644 (file)
@@ -1,28 +1,23 @@
 Sup FAQ
 -------
 Q: What does Sup stand for?
-A: "What's up?".
 
-Q: How is Sup even possible?
-A: Sup is only possible through the hard work of Dave Balmain, the
-   author of ferret.
+A: It stands for "what's up?", which is more or less the question I'm
+   asking when I read my mail.
+
+Q: If you love GMail so much, why not just use it?
 
-   I started using Ferret when it was still slightly buggy, and it
-   seemed like every week Dave released a bugfix or a speed
-   improvement that directly affected sup. Ferret has become a
-   first-class piece of software, and it's due to the tremendous
-   amount of time and effort he's put in to it.
+A: I hate using a mouse, and I hate ads, and I hate non-programmability
+   and non-extensibility.
 
 Q: Why the console?
-A: As the millions (ok, hundreds) of mutt users will tell you, there are
-   many advantages to the console:
-   - You don't need web browser.
-   - Instantaneous interaction.
-   - A few keystrokes can accomplish the work of a hundred mouse
-     clicks.
+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.
 
-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.
+   That said, a good Ajax programmer could probably replicate GMail
+   pretty easily using Sup as the backend.
 
 Q: How does Sup deal with spam?
 A: You can manually mark messages as spam, which prevents them from
@@ -38,3 +33,9 @@ A: That was Sup's original name. (Think pine, elm. Although I am a
    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.
+
index 83067f69713968a9c466d0c700d638c5642cf42d..78b559d050550c11eb973a42807c1af92384775e 100644 (file)
@@ -11,31 +11,36 @@ it. Keeping up with the all the new traffic is painful, even with
 Mutt's excellent threading features, simply because there's so much of
 it---a single thread can span several pages, and God help you if you
 lag behind. And Mutt is probably the best email client out there in
-terms of threading and mailing list support.
-
-The principle problem with traditional clients is that they place a
-high mental cost on the user for each incoming email, by forcing them
-to ask:
- - Should I keep this email, or delete it?
- - If I keep it, where should I file it?
-
-For example, I've spent the last 10 years of my life laboriously
-hand-filing every email message I received and feeling a mild sense of
-panic every time an email was both "from Mom" and "about school". The
-massive amounts of email that many people receive, and the cheap cost
-of storage, have made these questions both more costly and less useful
-to answer.
-
-As a long-time Mutt user, when I watched people use GMail, I saw them
-use email differently from how I had ever used it. I saw that making
-certain operations quantitatively easier (namely, search) resulted in
-a qualitative difference in usage. And I saw that thread-centrism had
-many advantages over message-centrism, especially when volume was high.
+terms of threading and mailing list support. God help me if I try and
+throw Thunderbird at that.
+
+The principle problem with traditional clients is that they deal with
+individual pieces of email, and place a high mental cost on the user
+for each incoming email, by forcing them to ask: Should I keep this
+email, or delete it?  If I keep it, where should I file it?
+
+I've spent the last 10 years of my life laboriously hand-filing every
+email message I received and feeling a mild sense of panic every time
+an email was both "from Mom" and "about school". The massive amounts
+of email that many people receive, and the cheap cost of storage, have
+made these questions both more costly and less useful to answer.
+
+As a long-time Mutt user, when I first watched people use GMail, I saw
+them use email differently from how I had ever used it. I saw that
+making certain operations quantitatively easier (namely, search)
+resulted in a qualitative difference in usage: you don't have to worry
+about filing correctly, because you can always find things later by
+search. And I saw that thread-centrism had many advantages over
+message-centrism when message volume was high.
 
 So, in many ways, I believe GMail has taken the right approach to
 handle both of the factors above, and much of the inspiration for Sup
-was based on GMail. Ultimately, GMail wasn't right for me, which is
-why the idea for Sup was born.
+was based on GMail. I think it's to the GMail designers' credit that
+they started with a somewhat ad-hoc idea (hey, we're really good at
+search engines, so can we build an email client on top of one?) and
+managed to build something that was actually better than everything
+else out there. But ultimately, GMail wasn't right for me (see FAQ),
+which is why the idea for Sup was born.
 
 Sup is based on the following principles, which I more or less stole
 directly from GMail:
@@ -44,15 +49,17 @@ directly from GMail:
   entire email archive eliminates most of the need for folders,
   and eliminates the necessity of having to ever delete email.
 
-- Labels eliminate the remaining need for folders.
+- Labels eliminate what little need for folders that search doesn't
+  eliminate.
 
 - A thread-centric approach to the UI is much more in line with how
-  people operate than dealing with individual messages is. A message
-  and its content deserve the same treatment in the vast majority
-  of cases.
+  people operate than dealing with individual messages is. In the vast
+  majority of cases, a message and its context should be subject to
+  the same treatment.
 
 Sup is also based on many ideas from mutt and Emacs and vi, having to
 do with the fantastic productivity of a console- and keyboard-based
 application, the usefulness of multiple buffers, the necessity of
 handling multiple email accounts, etc.
 
+Give it a go and let me know what you think.
index da6cd0d79253dcef53b0d51d48b297ac99478042..3c3fa28aaeed244499d075266b43aef2e382ae24 100644 (file)
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,3 +1,6 @@
+use Net::SMTP
+'R' to quick-resume most recent draft
+support different smtp servers per user account
 search for other messages from author in thread-view-mode
 forward attachments
 tab completion on labels, contacts
@@ -12,7 +15,11 @@ annotations on messages
 gmail
 pop
 move sup-import argument handling to getopt or something
+move sup-import username/password prompts to highline
+mark individual messages as spam in thread-view-mode
+support for message-content modules such as ruby-talk:XXXXX detection
 
+x mbox+ssh
 x handle broken sources better
 x imap
 x word wrap