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 almost entirely due to him.
- It amazes me just how much time and effort he has put into it.
+ 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.
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 a bulky web browser.
- - You can ssh and check your mail on another machine.
+ - You don't need web browser.
- Instantaneous interaction.
- - A few keystrokes are worth a hundred mouse clicks.
+ - A few keystrokes can accomplish the work of a hundred mouse
+ clicks.
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.
-Must an email client have a philosophy? I think so. For many people,
-it is our primary means of communication. Something so important
-should warrant a little thought.
+Should an email client have a philosophy? I think so. For many people,
+email is our primary means of communication. Something so important
+ought to warrant a little thought.
So here's Sup's philosophy.
Anyone who's on a high-traffic mailing list knows this. My ruby-talk
folder is 350 megs and Mutt sits there for 60 seconds while it opens
it. Keeping up with the all the new traffic is painful, even with
-Mutt's excellent threading features, just because there's so much of
-it. A single thread can span several pages. And Mutt is probably the
-best email client out there in terms of threading and mailing list
-support.
+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
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 for the better!). I saw that
-thread-centrism had many advantages over message-centrism.
+a qualitative difference in usage. And I saw that thread-centrism had
+many advantages over message-centrism, especially when 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 using GMail. Of course, I don't ultimately like using
-GMail, which is why I created Sup in the first place.
+was based on GMail. Ultimately, GMail wasn't right for me, which is
+why the idea for Sup was born.
-Sup is based on the following principles, which I learned from GMail:
+Sup is based on the following principles, which I more or less stole
+directly from GMail:
- An immediately accessible and fast search capability over the
entire email archive eliminates most of the need for folders,
and its content deserve the same treatment in the vast majority
of cases.
-Sup is also based on many ideas from mutt (and Emacs and vi!), having
-to do with the fantastic productivity of a console- and key-based
-application, and the usefulness of multiple buffers, etc., and the
-necessity of handling multiple email accounts, but these features form
-less of the philosophy and more of the general usefulness of Sup.
-
+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.
projects / sup / commitdiff