sup 0.0.5 → 0.0.6

data/History.txt

@@ -1,3 +1,6 @@
+== 0.0.6 / 2007-01-06
+* Very minor fix to support more types of IMAP authentication.
+
 == 0.0.5 / 2007-01-05
 
 * More bugfixes, primarily for IMAP.

data/doc/FAQ.txt

@@ -1,12 +1,10 @@
 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.
 
 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
    and non-extensibility.
 

data/doc/Philosophy.txt

@@ -1,6 +1,6 @@
 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.
+email is one of our primary means of communication. Something so
+important ought to warrant a little thought.
 
 So here's Sup's philosophy.
 
@@ -9,38 +9,42 @@ 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, 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. God help me if I try and
-throw Thunderbird at that.
+it. A single thread can span several pages in the folder index view
+alone! And Mutt is probably the fastest email client out there, and
+the most featureful and in 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
+individual pieces of email. This places 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?
+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.
 
-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.
+I think GMail has taken the right approach. As a long-time Mutt user,
+I was blown away when I first saw people use GMail, because I saw them
+treat their email differently from how I had ever treated mine. I saw
+that making certain operations quantitatively easier (namely, search)
+resulted in a qualitative difference in usage. Uou didn't have to
+worry about filing things into folders correctly, because you could
+just find things later by searching for them. I also saw that
+thread-centrism had many advantages over message-centrism when message
+volume was high.
 
-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.
+Much of the inspiration for Sup 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 maybe we can build
+an email client on top of one) and managed to build something that was
+actually better than everything else out there. At least, that's how I
+imagine in happened. Maybe they knew what they were doing from the
+start.
 
-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. 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.
+But 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 more or less stole
 directly from GMail:
@@ -49,8 +53,7 @@ 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 what little need for folders that search doesn't
-  eliminate.
+- Labels eliminate what little need for folders search doesn't cover.
 
 - A thread-centric approach to the UI is much more in line with how
   people operate than dealing with individual messages is. In the vast
@@ -60,6 +63,6 @@ directly from GMail:
 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.
+handling multiple email accounts, etc. But those are just details!
 
-Give it a go and let me know what you think.
+So give it a go and let me know what you think.

data/doc/TODO

@@ -1,4 +1,6 @@
+fix bug: when returning from a shelling out, ncurses is crazy 
 batch deletion
+maildir
 on startup, multi-threadedly call #connect on all sources 
 support for message-content modules such as ruby-talk:XXXXX detection
 use Net::SMTP
@@ -18,6 +20,7 @@ pop
 move sup-import argument handling to getopt
 be able to mark individual messages as spam in thread-view-mode
 
+x fix bug: envelope-to thing still not working
 x fix snippet repetitions with small snippets
 x fix next and previous in thread-view-mode with <unreceived messages>
 x move sup-import username/password prompts to highline

data/doc/UserGuide.txt

@@ -73,9 +73,9 @@ Search and labels are an integral part of Sup because in Sup, rather
 than viewing the contents of a folder, you view the results of a
 search. I mentioned above that your inbox is, by definition, the set
 of all messages that aren't archived. This means that your inbox is,
-in fact, the result of the search for "all messages without the label
-'archive'". It's actually slightly more complicated---we omit killed,
-deleted and spam messages as well.
+in fact, the result of the search for all messages with the label
+"inbox". (It's actually slightly more complicated---we omit killed,
+deleted and spam messages as well.)
 
 So you could replicate the folder paradigm easily under this scheme,
 by giving each message exactly one label and only viewing the results

data/lib/sup.rb

@@ -13,7 +13,7 @@ class Object
 end
 
 module Redwood
-  VERSION = "0.0.5"
+  VERSION = "0.0.6"
 
   BASE_DIR   = ENV["SUP_BASE"] || File.join(ENV["HOME"], ".sup")
   CONFIG_FN  = File.join(BASE_DIR, "config.yaml")

data/lib/sup/imap.rb

@@ -112,7 +112,21 @@ class IMAP < Source
         #raise Net::IMAP::ByeResponseError, "simulated imap failure"
         @imap = Net::IMAP.new host, port, ssl?
         say "Logging in..."
-        @imap.authenticate 'LOGIN', @username, @password
+
+        ## although RFC1730 claims that "If an AUTHENTICATE command
+        ## fails with a NO response, the client may try another", in
+        ## practice it seems like they will also send BAD responses.
+        begin
+          @imap.authenticate 'CRAM-MD5', @username, @password
+        rescue Net::IMAP::BadResponseError, Net::IMAP::NoResponseError => e
+          Redwood::log "CRAM-MD5 authentication failed: #{e.class}. Trying LOGIN auth..."
+          begin
+            @imap.authenticate 'LOGIN', @username, @password
+          rescue Net::IMAP::BadResponseError, Net::IMAP::NoResponseError => e
+            Redwood::log "LOGIN authentication failed: #{e.class}. Trying plain-text LOGIN..."
+            @imap.login @username, @password
+          end
+        end
         scan_mailbox
         say "Successfully connected to #{@parsed_uri}."
       rescue SocketError, Net::IMAP::Error, SourceError => e
@@ -190,7 +204,7 @@ private
     message =
       case e
       when Exception
-        "Error while #{opts[:while]}: #{e.message.chomp}."
+        "Error while #{opts[:while]}: #{e.message.chomp} (#{e.class.name})."
       when String
         e
       end
@@ -199,7 +213,7 @@ private
 
     self.broken_msg = message
     Redwood::log message
-    BufferManager.flash "Error communicating with IMAP server. See log for details."
+    BufferManager.flash "Error communicating with IMAP server. See log for details." if BufferManager.instantiated?
     raise SourceError, message
   end
   

data/lib/sup/mbox/loader.rb

@@ -106,7 +106,7 @@ class Loader < Source
         @f.gets # now we're at a BREAK_RE, so skip past it
       else # case 2
         returned_offset = cur_offset
-        ## we've already skipped past the BREAK_RE, to just go
+        ## we've already skipped past the BREAK_RE, so just go
       end
 
       while(line = @f.gets)

data/lib/sup/source.rb

@@ -3,26 +3,48 @@ module Redwood
 class SourceError < StandardError; end
 
 class Source
-  ## dirty? described whether cur_offset has changed, which means the
-  ## source needs to be re-saved to disk.
+  ## Implementing a new source is typically quite easy, because Sup
+  ## only needs to be able to:
+  ##  1. See how many messages it contains
+  ##  2. Get an arbirtrary message
+  ##  3. (optional) see whether the source has marked it read or not
   ##
-  ## broken? means no message can be loaded, e.g. IMAP server is
-  ## down, mbox file is corrupt and needs to be rescanned.
-
-  ## When writing a new source, you should implement:
+  ## In particular, Sup doesn't need to move messages, mark them as
+  ## read, delete them, or anything else. (Well, maybe delete at some
+  ## point.)
   ##
-  ## start_offset
-  ## end_offset
-  ## load_header(offset)
-  ## load_message(offset)
-  ## raw_header(offset)
-  ## raw_full_message(offset)
-  ## next (or each, if you prefer)
-
-  ## you can throw SourceErrors from any of those, but we don't catch
-  ## anything else, so make sure you catch all non-fatal errors and
-  ## reraise them as source errors.
+  ## On the other hand, Sup assumes that you can assign each message a
+  ## unique integer id, such that newer messages have higher ids than
+  ## earlier ones, and that those ids stay constant across sessions
+  ## (in the absence of some other client going in and fucking
+  ## everything up). For example, for mboxes I use the file offset of
+  ## the start of the message. If a source does NOT have that
+  ## capability, e.g. IMAP, then you have to do a little more work to
+  ## simulate it.
+  ##
+  ## To write a new source, subclass this class, and should implement:
+  ##
+  ## - start_offset
+  ## - end_offset
+  ## - load_header offset
+  ## - load_message offset
+  ## - raw_header offset
+  ## - raw_full_message offset-
+  ## - next (or each, if you prefer)
+  ##
+  ## You can throw SourceErrors from any of those, but we don't catch
+  ## anything else, so make sure you catch *all* errors and reraise
+  ## them as SourceErrors, and set broken_msg to something if the
+  ## source needs to be rescanned.
+  ##
+  ## Also, be sure to make the source thread-safe, since it WILL be
+  ## pummeled from multiple threads at once.
 
+  ## dirty? described whether cur_offset has changed, which means the
+  ## source info needs to be re-saved to sources.yaml.
+  ##
+  ## broken? means no message can be loaded, e.g. IMAP server is
+  ## down, mbox file is corrupt and needs to be rescanned, etc.
   bool_reader :usual, :archived, :dirty
   attr_reader :uri, :cur_offset, :broken_msg
   attr_accessor :id

metadata

@@ -3,8 +3,8 @@ rubygems_version: 0.8.11
 specification_version: 1
 name: sup
 version: !ruby/object:Gem::Version 
-  version: 0.0.5
-date: 2007-01-05 00:00:00 -08:00
+  version: 0.0.6
+date: 2007-01-06 00:00:00 -08:00
 summary: A console-based email client with the best features of GMail, mutt, and emacs. Features full text search, labels, tagged operations, multiple buffers, recent contacts, and more.
 require_paths: 
 - lib