sup

community/pipermail-archives/sup-talk/2009-06.txt (434267B) - raw

 From ezyang@MIT.EDU  Mon Jun  1 19:18:26 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 01 Jun 2009 19:18:26 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 Message-ID: <1243898254-sup-7513@javelin>
 
 Hello,
 
 I'm attempting to create a reply-from.rb hook that looks like this:
 
 if message.has_label? 'twp':
     Person.from_address "Edward Z. Yang <edwardzyang at thewritingpot.com>"
 end
 
 Unfortunately, it doesn't seem to work. I'm running sup v0.7.
 
 Cheers,
 Edward
 
 From dom.lobue@gmail.com  Mon Jun  1 21:54:58 2009
 From: dom.lobue@gmail.com (Dominic LoBue)
 Date: Mon, 1 Jun 2009 18:54:58 -0700
 Subject: [sup-talk] Need help with OfflineIMAP integration and Iconv errors
 Message-ID: <93de24940906011854m70b8511cv139d0c7a830fc914@mail.gmail.com>
 
 Hello,
 
 Let me start off by saying that I am incredibly impressed with sup.
 I'm really looking forward to being able to replace Outlook with Sup,
 but I'm running into some problems that are preventing a complete
 transition.
 
 The first problem I'm having is when ferret is parsing through my
 emails to build its indicies I get numerous "warning: error
 (Iconv::IllegalSequence) decoding message body from X" errors, This
 prevents a lot of my email from showing up at all. Iconv has this
 problem from attempting to convert from Windows-1252, UTF-8, and
 iso-8859-1. While I doubt its the cause of the problem, I am
 downloading my email from the Exchange 2003 server at work via
 OfflineIMAP.
 
 The other major problem I'm running into is I can't figure out how to
 get Sup and OfflineIMAP talking together correctly so that labels and
 Seen flags are uploaded back to the Exchange server. I read that there
 were no plans to support uploading meta-data back to IMAP servers, so
 I was hoping that OfflineIMAP would sidestep the problem entirely. I
 searched the archives but I didn't find any examples of working
 configs.  If anyone can point me to a working example I'd greatly
 appreciate it.
 
 I've tried both the latest official release and the latest revision
 uploaded to github as of 20 minutes ago.
 
 Any help would be greatly appreciated!
 Dominic LoBue
 
 From wmorgan-sup@masanjin.net  Tue Jun  2 10:54:23 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 02 Jun 2009 07:54:23 -0700
 Subject: [sup-talk] utf patch needs work, i think
 In-Reply-To: <1243731497-sup-5619@entry>
 References: <1243539136-sup-9008@ntdws12.chass.utoronto.ca>
 	<1243553511-sup-472@ntdws12.chass.utoronto.ca>
 	<1243731497-sup-5619@entry>
 Message-ID: <1243954348-sup-1644@entry>
 
 Reformatted excerpts from William Morgan's message of 2009-05-30:
 > I suspect there's something like a tab or a weird character coming out
 > of the decoding (which appears to be some non-utf16 text claiming a
 > utf16 big-endian encoding) that is screwing with Ncurses.
 
 I've committed some changes that should remove invalid characters
 for your encoding before display. I think this should help. Also
 various display tweaks to account for multibyte characters. I still
 see some inconsistencies but I think it's getting better.
 
 That message renders "fine" for me now. (A bunch of nonsense Chinese
 characters mixed with some boxes.) I'm using utf8 in a gnome-terminal.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marka@pobox.com  Tue Jun  2 12:29:13 2009
 From: marka@pobox.com (Mark Alexander)
 Date: Tue, 02 Jun 2009 09:29:13 -0700
 Subject: [sup-talk] [PATCH] Handle nil charset on attachments.
 Message-ID: <1243959935-sup-8233@r50p>
 
 I updated to the latest 'next' branch of sup
 this morning, and immediately ran into a crash
 when viewing a message with an attachement, which
 was probably sent by an Outlook user.  The crash
 was due to a nil charset; this patch fixes the crash.
 ---
  lib/sup/message-chunks.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
 index 3f57346..41d924b 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -98,7 +98,7 @@ EOS
        text =
          case @content_type
          when /^text\/plain\b/
 -          Iconv.easy_decode $encoding, encoded_content.charset, @raw_content
 +          Iconv.easy_decode $encoding, encoded_content.charset || $encoding, @raw_content
          else
            HookManager.run "mime-decode", :content_type => content_type,
                            :filename => lambda { write_to_disk },
 
 From wmorgan-sup@masanjin.net  Tue Jun  2 12:46:00 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 02 Jun 2009 09:46:00 -0700
 Subject: [sup-talk] [PATCH] Handle nil charset on attachments.
 In-Reply-To: <1243959935-sup-8233@r50p>
 References: <1243959935-sup-8233@r50p>
 Message-ID: <1243961075-sup-6760@entry>
 
 Reformatted excerpts from Mark Alexander's message of 2009-06-02:
 > I updated to the latest 'next' branch of sup this morning, and
 > immediately ran into a crash when viewing a message with an
 > attachement, which was probably sent by an Outlook user. The crash
 > was due to a nil charset; this patch fixes the crash.
 
 Sloppy of me. Applied, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ingmar.stdin@gmail.com  Tue Jun  2 18:09:16 2009
 From: ingmar.stdin@gmail.com (Ingmar Vanhassel)
 Date: Wed, 03 Jun 2009 00:09:16 +0200
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1243898254-sup-7513@javelin>
 References: <1243898254-sup-7513@javelin>
 Message-ID: <1243980495-sup-7229@cannonball>
 
 Excerpts from Edward Z. Yang's message of Tue Jun 02 01:18:26 +0200 2009:
 > Hello,
 > 
 > I'm attempting to create a reply-from.rb hook that looks like this:
 > 
 > if message.has_label? 'twp':
 >     Person.from_address "Edward Z. Yang <edwardzyang at thewritingpot.com>"
 > end
 
 if message.has_label? twp
     Person.from_address "Edward Z. Yang <edwardzyang at thewritingpot.com>"
 end
 
 > Unfortunately, it doesn't seem to work. I'm running sup v0.7.
 
 If the above doesn't work, post some relevant error output.
 
 > Cheers,
 > Edward
 
 Regards,
 Ingmar
 
 From ezyang@MIT.EDU  Tue Jun  2 22:54:02 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Tue, 02 Jun 2009 22:54:02 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1243980495-sup-7229@cannonball>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 Message-ID: <1243997614-sup-7485@javelin>
 
 Excerpts from Ingmar Vanhassel's message of Tue Jun 02 18:09:16 -0400 2009:
 > If the above doesn't work, post some relevant error output.
 
 It silently fails. Is there any Sup way of making debug messages in
 hooks?
 
 Cheers,
 Edward
 
 From bwalton@artsci.utoronto.ca  Wed Jun  3 07:44:24 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 03 Jun 2009 07:44:24 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1243997614-sup-7485@javelin>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 Message-ID: <1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 
 Excerpts from Edward Z. Yang's message of Tue Jun 02 22:54:02 -0400 2009:
 
 > It silently fails. Is there any Sup way of making debug messages in
 > hooks?
 
 Redwood::log "my message"
 
 Then, look in the log buffer.
 
 HTH.
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090603/2d66ef11/attachment.bin>
 
 From ezyang@MIT.EDU  Wed Jun  3 13:39:40 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 03 Jun 2009 13:39:40 -0400
 Subject: [sup-talk] Sup is hanging
 Message-ID: <1244050695-sup-5990@javelin>
 
 Hey all,
 
 Somehow, I messed something up really bad, and now, whenever Sup
 attempts to poll for new messages, it hang completely, spinning the
 CPU.  I've let it run for an appreciable amount of time, and haven't
 seen any change.  I was wondering how I could fix this, or go about
 debugging it.  There also seems to be a single mail source at fault,
 but I can't remove it without having Sup complain at me.  Right now,
 I'm running sup as -no.
 
 Thanks,
 Edward
 
 From wmorgan-sup@masanjin.net  Wed Jun  3 14:11:28 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 03 Jun 2009 11:11:28 -0700
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244050695-sup-5990@javelin>
 References: <1244050695-sup-5990@javelin>
 Message-ID: <1244052318-sup-6595@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
 > Somehow, I messed something up really bad, and now, whenever Sup
 > attempts to poll for new messages, it hang completely, spinning the
 > CPU.  I've let it run for an appreciable amount of time, and haven't
 > seen any change.  I was wondering how I could fix this, or go about
 > debugging it.
 
 Is the curses interface hung? If not, can you see if there's activity in
 the poll mode or the log mode buffers? (Hit ; if you're running from
 git, or B if you're running 0.7.) It might be that you've somehow reset
 the recorded offset for a very large source, so Sup is polling a lot of
 stuff in the background.
 
 If it's completely hung (which would be weird), try first disabling your
 hooks (move them from ~/.sup/hooks to another directory) and see if that
 helps. If not, please describe the behavior of running sup-sync.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Wed Jun  3 14:21:35 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 03 Jun 2009 14:21:35 -0400
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244050695-sup-5990@javelin>
 References: <1244050695-sup-5990@javelin>
 Message-ID: <1244053108-sup-4982@javelin>
 
 The current working theory (based on strace'ing and lsof) is that Sup
 is hanging on a select() call that doesn't have any timeout.  The reason
 why this is hanging is because between opening the connection and
 closing it, Sup does some ridiculously slow message parsing code (that
 really thrashes the CPU) and by the time it's done the server has
 closed the connection (but we don't know about it).  The fix would probably
 be to always set a timeout, but I don't know what code needs to be fixed
 for that.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Wed Jun  3 14:26:44 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 3 Jun 2009 14:26:44 -0400 (EDT)
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244052318-sup-6595@entry>
 References: <1244050695-sup-5990@javelin> <1244052318-sup-6595@entry>
 Message-ID: <alpine.DEB.2.00.0906031425430.6338@javelin>
 
 On Wed, 3 Jun 2009, William Morgan wrote:
 > Is the curses interface hung?>
 
 Yep.
 
 > If it's completely hung (which would be weird), try first disabling your
 > hooks (move them from ~/.sup/hooks to another directory) and see if that
 > helps. If not, please describe the behavior of running sup-sync.
 
 I can try that. I've described the behavior of sup-sync in my other
 email.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Wed Jun  3 14:45:59 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 3 Jun 2009 14:45:59 -0400 (EDT)
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244053108-sup-4982@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 Message-ID: <alpine.DEB.2.00.0906031445190.6338@javelin>
 
 Also, if it helps, here's the backtrace for when it's hanging on the
 select:
 
      /usr/lib/ruby/1.8/monitor.rb:102:in `stop': Interrupt
      from /usr/lib/ruby/1.8/monitor.rb:102:in `wait'
      from /usr/lib/ruby/1.8/net/imap.rb:972:in `get_tagged_response'
      from /usr/lib/ruby/1.8/net/imap.rb:1032:in `send_command'
      from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
      from /usr/lib/ruby/1.8/net/imap.rb:1017:in `send_command'
      from /usr/lib/ruby/1.8/net/imap.rb:409:in `examine'
      from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
      from /usr/lib/ruby/1.8/net/imap.rb:407:in `examine'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:145:in `unsynchronized_scan_mailbox'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:322:in `safely'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:144:in `unsynchronized_scan_mailbox'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:192:in `unsynchronized_start_offset'
      from (eval):3:in `start_offset'
      from (eval):3:in `synchronize'
      from (eval):3:in `start_offset'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `send'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `__pass'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:531:in `method_missing'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:147
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:160:in `add_messages_from'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:187:in `each'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:175:in `upto'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:175:in `each'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `send'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `__pass'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:531:in `method_missing'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:141:in `add_messages_from'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `send'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `method_missing'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:140
      from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:135:in `each'
      from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:135
      from /var/lib/gems/1.8/bin/sup-sync:19:in `load'
      from /var/lib/gems/1.8/bin/sup-sync:19
 
 Cheers,
 Edward
 
 From wmorgan-sup@masanjin.net  Wed Jun  3 17:36:15 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 03 Jun 2009 14:36:15 -0700
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244053108-sup-4982@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 Message-ID: <1244064889-sup-9506@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
 > The current working theory (based on strace'ing and lsof) is that Sup
 > is hanging on a select() call that doesn't have any timeout.  The
 > reason why this is hanging is because between opening the connection
 > and closing it, Sup does some ridiculously slow message parsing code
 > (that really thrashes the CPU) and by the time it's done the server
 > has closed the connection (but we don't know about it).
 
 That may all be true, but I'd be surprised if a) Sup didn't know that
 the server had closed the connection, and b) that this would cause the
 whole thing to hang.
 
 When you don't use -n, does Sup still lock up?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Wed Jun  3 17:48:56 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 3 Jun 2009 17:48:56 -0400 (EDT)
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244064889-sup-9506@entry>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 Message-ID: <alpine.DEB.2.00.0906031740370.22220@javelin>
 
 On Wed, 3 Jun 2009, William Morgan wrote:
 > Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
 >> The current working theory (based on strace'ing and lsof) is that Sup
 >> is hanging on a select() call that doesn't have any timeout.  The
 >> reason why this is hanging is because between opening the connection
 >> and closing it, Sup does some ridiculously slow message parsing code
 >> (that really thrashes the CPU) and by the time it's done the server
 >> has closed the connection (but we don't know about it).
 >
 > That may all be true, but I'd be surprised if a) Sup didn't know that
 > the server had closed the connection, and
 
 It doesn't have anything to do with Sup: the system select() call is
 hanging; Sup (and Ruby for that matter) is out of the equation. This
 might be IMAP server weirdness, but that shouldn't cause Sup to
 freeze.
 
 > b) that this would cause the
 > whole thing to hang.
 
 That's what I find surprising, since Sup is multithreaded. I suppose
 all of the threads are blocking on the select.
 
 Sup hangs without -n. (it always hangs after it's "done fetching IMAP
 headers"). "done fetching IMAP headers" is the last message we get.
 
 The behavior seems to be:
 
 1. Log reports "done fetching IMAP headers"
 
 2. Sup begins malloc'ing like crazy. sup-sync still is able to catch
     signals and if you kill it you find that it's somewhere in
     lib/sup/message.rb, message_to_chunks. sup doesn't respond to Ctrl+C
 
 3. After some minutes, CPU usage dies off, but Sup doesn't unfreeze.
     strace indicates that sup/sup-sync is waiting on a select(), and that
     the descriptors are TCP connections to the IMAP server.
 
 Cheers,
 Edward
 
 
 From ezyang@MIT.EDU  Wed Jun  3 18:00:06 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 3 Jun 2009 18:00:06 -0400 (EDT)
 Subject: [sup-talk] Sup is hangingy
 In-Reply-To: <1244064889-sup-9506@entry>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 Message-ID: <alpine.DEB.2.00.0906031758290.24343@javelin>
 
 Oh hey, I managed to kill Sup:
 
 ezyang at javelin:~$ sup
 [Wed Jun 03 17:42:43 -0400 2009] using character set encoding "UTF-8"
 [Wed Jun 03 17:42:44 -0400 2009] dynamically loading setlocale() from
 libc.so.6
 [Wed Jun 03 17:42:44 -0400 2009] setting locale...
 [Wed Jun 03 17:42:44 -0400 2009] locking /home/ezyang/.sup/lock...
 [Wed Jun 03 17:42:44 -0400 2009] crypto: detected gpg binary in
 /usr/bin/gpg
 [Wed Jun 03 17:42:44 -0400 2009] loading index...
 [Wed Jun 03 17:42:44 -0400 2009] loaded index of 20188 messages
 [Wed Jun 03 17:42:44 -0400 2009] starting curses
 [Wed Jun 03 17:54:47 -0400 2009] stopped cursing
 [Wed Jun 03 17:54:47 -0400 2009] oh crap, an exception
 [Wed Jun 03 17:54:47 -0400 2009] unlocking /home/ezyang/.sup/lock...
 ----------------------------------------------------------------
 I'm very sorry. It seems that an error occurred in Sup. Please
 accept my sincere apologies. If you don't mind, please send the
 contents of ~/.sup/exception-log.txt and a brief report of the
 circumstances to sup-talk at rubyforge dot orgs so that I might
 address this problem. Thank you!
 
 Sincerely,
 William
 ----------------------------------------------------------------
 --- Interrupt from thread: main
 
 /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in
 `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:109:in `write'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:245:in
 `draw_line_from_string'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:182:in
 `draw_line'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
 `draw'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
 `each'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
 `draw'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:99:in `draw'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:303:in
 `draw_screen'
 /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:308
 /var/lib/gems/1.8/bin/sup:19:in `load'
 /var/lib/gems/1.8/bin/sup:19
 
 This seems... unrelated.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Wed Jun  3 21:26:01 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 03 Jun 2009 21:26:01 -0400
 Subject: [sup-talk] Sup is hangingy
 In-Reply-To: <alpine.DEB.2.00.0906031758290.24343@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 Message-ID: <1244078482-sup-4986@javelin>
 
 Ok, after a bit of fiddling, I've managed to figure out that this is
 two problems, not one.
 
 The first is related to a naughty IMAP server which simply stops responding
 after a certain number of seconds.  Unfortunately, this is my workplace's
 IMAP server, so I can't give you a test environment.  Furthermore, the code
 that would be appropriate to change is in Net::Imap, and thus is not
 easily accessible by Sup.  I've worked around this by making it an unusual
 source.
 
 The second is a large amount of CPU thrashing as Sup parses messages. This
 is something we can fix, and I hope to do some more poking to help make
 Sup run faster in this respect. The basic behavior is Sup repeatedly
 allocates some amount of memory, reallocates it twice (quadrupling it
 in size to about 4MB), deallocates, and then does it again. I'm running
 ruby-prof in hopes of tickling this again.  Unlike the hung IMAP server,
 this eventually finishes, but it is extremely obnoxious when it happens
 and blocks everything else. It commonly occurs when I open an email message.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Wed Jun  3 21:53:12 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 3 Jun 2009 21:53:12 -0400 (EDT)
 Subject: [sup-talk] Sup is hangingyy
 In-Reply-To: <1244078482-sup-4986@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 	<1244078482-sup-4986@javelin>
 Message-ID: <alpine.DEB.2.00.0906032152200.6894@javelin>
 
 On Wed, 3 Jun 2009, Edward Z. Yang wrote:
 > The second is a large amount of CPU thrashing as Sup parses messages. This
 > is something we can fix, and I hope to do some more poking to help make
 > Sup run faster in this respect. The basic behavior is Sup repeatedly
 > allocates some amount of memory, reallocates it twice (quadrupling it
 > in size to about 4MB), deallocates, and then does it again. I'm running
 > ruby-prof in hopes of tickling this again.  Unlike the hung IMAP server,
 > this eventually finishes, but it is extremely obnoxious when it happens
 > and blocks everything else. It commonly occurs when I open an email message.
 
 Here we go:
 
 http://web.mit.edu/~ezyang/Public/sup-performance.png
 
 Look at String::=~. Definitely not acceptable.
 
 Cheers,
 Edward
 
 
 From ross.macduff@gmail.com  Wed Jun  3 22:04:32 2009
 From: ross.macduff@gmail.com (Ross Macduff)
 Date: Wed, 3 Jun 2009 22:04:32 -0400
 Subject: [sup-talk] (no subject)
 In-Reply-To: <200906010101.n5111ADJ007928@ntdws12.chass.utoronto.ca>
 References: <200906010101.n5111ADJ007928@ntdws12.chass.utoronto.ca>
 Message-ID: <b689a800906031904s7a0606f3m229e1c726a2a83b1@mail.gmail.com>
 
 I merged this patch into the mainline from gitorius.  Works as
 expected.  Definitely a nice addition.
 
 Ross
 
 On Sun, May 31, 2009 at 9:01 PM, Ben Walton <bwalton at cquest.utoronto.ca> wrote:
 > >From 702b2cc1e652c1f20f4280b11355cb337291df87 Mon Sep 17 00:00:00 2001
 > From: Ben Walton <bwalton at artsci.utoronto.ca>
 > Date: Sun, 31 May 2009 20:37:11 -0400
 > Subject: [PATCH] Add bounce message feature
 >
 > By pressing ! in thread view mode, a message can be re-injected to the
 > mail system without any modification. ?The interesting/useful property
 > of this feature is that, because only the envelope sender changes, the
 > mail will show up at the new destination with the original From:
 > header. ?A use case for this is redirecting mail sent to an individual
 > into a ticket system such that the original sender gets the
 > auto-response.
 >
 > Signed-off-by: Ben Walton <bwalton at artsci.utoronto.ca>
 > ---
 > ?lib/sup/modes/thread-view-mode.rb | ? 19 +++++++++++++++++++
 > ?1 files changed, 19 insertions(+), 0 deletions(-)
 >
 > diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 > index 42c6280..4737dde 100644
 > --- a/lib/sup/modes/thread-view-mode.rb
 > +++ b/lib/sup/modes/thread-view-mode.rb
 > @@ -41,6 +41,7 @@ EOS
 > ?# ? ?k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N'
 > ? ? k.add :reply, "Reply to a message", 'r'
 > ? ? k.add :forward, "Forward a message or attachment", 'f'
 > + ? ?k.add :bounce, "Bounce message to other recipient(s)", '!'
 > ? ? k.add :alias, "Edit alias/nickname for a person", 'i'
 > ? ? k.add :edit_as_new, "Edit message as new", 'D'
 > ? ? k.add :save_to_disk, "Save message/attachment to disk", 's'
 > @@ -172,6 +173,24 @@ EOS
 > ? ? end
 > ? end
 >
 > + ?def bounce
 > + ? ?m = @message_lines[curpos] or return
 > + ? ?to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return
 > +
 > + ? ?if BufferManager.ask_yes_or_no "Really bounce to #{to.join(', ')}?"
 > + ? ? ?cmd = "sendmail -oem -i #{to.map { |t| t.email}.join(' ')}"
 > + ? ? ?begin
 > + ? ? ? ?IO.popen(cmd, 'w') do |sm|
 > + ? ? ? ? ?sm.puts m.raw_message
 > + ? ? ? ?end
 > + ? ? ? ?raise SendmailCommandFailed, "Couldn't execute #{cmd}" unless $? == 0
 > + ? ? ?rescue SystemCallError, SendmailCommandFailed => e
 > + ? ? ? ?Redwood::log "Problem sending mail: #{e.message}"
 > + ? ? ? ?BufferManager.flash "Problem sending mail: #{e.message}"
 > + ? ? ?end
 > + ? ?end
 > + ?end
 > +
 > ? include CanAliasContacts
 > ? def alias
 > ? ? p = @person_lines[curpos] or return
 > --
 > 1.6.3
 >
 > _______________________________________________
 > sup-talk mailing list
 > sup-talk at rubyforge.org
 > http://rubyforge.org/mailman/listinfo/sup-talk
 >
 
 From wmorgan-sup@masanjin.net  Wed Jun  3 22:11:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 03 Jun 2009 19:11:31 -0700
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <alpine.DEB.2.00.0906031740370.22220@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031740370.22220@javelin>
 Message-ID: <1244081477-sup-4133@entry>
 
 [resent to list]
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
 > That's what I find surprising, since Sup is multithreaded. I suppose
 > all of the threads are blocking on the select.
 
 It's possible... Ruby does use green threads and a GIL, so there's
 always the possibility that something in C land will block all Ruby
 threads, but my impression was that that was an issue mainly with
 third-party libraries. I believe that Net::IMAP is pure Ruby, thus using
 the core Ruby IO mechanisms, and I thought those were pretty good about
 being preemptible. Curious!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jun  3 22:12:25 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 03 Jun 2009 19:12:25 -0700
 Subject: [sup-talk] Sup is hangingy
 In-Reply-To: <alpine.DEB.2.00.0906031758290.24343@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 Message-ID: <1244081540-sup-7695@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
 > Oh hey, I managed to kill Sup:
 > 
 > ezyang at javelin:~$ sup
 > [Wed Jun 03 17:42:43 -0400 2009] using character set encoding "UTF-8"
 > [Wed Jun 03 17:42:44 -0400 2009] dynamically loading setlocale() from
 > libc.so.6
 > [Wed Jun 03 17:42:44 -0400 2009] setting locale...
 > [Wed Jun 03 17:42:44 -0400 2009] locking /home/ezyang/.sup/lock...
 > [Wed Jun 03 17:42:44 -0400 2009] crypto: detected gpg binary in
 > /usr/bin/gpg
 > [Wed Jun 03 17:42:44 -0400 2009] loading index...
 > [Wed Jun 03 17:42:44 -0400 2009] loaded index of 20188 messages
 > [Wed Jun 03 17:42:44 -0400 2009] starting curses
 > [Wed Jun 03 17:54:47 -0400 2009] stopped cursing
 > [Wed Jun 03 17:54:47 -0400 2009] oh crap, an exception
 > [Wed Jun 03 17:54:47 -0400 2009] unlocking /home/ezyang/.sup/lock...
 > ----------------------------------------------------------------
 > I'm very sorry. It seems that an error occurred in Sup. Please
 > accept my sincere apologies. If you don't mind, please send the
 > contents of ~/.sup/exception-log.txt and a brief report of the
 > circumstances to sup-talk at rubyforge dot orgs so that I might
 > address this problem. Thank you!
 > 
 > Sincerely,
 > William
 > ----------------------------------------------------------------
 > --- Interrupt from thread: main
 > 
 > /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in
 > `method_missing'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:109:in `write'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:245:in
 > `draw_line_from_string'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:182:in
 > `draw_line'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
 > `draw'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
 > `each'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in
 > `draw'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:99:in `draw'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:303:in
 > `draw_screen'
 > /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:308
 > /var/lib/gems/1.8/bin/sup:19:in `load'
 > /var/lib/gems/1.8/bin/sup:19
 > 
 > This seems... unrelated.
 > 
 > Cheers,
 > Edward
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jun  3 22:13:58 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 03 Jun 2009 19:13:58 -0700
 Subject: [sup-talk] Sup is hangingy
 In-Reply-To: <alpine.DEB.2.00.0906031758290.24343@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 Message-ID: <1244081553-sup-5115@entry>
 
 [sorry about that last one. really not doing too well with the ol' email
 today.]
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
 > --- Interrupt from thread: main
 > 
 > /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in `method_missing'
 [snip]
 > 
 > This seems... unrelated.
 
 This looks like a ctrl-c that got caught by an ncurses thread. I agree,
 seems unrelated.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jun  3 23:05:07 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 03 Jun 2009 20:05:07 -0700
 Subject: [sup-talk] Need help with OfflineIMAP integration and Iconv
 	errors
 In-Reply-To: <93de24940906011854m70b8511cv139d0c7a830fc914@mail.gmail.com>
 References: <93de24940906011854m70b8511cv139d0c7a830fc914@mail.gmail.com>
 Message-ID: <1244084554-sup-6080@entry>
 
 Hi Dominic,
 
 Reformatted excerpts from Dominic LoBue's message of 2009-06-01:
 > Let me start off by saying that I am incredibly impressed with sup.
 
 Great! That's nice to hear.
 
 > The first problem I'm having is when ferret is parsing through my
 > emails to build its indicies I get numerous "warning: error
 > (Iconv::IllegalSequence) decoding message body from X" errors, This
 > prevents a lot of my email from showing up at all.
 
 This is just a warning when iconv gets finnicky. It shouldn't prevent
 email from being indexed or from appearing.
 
 > I read that there were no plans to support uploading meta-data back to
 > IMAP servers, so I was hoping that OfflineIMAP would sidestep the
 > problem entirely. I searched the archives but I didn't find any
 > examples of working configs.  If anyone can point me to a working
 > example I'd greatly appreciate it.
 
 Maildir doesn't help you either. Sup doesn't export its message state
 back to the source for any source type, except for certain limited cases
 with sup-sync-back.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Thu Jun  4 12:03:10 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu,  4 Jun 2009 12:03:10 -0400
 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and body).
 Message-ID: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca>
 
 This is an augment of the already existing view header (H) command,
 but allows viewing of all mime parts in their raw form, etc.
 
 Signed-off-by: Ben Walton <bwalton at artsci.utoronto.ca>
 ---
  lib/sup/modes/thread-view-mode.rb |    8 ++++++++
  1 files changed, 8 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 42c6280..8de7ab0 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -27,6 +27,7 @@ EOS
    register_keymap do |k|
      k.add :toggle_detailed_header, "Toggle detailed header", 'h'
      k.add :show_header, "Show full message header", 'H'
 +    k.add :show_message, "Show full message (raw form)", 'V'
      k.add :activate_chunk, "Expand/collapse or activate item", :enter
      k.add :expand_all_messages, "Expand/collapse all messages", 'E'
      k.add :edit_draft, "Edit draft", 'e'
 @@ -134,6 +135,13 @@ EOS
      end
    end
  
 +  def show_message
 +    m = @message_lines[curpos] or return
 +    BufferManager.spawn_unless_exists("Raw message for #{m.id}") do
 +      TextMode.new m.raw_message
 +    end
 +  end
 +
    def toggle_detailed_header
      m = @message_lines[curpos] or return
      @layout[m].state = (@layout[m].state == :detailed ? :open : :detailed)
 -- 
 1.6.3
 
 
 From wmorgan-sup@masanjin.net  Thu Jun  4 12:09:40 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 04 Jun 2009 09:09:40 -0700
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <alpine.DEB.2.00.0906032152200.6894@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 	<1244078482-sup-4986@javelin>
 	<alpine.DEB.2.00.0906032152200.6894@javelin>
 Message-ID: <1244130722-sup-4496@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-03:
 > http://web.mit.edu/~ezyang/Public/sup-performance.png
 > 
 > Look at String::=~. Definitely not acceptable.
 
 Doing some profiling on my end, it looks like the majority of IMAP
 syncing time is spent in these five methods:
 
 Redwood::Index#load_entry_for_id (22%)
 Redwood::IMAP#load_message (25%)
 Redwood::Message#message_to_chunks (16.5%)
 Redwood::IMAP#load_header (14%)
 Redwood::Index#sync_message (13%)
 
 Four of those are essentially wrappers around IMAP or Ferret methods.
 The Sup-specific one is Message#message_to_chunks. But message_to_chunks
 and its callee text_to_chunks doesn't seem to have a major culprits.
 String#=~ only takes 2.3% of the CPU time, and a chunk of that is coming
 from RubyMail.
 
 Just for good measure, I "manually" measured the individual regexen in
 text_to_chunks. After parsing 100 messages from an IMAP server, which
 took 1m27s for me, I got:
 
            time (s)   calls
      bqp = 0.00854 /  1789 = 209411.2 calls/second
       n1 = 0.00218 /   313 = 143709.8 calls/second
      qsp = 0.03212 /  1923 =  59873.0 calls/second
       n2 = 0.00202 /   312 = 154226.4 calls/second
    empty = 0.00061 /    90 = 146341.5 calls/second
       sp = 0.02570 /  1927 =  74995.1 calls/second
       qp = 0.03392 /  4459 = 131452.5 calls/second
 
 The names are abbreviations for the various regexen in that method. You
 can see that the cumulative time spent on any one regex is at most .034
 seconds (qp, which is QUERY_PATTERN), and that the slowest one is qsp,
 QUERY_START_PATTERN.
 
 Incidentally, I can parse IMAP mailboxes at a little over 1 message/s,
 and mbox files at ~50 messages/second, which also suggests that the IMAP
 libraries are the biggest time sink here.
 
 This is all with ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]), Sup
 git next.
 
 Now that's all CPU stuff. There might be memory blowup issues. If
 nothing else, Sup leaks memory over time, but fixing that involves the
 getting into the hellish world of Ruby<->C land or the even more hellish
 internals of MRI, so I've been loathe to start down that path.
 
 You might be able to speed up sup-sync runs on IMAP by threading the
 network access and the parsing. But the IMAP connection seems pretty
 CPU-heavy so who knows.
 
 None of this answers the original question of why all Ruby threads block
 when Sup waits for a response from IMAP. Since I'm pretty sure the IMAP
 libraries are all Ruby (why they're so slow!), and that core Ruby IO
 should be nonblocking, this might be an interpreter bug. Are you able to
 pinpoint what part of MRI is blocking?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From mailinglist@flasht.de  Thu Jun  4 17:28:58 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 04 Jun 2009 23:28:58 +0200
 Subject: [sup-talk] Toggle expand/collapse of a message in threadview
 Message-ID: <1244150874-sup-6554@thinkpad-ubuntu>
 
 Hi!
 I've been wondering:
 Is there a way to expand/collsape the current message I'm reading when in the
 middle of it?
 I know I can press ENTER to toggle it when I'm hovering the message's header,
 but is it possible when I'm in the middle of a message?
 When reading long threads with long messages, this would really be handy, as
 for now I always have to go up or toggle all messages and
 work my way through a thread like that.
 It would be nice if I could simply press a key to toggle the current message
 I'm looking at (where the current highlighted line belongs to).
 
 Maybe I'm blind and simply haven't found this feature? Can't find it in the
 help menu.
 
 
 Thanks,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 
 From wmorgan-sup@masanjin.net  Thu Jun  4 23:38:23 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 04 Jun 2009 20:38:23 -0700
 Subject: [sup-talk] Toggle expand/collapse of a message in threadview
 In-Reply-To: <1244150874-sup-6554@thinkpad-ubuntu>
 References: <1244150874-sup-6554@thinkpad-ubuntu>
 Message-ID: <1244172932-sup-1101@entry>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
 > Is there a way to expand/collsape the current message I'm reading when
 > in the middle of it?
 
 Good idea. I've changed this in git. Pressing enter on a text region now
 collapses the message. Behavior of enter on quotes, signatures,
 attachments, etc. is unchanged.
 
 Also, collapsing a message will make the cursor jump to the next open
 message. So you should be able to scan rapidly through a thread one
 message at a time by hitting enter to collapse it or 'n' to leave open.
 (And then 'p' and 'n' to review all open messages.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Fri Jun  5 01:08:10 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 05 Jun 2009 01:08:10 -0400
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244130722-sup-4496@entry>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 	<1244078482-sup-4986@javelin>
 	<alpine.DEB.2.00.0906032152200.6894@javelin>
 	<1244130722-sup-4496@entry>
 Message-ID: <1244177820-sup-6051@javelin>
 
 Hi William,
 
 I tickled the bug and took a more careful look at the message that had
 triggered it, and noticed that it was an auto-generated commit message
 that was really long.  So one possible stop-gap would be just to detect
 if a message is long and disable quoting if that was the case (a long
 message would be, say, one over 100KB).  There is also a possibility
 that the commit message had some pathological backtracking built into
 it.
 
 Excerpts from William Morgan's message of Thu Jun 04 12:09:40 -0400 2009:
 > Redwood::Index#load_entry_for_id (22%)
 > Redwood::IMAP#load_message (25%)
 > Redwood::Message#message_to_chunks (16.5%)
 > Redwood::IMAP#load_header (14%)
 > Redwood::Index#sync_message (13%)
 
 Ok, so this isn't the same spread as when I managed to make Sup hang,
 so this isn't quite the same.
 
 > Now that's all CPU stuff. There might be memory blowup issues. If
 > nothing else, Sup leaks memory over time, but fixing that involves the
 > getting into the hellish world of Ruby<->C land or the even more hellish
 > internals of MRI, so I've been loathe to start down that path.
 
 Sup memory leakage has not been a problem; Sup will hang on a poll
 asynchronously (as in, UI is still responsive, but I get no more
 new messages) often enough that I have to quit and start sup up again.
 
 > None of this answers the original question of why all Ruby threads block
 > when Sup waits for a response from IMAP. Since I'm pretty sure the IMAP
 > libraries are all Ruby (why they're so slow!), and that core Ruby IO
 > should be nonblocking, this might be an interpreter bug. Are you able to
 > pinpoint what part of MRI is blocking?
 
 Not yet. I don't know Ruby threads well enough to know how to get more
 fine-grained information on thread mutex/blocking interaction.
 
 To summarize:
 
 1. If I thrash message_to_chunks() with a very long message, I cause
    sup to hang.
 
    * If this case is only caused by long messages, implement a hueristic
      to prevent quoting from happening to long messages.
 
    * If there is something specific about the message that causes massive
      back-tracking, fix the regex.
 
    In either case, message_to_chunks() should not block the rest of the
    interface (although if we fix either or the two sub-points, this
    may not be a noticeable problem).
 
 2. If an IMAP connection hangs, it occasionally causes all of Sup to
    block (this is rare, and comes from a pathological IMAP server. I
    think the ops administering the naughty IMAP server fixed it, so
    I am no longer seeing this hang).
 
 3. Under less pathological cases, an IMAP connection can hang, and
    asynchronously blocks any further polling from taking place, resulting
    in no new messages.  This happens commonly for me.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Fri Jun  5 01:24:36 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 05 Jun 2009 01:24:36 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 Message-ID: <1244179379-sup-6675@javelin>
 
 Excerpts from Ben Walton's message of Wed Jun 03 07:44:24 -0400 2009:
 > Redwood::log "my message"
 > 
 > Then, look in the log buffer.
 
 I tried probing several ways.
 
 - The reply-from.rb hook is being called.
 - The message variable does exist.
 - The message.has_label? "mylabel" returns false, as the body of the if
   statement never gets logged. (My contention is that the message very
   clearly has that label, so wtf).
 - It is difficult to get a str representation of the message
 
 I am still stymied.
 
 Cheers,
 Edward
 
 From nicolas.pouillard@gmail.com  Fri Jun  5 03:15:02 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Fri, 05 Jun 2009 09:15:02 +0200
 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and
 	body).
 In-Reply-To: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca>
 References: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca>
 Message-ID: <1244186006-sup-1399@ausone.inria.fr>
 
 Excerpts from Ben Walton's message of Thu Jun 04 18:03:10 +0200 2009:
 > This is an augment of the already existing view header (H) command,
 > but allows viewing of all mime parts in their raw form, etc.
 
 I usually use '|' followed by "cat" or "less" for this purpose, but maybe a
 dedicated key-binding is better.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From mailinglist@flasht.de  Fri Jun  5 07:02:13 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Fri, 05 Jun 2009 13:02:13 +0200
 Subject: [sup-talk] Toggle expand/collapse of a message in threadview
 In-Reply-To: <1244172932-sup-1101@entry>
 References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry>
 Message-ID: <1244199699-sup-8610@thinkpad-ubuntu>
 
 Oh cool!
 Thanks, works great and exactly what I wanted! :)
 
 Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009:
 > Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
 > > Is there a way to expand/collsape the current message I'm reading when
 > > in the middle of it?
 > 
 > Good idea. I've changed this in git. Pressing enter on a text region now
 > collapses the message. Behavior of enter on quotes, signatures,
 > attachments, etc. is unchanged.
 > 
 > Also, collapsing a message will make the cursor jump to the next open
 > message. So you should be able to scan rapidly through a thread one
 > message at a time by hitting enter to collapse it or 'n' to leave open.
 > (And then 'p' and 'n' to review all open messages.)
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 
 From mailinglist@flasht.de  Fri Jun  5 07:09:34 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Fri, 05 Jun 2009 13:09:34 +0200
 Subject: [sup-talk] Toggle expand/collapse of a message in threadview
 In-Reply-To: <1244172932-sup-1101@entry>
 References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry>
 Message-ID: <1244199822-sup-1224@thinkpad-ubuntu>
 
 Actually, now that I've been using it a little more, I think it would be nicer
 that when pressing enter on a collapsed message, the cursor would stay at the 
 header of that expanded message instead of moving to the next message header.
 Right now, it's always moving to the next message, even when expanding a collapsed
 message to read it.
 
 Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009:
 > Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
 > > Is there a way to expand/collsape the current message I'm reading when
 > > in the middle of it?
 > 
 > Good idea. I've changed this in git. Pressing enter on a text region now
 > collapses the message. Behavior of enter on quotes, signatures,
 > attachments, etc. is unchanged.
 > 
 > Also, collapsing a message will make the cursor jump to the next open
 > message. So you should be able to scan rapidly through a thread one
 > message at a time by hitting enter to collapse it or 'n' to leave open.
 > (And then 'p' and 'n' to review all open messages.)
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 
 From mailinglist@flasht.de  Fri Jun  5 07:24:07 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Fri, 05 Jun 2009 13:24:07 +0200
 Subject: [sup-talk] Toggle expand/collapse of a message in threadview
 In-Reply-To: <1244199822-sup-1224@thinkpad-ubuntu>
 References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry>
 	<1244199822-sup-1224@thinkpad-ubuntu>
 Message-ID: <1244200965-sup-607@thinkpad-ubuntu>
 
 
 Ok, wasn't so hard.
 Here's the patch:
 
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 2b6c58b..1e014c3 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -234,10 +234,12 @@ EOS
    ## view.
    def activate_chunk
      chunk = @chunk_lines[curpos] or return
 +    move_to_next = false
      if chunk.is_a? Chunk::Text
        ## if the cursor is over a text region, expand/collapse the
        ## entire message
        chunk = @message_lines[curpos]
 +      move_to_next = true
      end
      layout = if chunk.is_a?(Message)
        @layout[chunk]
 @@ -253,7 +255,7 @@ EOS
      end
      if chunk.is_a?(Message)
        jump_to_message chunk
 -      jump_to_next_open
 +      jump_to_next_open if move_to_next
      end
    end
 
 
 
 Excerpts from Christopher Bertels's message of Fr Jun 05 13:09:34 +0200 2009:
 > Actually, now that I've been using it a little more, I think it would be nicer
 > that when pressing enter on a collapsed message, the cursor would stay at the 
 > header of that expanded message instead of moving to the next message header.
 > Right now, it's always moving to the next message, even when expanding a
 > collapsed
 > message to read it.
 > 
 > Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009:
 > > Reformatted excerpts from Christopher Bertels's message of 2009-06-04:
 > > > Is there a way to expand/collsape the current message I'm reading when
 > > > in the middle of it?
 > > 
 > > Good idea. I've changed this in git. Pressing enter on a text region now
 > > collapses the message. Behavior of enter on quotes, signatures,
 > > attachments, etc. is unchanged.
 > > 
 > > Also, collapsing a message will make the cursor jump to the next open
 > > message. So you should be able to scan rapidly through a thread one
 > > message at a time by hitting enter to collapse it or 'n' to leave open.
 > > (And then 'p' and 'n' to review all open messages.)
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 
 From bwalton@artsci.utoronto.ca  Fri Jun  5 07:30:51 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 05 Jun 2009 07:30:51 -0400
 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and
 	body).
 In-Reply-To: <1244186006-sup-1399@ausone.inria.fr>
 References: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244186006-sup-1399@ausone.inria.fr>
 Message-ID: <1244201417-sup-2549@ntdws12.chass.utoronto.ca>
 
 Excerpts from Nicolas Pouillard's message of Fri Jun 05 03:15:02 -0400 2009:
 > Excerpts from Ben Walton's message of Thu Jun 04 18:03:10 +0200 2009:
 > > This is an augment of the already existing view header (H) command,
 > > but allows viewing of all mime parts in their raw form, etc.
 
 > I usually use '|' followed by "cat" or "less" for this purpose, but maybe a
 > dedicated key-binding is better.
 
 Yah, I was aiming for less typing...it's something I do often enough.
 
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090605/0f741833/attachment.bin>
 
 From dom.lobue@gmail.com  Fri Jun  5 08:35:15 2009
 From: dom.lobue@gmail.com (Dominic LoBue)
 Date: Fri, 5 Jun 2009 05:35:15 -0700
 Subject: [sup-talk] sup crash while attempting to load next email after
 	deleting previous
 Message-ID: <93de24940906050535p7178dedctc9f9f8c166acdf2e@mail.gmail.com>
 
 Hello,
 
 Sup just crashed on me. The last thing I did was do ,d to delete the
 email I was viewing and move on to the next. I had deleted several
 other emails previously in the exact same way with no problems.
 
 The only thing that may matter is that I had over 1000 threads loaded
 in the index view (I get a _lot_ of email at work :( ).
 
 I'm using a git release made from the below commit:
 commit a8869f951cf8ec3a4a50492290c9ca757c968f49
 Author: William Morgan <wmorgan-sup at masanjin.net>
 Date:   Sun May 31 08:58:16 2009 -0700
 
     yet another utf8 bugfix: fix string subsetting
 
     ... with a HORRIBLE SLOW HACK!
 
 
 
 And here is the exception-log:
 --- NoMethodError from thread: load messages for thread-view-mode
 undefined method `date' for nil:NilClass
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:783:in
 `text_for_thread_at'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:752:in
 `regen_text'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `map_with_index'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:641:in `each_with_index'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `each_with_index'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `map_with_index'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:752:in
 `regen_text'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:228:in
 `update'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:202:in
 `handle_deleted_update'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `relay'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `relay'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:431:in
 `delete_and_then'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:451:in
 `dispatch'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:119:in
 `call'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:119:in
 `select'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:71:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:99:in
 `select'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:149:in
 `launch_another_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:131:in
 `launch_next_thread_after'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:457:in
 `dispatch'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:429:in
 `delete_and_then'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:404:in
 `delete_and_next'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mode.rb:50:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mode.rb:50:in `handle_input'
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:249:in `handle_input'
 /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:238
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 
 
 
 Dominic
 
 From wmorgan-sup@masanjin.net  Fri Jun  5 09:23:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 05 Jun 2009 06:23:50 -0700
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244177820-sup-6051@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 	<1244078482-sup-4986@javelin>
 	<alpine.DEB.2.00.0906032152200.6894@javelin>
 	<1244130722-sup-4496@entry> <1244177820-sup-6051@javelin>
 Message-ID: <1244206531-sup-5503@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-04:
 > I tickled the bug and took a more careful look at the message that had
 > triggered it
 
 This is good stuff. I think we're getting somewhere. I was hoping to
 have this this fixed by 0.8 but I think it's going to have to wait till
 0.9.
 
 > and noticed that it was an auto-generated commit message that was
 > really long. So one possible stop-gap would be just to detect if a
 > message is long and disable quoting if that was the case (a long
 > message would be, say, one over 100KB).
 
 Yep, I bet that's the problem.
 
 Not parsing long messages would be fine as far as I'm concerned. Heck
 even 25k might be a reasonable limit (per MIME part).
 
 > There is also a possibility that the commit message had some
 > pathological backtracking built into it.
 
 It's possible... but I'm willing to bet that it's the sheer size. If
 we're still seeing this performance on smaller messages (e.g.  when you
 start sending me emails carefully constructed to induce worst-case
 performance in Sup's regexen) we can wrap a timeout around the whole
 parse as well.
 
 > Excerpts from William Morgan's message of Thu Jun 04 12:09:40 -0400 2009:
 > > Redwood::Index#load_entry_for_id (22%)
 > > Redwood::IMAP#load_message (25%)
 > > Redwood::Message#message_to_chunks (16.5%)
 > > Redwood::IMAP#load_header (14%)
 > > Redwood::Index#sync_message (13%)
 > 
 > Ok, so this isn't the same spread as when I managed to make Sup hang,
 > so this isn't quite the same.
 
 That makes sense.
 
 > 1. If I thrash message_to_chunks() with a very long message, I cause
 > sup to hang.
 
 This is still weird. It only makes sense if Ruby regexen block the whole
 interpreter when evaluating. I guess that might be the case if they're
 they haven't taken the (what I imagine must be trivial) step of allowing
 preemption during the DFA execution (or however the hell they're
 implemented). I guess an experiment would show this.
 
 > 2. If an IMAP connection hangs, it occasionally causes all of Sup to
 >    block (this is rare, and comes from a pathological IMAP server. I
 >    think the ops administering the naughty IMAP server fixed it, so
 >    I am no longer seeing this hang).
 
 This is also still weird, and I wonder if it's not just problems 1 and 3
 combining. If it comes back we will have to do some more investigation.
 
 > 3. Under less pathological cases, an IMAP connection can hang, and
 > asynchronously blocks any further polling from taking place, resulting
 > in no new messages.  This happens commonly for me.
 
 This one we can fix. (Though it's something the IMAP libraries should've
 done for us.) If we put a timeout block around that #examine call, we
 should be able to reset the connection if it hangs.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun  5 09:37:02 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 05 Jun 2009 06:37:02 -0700
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244179379-sup-6675@javelin>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin>
 Message-ID: <1244208597-sup-4979@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-04:
 > The message.has_label? "mylabel" returns false, as the body of the if
 > statement never gets logged. (My contention is that the message very
 > clearly has that label, so wtf).
 
 Try has_label? :mylabel. Sup represents labels as symbols instead of as
 strings.
 
 Sorry about that. The hook system is in need of much documentation.
 
 A good environment for playing around with this stuff is to run the console:
 
   w at drspaceman:~/devel/sup$ sh devel/console.sh 
   [...]
   >> Index.run_query "label:potato"
   => [1000]
   >> m = Index.build_message 1000
   => #<Redwood::Message:0x7f187b394ac8 [...]>
   >> m.labels
   => [:inbox, :unread, :potato]
   >> m.has_label? :potato
   => true
   >> m.has_label? "potato"
   => false
 
 HTH.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun  5 11:31:07 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 05 Jun 2009 08:31:07 -0700
 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and
 	body).
 In-Reply-To: <1244201417-sup-2549@ntdws12.chass.utoronto.ca>
 References: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244186006-sup-1399@ausone.inria.fr>
 	<1244201417-sup-2549@ntdws12.chass.utoronto.ca>
 Message-ID: <1244215854-sup-9273@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-05:
 > Yah, I was aiming for less typing...it's something I do often enough.
 
 Good enough for me. Applied directly to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun  5 11:31:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 05 Jun 2009 08:31:31 -0700
 Subject: [sup-talk] Toggle expand/collapse of a message in threadview
 In-Reply-To: <1244200965-sup-607@thinkpad-ubuntu>
 References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry>
 	<1244199822-sup-1224@thinkpad-ubuntu>
 	<1244200965-sup-607@thinkpad-ubuntu>
 Message-ID: <1244215876-sup-1528@entry>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-06-05:
 > Ok, wasn't so hard.  Here's the patch:
 
 I've applied a similar change to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun  5 11:36:55 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 05 Jun 2009 08:36:55 -0700
 Subject: [sup-talk] [PATCH] Prettier printing of enclosed messages
 In-Reply-To: <4a1fe5cd.0a04d00a.1d89.ffffe1b2@mx.google.com>
 References: <4a1fe5cd.0a04d00a.1d89.ffffe1b2@mx.google.com>
 Message-ID: <1244216191-sup-6520@entry>
 
 Reformatted excerpts from Israel Herraiz's message of 2009-05-29:
 > this patch prints enclosed messages with only some selected headers
 > instead of the full headers, just as "normal" messages.
 
 Branch enclosed-message-display-tweaks, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun  5 12:02:17 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 05 Jun 2009 09:02:17 -0700
 Subject: [sup-talk] [RFC] Bounce messages
 In-Reply-To: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
 References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
 Message-ID: <1244217075-sup-4385@entry>
 
 Hi Ben,
 
 I'm definitely interested in having this feature. But it does open up
 some complications because we have to be able to call the MTA in two
 different modes.
 
 But this might not be such a big deal because most MTAs have basic
 sendmail compatibility. Judging from the entries on the Sup Wiki for
 msmtp, ssmtp, and putmail, we should be fine just calling the account's
 sendmail command without -t and with the recipient email addresses.
 
 Reformatted excerpts from Ben Walton's message of 2009-05-31:
 > The other thing that I don't like presently is the confirmation UI.
 > Without resorting to a whole bounce-mode, is there a better way to
 > handle this in the face of (potentially) multiple recipients that may
 > make the question stretch outside the viewable area?
 
 You could just make it say "Bounce to #{to.size} recipients?". :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Fri Jun  5 12:20:32 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 05 Jun 2009 12:20:32 -0400
 Subject: [sup-talk] [RFC] Bounce messages
 In-Reply-To: <1244217075-sup-4385@entry>
 References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244217075-sup-4385@entry>
 Message-ID: <1244218650-sup-2427@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Fri Jun 05 12:02:17 -0400 2009:
 
 > I'm definitely interested in having this feature. But it does open
 > up
 
 Great.
 
 > some complications because we have to be able to call the MTA in two
 > different modes.
 
 Nothing is free! :)
 
 > But this might not be such a big deal because most MTAs have basic
 > sendmail compatibility. Judging from the entries on the Sup Wiki for
 > msmtp, ssmtp, and putmail, we should be fine just calling the account's
 > sendmail command without -t and with the recipient email addresses.
 
 Ok, I'll rework the patch to call the default account's sendmail
 command with any -t stripped out.
 
 > You could just make it say "Bounce to #{to.size} recipients?". :)
 
 That would work.  Still gives a chance to back out if things don't
 look right but not too heavy either.
 
 I'll rework this tonight.  I looked at refactoring against the
 EditMessageMode send function the other night and that's not straight
 forward since the shared code is a few classes up the object tree.
 Moving the send message code higher in the tree isn't ideal, as it
 doesn't really belong there...suggestions on that?
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090605/17101870/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Fri Jun  5 15:02:37 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 05 Jun 2009 12:02:37 -0700
 Subject: [sup-talk] [ANN] Sup 0.8 released
 Message-ID: <1244228405-sup-4363@entry>
 
 I'm pleased to announce the release of Sup 0.8.
 
 Sup is a console-based email client for people with a lot of email.
 It supports tagging, very fast full-text search, automatic contact-
 list management, and more. If you're the type of person who treats
 email as an extension of your long-term memory, Sup is for you.
 
 Get it: gem install sup
 Learn it: http://sup.rubyforge.org
 Love it: sup-talk at rubyforge.org
 
 Excitement in 0.8:
 * Undo support on many operations. Yay!
 * Mbox splitting fixes. No more "From "-line problems.
 * Mail parsing speedups.
 * Many utf8 and widechar fixes. Display of crazy characters should be pretty
   close.
 * Outgoing email with non-ASCII headers is now properly encoded.
 * Email addresses are no longer permanently attached to names. This was
   causing problems with automated email systems that used different names
   with the same address.
 * Curses background now retains the terminal default color. This also makes
   Sup work better on transparent terminals.
 * Improve dynamic loading of setlocale for Cygwin and BSD systems.
 * Labels can now be removed from multiple tagged threads.
 * Applying operations to tagged threads is now invoked with '='.
 * Buffer list is betterified and is now invoked with ';'.
 * Zsh autocompletion support.
 * As always, many bugfixes and tweaks.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Fri Jun  5 17:47:00 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 05 Jun 2009 17:47:00 -0400
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244227108-sup-3123@cabinet>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 	<1244078482-sup-4986@javelin>
 	<alpine.DEB.2.00.0906032152200.6894@javelin>
 	<1244130722-sup-4496@entry> <1244177820-sup-6051@javelin>
 	<1244227108-sup-3123@cabinet>
 Message-ID: <1244238388-sup-760@javelin>
 
 Excerpts from Marc Hartstein's message of Fri Jun 05 14:43:59 -0400 2009:
 > I noticed that one feature of the messages was that they contained one
 > extremely long line.  Not sure if this information will in any way help
 > figure out what's going on there.
 
 Now that you mention it, the messages that tickle this bug on my side also
 have one extremely long line.  That's very interesting.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Fri Jun  5 20:09:13 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 05 Jun 2009 20:09:13 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244208597-sup-4979@entry>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin> <1244208597-sup-4979@entry>
 Message-ID: <1244246896-sup-4529@javelin>
 
 Excerpts from William Morgan's message of Fri Jun 05 09:37:02 -0400 2009:
 > Try has_label? :mylabel. Sup represents labels as symbols instead of as
 > strings.
 
 Great! My hook works now. This is the sort of functionality that I think
 is worth generalizing and implementing as a configuration twiddle (one,
 I think, that should be on by default.)
 
 > A good environment for playing around with this stuff is to run the console:
 > 
 >   w at drspaceman:~/devel/sup$ sh devel/console.sh 
 >   [...]
 >   >> Index.run_query "label:potato"
 >   => [1000]
 >   >> m = Index.build_message 1000
 >   => #<Redwood::Message:0x7f187b394ac8 [...]>
 >   >> m.labels
 >   => [:inbox, :unread, :potato]
 >   >> m.has_label? :potato
 >   => true
 >   >> m.has_label? "potato"
 >   => false
 
 Nice!
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Sat Jun  6 02:20:25 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 06 Jun 2009 02:20:25 -0400
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244238388-sup-760@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 	<1244078482-sup-4986@javelin>
 	<alpine.DEB.2.00.0906032152200.6894@javelin>
 	<1244130722-sup-4496@entry> <1244177820-sup-6051@javelin>
 	<1244227108-sup-3123@cabinet> <1244238388-sup-760@javelin>
 Message-ID: <1244267416-sup-3720@javelin>
 
 Excerpts from Edward Z. Yang's message of Fri Jun 05 17:47:00 -0400 2009:
 > Now that you mention it, the messages that tickle this bug on my side also
 > have one extremely long line.  That's very interesting.
 
 Here is the culprit, laid out to bear its full shame:
 
     /\w.*:$/
 
 I thought this was a suspicious looking regexen; a simple test confirmed my
 belief:
 
     line = ":a" * 10000
     line =~ /\w.*:$/
 
 Ba boom ba boom ba boom.  This is a textbook case of catastrophic backtracking.
 
 I have two possible fixes, they end up being about the same time for regular
 cases, but the second one is more optimal for really long strings:
 
 First, the simple one:
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 5993729..0ddd3af 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -26,7 +26,7 @@ class Message
  
    QUOTE_PATTERN = /^\s{0,4}[>|\}]/
    BLOCK_QUOTE_PATTERN = /^-----\s*Original Message\s*----+$/
 -  QUOTE_START_PATTERN = /\w.*:$/
 +  QUOTE_START_PATTERN = /\w\W*:$/
    SIG_PATTERN = /(^-- ?$)|(^\s*----------+\s*$)|(^\s*_________+\s*$)|(^\s*--~--~-)|(^\s*--\+\+\*\*==)/
  
    MAX_SIG_DISTANCE = 15 # lines from the end
 
 And the slightly more complicated one (but optimal for large n):
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 5993729..c5481a6 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -26,7 +26,6 @@ class Message
  
    QUOTE_PATTERN = /^\s{0,4}[>|\}]/
    BLOCK_QUOTE_PATTERN = /^-----\s*Original Message\s*----+$/
 -  QUOTE_START_PATTERN = /\w.*:$/
    SIG_PATTERN = /(^-- ?$)|(^\s*----------+\s*$)|(^\s*_________+\s*$)|(^\s*--~--~-)|
  
    MAX_SIG_DISTANCE = 15 # lines from the end
 @@ -449,7 +448,7 @@ private
        when :text
          newstate = nil
  
 -        if line =~ QUOTE_PATTERN || (line =~ QUOTE_START_PATTERN && nextline =~ QUO
 +        if line =~ QUOTE_PATTERN || (line =~ /:$/ && line =~ /\w/ && nextline =~ QU
            newstate = :quote
          elsif line =~ SIG_PATTERN && (lines.length - i) < MAX_SIG_DISTANCE
            newstate = :sig
 
 There are number of micro-optimizations that could be made to message
 parsing, but this will basically fix the egregious problem.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Sat Jun  6 02:54:01 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 06 Jun 2009 02:54:01 -0400
 Subject: [sup-talk] Sup annoyances
 Message-ID: <1244270435-sup-9288@javelin>
 
 Having just submitted my first patch, I feel entitled to gripe and
 moan about certain aspects of Sup. The hope is that I'll get some
 pointers on what code to look at to fix these gripes. These gripes
 are independent of the hanging/other behavior in my other monster
 thread. (I'd say the asynchronous polling hang is my other biggest
 gripe, but that's not an issue for here).
 
 1. Threads should be lazy-loaded (possibly in the background), with
    visible messages first.  If a conversation got a new message, Sup
    should only take its time to load that message, and not the frickin'
    24 other messages that were also incidentally there.  I suspect
    this will require some pretty major refactoring.  As a stop-gap,
    I should have the option of cancelling when I open a long thread
    (right now, I think it causes sup to crash).
 
 2. Auto-completion sucks and should be improved.  I should be able
    to press "c", type two letters, and then mash tab. If auto-completion
    actually works, then I'll blame it on dismal contacts.txt support
    (if I send mail to someone, there should be a configuration twiddle
    that saves it to contacts.txt. And then remembers it the next
    time I want to compose mail to them).
 
 3. Polling and loading of threads should started, asynchronously, at
    the same time.  Loading of threads should not hose my CPU.  Loading
    of threads should do smart things, instead of doing an O(n) time warp.
    It takes forever for a mail from two months ago that is still in my
    inbox, because it still hasn't been addressed, to show up.  This could
    probably be fixed with a cache file.  This isn't as big of a deal
    if asynchronous polling hang and crashing is fixed.
 
 4. Sup should prompt me whether or not I want to Reply All or Reply on
    appropriate cases, like pine.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Sat Jun  6 02:56:11 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 06 Jun 2009 02:56:11 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244270435-sup-9288@javelin>
 References: <1244270435-sup-9288@javelin>
 Message-ID: <1244271263-sup-3881@javelin>
 
 Excerpts from Edward Z. Yang's message of Sat Jun 06 02:54:01 -0400 2009:
 > 4. Sup should prompt me whether or not I want to Reply All or Reply on
 >    appropriate cases, like pine.
 
 To be clear, this should be a configuration twiddle.
 
 I think I also have just remembered one more thing:
 
 5. Killing a thread should kill it *now*, not "when Sup next restarts".
 
 Cheers,
 Edward
 
 From nicolas.pouillard@gmail.com  Sat Jun  6 06:16:55 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 06 Jun 2009 12:16:55 +0200
 Subject: [sup-talk] [RFC] Bounce messages
 In-Reply-To: <1244217075-sup-4385@entry>
 References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244217075-sup-4385@entry>
 Message-ID: <1244283371-sup-2895@ausone.local>
 
 Excerpts from William Morgan's message of Fri Jun 05 18:02:17 +0200 2009:
 > Hi Ben,
 > 
 > I'm definitely interested in having this feature. But it does open up
 > some complications because we have to be able to call the MTA in two
 > different modes.
 
 I don't get the purpose of this, how it is different from hitting 'D' to send
 again the same message?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From bwalton@artsci.utoronto.ca  Sat Jun  6 08:44:15 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 06 Jun 2009 08:44:15 -0400
 Subject: [sup-talk] [RFC] Bounce messages
 In-Reply-To: <1244283371-sup-2895@ausone.local>
 References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244217075-sup-4385@entry> <1244283371-sup-2895@ausone.local>
 Message-ID: <1244291795-sup-1695@ntdws12.chass.utoronto.ca>
 
 Excerpts from Nicolas Pouillard's message of Sat Jun 06 06:16:55 -0400 2009:
 > I don't get the purpose of this, how it is different from hitting 'D' to send
 > again the same message?
 
 Look at the From: header when you do that.  It gets set to _your_
 address.  You could use D, edit the from address to that of the
 original sender and then fire to achieve the same effect (although I'm
 not sure how it handles attachments, etc), but that's a lot of typing
 for a common action.  I also believe that with D, since you're
 injecting a new message with original content, that you'd lose much of
 the original header info.
 
 The idea is that when you 'bounce' the message, it's akin to you
 having had a .forward in place at MTA delivery time.  Redirect, not
 forward.
 
 My biggest use case for this is bouncing mail sent to me personally
 asking for support into our ticket system.  The original sender will
 see the autoreply with the ticket id, etc because the From: header
 contained their address.  Colleagues using other mail clients lacking
 this feature will forward mail to the ticket system which sees them
 get the replies.  They then have to go into the ticket and set a
 proper 'requester' address for further correspondence on the ticket.
 
 I remember when I discovered this feature in mutt how weird I thought
 it was.  It wasn't long before it was in common use for me though.
 
 Does that make sense?
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/6730fbb2/attachment.bin>
 
 From nicolas.pouillard@gmail.com  Sat Jun  6 10:36:12 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 06 Jun 2009 16:36:12 +0200
 Subject: [sup-talk] [RFC] Bounce messages
 In-Reply-To: <1244291795-sup-1695@ntdws12.chass.utoronto.ca>
 References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244217075-sup-4385@entry> <1244283371-sup-2895@ausone.local>
 	<1244291795-sup-1695@ntdws12.chass.utoronto.ca>
 Message-ID: <1244298935-sup-5932@ausone.local>
 
 Excerpts from Ben Walton's message of Sat Jun 06 14:44:15 +0200 2009:
 > Excerpts from Nicolas Pouillard's message of Sat Jun 06 06:16:55 -0400 2009:
 > > I don't get the purpose of this, how it is different from hitting 'D' to send
 > > again the same message?
 > 
 > Look at the From: header when you do that.  It gets set to _your_
 > address.  You could use D, edit the from address to that of the
 > original sender and then fire to achieve the same effect (although I'm
 > not sure how it handles attachments, etc), but that's a lot of typing
 > for a common action.  I also believe that with D, since you're
 > injecting a new message with original content, that you'd lose much of
 > the original header info.
 > 
 > The idea is that when you 'bounce' the message, it's akin to you
 > having had a .forward in place at MTA delivery time.  Redirect, not
 > forward.
 > 
 > My biggest use case for this is bouncing mail sent to me personally
 > asking for support into our ticket system.  The original sender will
 > see the autoreply with the ticket id, etc because the From: header
 > contained their address.  Colleagues using other mail clients lacking
 > this feature will forward mail to the ticket system which sees them
 > get the replies.  They then have to go into the ticket and set a
 > proper 'requester' address for further correspondence on the ticket.
 > 
 > I remember when I discovered this feature in mutt how weird I thought
 > it was.  It wasn't long before it was in common use for me though.
 > 
 > Does that make sense?
 
 It does! Thanks for the explanation.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From helgedt@tihlde.org  Sat Jun  6 08:03:14 2009
 From: helgedt@tihlde.org (Helge Titlestad)
 Date: Sat, 06 Jun 2009 14:03:14 +0200
 Subject: [sup-talk] [RFC] Bounce messages
 In-Reply-To: <1244283371-sup-2895@ausone.local>
 References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244217075-sup-4385@entry> <1244283371-sup-2895@ausone.local>
 Message-ID: <1244289688-sup-9384@colargol.tihlde.org>
 
 Excerpts from Nicolas Pouillard's message of Sat Jun 06 12:16:55 +0200 2009:
 > I don't get the purpose of this, how it is different from hitting 'D' to send
 > again the same message?
 
 One out of several differences: D doesn't include attachments.
 
 My personal use case: I have a couple of mail accounts - this one for all my
 normal private stuff, one gmail account mostly for sharing documents and so on.
 If I get a mail with an attachment that I can't read in a terminal (typically
 pdf) to my private account, I will bounce it to my gmail account. That 
 preserves the whole message, and is different from both "D" (which I use
 to re-send mail) and forward (which I use to forward interesting stuff to
 other people).
 -- 
 alge
 
 From ezyang@MIT.EDU  Sat Jun  6 14:17:29 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 06 Jun 2009 14:17:29 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244308338-sup-4735@cabinet>
 References: <1244270435-sup-9288@javelin> <1244271263-sup-3881@javelin>
 	<1244308338-sup-4735@cabinet>
 Message-ID: <1244312041-sup-9128@javelin>
 
 Excerpts from Marc Hartstein's message of Sat Jun 06 13:16:39 -0400 2009:
 > sup gives you a menu to select whether to reply to Sender, Recipient,
 > List, or All.  It's right up near the top of the reply-mode screen.  Use
 > regular vertical movement keys to select the Reply to: line, then
 > horizontal movement to select an option.
 
 Yep, I know about this.
 
 > You can improve the default selection using the reply-to hook.  See `sup
 > --list-hooks` for documentation.
 
 I didn't know about that.
 
 > I found it a little weird getting used to (coming from mutt, where I
 > actually used a different reply key for each mode), but the default
 > behavior is generally correct, and selecting from the menu isn't too
 > bad.
 
 The trouble is I always forget to check the To: header on my mails, and
 there is a ~large class of mailing list emails that don't actually do
 the right thing by default.  Improving the heuristic may be an alternate
 possibility.
 
 Cheers,
 Edward
 
 From bwalton@artsci.utoronto.ca  Sat Jun  6 15:06:49 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 06 Jun 2009 15:06:49 -0400
 Subject: [sup-talk] sup/gpg
 In-Reply-To: <1244314253-sup-6338@cabinet>
 References: <1243463452-sup-1174@cabinet>
 	<1243466444-sup-3672@ntdws12.chass.utoronto.ca>
 	<1243622801-sup-6484@cabinet>
 	<1243819025-sup-136@ntdws12.chass.utoronto.ca>
 	<1244037417-sup-8346@cabinet>
 	<1244313900-sup-578@ntdws12.chass.utoronto.ca>
 	<1244314253-sup-6338@cabinet>
 Message-ID: <1244314983-sup-482@ntdws12.chass.utoronto.ca>
 
 Excerpts from Marc Hartstein's message of Sat Jun 06 14:53:55 -0400 2009:
 > Excerpts from Ben Walton's message of Sat Jun 06 14:45:56 -0400 2009:
 > > 
 > > This just got stranger, which makes me think it may be a sup issue
 > > still.  The thread you replied twice to earlier today has one message
 > > validating and the other not.  See attached.
 > 
 > Ok, that's totally bizarre.
 > 
 > Things I can think of:
 > 
 > Those were two different sup instances (I'd quit, created a branch, and
 > applied the discussed patch in between sending the two replies)
 
 Well, if the patch altered the behaviour, that's a possibility.
 
 > I might well have typoed my passphrase for one of the messages and not
 > the other, though I'm not sure which.  I think it's slightly more likely
 > that the BAD message was the one where I made a typo, though.  [I then
 > proceeded to enter it correctly the second time, though, so...]
 
 When I enter a bad passphrase into pinentry, sup detects this and
 won't send the message...to my knowledge, I'm not able to get a
 multipart/gpg message sent if I don't enter a proper passphrase.
 
 > Think we should move the discussion to the sup list to see if anybody
 > has thoughts?
 
 I think that's reasonable.  My next thought is that there is a small
 bug in the mime parsing (or creating) code...
 
 Does anyone else have thoughts on what would cause broken gpg
 signatures?  I've previously had issues when using gpg2 instead of
 gpg1, but that was completely the fault of gpg2 (or my use of it,
 anyway).  Switching to gpg1 resolved the problem at that time.  In
 this instance, Mark isn't able to validate my signatures and I was
 able to validate his until just recently...I'm now hit-and-miss with
 his.
 
 Thoughts?
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090606/ff5e9ca6/attachment.bin>
 
 From ingmar@exherbo.org  Fri Jun  5 20:35:50 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Sat, 06 Jun 2009 02:35:50 +0200
 Subject: [sup-talk] [PATCH] Use terminal width instead of hardcoded 80
 	as the wrap length.
 In-Reply-To: <1243439667-sup-3947@entry>
 References: <1243102667-sup-6007@r50p>
 	<4c4248150905231318kab3819dw68e3a3a614241c0d@mail.gmail.com>
 	<1243123134-sup-8032@ntdws12.chass.utoronto.ca>
 	<1243439667-sup-3947@entry>
 Message-ID: <1244248537-sup-5155@cannonball>
 
 Excerpts from William Morgan's message of Wed May 27 17:58:23 +0200 2009:
 > Reformatted excerpts from Ben Walton's message of 2009-05-23:
 > > But if you leave sup's "we dont' force wrapping" rules alone, this
 > > makes reading mail scroll free if your terminal is wide enough and
 > > doesn't change the behaviour if the terminal is narrower.  (Not that
 > > I'm against making it an option either.)
 > 
 > Seems like there are three main modes of operation that would be
 > desirable:
 > 
 > 1. wrap at 80 chars;
 > 2. wrap at current terminal width;
 > 3. don't wrap.
 > 
 > (In all cases, existing line breaks in the message are left alone.)
 > 
 > Would a three-way toggle irritate anyone?
 
 Works for me.
 
 From bwalton@artsci.utoronto.ca  Sun Jun  7 08:33:49 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 07 Jun 2009 08:33:49 -0400
 Subject: [sup-talk] exception with undomanager
 Message-ID: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 
 
 Hi All,
 
 I bumped into this this morning.  I've not used the undo stuff much,
 but I tried it today.  The (rough) sequence of events leading to this
 was: I archived two threads separately and then decided I wanted to
 undo the first of two actions.  I hit u once and got the latest thread
 back and when I hit it again, sup crashed.  If I get a chance I'll
 look into it myself, but I'm tossing it out for people more familiar
 with these bits to see also.
 
 Thanks
 -Ben
 
 
 $ less ~/.sup/exception-log.txt 
 --- NoMethodError from thread: main
 undefined method `content_width' for nil:NilClass
 ./sup/modes/thread-index-mode.rb:868:in `from_width'
 ./sup/modes/thread-index-mode.rb:793:in `text_for_thread_at'
 /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
 `each_with_index'
 ./sup/modes/thread-index-mode.rb:792:in `each'
 ./sup/modes/thread-index-mode.rb:792:in `each_with_index'
 ./sup/modes/thread-index-mode.rb:792:in `text_for_thread_at'
 ./sup/modes/thread-index-mode.rb:753:in `regen_text'
 ./sup/util.rb:346:in `map_with_index'
 /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
 `each_with_index'
 ./sup/util.rb:346:in `each'
 ./sup/util.rb:346:in `each_with_index'
 ./sup/util.rb:346:in `map_with_index'
 ./sup/modes/thread-index-mode.rb:753:in `regen_text'
 ./sup/modes/thread-index-mode.rb:228:in `update'
 ./sup/modes/thread-index-mode.rb:697:in `add_or_unhide'
 ./sup/modes/thread-index-mode.rb:319:in `actually_toggle_spammed'
 ./sup/undo.rb:28:in `call'
 ./sup/undo.rb:28:in `undo'
 ./sup/undo.rb:28:in `each'
 ./sup/undo.rb:28:in `undo'
 ./sup/util.rb:505:in `send'
 ./sup/util.rb:505:in `method_missing'
 ./sup/modes/thread-index-mode.rb:217:in `undo'
 ./sup/mode.rb:50:in `send'
 ./sup/mode.rb:50:in `handle_input'
 ./sup/buffer.rb:249:in `handle_input'
 ../bin/sup:237
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090607/3fcc2660/attachment.bin>
 
 From sup@davekap.com  Sun Jun  7 19:52:10 2009
 From: sup@davekap.com (David L.Kaplan)
 Date: Sun, 07 Jun 2009 19:52:10 -0400
 Subject: [sup-talk] crash with .8 on save ($)
 Message-ID: <1244418650-sup-3064@ubuntu>
 
 To the best of my recollection, I had archived a few messages and then
 hit $ to save state.  Exception file attached.
 
 Thanks for sup.
 
 Dave
 --- RuntimeError from thread: periodic poll
 trying to delete non-corresponding entry 47607 with index message-id
 "2ca9fdfb2b3c1c3c3981de95447977b2 at www.facebook.com" and parameter message id
 "988542971151613.JXQSVJUEOLXELKD at 187-45-0-136.clientes.cilnet.com.br"
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/index.rb:191:in `sync_message'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/index.rb:190:in `sync_message'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:161:in `add_messages_from'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:130:in `each'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `upto'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `each'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `send'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `__pass'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:531:in `method_missing'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:141:in `add_messages_from'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:98:in `do_poll'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `each'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `do_poll'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `synchronize'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `do_poll'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/modes/poll-mode.rb:17:in `poll'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:53:in `poll'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:70:in `start'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `new'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:67:in `start'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
 /home/dave/.gem/ruby/1.8/gems/sup-0.8/bin/sup:213
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 From bwalton@artsci.utoronto.ca  Sun Jun  7 20:02:25 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun,  7 Jun 2009 20:02:25 -0400
 Subject: [sup-talk] (no subject)
 Message-ID: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 
 Hi All,
 
 Here's a stab at implementing a message bouncing functionality worthy
 of being included on mainline.
 
 The first patch adds the basic functionality with the ability to
 supply a command in the :bounce_sendmail option that overrides the
 default command used.  The default is to use the sendmail command of
 the default account with -t removed.
 
 The second patch takes this a step further and strips the
 configuration option in favour of a hook named bounce-command.  This
 hooks gets the From header of the message being bounced and an array
 of recipient addresses supplied by the user.
 
 I think these are in good shape, with the caveat that the mail sending
 (IO.popen) part could still be refactored with the code in
 edit-message-mode.
 
 Anyone interested can grab this code from the bw/bounce_message branch
 of git://code.chass.utoronto.ca/bwalton-sup.git.  It merges cleanly
 into next as of now.
 
 Feedback welcome.
 
 Thanks
 -Ben
 
 
 From bwalton@artsci.utoronto.ca  Sun Jun  7 20:02:26 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun,  7 Jun 2009 20:02:26 -0400
 Subject: [sup-talk] [PATCH 1/2] Add message bouncing capability
 In-Reply-To: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 Message-ID: <1244419347-11330-2-git-send-email-bwalton@artsci.utoronto.ca>
 
 Bouncing a message is akin to redirecting a mail with a .forward
 entry.  It is passed back to the mail system as it sits on disk.
 
 By pressing ! while viewing a message, you can now re-inject it to the
 mail system using either the command defined in bounce_sendmail or the
 sendmail command for the default account with any instance of -t
 removed. The user is prompted for the recipients of the message and is
 offered a chance to confirm the bounce before it is sent.
 
 The message is _not_ stored in the sent box, as this doesn't make
 sense with bounced messages (and would not show up uniquely anyway).
 
 The bounce_sendmail configuration item allows users that require
 different sendmail commands depending on where the bounce is destined
 to write a wrapper around their local mail tools to pick and choose
 the appropriate injection method for the message based on the
 addresses passed in.  Most systems can likely use: sendmail -oem -i
 
 Signed-off-by: Ben Walton <bwalton at artsci.utoronto.ca>
 ---
  lib/sup.rb                        |    1 +
  lib/sup/modes/thread-view-mode.rb |   33 +++++++++++++++++++++++++++++++++
  2 files changed, 34 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup.rb b/lib/sup.rb
 index 96510b2..76444c9 100644
 --- a/lib/sup.rb
 +++ b/lib/sup.rb
 @@ -207,6 +207,7 @@ else
      :confirm_top_posting => true,
      :discard_snippets_from_encrypted_messages => false,
      :default_attachment_save_dir => "",
 +    :bounce_sendmail => "",
    }
    begin
      FileUtils.mkdir_p Redwood::BASE_DIR
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 42c6280..8842e59 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -41,6 +41,7 @@ EOS
  #    k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N'
      k.add :reply, "Reply to a message", 'r'
      k.add :forward, "Forward a message or attachment", 'f'
 +    k.add :bounce, "Bounce message to other recipient(s)", '!'
      k.add :alias, "Edit alias/nickname for a person", 'i'
      k.add :edit_as_new, "Edit message as new", 'D'
      k.add :save_to_disk, "Save message/attachment to disk", 's'
 @@ -172,6 +173,38 @@ EOS
      end
    end
  
 +  def bounce
 +    m = @message_lines[curpos] or return
 +    to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return
 +
 +    defcmd = AccountManager.default_account.sendmail.sub(/\s(\-(ti|it|t))\b/) do |match|
 +      case "$1"
 +        when '-t' then ''
 +        else ' -i'
 +      end
 +    end
 +
 +    cmd = case $config[:bounce_sendmail]
 +          when nil, /^$/ then defcmd
 +          else $config[:bounce_sendmail]
 +          end + ' ' + to.map { |t| t.email }.join(' ')
 +
 +    bt = to.size > 1 ? "#{to.size} recipients" : to.to_s
 +
 +    if BufferManager.ask_yes_or_no "Really bounce to #{bt}?"
 +      Redwood::log "Bounce Command: #{cmd}"
 +      begin
 +        IO.popen(cmd, 'w') do |sm|
 +          sm.puts m.raw_message
 +        end
 +        raise SendmailCommandFailed, "Couldn't execute #{cmd}" unless $? == 0
 +      rescue SystemCallError, SendmailCommandFailed => e
 +        Redwood::log "Problem sending mail: #{e.message}"
 +        BufferManager.flash "Problem sending mail: #{e.message}"
 +      end
 +    end
 +  end
 +
    include CanAliasContacts
    def alias
      p = @person_lines[curpos] or return
 -- 
 1.6.3
 
 
 From bwalton@artsci.utoronto.ca  Sun Jun  7 20:02:27 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun,  7 Jun 2009 20:02:27 -0400
 Subject: [sup-talk] [PATCH 2/2] Bounce Message Hook
 In-Reply-To: <1244419347-11330-2-git-send-email-bwalton@artsci.utoronto.ca>
 References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244419347-11330-2-git-send-email-bwalton@artsci.utoronto.ca>
 Message-ID: <1244419347-11330-3-git-send-email-bwalton@artsci.utoronto.ca>
 
 Determine the command used to bounce a message based on a Hook instead
 of a configuration option.  Instead of writing an external script that
 can send the message properly based on the recipient addresses, rely
 on a hook that can return the command based on the From header in the
 mail being bounced as well as the intended recipients.  This is more
 in line with the sup philosophy.
 
 The default is still to strip any -t from the sendmail command of the
 default account.
 
 Signed-off-by: Ben Walton <bwalton at artsci.utoronto.ca>
 ---
  lib/sup.rb                        |    1 -
  lib/sup/modes/thread-view-mode.rb |   16 ++++++++++++++--
  2 files changed, 14 insertions(+), 3 deletions(-)
 
 diff --git a/lib/sup.rb b/lib/sup.rb
 index 76444c9..96510b2 100644
 --- a/lib/sup.rb
 +++ b/lib/sup.rb
 @@ -207,7 +207,6 @@ else
      :confirm_top_posting => true,
      :discard_snippets_from_encrypted_messages => false,
      :default_attachment_save_dir => "",
 -    :bounce_sendmail => "",
    }
    begin
      FileUtils.mkdir_p Redwood::BASE_DIR
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 8842e59..76a1d1e 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -24,6 +24,18 @@ Return value:
    None. The variable 'headers' should be modified in place.
  EOS
  
 +  HookManager.register "bounce-command", <<EOS
 +Determines the command used to bounce a message.
 +Variables:
 +      from: The From header of the message being bounced
 +            (eg: likely _not_ your address).
 +        to: The addresses you asked the message to be bounced to as an array.
 +Return value:
 +  A string representing the command to pipe the mail into.  This
 +  should include the entire command except for the destination addresses,
 +  which will be appended by sup.
 +EOS
 +
    register_keymap do |k|
      k.add :toggle_detailed_header, "Toggle detailed header", 'h'
      k.add :show_header, "Show full message header", 'H'
 @@ -184,9 +196,9 @@ EOS
        end
      end
  
 -    cmd = case $config[:bounce_sendmail]
 +    cmd = case HookManager.run "bounce-command", :from => m.from, :to => to
            when nil, /^$/ then defcmd
 -          else $config[:bounce_sendmail]
 +          else hookcmd
            end + ' ' + to.map { |t| t.email }.join(' ')
  
      bt = to.size > 1 ? "#{to.size} recipients" : to.to_s
 -- 
 1.6.3
 
 
 From garoth@gmail.com  Mon Jun  8 08:55:14 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 8 Jun 2009 08:55:14 -0400
 Subject: [sup-talk] Fwd: [REQUEST] reply-to-list
 In-Reply-To: <80055d7c0906080553t41909b18j6c4a0f8fd119fa36@mail.gmail.com>
 References: <80055d7c0906080553t41909b18j6c4a0f8fd119fa36@mail.gmail.com>
 Message-ID: <80055d7c0906080555h37e2b551i606e60dbdd5414f2@mail.gmail.com>
 
 Hello there,
 
 Today I was told to read
 http://liw.iki.fi/liw/log/2003-Enemies-of-Carlotta.html.
 
 It suggests that a good mailing client should have a reply-to-list
 button since mailing lists should not add themselves as a reply-to.
 The reply-to-list uses the standard List-ID header to know where to
 reply to.
 
 As far as I can tell from ?-ing around the client, sup does not have
 this feature (though kudos for having a button for unsubscribe, which
 I find mildly curious but cool).
 
 I'm told that the mutt key for this is l (ell), which I guess is reasonable.
 
 Also, hello to the mailing list :)
 
 Cheers,
 
 -AT
 
 From bwalton@artsci.utoronto.ca  Mon Jun  8 09:03:11 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 08 Jun 2009 09:03:11 -0400
 Subject: [sup-talk] Fwd: [REQUEST] reply-to-list
 In-Reply-To: <80055d7c0906080555h37e2b551i606e60dbdd5414f2@mail.gmail.com>
 References: <80055d7c0906080553t41909b18j6c4a0f8fd119fa36@mail.gmail.com>
 	<80055d7c0906080555h37e2b551i606e60dbdd5414f2@mail.gmail.com>
 Message-ID: <1244466128-sup-135@ntdws12.chass.utoronto.ca>
 
 Excerpts from Andrei Thorp's message of Mon Jun 08 08:55:14 -0400 2009:
 > As far as I can tell from ?-ing around the client, sup does not have
 > this feature (though kudos for having a button for unsubscribe, which
 > I find mildly curious but cool).
 > 
 > I'm told that the mutt key for this is l (ell), which I guess is reasonable.
 
 Sup handles this in a smarter way.  When you hit r to reply to a
 message, if it's detected as a list post, the 'reply to' menu
 selection defaults to 'Mailing list.'  You can toggle this selection
 with the arrow keys.
 
 HTH.
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/00bf4f2d/attachment.bin>
 
 From joe@talkhouse.com  Mon Jun  8 11:21:52 2009
 From: joe@talkhouse.com (=?ISO-8859-1?Q?Joe_W=F6lfel?=)
 Date: Mon, 8 Jun 2009 11:21:52 -0400
 Subject: [sup-talk] Can't seem to send mail
 Message-ID: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 
 First, Sup awesome.   It's saves an incredible amount of time  
 searching through mail!
 
 I haven't been able to send messages with it yet though.  I can only  
 search and read.   I used sup-config to configure imap.   According to  
 the config.yaml file it's using sendmail -oem -ti to send.  If I try  
 to send a message it claims it's sent, but no such luck.   Do I need  
 to do something else in addition?  Actually, I'd like to be able to  
 send from multiple accounts and I'm not sure how to setup Sup to do  
 that.
   
   
 
 From garoth@gmail.com  Mon Jun  8 11:50:47 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 8 Jun 2009 11:50:47 -0400
 Subject: [sup-talk] Can't seem to send mail
 In-Reply-To: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 Message-ID: <80055d7c0906080850o2f861903v5b3a51effb215e0b@mail.gmail.com>
 
 Well, as far as I can tell, sup doesn't actually send mail itself, and can't.
 
 As such, it uses sendmail by default. Therefore, if you want it to
 send mail properly, you want to set up sendmail to send your mail.
 
 If you're sending through something sane, it probably uses smtp.
 Today, I installed msmtp and am using it with sup successfully to
 accomplish this, though you have to change the sendmail command to
 /usr/bin/msmtp -t.
 
 Alternatively, you could run your own mail server and use the sendmail
 that comes with that.
 
 From bwalton@artsci.utoronto.ca  Mon Jun  8 11:52:51 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 08 Jun 2009 11:52:51 -0400
 Subject: [sup-talk] Can't seem to send mail
 In-Reply-To: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 Message-ID: <1244476264-sup-5281@ntdws12.chass.utoronto.ca>
 
 Excerpts from Joe W?lfel's message of Mon Jun 08 11:21:52 -0400 2009:
 > I haven't been able to send messages with it yet though.  I can only  
 > search and read.   I used sup-config to configure imap.   According to  
 > the config.yaml file it's using sendmail -oem -ti to send.  If I try  
 > to send a message it claims it's sent, but no such luck.   Do I need  
 > to do something else in addition?  Actually, I'd like to be able to  
 > send from multiple accounts and I'm not sure how to setup Sup to do  
 > that.
 
 Check the log buffer first to see if sup reports errors interacting
 with (whatever is masquerading as) sendmail on your system...if there
 aren't errors there, check the mail logs on your system, since it has
 left the land of sup...If it doesn't make it to your index as a sent
 item, I suspect that the sendmail command may not be working
 correctly.
 
 HTH
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/67753431/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 13:18:30 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 10:18:30 -0700
 Subject: [sup-talk] exception with undomanager
 In-Reply-To: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 Message-ID: <1244481362-sup-970@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-07:
 > I bumped into this this morning.  I've not used the undo stuff much,
 > but I tried it today.  The (rough) sequence of events leading to this
 > was: I archived two threads separately and then decided I wanted to
 > undo the first of two actions.  I hit u once and got the latest thread
 > back and when I hit it again, sup crashed.  If I get a chance I'll
 > look into it myself, but I'm tossing it out for people more familiar
 > with these bits to see also.
 
 Something like this seems to happen fairly frequently. I think it's a
 (shudder) threading issue. Something is killing a buffer (possibly the
 user) while it's being redrawn and this happens. I need to stick another
 mutex in there somewhere. Or rewrite Sup for Ruby 1.9 with fibers
 instead of threads.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 13:23:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 10:23:43 -0700
 Subject: [sup-talk] sup/gpg
 In-Reply-To: <1244314983-sup-482@ntdws12.chass.utoronto.ca>
 References: <1243463452-sup-1174@cabinet>
 	<1243466444-sup-3672@ntdws12.chass.utoronto.ca>
 	<1243622801-sup-6484@cabinet>
 	<1243819025-sup-136@ntdws12.chass.utoronto.ca>
 	<1244037417-sup-8346@cabinet>
 	<1244313900-sup-578@ntdws12.chass.utoronto.ca>
 	<1244314253-sup-6338@cabinet>
 	<1244314983-sup-482@ntdws12.chass.utoronto.ca>
 Message-ID: <1244481592-sup-4821@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-06:
 > Excerpts from Marc Hartstein's message of Sat Jun 06 14:53:55 -0400 2009:
 > > Excerpts from Ben Walton's message of Sat Jun 06 14:45:56 -0400 2009:
 > > Those were two different sup instances (I'd quit, created a branch, and
 > > applied the discussed patch in between sending the two replies)
 > 
 > Well, if the patch altered the behaviour, that's a possibility.
 
 What was the patch?
 
 > > I might well have typoed my passphrase for one of the messages and not
 > > the other, though I'm not sure which.  I think it's slightly more likely
 > > that the BAD message was the one where I made a typo, though.  [I then
 > > proceeded to enter it correctly the second time, though, so...]
 > 
 > When I enter a bad passphrase into pinentry, sup detects this and
 > won't send the message...to my knowledge, I'm not able to get a
 > multipart/gpg message sent if I don't enter a proper passphrase.
 
 Yeah, an incorrect passphrase will error out, it won't produce a bad
 message.
 
 > I think that's reasonable.  My next thought is that there is a small
 > bug in the mime parsing (or creating) code...
 
 That is where I would start looking. If you tweak crypto.rb so that it
 dumps the payload somewhere (look in #format_payload), you can then
 compare that to what ends up in your sent.mbox.
 
 Also you can look at encrypting messages to yourself. Are you able to
 decrypt them reliably? If not, is there a pattern? (Non-ASCII in the
 headers, body, etc.?)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 14:00:23 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 11:00:23 -0700
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244270435-sup-9288@javelin>
 References: <1244270435-sup-9288@javelin>
 Message-ID: <1244481844-sup-9094@entry>
 
 Hi Edward,
 
 I think these are by and large legitimate gripes and I'd be delighted to
 have someone motivated to fix them!
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-05:
 > 1. Threads should be lazy-loaded (possibly in the background), with
 >    visible messages first.
 
 FWIW, this is particularly egregious in a direct IMAP connection, and
 those of us who have switched to Maildir or who use mbox aren't
 punished. But it would be very cool to have this.
 
 > If a conversation got a new message, Sup should only take its time to
 > load that message, and not the frickin' 24 other messages that were
 > also incidentally there.  I suspect this will require some pretty
 > major refactoring.
 
 It might not be too bad. Turn off the call to m.load_from_source! on
 line 106 of thread-index-mode.rb, add a Queue to ThreadViewMode
 containing messages to call #load_from_source! on, don't call m.chunks
 in ThreadViewMode#regen_text unless the message has been loaded, start a
 thread that pops messages from the queue, calls #load_from_source!  on
 them, and then calls regen_text when an open message has been loaded...
 and you're 90% of the way there.
 
 > 2. Auto-completion sucks and should be improved.  I should be able
 > to press "c", type two letters, and then mash tab. If auto-completion
 > actually works, then I'll blame it on dismal contacts.txt support
 
 The auto-completion is awesome. Adding a recipient to the contacts list is
 a good idea.
 
 > 3. Polling and loading of threads should started, asynchronously, at
 >    the same time.
 
 > Loading of threads should not hose my CPU.
 
 Agreed. Please fix.
 
 > Loading of threads should do smart things, instead of doing an O(n)
 > time warp.
 
 It's definitely worse than O(n). Loading threads could be sped up
 dramatically by storing the thread structure somewhere (either cached or
 just for every thread), since Sup does a lot of extra work rethreading
 everything every time you start it up. FWIW I'm doing this the right way
 in Sup 2.0.
 
 > 4. Sup should prompt me whether or not I want to Reply All or Reply on
 >    appropriate cases, like pine.
 
 There have been a couple similar requests like this recently, though
 it's not clear if everyone has known about the ability to change the
 reply mode and about the reply-to hook.  Since hitting 'r' defaults to
 replying to the sender alone (except for mailing list messages), I'd be
 ok with adding a Mutt-style reply-to-all key that starts up reply-mode
 with the 'reply to all' mode active.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 14:09:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 11:09:52 -0700
 Subject: [sup-talk] Sup is hanging
 In-Reply-To: <1244267416-sup-3720@javelin>
 References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin>
 	<1244064889-sup-9506@entry>
 	<alpine.DEB.2.00.0906031758290.24343@javelin>
 	<1244078482-sup-4986@javelin>
 	<alpine.DEB.2.00.0906032152200.6894@javelin>
 	<1244130722-sup-4496@entry> <1244177820-sup-6051@javelin>
 	<1244227108-sup-3123@cabinet> <1244238388-sup-760@javelin>
 	<1244267416-sup-3720@javelin>
 Message-ID: <1244484134-sup-5651@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-05:
 > -        if line =~ QUOTE_PATTERN || (line =~ QUOTE_START_PATTERN && nextline  =~ QUO
 > +        if line =~ QUOTE_PATTERN || (line =~ /:$/ && line =~ /\w/ && nextline =~ QU
 
 Seems fine to me. I've applied that change directly to master. Not only
 are there millions of optimiziations for this stuff, there are millions
 of tweaks to improve detection precision and recall.
 
 Thanks for your help with this, Edward!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From joe@talkhouse.com  Mon Jun  8 14:05:34 2009
 From: joe@talkhouse.com (=?ISO-8859-1?Q?Joe_W=F6lfel?=)
 Date: Mon, 8 Jun 2009 14:05:34 -0400
 Subject: [sup-talk] Can't seem to send mail
 In-Reply-To: <1244476264-sup-5281@ntdws12.chass.utoronto.ca>
 References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 	<1244476264-sup-5281@ntdws12.chass.utoronto.ca>
 Message-ID: <AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
 
 
 On Jun 8, 2009, at 11:52 AM, Ben Walton wrote:
 
 > Excerpts from Joe W?lfel's message of Mon Jun 08 11:21:52 -0400 2009:
 >> I haven't been able to send messages with it yet though.  I can only
 >> search and read.   I used sup-config to configure imap.   According  
 >> to
 >> the config.yaml file it's using sendmail -oem -ti to send.  If I try
 >> to send a message it claims it's sent, but no such luck.   Do I need
 >> to do something else in addition?  Actually, I'd like to be able to
 >> send from multiple accounts and I'm not sure how to setup Sup to do
 >> that.
 >
 > Check the log buffer first to see if sup reports errors interacting
 > with (whatever is masquerading as) sendmail on your system...if there
 > aren't errors there, check the mail logs on your system, since it has
 > left the land of sup...If it doesn't make it to your index as a sent
 > item, I suspect that the sendmail command may not be working
 > correctly.
 >
 > HTH
 > -Ben
 >
 > -- 
 > Ben Walton
 > Systems Programmer - CHASS
 > University of Toronto
 > C:416.407.5610 | W:416.978.4302
 >
 > GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 > Contact me to arrange for a CAcert assurance meeting.
 > _______________________________________________
 > sup-talk mailing list
 > sup-talk at rubyforge.org
 > http://rubyforge.org/mailman/listinfo/sup-talk
 
 It looks like sendmail isn't functioning and doesn't generate any  
 errors.   Maybe it's a mac problem.  I haven't tried it on anything  
 else yet.
 
 
 From ezyang@MIT.EDU  Mon Jun  8 14:18:41 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 14:18:41 -0400
 Subject: [sup-talk] exception with undomanager
 In-Reply-To: <1244481362-sup-970@entry>
 References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 	<1244481362-sup-970@entry>
 Message-ID: <1244485084-sup-973@javelin>
 
 Excerpts from William Morgan's message of Mon Jun 08 13:18:30 -0400 2009:
 > Something like this seems to happen fairly frequently. I think it's a
 > (shudder) threading issue. Something is killing a buffer (possibly the
 > user) while it's being redrawn and this happens. I need to stick another
 > mutex in there somewhere. Or rewrite Sup for Ruby 1.9 with fibers
 > instead of threads.
 
 The unfortunate bit about Ruby 1.9 is that the majority of libraries sup uses
 aren't on 1.9 yet...
 
 Cheers,
 Edward
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 14:25:10 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 11:25:10 -0700
 Subject: [sup-talk] sup/gpg
 In-Reply-To: <1244483397-sup-3035@cabinet>
 References: <1243463452-sup-1174@cabinet>
 	<1243466444-sup-3672@ntdws12.chass.utoronto.ca>
 	<1243622801-sup-6484@cabinet>
 	<1243819025-sup-136@ntdws12.chass.utoronto.ca>
 	<1244037417-sup-8346@cabinet>
 	<1244313900-sup-578@ntdws12.chass.utoronto.ca>
 	<1244314253-sup-6338@cabinet>
 	<1244314983-sup-482@ntdws12.chass.utoronto.ca>
 	<1244481592-sup-4821@entry> <1244483397-sup-3035@cabinet>
 Message-ID: <1244485140-sup-1973@entry>
 
 Reformatted excerpts from Marc Hartstein's message of 2009-06-08:
 > The regexp fix for messages with very long lines.
 
 Yeah, that shouldn't change anything. Doesn't even change Sup's output!
 
 > Yeah, it bounces me back to pinentry, where I proceeded to enter it
 > correctly.  It *shouldn't* produce a bad message, it was just one of
 > the only things I could think of that had changed between the two
 > messages which might have led to different behavior.
 
 Except the message content, I guess. :)
 
 > > Also you can look at encrypting messages to yourself. Are you able
 > > to decrypt them reliably? If not, is there a pattern? (Non-ASCII in
 > > the headers, body, etc.?)
 > 
 > I expect this will have the same behavior as checking signatures on
 > messages I send, no?
 
 It should; I was just suggesting it as an alternative approach to
 figuring out what was causing the problem. Then Ben isn't in the loop
 any more and you can spend all night happily debuggin this. :)
 
 > Ben is using gpg 1 after correspondents complained the switch to gpg 2
 > caused his messages to have bad signatures.
 
 Was he using Sup the entire time?
 
 > I am using gpg 2.0.11
 > 
 > I see *all* Ben's messages as having bad signatures, and see all my
 > own (either in sent.mbox or bounced back to me from the list) as good.
 > I also see Ben's signatures as bad when looking at the same messages
 > through mutt.  I see the same thing going back to his first signed
 > message to sup-talk, and also in his direct emails to me.
 >
 > Ben sees most of my signatures as good, but has recently experienced
 > an intermittent issue where my signatures are bad.
 
 It sounds like there might be some possibility that it's a GPG version
 incompatibility, though I'd be a little surprised if that were really
 the case. It might be helpful if you guys could do a control experiment
 with Mutt, since I have a fair amount of faith in its GPG
 implementation.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From garoth@gmail.com  Mon Jun  8 14:42:28 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 8 Jun 2009 14:42:28 -0400
 Subject: [sup-talk] Can't seem to send mail
 In-Reply-To: <AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
 References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 	<1244476264-sup-5281@ntdws12.chass.utoronto.ca>
 	<AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
 Message-ID: <80055d7c0906081142w63a5ddf3w2d7c06fd174b3740@mail.gmail.com>
 
 Heh.
 
 # file /usr/sbin/sendmail
 /usr/sbin/sendmail: symbolic link to `/bin/true'
 
 Fail.
 
 (or it would be ;)
 
 -AT
 
 From bwalton@artsci.utoronto.ca  Mon Jun  8 14:44:50 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 08 Jun 2009 14:44:50 -0400
 Subject: [sup-talk] Can't seem to send mail
 In-Reply-To: <AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
 References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 	<1244476264-sup-5281@ntdws12.chass.utoronto.ca>
 	<AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
 Message-ID: <1244486438-sup-3501@ntdws12.chass.utoronto.ca>
 
 Excerpts from Joe W?lfel's message of Mon Jun 08 14:05:34 -0400 2009:
 > It looks like sendmail isn't functioning and doesn't generate any  
 > errors.   Maybe it's a mac problem.  I haven't tried it on anything  
 > else yet.
 
 Personally, I don't think sendmail has _ever_ been functional, but
 that's just the grumpy side of me that has to configure it on clunky
 old boxes still! :)
 
 It's likely working, but has a local delivery setup configured.  Try
 using `mailq` to see if anything is sitting in the outbound queue.
 You may also want to look in /var/spool/mail for mbox files sitting
 there with the messages (or bounces) sent from sup.
 
 If you want to get your hands dirty, I recommend exim as the
 replacment for sendmail.  I like it's configuration and acl setup
 better than postfix, but that would also work.  If you just want to
 send mail quickly and easily, try msmtp or a similar package.
 
 HTH.
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/1f82e67c/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Mon Jun  8 14:50:19 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 08 Jun 2009 14:50:19 -0400
 Subject: [sup-talk] exception with undomanager
 In-Reply-To: <1244485084-sup-973@javelin>
 References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 	<1244481362-sup-970@entry> <1244485084-sup-973@javelin>
 Message-ID: <1244486944-sup-293@ntdws12.chass.utoronto.ca>
 
 Excerpts from Edward Z. Yang's message of Mon Jun 08 14:18:41 -0400 2009:
 > The unfortunate bit about Ruby 1.9 is that the majority of libraries sup uses
 > aren't on 1.9 yet...
 
 ...and some platforms don't have packages for it yet, which puts more
 onus on the user to get it up and going...
 
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/836af547/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 14:59:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 11:59:04 -0700
 Subject: [sup-talk] exception with undomanager
 In-Reply-To: <1244485084-sup-973@javelin>
 References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 	<1244481362-sup-970@entry> <1244485084-sup-973@javelin>
 Message-ID: <1244487518-sup-3141@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
 > The unfortunate bit about Ruby 1.9 is that the majority of libraries
 > sup uses aren't on 1.9 yet...
 
 Not a serious suggestion. One rewrite going at a time is my rule. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Mon Jun  8 15:02:28 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 15:02:28 -0400
 Subject: [sup-talk] exception with undomanager
 In-Reply-To: <1244486944-sup-293@ntdws12.chass.utoronto.ca>
 References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 	<1244481362-sup-970@entry> <1244485084-sup-973@javelin>
 	<1244486944-sup-293@ntdws12.chass.utoronto.ca>
 Message-ID: <1244487681-sup-5778@javelin>
 
 Excerpts from Ben Walton's message of Mon Jun 08 14:50:19 -0400 2009:
 > ...and some platforms don't have packages for it yet, which puts more
 > onus on the user to get it up and going...
 
 Ruby is basically not usable with your package manager. You *have* to
 roll the gems yourself.
 
 Cheers,
 Edward
 
 From bwalton@artsci.utoronto.ca  Mon Jun  8 15:20:31 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 08 Jun 2009 15:20:31 -0400
 Subject: [sup-talk] exception with undomanager
 In-Reply-To: <1244487681-sup-5778@javelin>
 References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca>
 	<1244481362-sup-970@entry> <1244485084-sup-973@javelin>
 	<1244486944-sup-293@ntdws12.chass.utoronto.ca>
 	<1244487681-sup-5778@javelin>
 Message-ID: <1244488618-sup-3388@ntdws12.chass.utoronto.ca>
 
 Excerpts from Edward Z. Yang's message of Mon Jun 08 15:02:28 -0400 2009:
 > Ruby is basically not usable with your package manager. You *have* to
 > roll the gems yourself.
 
 I realize this.  Gems are awesome and gems suck.  I'm talking about
 the matz ruby interpreter itself.  In some instances, not only would
 the user need all of the gems, but they'd need a 1.9 ruby too...that a
 big commitment to run a mail client.
 
 [As a side note, Debian/Ubuntu do package many of the gems, but it's a
 round hole, square peg affair.]
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/33159422/attachment.bin>
 
 From joe@talkhouse.com  Mon Jun  8 16:03:58 2009
 From: joe@talkhouse.com (=?ISO-8859-1?Q?Joe_W=F6lfel?=)
 Date: Mon, 8 Jun 2009 16:03:58 -0400
 Subject: [sup-talk] Can't seem to send mail
 In-Reply-To: <1244486438-sup-3501@ntdws12.chass.utoronto.ca>
 References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 	<1244476264-sup-5281@ntdws12.chass.utoronto.ca>
 	<AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
 	<1244486438-sup-3501@ntdws12.chass.utoronto.ca>
 Message-ID: <B9FE7468-E096-4E40-A6E8-37372F266EA2@talkhouse.com>
 
 
 On Jun 8, 2009, at 2:44 PM, Ben Walton wrote:
 
 > Excerpts from Joe W?lfel's message of Mon Jun 08 14:05:34 -0400 2009:
 >> It looks like sendmail isn't functioning and doesn't generate any
 >> errors.   Maybe it's a mac problem.  I haven't tried it on anything
 >> else yet.
 >
 > Personally, I don't think sendmail has _ever_ been functional, but
 > that's just the grumpy side of me that has to configure it on clunky
 > old boxes still! :)
 >
 > It's likely working, but has a local delivery setup configured.  Try
 > using `mailq` to see if anything is sitting in the outbound queue.
 > You may also want to look in /var/spool/mail for mbox files sitting
 > there with the messages (or bounces) sent from sup.
 >
 > If you want to get your hands dirty, I recommend exim as the
 > replacment for sendmail.  I like it's configuration and acl setup
 > better than postfix, but that would also work.  If you just want to
 > send mail quickly and easily, try msmtp or a similar package.
 
 Thanks.  Looks like msmtp did the trick.  Debugging sendmail was more  
 than I cared to take on. 
   
 
 From garoth@gmail.com  Mon Jun  8 16:53:42 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 8 Jun 2009 16:53:42 -0400
 Subject: [sup-talk] Can't seem to send mail
 In-Reply-To: <B9FE7468-E096-4E40-A6E8-37372F266EA2@talkhouse.com>
 References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com>
 	<1244476264-sup-5281@ntdws12.chass.utoronto.ca>
 	<AAB8FA5E-9E58-4C24-9290-F3C80155E55D@talkhouse.com>
 	<1244486438-sup-3501@ntdws12.chass.utoronto.ca>
 	<B9FE7468-E096-4E40-A6E8-37372F266EA2@talkhouse.com>
 Message-ID: <80055d7c0906081353s276ed18o156f12d8df981e28@mail.gmail.com>
 
 > Thanks. ?Looks like msmtp did the trick. ?Debugging sendmail was more than I
 
 Yeah, it sure is scary. Glad that helped.
 
 Cheers,
 
 -AT
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 17:34:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 14:34:31 -0700
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244246896-sup-4529@javelin>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin> <1244208597-sup-4979@entry>
 	<1244246896-sup-4529@javelin>
 Message-ID: <1244496654-sup-5759@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-05:
 > Great! My hook works now. This is the sort of functionality that I
 > think is worth generalizing and implementing as a configuration
 > twiddle (one, I think, that should be on by default.)
 
 I have a strong preference for hooks over configuration variables. Look
 at the .muttrc documentation for why.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Mon Jun  8 17:59:39 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 17:59:39 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244496654-sup-5759@entry>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin> <1244208597-sup-4979@entry>
 	<1244246896-sup-4529@javelin> <1244496654-sup-5759@entry>
 Message-ID: <1244498316-sup-1297@javelin>
 
 Excerpts from William Morgan's message of Mon Jun 08 17:34:31 -0400 2009:
 > I have a strong preference for hooks over configuration variables. Look
 > at the .muttrc documentation for why.
 
 There's an interesting usability argument there.  Right now, I still (possibly
 naively) believe that if you organize your configuration properly, you can
 have an arbitrarily large amount of it.
 
 What's your opinion on making this default behavior, with no configuration
 twiddle?
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Mon Jun  8 19:14:32 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 19:14:32 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244481844-sup-9094@entry>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 Message-ID: <1244502545-sup-9840@javelin>
 
 Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
 > It might not be too bad. Turn off the call to m.load_from_source! on
 > line 106 of thread-index-mode.rb, add a Queue to ThreadViewMode
 > containing messages to call #load_from_source! on, don't call m.chunks
 > in ThreadViewMode#regen_text unless the message has been loaded, start a
 > thread that pops messages from the queue, calls #load_from_source!  on
 > them, and then calls regen_text when an open message has been loaded...
 > and you're 90% of the way there.
 
 A few questions:
 
 * How do I tell if a message is shown on the screen or not?
 
 * The implementation you describe still downloads the messages
   sequentially, which are usually not the messages we want to download
   first. I don't mind sup blocking on downloading a message, as long
   as it's one or two, which means I don't strictly need threads: I
   just need some API for, when a new message is opened, downloading it
   and then rendering it.  What do you think of this?
 
 > The auto-completion is awesome. Adding a recipient to the contacts list is
 > a good idea.
 
 Does contacts.rb apply to people.txt or contacts.txt?
 
 > It's definitely worse than O(n). Loading threads could be sped up
 > dramatically by storing the thread structure somewhere (either cached or
 > just for every thread), since Sup does a lot of extra work rethreading
 > everything every time you start it up. FWIW I'm doing this the right way
 > in Sup 2.0.
 
 Can you backport it easily to Sup 1.0?
 
 > There have been a couple similar requests like this recently, though
 > it's not clear if everyone has known about the ability to change the
 > reply mode and about the reply-to hook.  Since hitting 'r' defaults to
 > replying to the sender alone (except for mailing list messages), I'd be
 > ok with adding a Mutt-style reply-to-all key that starts up reply-mode
 > with the 'reply to all' mode active.
 
 The explicit prompt makes me think about who I want to send the message
 to.  I frequently forget to move the little knob with Sup's behavior.
 
 Cheers,
 Edward
 
 From wmorgan-sup@masanjin.net  Mon Jun  8 19:46:39 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 08 Jun 2009 16:46:39 -0700
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244502545-sup-9840@javelin>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin>
 Message-ID: <1244503985-sup-8587@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
 > * How do I tell if a message is shown on the screen or not?
 
 If m is the message, @layout[m].state will be :open, :detailed or
 :closed. If it's not :closed, it is visible.
 
 > * The implementation you describe still downloads the messages
 > sequentially, which are usually not the messages we want to download
 > first.
 
 Only if you add them to the Queue sequentially. You could instead add
 the ones with :unread or :starred labels first. And ideally if you
 expand a collapsed unloaded message, that should be pushed to the head
 of the Queue.
 
 > I don't mind sup blocking on downloading a message, as long
 > as it's one or two, which means I don't strictly need threads: I
 > just need some API for, when a new message is opened, downloading it
 > and then rendering it.  What do you think of this?
 
 So you would only preload the new/starred ones, and load the others only
 when they're expanded? I think that simply removing that call in
 thread-index-mode.rb would accomplish this.
 
 I'd rather have the threaded version, since loading a thread of 100 new
 messages sucks, but either way would be an improvement.
 
 > > The auto-completion is awesome. Adding a recipient to the contacts
 > > list is a good idea.
 > 
 > Does contacts.rb apply to people.txt or contacts.txt?
 
 contacts.txt. people.txt is deprecated. In fact I'm surprised you have
 one.
 
 > > It's definitely worse than O(n). Loading threads could be sped up
 > > dramatically by storing the thread structure somewhere (either
 > > cached or just for every thread), since Sup does a lot of extra work
 > > rethreading everything every time you start it up. FWIW I'm doing
 > > this the right way in Sup 2.0.
 > 
 > Can you backport it easily to Sup 1.0?
 
 No, it's completely different. It would be easier to rewrite from
 scratch for the existing Sup.
 
 > The explicit prompt makes me think about who I want to send the
 > message to. I frequently forget to move the little knob with Sup's
 > behavior.
 
 When do you want it to prompt you? Is this a yes/no prompt?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Mon Jun  8 20:12:44 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 20:12:44 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244502124-sup-7043@cabinet>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin> <1244208597-sup-4979@entry>
 	<1244246896-sup-4529@javelin> <1244496654-sup-5759@entry>
 	<1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet>
 Message-ID: <1244506097-sup-8895@javelin>
 
 Excerpts from Marc Hartstein's message of Mon Jun 08 19:09:16 -0400 2009:
 > Reading the thread, it's not clear exactly what your hook does, or what
 > behavior you want as the default.  I didn't see anything which said what
 > you were trying to accomplish.
 
 My apologies.
 
 My sup email comes from three distinct sources, and as part of my
 configuration they get a label as such (mit, twp or ita).  This label
 is the most visible way of telling me which source my mail came from.
 
 I am subscribed to numerous mailing lists, however, which do not
 explicitly list my mail address in To or CC. As a result, Sup defaults
 to my "main address".
 
 What I would like Sup to do is look at the label, find the appropriate
 source, and use the email in the source to populate the From field.
 This is different from what you describe below.
 
 > Attempting to figure it out from your code samples, I'm guessing that
 > you're trying to get sup to always reply with a from address of the
 > known address of yours found in the recipient list of the email being
 > relied to, if any?
 
 If Sup doesn't do the correct thing in this case, this additional hook
 would be useful.
 
 > I do get the sense that there might be a lot of people out there who
 > want to use the default (always use default account) behavior, so I'm
 > not sure about switching the default.  I wouldn't exactly be against it,
 > though.
 
 I would argue that most people have at least a personal and a work
 email account, and that it is not appropriate to conflate the two.
 They can write a hook that overrides an address (or, horror horror,
 a twiddle in sources) to do it.
 
 Cheers,
 Edward
 
 From garoth@gmail.com  Mon Jun  8 20:37:53 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 8 Jun 2009 17:37:53 -0700
 Subject: [sup-talk] Gmail Labels Sidebar
 Message-ID: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 
 Hello there,
 
 As some of you probably remember, there is a handy sidebar in Gmail
 which lists your tags and how many e-mails you have in each one.
 
 What I do with this is have e-mail skip my inbox, get a mailing list
 tag applied to it, and then get archived, at which point it shows up
 in my labels sidebar. I have my "important" mail in my inbox, and the
 mailing lists with updates are clearly marked.
 
 Any suggestions as to what sup users do to have this kind of workflow?
 It's preferable for me because it keeps things tidy, I can see the new
 mails, and I get >50 e-mails per day. It'd be a shame to have them all
 fall into my inbox and spam it up, which I prefer to keep clean for
 "needs to be taken care of immediately" type e-mail.
 
 Thanks,
 
 -AT
 
 From bwalton@artsci.utoronto.ca  Mon Jun  8 21:05:06 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 08 Jun 2009 21:05:06 -0400
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 Message-ID: <1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 
 Excerpts from Andrei Thorp's message of Mon Jun 08 20:37:53 -0400 2009:
 > Any suggestions as to what sup users do to have this kind of workflow?
 > It's preferable for me because it keeps things tidy, I can see the new
 > mails, and I get >50 e-mails per day. It'd be a shame to have them all
 > fall into my inbox and spam it up, which I prefer to keep clean for
 > "needs to be taken care of immediately" type e-mail.
 
 Use the Label view.  Hit L followed by enter.
 
 HTH
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 235 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/563b1ece/attachment.bin>
 
 From ezyang@MIT.EDU  Mon Jun  8 22:13:17 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 22:13:17 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244503985-sup-8587@entry>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 Message-ID: <1244506405-sup-5117@javelin>
 
 Thanks for the answers to the technical questions.
 
 Excerpts from William Morgan's message of Mon Jun 08 19:46:39 -0400 2009:
 > So you would only preload the new/starred ones, and load the others only
 > when they're expanded? I think that simply removing that call in
 > thread-index-mode.rb would accomplish this.
 > 
 > I'd rather have the threaded version, since loading a thread of 100 new
 > messages sucks, but either way would be an improvement.
 
 I am somewhat skeptical of your described change, but I will try it
 out and report back.  The threaded version would certainly be a nice
 thing.
 
 > contacts.txt. people.txt is deprecated. In fact I'm surprised you have
 > one.
 
 Um... my contacts.txt is empty, and people.txt has lots of entries in it.
 
 > No, it's completely different. It would be easier to rewrite from
 > scratch for the existing Sup.
 
 Savvy.
 
 > > The explicit prompt makes me think about who I want to send the
 > > message to. I frequently forget to move the little knob with Sup's
 > > behavior.
 > 
 > When do you want it to prompt you? Is this a yes/no prompt?
 
 Yes. (to yes/no).
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Mon Jun  8 22:14:30 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 22:14:30 -0400
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 Message-ID: <1244513641-sup-360@javelin>
 
 Excerpts from Ben Walton's message of Mon Jun 08 21:05:06 -0400 2009:
 > Use the Label view.  Hit L followed by enter.
 
 I think what he's looking for is the information about his labels
 to always be present, as opposed to something he has to remind
 himself to check.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Mon Jun  8 22:23:44 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 22:23:44 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244506405-sup-5117@javelin>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 	<1244506405-sup-5117@javelin>
 Message-ID: <1244514081-sup-2943@javelin>
 
 Excerpts from Edward Z. Yang's message of Mon Jun 08 22:13:17 -0400 2009:
 > I am somewhat skeptical of your described change, but I will try it
 > out and report back.  The threaded version would certainly be a nice
 > thing.
 
 It works, although it acts a bit strangely when there are still
 threads loading into memory.
 
 
 >From b2518f113118e489e22a1c2085b33a9c18721f97 Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <edwardzyang at thewritingpot.com>
 Date: Mon, 8 Jun 2009 22:21:01 -0400
 Subject: [PATCH] Remove message pre-loading; optimizes for the common case.
  Signed-off-by: Edward Z. Yang <edwardzyang at thewritingpot.com>
 
 ---
  lib/sup/modes/thread-index-mode.rb |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index 9b44ee3..29de39a 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -103,7 +103,6 @@ EOS
          t.each_with_index do |(m, *o), i|
            next unless m
            BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1
 -          m.load_from_source! 
          end
        end
        mode = ThreadViewMode.new t, @hidden_labels, self
 -- 
 1.6.0.4
 
 From bwalton@artsci.utoronto.ca  Mon Jun  8 22:24:42 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 08 Jun 2009 22:24:42 -0400
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244513641-sup-360@javelin>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 Message-ID: <1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 
 Excerpts from Edward Z. Yang's message of Mon Jun 08 22:14:30 -0400 2009:
 > I think what he's looking for is the information about his labels
 > to always be present, as opposed to something he has to remind
 > himself to check.
 
 So something similar to the folder view hack/patch for mutt?  That
 doesn't exist in sup.  The closest you get is having the 'All Labels'
 buffer open.  You can jump to a view of all messages with that label
 by hitting enter on the selected label.  Moving back to it is simple
 with the buffer rolling keys.  I believe that some people operate from
 this buffer instead of the inbox one.  Not my cup of tea though.
 
 HTH.
 -Ben
 
 
 
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090608/a9e55e8a/attachment.bin>
 
 From ezyang@MIT.EDU  Mon Jun  8 22:35:04 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 22:35:04 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244514081-sup-2943@javelin>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 	<1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin>
 Message-ID: <1244514851-sup-1414@javelin>
 
 Excerpts from Edward Z. Yang's message of Mon Jun 08 22:23:44 -0400 2009:
 > It works, although it acts a bit strangely when there are still
 > threads loading into memory.
 
 I think I've been able to pin down this behavior more precisely,
 and it's not just this patches fault: displaying messages seems to
 block on having all of the threads present.  Does this ring a bell?
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Mon Jun  8 22:38:08 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 22:38:08 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244481844-sup-9094@entry>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 Message-ID: <1244515056-sup-4758@javelin>
 
 Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
 > > 3. Polling and loading of threads should started, asynchronously, at
 > >    the same time.
 > 
 > > Loading of threads should not hose my CPU.
 > 
 > Agreed. Please fix.
 
 It appears that polling blocks on loading threads, so it doesn't help
 to fix that until we fix the thread loading code.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Mon Jun  8 23:00:55 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 08 Jun 2009 23:00:55 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244481844-sup-9094@entry>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 Message-ID: <1244515897-sup-539@javelin>
 
 Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
 > It's definitely worse than O(n). Loading threads could be sped up
 > dramatically by storing the thread structure somewhere (either cached or
 > just for every thread), since Sup does a lot of extra work rethreading
 > everything every time you start it up. FWIW I'm doing this the right way
 > in Sup 2.0.
 
 I'm thinking about how to do this, and one of the first I'm blockers
 I'm running against is that it's not quite obvious what's invoking
 the thread building code thread.rb.
 
 As for caching the thread, I'm thinking of generating a unique
 ID for each thread and sticking that on every message.  Whether or
 not this will actually help depends a lot on what the answer to the
 above question is.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Tue Jun  9 00:06:40 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Tue, 09 Jun 2009 00:06:40 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244518550-sup-6361@cabinet>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin> <1244208597-sup-4979@entry>
 	<1244246896-sup-4529@javelin> <1244496654-sup-5759@entry>
 	<1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet>
 	<1244506097-sup-8895@javelin> <1244518550-sup-6361@cabinet>
 Message-ID: <1244519893-sup-7418@javelin>
 
 Excerpts from Marc Hartstein's message of Mon Jun 08 23:46:48 -0400 2009:
 > I think that's beyond what I'd personally think of as a "configuration
 > twiddle", though...
 
 Perhaps.
 
 > You'd do it by, what, having a 1:1 mapping between email addresses and
 > labels somewhere in the configuration, anything coming to the email
 > address gets the label, and any reply to a message with the label
 > (however it got it) gets the email address?
 
 Yes.
 
 > (It's also not as though the hook to only use your default address is
 > hard to write.)
 
 Indeed.
 
 Cheers,
 Edward
 
 From tarko@lanparty.ee  Tue Jun  9 06:00:13 2009
 From: tarko@lanparty.ee (Tarko Tikan)
 Date: Tue, 09 Jun 2009 13:00:13 +0300
 Subject: [sup-talk] display_length issue with special-characters on non-UTF8
 	terminal
 Message-ID: <1244536704-sup-7027@valgus>
 
 hey,
 
 When String.display_length was introduced in recent update, it broke the length for non-UTF8 strings that contain the special characters. Wrong length results corrupted display (line ends chopped off).
 
 Terminal is iso-8859-15 and it's detected by sup correctly.
 
 I've tracked it down to /./u regexp. Here are some examples:
 
 irb(main):001:0> "asd".scan(/./u)
 => ["a", "s", "d"]
 irb(main):002:0> "asd????".scan(/./u)
 => ["a", "s", "d", "\365\374\344\366"]
 irb(main):017:0> "asd???".scan(/./u)
 => ["a", "s", "d"]
 
 irb(main):008:0* "asd".scan(/./)
 => ["a", "s", "d"]
 irb(main):009:0> "asd????".scan(/./)
 => ["a", "s", "d", "\365", "\374", "\344", "\366"]
 
 Expecting UTF8 gives unexpected results :) Also, old behaviour of String.length gives correct results with these test cases.
 
 -- 
 tarko
 
 From garoth@gmail.com  Tue Jun  9 09:33:15 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 9 Jun 2009 09:33:15 -0400
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 Message-ID: <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 
 Yeah, I guess that makes sense. It is a rather nice interface
 actually, I didn't really think about it for some reason.
 
 And I guess there are probably some configuration options to skip
 inbox and attach labels to stuff matching stuff automatically, with
 procmail. I think I saw a page about that somewhere.
 
 I guess there is probably a way to programatically access this kind of
 information also, but are there any command line tools I can use to
 query for this kind of stuff? If so, I can hack my window manager's
 panels to display the mails in these labels, which would be pretty
 rad. (My WM is "Awesome" btw -- that's the name.)
 
 Any suggestions for quickly getting this labels-has-unread-messages
 info outside of sup?
 
 Thanks guys! :)
 
 -AT
 
 From garoth@gmail.com  Tue Jun  9 09:42:29 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 9 Jun 2009 09:42:29 -0400
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 Message-ID: <80055d7c0906090642h421964f2t41d52290042469bc@mail.gmail.com>
 
 On Tue, Jun 9, 2009 at 9:33 AM, Andrei Thorp<garoth at gmail.com> wrote:
 > Yeah, I guess that makes sense. It is a rather nice interface
 > actually, I didn't really think about it for some reason.
 
 I just actually ran a quick test (with 0.8) and it looks like the
 label-list-mode fails to update automatically D:
 
 What I did was put on the label-list-mode, manually send myself an
 e-mail, re-run fetchmail to grab it (I get a notification via procmail
 saying it came in). Then I remember that sup polls at intervals, so I
 wait.
 
 Eventually, the status bar at the bottom says that there is a new
 message in the inbox, but the Inbox label does not get updated in my
 view. It still says 0/0.
 
 I press x to go back to the inbox screen, it has the mail. I go back
 to label-list-mode, and now it registers it.
 
 So I guess I'd call that a bug actually, and it's unlikely that people
 operate out of this mode habitually or else this would have probably
 been found.
 
 (Unless it already has?)
 
 Cheers,
 
 -AT
 
 From marcus-sup@bar-coded.net  Tue Jun  9 10:11:08 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 09 Jun 2009 15:11:08 +0100
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 Message-ID: <1244556424-sup-1426@tomsk>
 
 On 9.6.2009, Andrei Thorp wrote:
 > Any suggestions for quickly getting this labels-has-unread-messages
 > info outside of sup?
 
 Attached is a labels mode outside of sup... Useful for conky etc. Just
 pipe the output to a file (warnings errors etc wont go to the file)
 
 William - if you want to add this to sup/bin feel free. Its basically
 the regen_text method lifted and edited slightly from the
 label-list-mode
 
 It might need a few more tweaks - I'm not sure it needs to
 load/save/unlock the index really. They're there because they came for
 free with the copy and paste of bin/sup-tweak-labels :)
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-list-labels
 Type: application/octet-stream
 Size: 1773 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090609/344b333b/attachment.obj>
 
 From marcus-sup@bar-coded.net  Tue Jun  9 10:24:35 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 09 Jun 2009 15:24:35 +0100
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244556424-sup-1426@tomsk>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 	<1244556424-sup-1426@tomsk>
 Message-ID: <1244557461-sup-4140@tomsk>
 
 On 9.6.2009, I wrote:
 > On 9.6.2009, Andrei Thorp wrote:
 > > Any suggestions for quickly getting this labels-has-unread-messages
 > > info outside of sup?
 > 
 > Attached is a labels mode outside of sup... Useful for conky etc. Just
 > pipe the output to a file (warnings errors etc wont go to the file)
 
 Oh and I forgot - if you want to kick off sup from a click on one of
 these labels (assuming you can do something like that in your WM) you
 can call sup with --search "label:somelabel" to get that label
 displayed.
 
 Marcus
 
 From marcus-sup@bar-coded.net  Tue Jun  9 10:29:55 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 09 Jun 2009 15:29:55 +0100
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244556424-sup-1426@tomsk>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 	<1244556424-sup-1426@tomsk>
 Message-ID: <1244557672-sup-7417@tomsk>
 
 On 9.6.2009, I wrote:
 > William - if you want to add this to sup/bin feel free. Its basically
 > the regen_text method lifted and edited slightly from the
 > label-list-mode
 
 You might want to delete lines 24-26 as well to save the warning about
 uninitialised variable. At some point I'll post my version with a
 query which is a little less hurried, but doesnt work quite how I want
 yet.
 
 Marcus
 
 From garoth@gmail.com  Tue Jun  9 10:37:54 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 9 Jun 2009 10:37:54 -0400
 Subject: [sup-talk] Fwd:  Gmail Labels Sidebar
 In-Reply-To: <80055d7c0906090735x581d27a2pfeb3ca2d470bb099@mail.gmail.com>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 	<1244556424-sup-1426@tomsk> <1244557461-sup-4140@tomsk>
 	<80055d7c0906090735x581d27a2pfeb3ca2d470bb099@mail.gmail.com>
 Message-ID: <80055d7c0906090737g46f9f3b3y7ee00b91dbe08f22@mail.gmail.com>
 
 > Oh and I forgot - if you want to kick off sup from a click on one of
 > these labels (assuming you can do something like that in your WM) you
 > can call sup with --search "label:somelabel" to get that label
 > displayed.
 
 Damn, that's a great idea! I didn't even think about that.
 
 /me checks up on what else sup has in its cli flags.
 
 Cheers,
 
 -AT
 
 PS.
 
 Well, while I'm here, I guess I'll also mention this fairly obvious
 script line that just outputs the unread messages in a filtered list:
 sup-list-labels 2> /dev/null | grep -E "Inbox|Sent" | sed -r "s/^
 *([A-Za-z]*).* ([0-9]+) unread/\1: \2/"
 
 So to go through this:
 ?- Pipe the stderr to /dev/null (we don't want to see the messages)
 ?- grep for either "Inbox" or "Sent" -- you can put lots more |blah|blah there
 ?- sed magic to extract and reformat the data
 
 This might be useful for outputting somewhere like in a shell prompt or panel.
 
 PPS. argh, still not using sup for this mailing list so I replied to
 an individual. Forwarded D:
 
 PPPS. Sorry that it wrapped my sed command there, but I'm sure you get the idea.
 
 PPPPS. Sorry about the unfashionable amount of PSes ;)
 
 From wmorgan-sup@masanjin.net  Tue Jun  9 12:52:37 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 09 Jun 2009 09:52:37 -0700
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244518550-sup-6361@cabinet>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin> <1244208597-sup-4979@entry>
 	<1244246896-sup-4529@javelin> <1244496654-sup-5759@entry>
 	<1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet>
 	<1244506097-sup-8895@javelin> <1244518550-sup-6361@cabinet>
 Message-ID: <1244565962-sup-4211@entry>
 
 Reformatted excerpts from Marc Hartstein's message of 2009-06-08:
 > I think that's beyond what I'd personally think of as a "configuration
 > twiddle", though...
 
 I tend to agree. I completely understand the use case, and I agree it's
 probably a common one, but this is exactly the kind of thing I want to
 address with hooks instead of with configuration. (Not that there's
 *really* a distinction between these two things in the first place.)
 
 Then when the next guy comes along and says, "I like this but I want my
 from address based on X instead of the label", I can also avoid having
 to do any work.
 
 Edward, if you want to invest time on making this particular scheme easy
 for users, I would be happy to include contributed hooks as part of the
 Sup distribution, and you can supply one that reads a simple
 configuration file and produces this behavior.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jun  9 13:32:53 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 09 Jun 2009 10:32:53 -0700
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244506405-sup-5117@javelin>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 	<1244506405-sup-5117@javelin>
 Message-ID: <1244567126-sup-1563@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
 > Excerpts from William Morgan's message of Mon Jun 08 19:46:39 -0400 2009:
 > > contacts.txt. people.txt is deprecated. In fact I'm surprised you have
 > > one.
 > 
 > Um... my contacts.txt is empty, and people.txt has lots of entries in it.
 
 Does your people.txt have a really old timestamp? That file doesn't get
 touched by any version of Sup later less than three months old.
 Do you add people to your contact list with 'i'? If not, contacts.txt
 will be empty.
 
 > > When do you want it to prompt you? Is this a yes/no prompt?
 > 
 > Yes. (to yes/no).
 
 So... once you write the email and you press 'y' it prompts you whether
 you want to send it? Or when you press 'r' it prompts you whether you
 really want to reply?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jun  9 13:40:38 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 09 Jun 2009 10:40:38 -0700
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244514851-sup-1414@javelin>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 	<1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin>
 	<1244514851-sup-1414@javelin>
 Message-ID: <1244569129-sup-4112@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
 > I think I've been able to pin down this behavior more precisely,
 > and it's not just this patches fault: displaying messages seems to
 > block on having all of the threads present.  Does this ring a bell?
 
 Not entirely sure what you mean by "having all the threads present", but
 opening a thread-view-mode buffer doesn't block on anything, at least
 with that patch applied. Without the patch, it blocks on loading the
 message body for every message in that particular thread from the
 server.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jun  9 13:45:45 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 09 Jun 2009 10:45:45 -0700
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244515056-sup-4758@javelin>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244515056-sup-4758@javelin>
 Message-ID: <1244569341-sup-7836@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
 > Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009:
 > > > 3. Polling and loading of threads should started, asynchronously,
 > > > at the same time.
 > > 
 > > > Loading of threads should not hose my CPU.
 > > 
 > > Agreed. Please fix.
 > 
 > It appears that polling blocks on loading threads, so it doesn't help
 > to fix that until we fix the thread loading code.
 
 My "agreed, please fix" was in response to "loading of threads should
 not hose my CPU".
 
 Polling currently blocks on loading threads, but that's an explicit
 block. I forget why I did that now. You can unblock it and see if it
 makes life better.  (bin/sup circa line 205.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jun  9 13:48:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 09 Jun 2009 10:48:59 -0700
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244514081-sup-2943@javelin>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 	<1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin>
 Message-ID: <1244569567-sup-7515@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-06-08:
 > From: Edward Z. Yang <edwardzyang at thewritingpot.com>
 > Date: Mon, 8 Jun 2009 22:21:01 -0400
 > Subject: [PATCH] Remove message pre-loading; optimizes for the common case.
 
 The problem with this patch as is is that loading a large thread
 composed of entirely new messages still requires loading all the message
 bodies from the server, which can take a couple seconds, but now there's
 no indication of what's happening. So either the fancy background
 loading needs to happen, or somehow a message needs to be displayed when
 the bodies are being loaded.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Tue Jun  9 20:55:45 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 09 Jun 2009 20:55:45 -0400
 Subject: [sup-talk] lockmanager
 Message-ID: <1244595206-sup-6689@ntdws12.chass.utoronto.ca>
 
 
 Hi William,
 
 I've attached the base LockManager class that I'm envisioning for
 sup.  It's still rough, but the basic functionality is in place.  I
 think it should stand up to the potential contention between
 PollManager and SentManager.  If it looks reasonable, I'll flesh it
 out with some timeouts and exception handling.
 
 Let me know.
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: lock.rb
 Type: application/octet-stream
 Size: 3575 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090609/e56ad52c/attachment.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090609/e56ad52c/attachment.bin>
 
 From ezyang@MIT.EDU  Wed Jun 10 01:44:54 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 10 Jun 2009 01:44:54 -0400
 Subject: [sup-talk] [PATCH] before-search hook
 Message-ID: <1244612627-sup-982@javelin>
 
 >From a5c72844e8195df7a8eabd5ea592507599de72cb Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <edwardzyang at thewritingpot.com>
 Date: Wed, 10 Jun 2009 01:42:50 -0400
 Subject: [PATCH] Add before-search hook, for shortcuts for custom search queries.
  Signed-off-by: Edward Z. Yang <edwardzyang at thewritingpot.com>
 
 ---
  lib/sup/hook.rb  |    4 ++++
  lib/sup/index.rb |   12 +++++++++++-
  2 files changed, 15 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
 index 0a0a2f6..d446aa3 100644
 --- a/lib/sup/hook.rb
 +++ b/lib/sup/hook.rb
 @@ -19,6 +19,10 @@ class HookManager
  
      attr_writer :__locals
  
 +    ## an annoying gotcha here is that if you try something
 +    ## like var = var.foo(), var will magically get allocated
 +    ## to Nil and method_missing will never get called.  Stick
 +    ## to mutation, kiddos!
      def method_missing m, *a
        case @__locals[m]
        when Proc
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index e403570..19556f0 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -25,6 +25,13 @@ class Index
  
    include Singleton
  
 +  HookManager.register "before-search", <<EOS
 +Executes before a string search is applied to the index.
 +Variables:
 +  subs: The string being searched, use gsub! to change the
 +  search (you must use mutation!)
 +EOS
 +
    ## these two accessors should ONLY be used by single-threaded programs.
    ## otherwise you will have a naughty ferret on your hands.
    attr_reader :index
 @@ -508,7 +515,10 @@ protected
    def parse_user_query_string s
      extraopts = {}
  
 -    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 +    subs = String.new s
 +    HookManager.run("before-search", :subs => subs)
 +
 +    subs = subs.gsub(/\b(to|from):(\S+)\b/) do
        field, name = $1, $2
        if(p = ContactManager.contact_for(name))
          [field, p.email]
 -- 
 1.6.0.4
 
 From joe@talkhouse.com  Wed Jun 10 13:21:58 2009
 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=)
 Date: Wed, 10 Jun 2009 13:21:58 -0400
 Subject: [sup-talk] IMAP alternative for Sup?
 Message-ID: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local>
 
 I am using sup with IMAP.  I connect via multiple accounts using multiple
 machines.  This is not surprisingly very slow.  Is there an IMAP alternative
 that caches all messages locally that is not too complicated to setup with Sup? 
 
 Thanks,
 Joe
 
 From ezyang@MIT.EDU  Wed Jun 10 13:25:08 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 10 Jun 2009 13:25:08 -0400
 Subject: [sup-talk] IMAP alternative for Sup?
 In-Reply-To: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local>
 References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local>
 Message-ID: <1244654688-sup-4183@javelin>
 
 Excerpts from Joe W?lfel's message of Wed Jun 10 13:21:58 -0400 2009:
 > I am using sup with IMAP.  I connect via multiple accounts using multiple
 > machines.  This is not surprisingly very slow.  Is there an IMAP alternative
 > that caches all messages locally that is not too complicated to setup with Sup? 
 
 The solution commonly recommended is OfflineImap. I have not tried this myself.
 
 Cheers,
 Edward
 
 From joe@talkhouse.com  Wed Jun 10 10:42:34 2009
 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=)
 Date: Wed, 10 Jun 2009 10:42:34 -0400
 Subject: [sup-talk] IMAP alternative works well with sup?
 Message-ID: <1244644197-sup-9224@joe-wolfels-power-mac-g5.local>
 
 I've been using sup with IMAP and retrieving messages from 3rd party providers
 is not surprisingly slow.  Is there a good alternative that will cache messages
 locally that isn't complicated to setup with sup?  I use multiple machines with
 multiple accounts. 
 
 Thanks,
 Joe
 
 From bachjh@googlemail.com  Wed Jun 10 13:50:49 2009
 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=)
 Date: Wed, 10 Jun 2009 19:50:49 +0200
 Subject: [sup-talk] sup and ncursesw
 Message-ID: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
 
 Hi all,
 
 I recently installed sup 0.8 and find I am having problems with umlauts and
 accented characters. There is a patch for the ncurses-0.9.1 gem on the sup
 wiki ("utf8-issues") which allows the characters to be displayed correctly,
 but after applying the patch I can't enter proper text. Hitting 'c' for
 compose works, but entering '123' for subject ends in a subject line such
 as:
 
 Subject: P<85>??P<85>???C"      ?C"
 
 (it's a different set of confused characters each time)
 Similar when searching for messages using '\' or 'L'.
 
 I am on ubuntu 9.04 with libncursesw5{,-dev} version 5.7+20090207, sup 0.8.
 Any hints?
 
 cheers,
 - J?rg-Hendrik
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090610/aa0a2b51/attachment.html>
 
 From ezyang@MIT.EDU  Wed Jun 10 17:51:01 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 10 Jun 2009 17:51:01 -0400
 Subject: [sup-talk] [PATCH] before-search hook
 In-Reply-To: <1244612627-sup-982@javelin>
 References: <1244612627-sup-982@javelin>
 Message-ID: <1244670591-sup-7078@javelin>
 
 For the curious, here is the hook that I'm using with this:
 
 subs.gsub!(/\bmy:unread\b/) do
     "is:unread !label:inbox"
 end
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Wed Jun 10 23:18:46 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 10 Jun 2009 23:18:46 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244569129-sup-4112@entry>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 	<1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin>
 	<1244514851-sup-1414@javelin> <1244569129-sup-4112@entry>
 Message-ID: <1244690240-sup-884@javelin>
 
 Excerpts from William Morgan's message of Tue Jun 09 13:40:38 -0400 2009:
 > Not entirely sure what you mean by "having all the threads present", but
 > opening a thread-view-mode buffer doesn't block on anything, at least
 > with that patch applied. Without the patch, it blocks on loading the
 > message body for every message in that particular thread from the
 > server.
 
 Yeah. I mean what I mean: it *shouldn't* block on anything, but as
 far as I can tell from manual testing, thread-view-mode doesn't open
 up until I'm done threading the index.  Maybe that's why.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Wed Jun 10 23:19:32 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 10 Jun 2009 23:19:32 -0400
 Subject: [sup-talk] Sup annoyances
 In-Reply-To: <1244569567-sup-7515@entry>
 References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry>
 	<1244502545-sup-9840@javelin> <1244503985-sup-8587@entry>
 	<1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin>
 	<1244569567-sup-7515@entry>
 Message-ID: <1244690337-sup-2840@javelin>
 
 Excerpts from William Morgan's message of Tue Jun 09 13:48:59 -0400 2009:
 > The problem with this patch as is is that loading a large thread
 > composed of entirely new messages still requires loading all the message
 > bodies from the server, which can take a couple seconds, but now there's
 > no indication of what's happening. So either the fancy background
 > loading needs to happen, or somehow a message needs to be displayed when
 > the bodies are being loaded.
 
 Understood. There's also another odd bug where the headers for the open
 messages "blow up" (get split into three lines each) which gets fixed
 when you collapse and the expand the headers again.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Wed Jun 10 23:38:12 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 10 Jun 2009 23:38:12 -0400
 Subject: [sup-talk] Attempt at reply-from hook
 In-Reply-To: <1244565962-sup-4211@entry>
 References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball>
 	<1243997614-sup-7485@javelin>
 	<1244029436-sup-6141@ntdws12.chass.utoronto.ca>
 	<1244179379-sup-6675@javelin> <1244208597-sup-4979@entry>
 	<1244246896-sup-4529@javelin> <1244496654-sup-5759@entry>
 	<1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet>
 	<1244506097-sup-8895@javelin> <1244518550-sup-6361@cabinet>
 	<1244565962-sup-4211@entry>
 Message-ID: <1244691413-sup-727@javelin>
 
 Excerpts from William Morgan's message of Tue Jun 09 12:52:37 -0400 2009:
 > Edward, if you want to invest time on making this particular scheme easy
 > for users, I would be happy to include contributed hooks as part of the
 > Sup distribution, and you can supply one that reads a simple
 > configuration file and produces this behavior.
 
 The thing is that this needs no configuration: sources.yaml will
 tell us the correspondence between label and email.  If anything,
 I would bill this as an improvement to the "From" detection algorithm.
 
 Cheers,
 Edward
 
 From marcus-sup@bar-coded.net  Thu Jun 11 05:05:38 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 11 Jun 2009 10:05:38 +0100
 Subject: [sup-talk] Sup locking up
 Message-ID: <1244710855-sup-1368@tomsk>
 
 Hi -
 
 Something new has started happening in sup ? I think this is what
 Edward was talking about, but it appears to lock up every now and
 again in a way that it never used to.
 
 Once its locked up it doesnt come back and I dont seem to be able to
 ctrl-c/d/z out of it. Its only started in the last few days and I dont
 think its my IMAP server.
 
 Oddly its breaking my screen session as well which is odder still -
 the screen with sup running is locked completely (I can create new
 shells from screen and use them fine, its just the sup session within
 screen).
 
 Anyone else seeing this (running next branch)?
 
 Marcus
 
 From bwalton@artsci.utoronto.ca  Thu Jun 11 07:23:49 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 11 Jun 2009 07:23:49 -0400
 Subject: [sup-talk] Sup locking up
 In-Reply-To: <1244710855-sup-1368@tomsk>
 References: <1244710855-sup-1368@tomsk>
 Message-ID: <1244719333-sup-9770@ntdws12.chass.utoronto.ca>
 
 Excerpts from Marcus Williams's message of Thu Jun 11 05:05:38 -0400 2009:
 
 > Anyone else seeing this (running next branch)?
 
 No...and I'm running from the most recent next with a few local
 patches (message bouncing, currently).  I run in screen as well.
 
 Is there anything constant about when the lockup occurs?  Has anything
 else about your system/setup changed that could impact this?
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090611/8810e1f0/attachment.bin>
 
 From usul@aruba.it  Thu Jun 11 07:39:29 2009
 From: usul@aruba.it (Fabio Riga)
 Date: Thu, 11 Jun 2009 13:39:29 +0200
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1244717279-sup-5999@viajero>
 References: <1244717279-sup-5999@viajero>
 Message-ID: <1244719933-sup-4261@viajero>
 
 Excerpts from Fabio Riga's message of Thu Jun 11 12:48:59 +0200 2009:
 > a sup-sync, there are no Sent messages in index. Maybe it's a problem
 > with locale (it) as sup-sync -a sup://sent gives me a lot of lines like:
 > 
 > [Thu Jun 11 12:32:36 +0200 2009] found invalid date in potential mbox
 > split line, not splitting: "From usul at aruba.it Thu Jun 11 11:45:37 +0200
 > 2009\n"
 > Scanned 14, added 0, updated 14 messages from sup://sent.
 > 
 
 Hello again,
 
 I translated with a script names of days and months in ~/.sup/sent.mbox,
 then made a sup-sync -a sup://sent.mbox and run
   $ LANG=C sup
 
 All is fine, I just need to remember to launch sup this way. Maybe it
 needs some work on localization?
 
 Cheers,
 Fabio
 -- 
 Fabio Riga
 
 348 4458014 - fabio at comunicattiva.it
 
 ComunicAttiva S.a.s. di Silvana D'Agata & C.
 via Campestre,189 - Sesto San Giovanni (MI) - Italia
 tel. 02 97373202 - fax 02 97373474
 
 From garoth@gmail.com  Thu Jun 11 09:17:12 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Thu, 11 Jun 2009 09:17:12 -0400
 Subject: [sup-talk] [BUG?] label-list-mode doesn't update
 Message-ID: <80055d7c0906110617j2b9a33cene229c1dd28170003@mail.gmail.com>
 
 This is forwarded from the middle of another thread. I figured it got lost.
 
 On Tue, Jun 9, 2009 at 9:33 AM, Andrei Thorp<garoth at gmail.com> wrote:
 > Yeah, I guess that makes sense. It is a rather nice interface
 > actually, I didn't really think about it for some reason.
 
 I just actually ran a quick test (with 0.8) and it looks like the
 label-list-mode fails to update automatically D:
 
 What I did was put on the label-list-mode, manually send myself an
 e-mail, re-run fetchmail to grab it (I get a notification via procmail
 saying it came in). Then I remember that sup polls at intervals, so I
 wait.
 
 Eventually, the status bar at the bottom says that there is a new
 message in the inbox, but the Inbox label does not get updated in my
 view. It still says 0/0.
 
 I press x to go back to the inbox screen, it has the mail. I go back
 to label-list-mode, and now it registers it.
 
 So I guess I'd call that a bug actually, and it's unlikely that people
 operate out of this mode habitually or else this would have probably
 been found.
 
 (Unless it already has?)
 
 Cheers,
 
 -AT
 
 From marcus-sup@bar-coded.net  Thu Jun 11 10:23:28 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 11 Jun 2009 15:23:28 +0100
 Subject: [sup-talk] Sup locking up
 In-Reply-To: <1244719333-sup-9770@ntdws12.chass.utoronto.ca>
 References: <1244710855-sup-1368@tomsk>
 	<1244719333-sup-9770@ntdws12.chass.utoronto.ca>
 Message-ID: <1244730053-sup-6905@tomsk>
 
 On 11.6.2009, Ben Walton wrote:
 > No...and I'm running from the most recent next with a few local
 > patches (message bouncing, currently).  I run in screen as well.
 
 Mmmmm. Strange.
 
 > Is there anything constant about when the lockup occurs?  Has anything
 > else about your system/setup changed that could impact this?
 
 I _think_ it occurs during a poll for new messages. Its difficult to
 tell though because like I say that "window" in screen gets completely
 blocked, only killing sup will get out of it (kill -9 rather than a
 ctrl-c/z/d). Its very odd.
 
 Nothing has changed on my box bar sup in recent weeks.
 
 Marcus
 
 From bwalton@artsci.utoronto.ca  Thu Jun 11 11:46:19 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 11 Jun 2009 11:46:19 -0400
 Subject: [sup-talk] Sup locking up
 In-Reply-To: <1244730053-sup-6905@tomsk>
 References: <1244710855-sup-1368@tomsk>
 	<1244719333-sup-9770@ntdws12.chass.utoronto.ca>
 	<1244730053-sup-6905@tomsk>
 Message-ID: <1244735117-sup-6933@ntdws12.chass.utoronto.ca>
 
 Excerpts from Marcus Williams's message of Thu Jun 11 10:23:28 -0400 2009:
 > I _think_ it occurs during a poll for new messages. Its difficult to
 > tell though because like I say that "window" in screen gets completely
 > blocked, only killing sup will get out of it (kill -9 rather than a
 > ctrl-c/z/d). Its very odd.
 
 Can you strace/truss/whatever the ruby process running sup to see what
 it's doing?
 
 > Nothing has changed on my box bar sup in recent weeks.
 
 ...ok.  At least that rules out most external interference.
 
 Thanks
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090611/7f2e26e6/attachment.bin>
 
 From garoth@gmail.com  Thu Jun 11 13:58:26 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Thu, 11 Jun 2009 13:58:26 -0400
 Subject: [sup-talk] Sup locking up
 In-Reply-To: <1244735117-sup-6933@ntdws12.chass.utoronto.ca>
 References: <1244710855-sup-1368@tomsk>
 	<1244719333-sup-9770@ntdws12.chass.utoronto.ca>
 	<1244730053-sup-6905@tomsk>
 	<1244735117-sup-6933@ntdws12.chass.utoronto.ca>
 Message-ID: <80055d7c0906111058q128b5eb7na8931a8b75b0d0bf@mail.gmail.com>
 
 Yeah...
 
 I have a theory. Have you learned some new stuff about screen lately?
 Screen has this binding that pretty much makes it freeze up. I guess
 I'm talking about http://savannah.gnu.org/bugs/?11610 which applies to
 screen 4.0.0, which is the one people have.
 
 Try maybe running sup out of screen for a while and see if it can happen then.
 
 Another test: if screen locks up but sup respects regular kill (not
 -9), sup's not locked up itself.
 
 -AT
 
 From marcus-sup@bar-coded.net  Thu Jun 11 15:09:19 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 11 Jun 2009 20:09:19 +0100
 Subject: [sup-talk] Sup locking up
 In-Reply-To: <80055d7c0906111058q128b5eb7na8931a8b75b0d0bf@mail.gmail.com>
 References: <1244710855-sup-1368@tomsk>
 	<1244719333-sup-9770@ntdws12.chass.utoronto.ca>
 	<1244730053-sup-6905@tomsk>
 	<1244735117-sup-6933@ntdws12.chass.utoronto.ca>
 	<80055d7c0906111058q128b5eb7na8931a8b75b0d0bf@mail.gmail.com>
 Message-ID: <1244747053-sup-4797@tomsk>
 
 On 11.6.2009, Andrei Thorp wrote:
 > I have a theory. Have you learned some new stuff about screen lately?
 > Screen has this binding that pretty much makes it freeze up. I guess
 > I'm talking about http://savannah.gnu.org/bugs/?11610 which applies to
 > screen 4.0.0, which is the one people have.
 
 I dont think debian has this problem, although I may have hit ctrl-a
 and then s by accident (I actually tried ctrl-q thinking that I had
 hit ctrl-s by accident when it hung but nothing happened... forgetting
 that I was in screen so would need to prepend ctrl-a). Its a bit wierd
 that its happened to me recently and not before though if this is what
 it was - I leave sup running in screen as it makes imap bearable and
 havnt run into this problem until recently when its happened a couple
 of times. I'll keep an eye on it and see if it happens again.
 
 Marcus
 
 From bwalton@artsci.utoronto.ca  Thu Jun 11 19:50:33 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 11 Jun 2009 19:50:33 -0400
 Subject: [sup-talk] (no subject)
 In-Reply-To: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 Message-ID: <1244764138-sup-2909@ntdws12.chass.utoronto.ca>
 
 Excerpts from Ben Walton's message of Sun Jun 07 20:02:25 -0400 2009:
 
 Hi William,
 
 > Here's a stab at implementing a message bouncing functionality worthy
 > of being included on mainline.
 
 Is there something you don't like about these patches or have you just
 been too busy to look at them?  I could collapse them into a single
 patch, thus removing any trace of using $config instead of a Hook, to
 keep the history cleaner if you'd prefer.
 
 If there is something else you'd like to see changed before picking it
 up, let me know.
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 
 From usul@aruba.it  Thu Jun 11 06:48:59 2009
 From: usul@aruba.it (Fabio Riga)
 Date: Thu, 11 Jun 2009 12:48:59 +0200
 Subject: [sup-talk] Crash after sending a message
 Message-ID: <1244717279-sup-5999@viajero>
 
 Hi all,
 
 First of all, Sup is a great peace of software because it's a superior and
 simplified  Mutt, it's fast, it isn't web-based (I hate web-based
 client...) and... Well, great job!
 
 I started using 0.7, with no problems at all, excepting those crappy
 character on screen... Since upgrading to 0.8 my screen looks very nice,
 but when I send a message, Sup crashes badly. It seems a problem
 with Ferret failing indexing my Sent box (attached exception-log). After
 a sup-sync, there are no Sent messages in index. Maybe it's a problem
 with locale (it) as sup-sync -a sup://sent gives me a lot of lines like:
 
 [Thu Jun 11 12:32:36 +0200 2009] found invalid date in potential mbox
 split line, not splitting: "From usul at aruba.it gio giu 11 11:45:37 +0200
 2009\n"
 Scanned 14, added 0, updated 14 messages from sup://sent.
 
 _My sent messages are much more then 14!_
 
 Anyway, messages are sent before the crash.. like this one!
 
 Ideas?
 
 Thanks,
 Fabio
 -- 
 Fabio Riga
 
 348 4458014 - fabio at comunicattiva.it
 
 ComunicAttiva S.a.s. di Silvana D'Agata & C.
 via Campestre,189 - Sesto San Giovanni (MI) - Italia
 tel. 02 97373202 - fax 02 97373474
 -------------- next part --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090611/fc505855/attachment.txt>
 
 From wmorgan-sup@masanjin.net  Thu Jun 11 23:44:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 11 Jun 2009 20:44:41 -0700
 Subject: [sup-talk] (no subject)
 In-Reply-To: <1244764138-sup-2909@ntdws12.chass.utoronto.ca>
 References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244764138-sup-2909@ntdws12.chass.utoronto.ca>
 Message-ID: <1244778083-sup-4566@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-11:
 > Is there something you don't like about these patches or have you just
 > been too busy to look at them?
 
 Just been busy. Sorry! My Sup time tends to be very bursty. I realize
 that's not great for contributors. Please have patience with your poor
 maintainer and feel free to keep bugging me.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Fri Jun 12 00:38:42 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 12 Jun 2009 00:38:42 -0400
 Subject: [sup-talk] Sup locking up
 In-Reply-To: <1244735117-sup-6933@ntdws12.chass.utoronto.ca>
 References: <1244710855-sup-1368@tomsk>
 	<1244719333-sup-9770@ntdws12.chass.utoronto.ca>
 	<1244730053-sup-6905@tomsk>
 	<1244735117-sup-6933@ntdws12.chass.utoronto.ca>
 Message-ID: <1244781466-sup-4096@javelin>
 
 Excerpts from Ben Walton's message of Thu Jun 11 11:46:19 -0400 2009:
 > Can you strace/truss/whatever the ruby process running sup to see what
 > it's doing?
 
 Seconded. You can attach strace to Sup while it's running, and it
 will give you a good fingerprint for what the process is doing when
 it locks up.
 
 Cheers,
 Edward
 
 From bwalton@artsci.utoronto.ca  Fri Jun 12 09:15:05 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 12 Jun 2009 09:15:05 -0400
 Subject: [sup-talk] (no subject)
 In-Reply-To: <1244778083-sup-4566@entry>
 References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 	<1244764138-sup-2909@ntdws12.chass.utoronto.ca>
 	<1244778083-sup-4566@entry>
 Message-ID: <1244812410-sup-2627@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Thu Jun 11 23:44:41 -0400 2009:
 > Reformatted excerpts from Ben Walton's message of 2009-06-11:
 > > Is there something you don't like about these patches or have you just
 > > been too busy to look at them?
 > 
 > Just been busy. Sorry! My Sup time tends to be very bursty. I realize
 > that's not great for contributors. Please have patience with your poor
 > maintainer and feel free to keep bugging me.
 
 No problem.  You're just very quick to respond typically, so I wanted
 to make sure that it hadn't fallen through the cracks...
 
 Thanks
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090612/0803c72a/attachment.bin>
 
 From joe@talkhouse.com  Fri Jun 12 09:21:11 2009
 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=)
 Date: Fri, 12 Jun 2009 09:21:11 -0400
 Subject: [sup-talk] IMAP alternative for Sup?
 In-Reply-To: <1244654688-sup-4183@javelin>
 References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local>
 	<1244654688-sup-4183@javelin>
 Message-ID: <1244812462-sup-9446@joe-wolfels-power-mac-g5.local>
 
 Excerpts from Edward Z. Yang's message of Wed Jun 10 13:25:08 -0400 2009:
 > Excerpts from Joe W?lfel's message of Wed Jun 10 13:21:58 -0400 2009:
 > > I am using sup with IMAP.  I connect via multiple accounts using multiple
 > > machines.  This is not surprisingly very slow.  Is there an IMAP alternative
 > > that caches all messages locally that is not too complicated to setup with Sup? 
 > 
 > The solution commonly recommended is OfflineImap. I have not tried this myself.
 > 
 > Cheers,
 > Edward
 
 That did the trick.  Now everything is instantaneous.  
 
 Also, I noticed that Sup's polling mechanism no longer locks up.   With IMAP I
 used to have to restart Sup on occasion.  Now that doesn't seem to happen.  I'm
 not sure if that's relevant to the that other sup-talk thread on locking but
 maybe it's helpful info . 
 
 Thanks,
 Joe
 
 From ezyang@MIT.EDU  Fri Jun 12 10:14:26 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 12 Jun 2009 10:14:26 -0400
 Subject: [sup-talk] IMAP alternative for Sup?
 In-Reply-To: <1244812462-sup-9446@joe-wolfels-power-mac-g5.local>
 References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local>
 	<1244654688-sup-4183@javelin>
 	<1244812462-sup-9446@joe-wolfels-power-mac-g5.local>
 Message-ID: <1244815945-sup-5020@javelin>
 
 Excerpts from Joe W?lfel's message of Fri Jun 12 09:21:11 -0400 2009:
 > Also, I noticed that Sup's polling mechanism no longer locks up.   With IMAP I
 > used to have to restart Sup on occasion.  Now that doesn't seem to happen.  I'm
 > not sure if that's relevant to the that other sup-talk thread on locking but
 > maybe it's helpful info . 
 
 This is probably because OfflineIMAP polls more frequently.  I've had good
 results getting rid of the lock up by decreasing Sup's polling time (unfortunately
 it's hard-coded in Sup).
 
 Cheers,
 Edward
 
 From bwalton@artsci.utoronto.ca  Fri Jun 12 10:34:48 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 12 Jun 2009 10:34:48 -0400
 Subject: [sup-talk] IMAP alternative for Sup?
 In-Reply-To: <1244815945-sup-5020@javelin>
 References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local>
 	<1244654688-sup-4183@javelin>
 	<1244812462-sup-9446@joe-wolfels-power-mac-g5.local>
 	<1244815945-sup-5020@javelin>
 Message-ID: <1244817210-sup-9892@ntdws12.chass.utoronto.ca>
 
 Excerpts from Edward Z. Yang's message of Fri Jun 12 10:14:26 -0400 2009:
 
 > This is probably because OfflineIMAP polls more frequently.  I've
 > had good results getting rid of the lock up by decreasing Sup's
 > polling time (unfortunately it's hard-coded in Sup).
 
 This is one thing that would be a good candiate for a $config setting,
 or maybe even a per-source value if you're in the unfortunate position
 of polling multiple imap servers.  Fortunately, I don't have to deal
 with imap myself.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090612/1b0a66e2/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 14:23:05 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 11:23:05 -0700
 Subject: [sup-talk] (no subject)
 In-Reply-To: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca>
 Message-ID: <1244830970-sup-1069@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-07:
 > Here's a stab at implementing a message bouncing functionality worthy
 > of being included on mainline.
 
 Looks good. I've merged this into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 14:56:09 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 11:56:09 -0700
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 Message-ID: <1244832722-sup-9953@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-08:
 > So something similar to the folder view hack/patch for mutt?  That
 > doesn't exist in sup.  The closest you get is having the 'All Labels'
 > buffer open.  You can jump to a view of all messages with that label
 > by hitting enter on the selected label.
 
 FWIW, there is some preliminary support for having multiple Sup buffers
 sharing the screen. (There's a notion of focus, and x/y/w/h values for
 each buffer.) If someone is very excited about having this behavior from
 mutt, that's how I'd try and implement it.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From garoth@gmail.com  Fri Jun 12 15:03:38 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 12 Jun 2009 15:03:38 -0400
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244832722-sup-9953@entry>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<1244832722-sup-9953@entry>
 Message-ID: <80055d7c0906121203g53b1e428q8abd035548331e49@mail.gmail.com>
 
 On Fri, Jun 12, 2009 at 2:56 PM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 > Reformatted excerpts from Ben Walton's message of 2009-06-08:
 >> So something similar to the folder view hack/patch for mutt? ?That
 >> doesn't exist in sup. ?The closest you get is having the 'All Labels'
 >> buffer open. ?You can jump to a view of all messages with that label
 >> by hitting enter on the selected label.
 >
 > FWIW, there is some preliminary support for having multiple Sup buffers
 > sharing the screen. (There's a notion of focus, and x/y/w/h values for
 > each buffer.) If someone is very excited about having this behavior from
 > mutt, that's how I'd try and implement it.
 
 That is indeed very exciting. Mutt's sidebar is actually very poor and
 limiting. If this could
 handle it with arbitrary splitting, this would be amazingly amazing.
 
 Thanks :)
 
 -AT
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 15:10:27 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 12:10:27 -0700
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244556424-sup-1426@tomsk>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 	<1244556424-sup-1426@tomsk>
 Message-ID: <1244833003-sup-9212@entry>
 
 Reformatted excerpts from Marcus Williams's message of 2009-06-09:
 > William - if you want to add this to sup/bin feel free. Its basically
 > the regen_text method lifted and edited slightly from the
 > label-list-mode
 
 Nice idea. I'd add such a thing, but I think you can make it
 significantly simpler. (As you point out, locking the index is not
 necessary.)
 
 Something like:
 
   #!/usr/bin/env ruby
 
   require 'sup'
   i = Redwood::Index.new; i.load
   l = Redwood::LabelManager.new File.join(ENV["HOME"], ".sup", "labels.txt")
 
   l.all_labels.
     map { |label| [label, l.string_for(label)] }.
     sort_by { |label, name| name }.
     each do |label, name|
       total = i.num_results_for :label => label
       unread = (label == :unread)? total : i.num_results_for(:labels => [label, :unread])
       printf "%20s: %6d messages, %6d unread\n", name, total, unread
     end
 
   puts "yay"
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 15:14:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 12:14:31 -0700
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <80055d7c0906090642h421964f2t41d52290042469bc@mail.gmail.com>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 	<80055d7c0906090642h421964f2t41d52290042469bc@mail.gmail.com>
 Message-ID: <1244833856-sup-5874@entry>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-06-09:
 > What I did was put on the label-list-mode, manually send myself an
 > e-mail, re-run fetchmail to grab it (I get a notification via procmail
 > saying it came in). Then I remember that sup polls at intervals, so I
 > wait.
 
 You can press "P" to force a poll.
 
 > Eventually, the status bar at the bottom says that there is a new
 > message in the inbox, but the Inbox label does not get updated in my
 > view. It still says 0/0.
 
 Yep, currently label-list-mode only updates when one of three things
 happens:
  - it gets created
  - it gets focus (you switch to it from another buffer)
  - you press '@'
 
 Also, it only reflects the index state, so if you read a new message
 something and don't press "$", it won't reflect that change.
 
 I'd happily accept patches for any of those issues. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 15:18:11 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 12:18:11 -0700
 Subject: [sup-talk] display_length issue with special-characters on
 	non-UTF8 terminal
 In-Reply-To: <1244536704-sup-7027@valgus>
 References: <1244536704-sup-7027@valgus>
 Message-ID: <1244834230-sup-1200@entry>
 
 Reformatted excerpts from Tarko Tikan's message of 2009-06-09:
 > When String.display_length was introduced in recent update, it broke
 > the length for non-UTF8 strings that contain the special characters.
 > Wrong length results corrupted display (line ends chopped off).
 
 That's a good point. I got a little utf8-centric with those changes.
 (I'm assuming that your terminal encoding is not UTF-8.)
 
 Does this patch fix the issue? If so, I will release an 0.8.1.
 
 --- cut here ---
 diff --git a/lib/sup.rb b/lib/sup.rb
 index 4f59eaa..20835ae 100644
 --- a/lib/sup.rb
 +++ b/lib/sup.rb
 @@ -244,7 +244,7 @@ end
      Redwood::log "using character set encoding #{$encoding.inspect}"
    else
      Redwood::log "warning: can't find character set by using locale, defaulting
 -    $encoding = "utf-8"
 +    $encoding = "UTF-8"
    end
  
  ## now everything else (which can feel free to call Redwood::log at load time)
 diff --git a/lib/sup/util.rb b/lib/sup/util.rb
 index 8a3004f..d5310bc 100644
 --- a/lib/sup/util.rb
 +++ b/lib/sup/util.rb
 @@ -172,7 +172,13 @@ class Object
  end
  
  class String
 -  def display_length; scan(/./u).size end
 +  def display_length
 +    if $encoding == "UTF-8"
 +      scan(/./u).size
 +    else
 +      size
 +    end
 +  end
  
    def camel_to_hyphy
      self.gsub(/([a-z])([A-Z0-9])/, '\1-\2').downcase
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 15:29:46 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 12:29:46 -0700
 Subject: [sup-talk] [PATCH] Use terminal width instead of hardcoded 80
 	as the wrap length.
 In-Reply-To: <1244392518-sup-9746@cabinet>
 References: <1243102667-sup-6007@r50p>
 	<4c4248150905231318kab3819dw68e3a3a614241c0d@mail.gmail.com>
 	<1243123134-sup-8032@ntdws12.chass.utoronto.ca>
 	<1243439667-sup-3947@entry> <1244392518-sup-9746@cabinet>
 Message-ID: <1244834906-sup-7818@entry>
 
 Reformatted excerpts from Marc Hartstein's message of 2009-06-07:
 > Do we currently honor format=flowed email?
 
 No.
 
 > If we don't, it would be desirable to take this into account when
 > designing the display wrapping options, and it seems like it would be
 > worth implementing down the road.
 
 Yes, I suppose so.
 
 > It might be useful to be able to specify the wrap margin to something
 > other than 80.  I don't know if anybody would actually use this,
 > though.
 
 I will leave that kind of thing for the Sup GUI clients. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Fri Jun 12 15:35:52 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 12 Jun 2009 12:35:52 -0700
 Subject: [sup-talk] [PATCH] fixes for ruby1.9
 Message-ID: <1244835352-10370-1-git-send-email-rlane@club.cc.cmu.edu>
 
 Change colons in case statements to 'then'
 Fix a block that didn't take enough arguments
 Rename variables to avoid shadowing warnings
 Use String.ord (and define it for 1.8)
 Use DL::Importer on 1.9
 Make require 'fastthread' optional
 Copy in RE_UTF8
 ---
  bin/sup                            |    5 +--
  lib/sup.rb                         |    4 +++
  lib/sup/index.rb                   |    1 -
  lib/sup/keymap.rb                  |   52 ++++++++++++++++++------------------
  lib/sup/message-chunks.rb          |    4 +-
  lib/sup/message.rb                 |    4 +-
  lib/sup/modes/edit-message-mode.rb |    5 +++-
  lib/sup/util.rb                    |   46 ++++++++++++++++++--------------
  8 files changed, 66 insertions(+), 55 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 9abe1b5..302ad7c 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -5,7 +5,6 @@ require 'ncurses'
  require 'curses'
  require 'fileutils'
  require 'trollop'
 -require 'fastthread'
  require "sup"
  
  BIN_VERSION = "git"
 @@ -89,7 +88,7 @@ end
  ## BSD users: if libc.so.6 is not found, try installing compat6x.
  require 'dl/import'
  module LibC
 -  extend DL::Importable
 +  extend DL.const_defined?(:Importer) ? DL::Importer : DL::Importable
    setlocale_lib = case Config::CONFIG['arch']
      when /darwin/; "libc.dylib"
      when /cygwin/; "cygwin1.dll"
 @@ -202,7 +201,7 @@ begin
      end
    end unless $opts[:no_initial_poll]
    
 -  imode.load_threads :num => ibuf.content_height, :when_done => lambda { reporting_thread("poll after loading inbox") { sleep 1; PollManager.poll } unless $opts[:no_threads] || $opts[:no_initial_poll] }
 +  imode.load_threads :num => ibuf.content_height, :when_done => lambda { |num| reporting_thread("poll after loading inbox") { sleep 1; PollManager.poll } unless $opts[:no_threads] || $opts[:no_initial_poll] }
  
    if $opts[:compose]
      ComposeMode.spawn_nicely :to_default => $opts[:compose]
 diff --git a/lib/sup.rb b/lib/sup.rb
 index 4f59eaa..dea9355 100644
 --- a/lib/sup.rb
 +++ b/lib/sup.rb
 @@ -5,6 +5,10 @@ require 'thread'
  require 'fileutils'
  require 'gettext'
  require 'curses'
 +begin
 +  require 'fastthread'
 +rescue LoadError
 +end
  
  class Object
    ## this is for debugging purposes because i keep calling #id on the
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index e403570..ca01ee7 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -2,7 +2,6 @@
  
  require 'fileutils'
  require 'ferret'
 -require 'fastthread'
  
  begin
    require 'chronic'
 diff --git a/lib/sup/keymap.rb b/lib/sup/keymap.rb
 index 76c7139..cb039e4 100644
 --- a/lib/sup/keymap.rb
 +++ b/lib/sup/keymap.rb
 @@ -9,22 +9,22 @@ class Keymap
  
    def self.keysym_to_keycode k
      case k
 -    when :down: Curses::KEY_DOWN
 -    when :up: Curses::KEY_UP
 -    when :left: Curses::KEY_LEFT
 -    when :right: Curses::KEY_RIGHT
 -    when :page_down: Curses::KEY_NPAGE
 -    when :page_up: Curses::KEY_PPAGE
 -    when :backspace: Curses::KEY_BACKSPACE
 -    when :home: Curses::KEY_HOME
 -    when :end: Curses::KEY_END
 -    when :ctrl_l: "\f"[0]
 -    when :ctrl_g: "\a"[0]
 -    when :tab: "\t"[0]
 -    when :enter, :return: 10 #Curses::KEY_ENTER
 +    when :down then Curses::KEY_DOWN
 +    when :up then Curses::KEY_UP
 +    when :left then Curses::KEY_LEFT
 +    when :right then Curses::KEY_RIGHT
 +    when :page_down then Curses::KEY_NPAGE
 +    when :page_up then Curses::KEY_PPAGE
 +    when :backspace then Curses::KEY_BACKSPACE
 +    when :home then Curses::KEY_HOME
 +    when :end then Curses::KEY_END
 +    when :ctrl_l then "\f".ord
 +    when :ctrl_g then "\a".ord
 +    when :tab then "\t".ord
 +    when :enter, :return then 10 #Curses::KEY_ENTER
      else
        if k.is_a?(String) && k.length == 1
 -        k[0]
 +        k.ord
        else
          raise ArgumentError, "unknown key name '#{k}'"
        end
 @@ -33,18 +33,18 @@ class Keymap
  
    def self.keysym_to_string k
      case k
 -    when :down: "<down arrow>"
 -    when :up: "<up arrow>"
 -    when :left: "<left arrow>"
 -    when :right: "<right arrow>"
 -    when :page_down: "<page down>"
 -    when :page_up: "<page up>"
 -    when :backspace: "<backspace>"
 -    when :home: "<home>"
 -    when :end: "<end>"
 -    when :enter, :return: "<enter>"
 -    when :tab: "tab"
 -    when " ": "<space>"
 +    when :down then "<down arrow>"
 +    when :up then "<up arrow>"
 +    when :left then "<left arrow>"
 +    when :right then "<right arrow>"
 +    when :page_down then "<page down>"
 +    when :page_up then "<page up>"
 +    when :backspace then "<backspace>"
 +    when :home then "<home>"
 +    when :end then "<end>"
 +    when :enter, :return then "<enter>"
 +    when :tab then "tab"
 +    when " " then "<space>"
      else
        Curses::keyname(keysym_to_keycode(k))
      end
 diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
 index ba07d35..a9f1a77 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -252,8 +252,8 @@ EOS
  
      def patina_color
        case status
 -      when :valid: :cryptosig_valid_color
 -      when :invalid: :cryptosig_invalid_color
 +      when :valid then :cryptosig_valid_color
 +      when :invalid then :cryptosig_invalid_color
        else :cryptosig_unknown_color
        end
      end
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 805c2f7..8525fdf 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -414,8 +414,8 @@ private
          elsif m.header["Content-Type"] && m.header["Content-Type"] !~ /^text\/plain/
            extension =
              case m.header["Content-Type"]
 -            when /text\/html/: "html"
 -            when /image\/(.*)/: $1
 +            when /text\/html/ then "html"
 +            when /image\/(.*)/ then $1
              end
  
            ["sup-attachment-#{Time.now.to_i}-#{rand 10000}", extension].join(".")
 diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
 index d7bd41c..74bdfb7 100644
 --- a/lib/sup/modes/edit-message-mode.rb
 +++ b/lib/sup/modes/edit-message-mode.rb
 @@ -2,7 +2,10 @@ require 'tempfile'
  require 'socket' # just for gethostname!
  require 'pathname'
  require 'rmail'
 -require 'jcode' # for RE_UTF8
 +
 +# from jcode.rb, not included in ruby 1.9
 +PATTERN_UTF8 = '[\xc0-\xdf][\x80-\xbf]|[\xe0-\xef][\x80-\xbf][\x80-\xbf]'
 +RE_UTF8 = Regexp.new(PATTERN_UTF8, 0, 'n')
  
  module Redwood
  
 diff --git a/lib/sup/util.rb b/lib/sup/util.rb
 index 8a3004f..1513c42 100644
 --- a/lib/sup/util.rb
 +++ b/lib/sup/util.rb
 @@ -133,8 +133,8 @@ class Object
    ## clone of java-style whole-method synchronization
    ## assumes a @mutex variable
    ## TODO: clean up, try harder to avoid namespace collisions
 -  def synchronized *meth
 -    meth.each do
 +  def synchronized *methods
 +    methods.each do |meth|
        class_eval <<-EOF
          alias unsynchronized_#{meth} #{meth}
          def #{meth}(*a, &b)
 @@ -144,8 +144,8 @@ class Object
      end
    end
  
 -  def ignore_concurrent_calls *meth
 -    meth.each do
 +  def ignore_concurrent_calls *methods
 +    methods.each do |meth|
        mutex = "@__concurrent_protector_#{meth}"
        flag = "@__concurrent_flag_#{meth}"
        oldmeth = "__unprotected_#{meth}"
 @@ -205,7 +205,7 @@ class String
      region_start = 0
      while pos <= length
        newpos = case state
 -        when :escaped_instring, :escaped_outstring: pos
 +        when :escaped_instring, :escaped_outstring then pos
          else index(/[,"\\]/, pos)
        end 
        
 @@ -219,26 +219,26 @@ class String
        case char
        when ?"
          state = case state
 -          when :outstring: :instring
 -          when :instring: :outstring
 -          when :escaped_instring: :instring
 -          when :escaped_outstring: :outstring
 +          when :outstring then :instring
 +          when :instring then :outstring
 +          when :escaped_instring then :instring
 +          when :escaped_outstring then :outstring
          end
        when ?,, nil
          state = case state
 -          when :outstring, :escaped_outstring:
 +          when :outstring, :escaped_outstring then
              ret << self[region_start ... newpos].gsub(/^\s+|\s+$/, "")
              region_start = newpos + 1
              :outstring
 -          when :instring: :instring
 -          when :escaped_instring: :instring
 +          when :instring then :instring
 +          when :escaped_instring then :instring
          end
        when ?\\
          state = case state
 -          when :instring: :escaped_instring
 -          when :outstring: :escaped_outstring
 -          when :escaped_instring: :instring
 -          when :escaped_outstring: :outstring
 +          when :instring then :escaped_instring
 +          when :outstring then :escaped_outstring
 +          when :escaped_instring then :instring
 +          when :escaped_outstring then :outstring
          end
        end
        pos = newpos + 1
 @@ -274,6 +274,12 @@ class String
      gsub(/\t/, "    ").gsub(/\r/, "")
    end
  
 +  if not defined? ord
 +    def ord
 +      self[0]
 +    end
 +  end
 +
    ## takes a space-separated list of words, and returns an array of symbols.
    ## typically used in Sup for translating Ferret's representation of a list
    ## of labels (a string) to an array of label symbols.
 @@ -628,10 +634,10 @@ class Iconv
    def self.easy_decode target, charset, text
      return text if charset =~ /^(x-unknown|unknown[-_ ]?8bit|ascii[-_ ]?7[-_ ]?bit)$/i
      charset = case charset
 -      when /UTF[-_ ]?8/i: "utf-8"
 -      when /(iso[-_ ])?latin[-_ ]?1$/i: "ISO-8859-1"
 -      when /iso[-_ ]?8859[-_ ]?15/i: 'ISO-8859-15'
 -      when /unicode[-_ ]1[-_ ]1[-_ ]utf[-_]7/i: "utf-7"
 +      when /UTF[-_ ]?8/i then "utf-8"
 +      when /(iso[-_ ])?latin[-_ ]?1$/i then "ISO-8859-1"
 +      when /iso[-_ ]?8859[-_ ]?15/i then 'ISO-8859-15'
 +      when /unicode[-_ ]1[-_ ]1[-_ ]utf[-_]7/i then "utf-7"
        else charset
      end
  
 -- 
 1.6.0.4
 
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 15:54:26 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 12:54:26 -0700
 Subject: [sup-talk] sup -c while sup is running?
 In-Reply-To: <1244646784-sup-7039@cabinet>
 References: <1244646784-sup-7039@cabinet>
 Message-ID: <1244835514-sup-3886@entry>
 
 Reformatted excerpts from Marc Hartstein's message of 2009-06-10:
 > How difficult would it be to allow sup -c to be run while sup is
 > already running?  The goal would be to be able to use sup as a mailto:
 > handler effectively.
 
 Not that difficult. In general, N Sup processes should be able to run as
 long as N-1 of them are readonly wrt the index and sources file. (I
 think!) So sup -c could launch either with a readonly inbox buffer, or
 without one at all. (Which would be faster, if the intention is just to
 quit after sending.)
 
 However, to be safe, locking should be added to the sent.mbox to prevent
 multiple Sup processing from overwriting each other's sent messages. Ben
 Walton's lock manager I think will be perfect for this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 16:03:22 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 13:03:22 -0700
 Subject: [sup-talk] sup and ncursesw
 In-Reply-To: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
 References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
 Message-ID: <1244836517-sup-5520@entry>
 
 Hi J?rg-Hendrik,
 
 Reformatted excerpts from J?rg-Hendrik Bach's message of 2009-06-10:
 > I recently installed sup 0.8 and find I am having problems with
 > umlauts and accented characters. There is a patch for the
 > ncurses-0.9.1 gem on the sup wiki ("utf8-issues") which allows the
 > characters to be displayed correctly, but after applying the patch I
 > can't enter proper text.
 
 What is your environment's character set? (Should be the first line of
 output logged by Sup.) What is your terminal emulator? Do other widechar
 ncurses programs work? And what's the behavior without the patch to
 ncurses.so?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Fri Jun 12 16:18:10 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 12 Jun 2009 21:18:10 +0100
 Subject: [sup-talk] Gmail Labels Sidebar
 In-Reply-To: <1244833003-sup-9212@entry>
 References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com>
 	<1244509454-sup-1208@ntdws12.chass.utoronto.ca>
 	<1244513641-sup-360@javelin>
 	<1244514031-sup-2335@ntdws12.chass.utoronto.ca>
 	<80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com>
 	<1244556424-sup-1426@tomsk> <1244833003-sup-9212@entry>
 Message-ID: <1244837827-sup-6632@tomsk>
 
 On 12.6.2009, William Morgan wrote:
 > Nice idea. I'd add such a thing, but I think you can make it
 > significantly simpler. (As you point out, locking the index is not
 > necessary.)
 
 Simpler is good - it was a quick hack anyway :) You version works out
 of the box so it would be a nice addition to sup/bin
 
 Marcus
 
 From marcus-sup@bar-coded.net  Fri Jun 12 16:46:32 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 12 Jun 2009 21:46:32 +0100
 Subject: [sup-talk] [PATCH] Minimalist view
 Message-ID: <1244839497-sup-547@tomsk>
 
 Adds a keypress to toggle to a minimalist view in thread index mode.
 This removes the date, authors and number of threads from the view
 leaving more room for labels/snippets
 ---
  lib/sup/modes/thread-index-mode.rb |   34 +++++++++++++++++++++++++++-------
  1 files changed, 27 insertions(+), 7 deletions(-)
 
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index 0bd8110..5fa4f4c 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -45,6 +45,7 @@ EOS
      k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '='
      k.add :join_threads, "Force tagged threads to be joined into the same thread", '#'
      k.add :undo, "Undo the previous action", 'u'
 +    k.add :toggle_minimalist, "Toggle minimalist view", '~'
    end
  
    def initialize hidden_labels=[], load_thread_opts={}
 @@ -62,6 +63,8 @@ EOS
      @hidden_labels = hidden_labels + LabelManager::HIDDEN_RESERVED_LABELS
      @date_width = DATE_WIDTH
  
 +    @minimal = false
 +
      @interrupt_search = false
      
      initialize_threads # defines @ts and @ts_mutex
 @@ -261,6 +264,11 @@ EOS
      end
    end  
  
 +  def toggle_minimalist 
 +    @minimal = !@minimal
 +    regen_text
 +  end
 +
    def toggle_starred 
      t = cursor_thread or return
      undo = actually_toggle_starred t
 @@ -833,13 +841,25 @@ protected
  
      size_widget_text = sprintf "%#{ @size_widget_width}s", size_widget
  
 -    [ 
 -      [:tagged_color, @tags.tagged?(t) ? ">" : " "],
 -      [:none, sprintf("%#{@date_width}s", date)],
 -      (starred ? [:starred_color, "*"] : [:none, " "]),
 -    ] +
 -      from +
 -      [
 +
 +    if @minimal
 +      if size_widget!=""
 +        size_widget_text = "+" 
 +      else
 +        size_widget_text = " " 
 +      end
 +      line = []
 +    else
 +      line =  [ 
 +                [:tagged_color, @tags.tagged?(t) ? ">" : " "],
 +                [:none, sprintf("%#{@date_width}s", date)],
 +                (starred ? [:starred_color, "*"] : [:none, " "]),
 +              ] + from
 +    end
 +
 +
 +    line +
 +    [
        [subj_color, size_widget_text],
        [:to_me_color, t.labels.member?(:attachment) ? "@" : " "],
        [:to_me_color, dp ? ">" : (p ? '+' : " ")],
 -- 
 1.5.4.1
 
 From me@nicholasbs.net  Fri Jun 12 18:14:55 2009
 From: me@nicholasbs.net (Nicholas Bergson-Shilcock)
 Date: Fri, 12 Jun 2009 18:14:55 -0400
 Subject: [sup-talk] Transitioning to OfflineIMAP
 Message-ID: <1244844014-sup-6606@twoface>
 
 Hi,
 
 I've been using sup for the past year and love it. In an attempt to
 speed things up, I'm hoping to switch to using OfflineIMAP and a maildir
 source (I'm currently using straight IMAP). I've installed and
 configured OfflineIMAP and have downloaded all of my messages. 
 
 Before I go any further, I wanted to know if sup supported any sort of
 "graceful" account transitioning --  I'd ideally like to switch to
 my new maildir source without losing the index information I have for my
 IMAP source. The obvious way of switching over (removing my old source
 and adding the new one) would mean essentially starting over. Is this
 what I have to do or is there another way for me to switch?
 
 Thanks! (And thanks for making sup such a joy to use!)
 
 -Nick
 
 From wmorgan-sup@masanjin.net  Fri Jun 12 20:24:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 12 Jun 2009 17:24:44 -0700
 Subject: [sup-talk] Transitioning to OfflineIMAP
 In-Reply-To: <1244844014-sup-6606@twoface>
 References: <1244844014-sup-6606@twoface>
 Message-ID: <1244852427-sup-5831@entry>
 
 Reformatted excerpts from Nicholas Bergson-Shilcock's message of 2009-06-12:
 > Before I go any further, I wanted to know if sup supported any sort of
 > "graceful" account transitioning --  I'd ideally like to switch to my
 > new maildir source without losing the index information I have for my
 > IMAP source. The obvious way of switching over (removing my old source
 > and adding the new one) would mean essentially starting over. Is this
 > what I have to do or is there another way for me to switch?
 
 I wouldn't call it graceful, exactly, but you should be able to preserve
 state by running sup-dump on the original source, drop the index (move
 your ~/.sup/ferret directory somewhere else), edit your source.yaml
 file, and use sup-sync --restored --restore <dumpfile> to scan over the
 new source and restore the state for each message.
 
 It will take a while. Try it on a subset of messages first if possible
 to make sure it's working. Post any questions and I'll try and help you.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From tarko@lanparty.ee  Sat Jun 13 07:13:06 2009
 From: tarko@lanparty.ee (Tarko Tikan)
 Date: Sat, 13 Jun 2009 14:13:06 +0300
 Subject: [sup-talk] display_length issue with special-characters on
 	non-UTF8 terminal
 In-Reply-To: <1244834230-sup-1200@entry>
 References: <1244536704-sup-7027@valgus> <1244834230-sup-1200@entry>
 Message-ID: <1244891132-sup-2424@valgus>
 
 > (I'm assuming that your terminal encoding is not UTF-8.)
 
 No, it's not.
 
 > Does this patch fix the issue? If so, I will release an 0.8.1.
 
 Yes it does. To me, this approach felt "hackish" so I didn't come up with a patch :) But I still don't have better idea how to fix it so it'll have to stay like this.
 
 > +    if $encoding == "UTF-8"
 > +      scan(/./u).size
 > +    else
 > +      size
 > +    end
 
 It would probably be correct to use:
 
 if $encoding == "UTF-8"
 	scan(/./u).size
 else
 	length
 end
 
 Thats because scan returns a array (hence using the size), without scan you are just invoking on string and it's correct to use length (for some reason size works too, backward compatibility?) 
 
 -- 
 tarko
 
 From bachjh@googlemail.com  Sat Jun 13 10:17:51 2009
 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=)
 Date: Sat, 13 Jun 2009 16:17:51 +0200
 Subject: [sup-talk] sup and ncursesw
 In-Reply-To: <1244836517-sup-5520@entry>
 References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
 	<1244836517-sup-5520@entry>
 Message-ID: <91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com>
 
 2009/6/12 William Morgan <wmorgan-sup at masanjin.net>
 
 >
 > What is your environment's character set? (Should be the first line of
 > output logged by Sup.) What is your terminal emulator? And what's the
 > behavior without the patch to ncurses.so?
 
 
 After playing around a bit i think the behaviour might be related to a
 problem with locale.
 I reinstalled ruby, rubygems, ncurses and sup. No patch to ncurses this
 time. Using gnome-terminal or xterm with "TERM=xterm" now lets umlauts etc
 look like, e.g. "JM-CM-6rg-Hendrik"). The reported character set is "utf8".
 The same happens when using urxvt with TERM=rxvt-unicode.
 
 However, calling sup like this:
 $ LC_ALL=en_GB.iso-8859-15 sup
 
 results in different behaviour in the two emulators: xterm looks OK when
 viewing the inbox, but inserts boxed question marks in thread-view.
 rxvt-unicode displays everything correctly, but drops the last character of
 a line when a non-ASCII element is somewhere in the line. In both variants
 sup reports the character set correctly as iso-8859-15.
 So I guess I could simply work in urxvt and that's OK, then.
 
 Do other widechar ncurses programs work?
 
 
 The only other ncurses-based program I am aware of using is midnight
 commander, and it seems to be working fine. But I don't know whether it uses
 the widechar variant.
 
 cheers,
 - J?rg-Hendrik
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090613/c8c73902/attachment.html>
 
 From aep@exys.org  Sun Jun 14 00:37:13 2009
 From: aep@exys.org (Arvid Picciani)
 Date: Sat, 13 Jun 2009 21:37:13 -0700
 Subject: [sup-talk] Sup won't save state
 Message-ID: <1244954212-sup-8783@andariel>
 
 
 Hi,
 I'm trying out sup and I totally like the concept so far, unfortunately it
 doesn't work correctly for me.
 
 1) It doesn't save its state.  The next time I open it up, read messages
 are new again.
 
 2) when pressing c, to compose a new message, it asks for a Subject.
 Later in vim I see the Subject field contains random characters instead.
 
 3) Most input "dialogs" (?) can't be killed.  Pressing ESC does nothing.
 The only to chancel such an operation is to kill sup.
 
 4) It behaves very odd when two clients are using the same imap account.
 Yes, the docs state that, but not how to work around that when you
 _have_  to use two clients. Currently I'm trying to use offlineimap,
 unfortunately that's broken.
 
 Thank you,
 Arvid
 
 From bwalton@artsci.utoronto.ca  Sat Jun 13 21:36:41 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 13 Jun 2009 21:36:41 -0400
 Subject: [sup-talk] [PATCH] Minimalist view
 In-Reply-To: <1244839497-sup-547@tomsk>
 References: <1244839497-sup-547@tomsk>
 Message-ID: <1244943297-sup-5509@ntdws12.chass.utoronto.ca>
 
 Excerpts from Marcus Williams's message of Fri Jun 12 16:46:32 -0400 2009:
 > Adds a keypress to toggle to a minimalist view in thread index mode.
 > This removes the date, authors and number of threads from the view
 > leaving more room for labels/snippets
 
 This patch looks sound, but I wonder if a Hook might be in order to
 make the alternate display customizable?  Not a bad idea at all
 though.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090613/4467445f/attachment.bin>
 
 From marcus-sup@bar-coded.net  Sun Jun 14 09:17:38 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Sun, 14 Jun 2009 14:17:38 +0100
 Subject: [sup-talk] [PATCH] Minimalist view
 In-Reply-To: <1244943297-sup-5509@ntdws12.chass.utoronto.ca>
 References: <1244839497-sup-547@tomsk>
 	<1244943297-sup-5509@ntdws12.chass.utoronto.ca>
 Message-ID: <1244985302-sup-9505@tomsk>
 
 On 14.6.2009, Ben Walton wrote:
 > This patch looks sound, but I wonder if a Hook might be in order to
 > make the alternate display customizable?  Not a bad idea at all
 > though.
 
 Slightly ahead of you :) This is the default view for my next patch
 which implements exactly that hook.
 
 I'm just wandering through my local commits and cleaning stuff up for
 submission so hopefully a few more to come as well.
 
 Marcus
 
 From aep@exys.org  Sun Jun 14 20:51:18 2009
 From: aep@exys.org (Arvid Picciani)
 Date: Sun, 14 Jun 2009 17:51:18 -0700
 Subject: [sup-talk] Sup won't save state
 In-Reply-To: <1244954212-sup-8783@andariel>
 References: <1244954212-sup-8783@andariel>
 Message-ID: <1245026779-sup-3938@andariel>
 
 Sorry,  still takes a little to get used to sup.  I have no clue what
 was on and off list, but I assume this was off,  so I'm going to repost
 it:
 
 
 > $ in inbox mode to save, or at intervals. does clean shutdown not do
 > this automatically?
 
 "clean shutdown" is one of the reasons I went away from Gui crap.
 It almost never works for me.
 I don't even know how to shut down a Linux computer "cleanly" other then
 by clicking some button on some Gui menu, which I don't have,
 so most Gui programs just crash and leave me next time with some
 ridiculous "recovery assistant".
 Sup does exactly that and it's highly annoying. It doesn't even work.
 Why the hell are you trying to kill a non existent sup instance?
 Maybe I should just alias sup="rm .sup/lock;sup"
 
 End of rant.
 
 So how do I configure sup to save automatically?
 
 
 PS:  the encrypt/reply to menu on the reply view is pretty cool :)
 
 From aep@exys.org  Sun Jun 14 20:58:31 2009
 From: aep@exys.org (Arvid Picciani)
 Date: Sun, 14 Jun 2009 17:58:31 -0700
 Subject: [sup-talk] Wrong messages in thread
 Message-ID: <1245027174-sup-4117@andariel>
 
 Two more questions  :P
 
 
 1) Some messages end up in the wrong thread.  When there is no other
 useful info, sup appears to guess a thread by the Subject similarity.
 Unfortunately that ends up being very wrong for my university mailing
 list, since they have no List-Id, but the full university name in the
 Subject and people won't learn to write meaningful Subjects.
 
 [blablablalblalbafooomal uni blabla] hi
 is displayed in the same thread with
 [blablablalblalbafooomal uni blabla] hello
 although those are two different threads.
 
 Can I manually fix those?
 
 
 2) how's that address book generated?
 I have sup-talk-request and sup-talk-something
 but not sup-talk.
 
 
 
 thanks
 --
 Arvid
 
 
 From ezyang@MIT.EDU  Sun Jun 14 13:36:08 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sun, 14 Jun 2009 13:36:08 -0400
 Subject: [sup-talk] Wrong messages in thread
 In-Reply-To: <1245027174-sup-4117@andariel>
 References: <1245027174-sup-4117@andariel>
 Message-ID: <1245000912-sup-6454@javelin>
 
 Excerpts from Arvid Picciani's message of Sun Jun 14 20:58:31 -0400 2009:
 > 2) how's that address book generated?
 > I have sup-talk-request and sup-talk-something
 > but not sup-talk.
 
 When you edit an address in thread-view-mode using i it gets added
 to your address book. Ideally, stuff should get added when you compose
 and email the first time. This is a patch I want to make at some point.
 
 Cheers,
 Edward
 
 From garoth@gmail.com  Sun Jun 14 16:35:57 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Sun, 14 Jun 2009 13:35:57 -0700
 Subject: [sup-talk] Sup won't save state
 In-Reply-To: <1245026779-sup-3938@andariel>
 References: <1244954212-sup-8783@andariel> <1245026779-sup-3938@andariel>
 Message-ID: <80055d7c0906141335r31848e05ydfc8557b0d1d9ca6@mail.gmail.com>
 
 Yeah, sorry, I replied to person accidentally while on handheld.
 Thanks for forwarding.
 
 Anyway, yeah, wish saving in sup was better. Don't really know
 anything better than sup-sync.
 
 -AT
 
 From nicolas.pouillard@gmail.com  Mon Jun 15 08:03:58 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 15 Jun 2009 14:03:58 +0200
 Subject: [sup-talk] Wrong messages in thread
 In-Reply-To: <1245000912-sup-6454@javelin>
 References: <1245027174-sup-4117@andariel> <1245000912-sup-6454@javelin>
 Message-ID: <1245067390-sup-2318@ausone.inria.fr>
 
 Excerpts from Edward Z. Yang's message of Sun Jun 14 19:36:08 +0200 2009:
 > Excerpts from Arvid Picciani's message of Sun Jun 14 20:58:31 -0400 2009:
 > > 2) how's that address book generated?
 > > I have sup-talk-request and sup-talk-something
 > > but not sup-talk.
 > 
 > When you edit an address in thread-view-mode using i it gets added
 > to your address book. Ideally, stuff should get added when you compose
 > and email the first time. This is a patch I want to make at some point.
 
 Yes it would be great to automatically prompt for adding the contact when
 we send a message to someone not yet in contacts.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 09:34:29 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 06:34:29 -0700
 Subject: [sup-talk] Wrong messages in thread
 In-Reply-To: <1245027174-sup-4117@andariel>
 References: <1245027174-sup-4117@andariel>
 Message-ID: <1245072716-sup-829@entry>
 
 Reformatted excerpts from Arvid Picciani's message of 2009-06-14:
 > 1) Some messages end up in the wrong thread.  When there is no other
 > useful info, sup appears to guess a thread by the Subject similarity.
 
 Sup does not do this. If you're seeing messages with different subjects
 in the same thread, a later one contains a reference to an earlier one.
 Sometimes this happens if people reply to a mailing list message and
 change the subject as a way of starting a new message. You can confirm
 this by examining the in-reply-to and references headers of the later
 message.
 
 > 2) how's that address book generated?
 > I have sup-talk-request and sup-talk-something
 > but not sup-talk.
 
 By manually adding contacts, e.g. with 'i' in thread-view-mode, plus a
 couple recent contacts automatically drawn from the index.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 09:37:15 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 06:37:15 -0700
 Subject: [sup-talk] Sup won't save state
 In-Reply-To: <1244954212-sup-8783@andariel>
 References: <1244954212-sup-8783@andariel>
 Message-ID: <1245072900-sup-2799@entry>
 
 Reformatted excerpts from Arvid Picciani's message of 2009-06-13:
 > 1) It doesn't save its state.  The next time I open it up, read
 > messages are new again.
 
 How are you quitting Sup?
 
 > 2) when pressing c, to compose a new message, it asks for a Subject.
 > Later in vim I see the Subject field contains random characters
 > instead.
 
 Strange. Are they related in any way? Can you give an example?
 
 
 > 3) Most input "dialogs" (?) can't be killed.  Pressing ESC does
 > nothing.  The only to chancel such an operation is to kill sup.
 
 Ctrl-g.
 
 > 4) It behaves very odd when two clients are using the same imap
 > account.  Yes, the docs state that, but not how to work around that
 > when you _have_  to use two clients.
 
 If you change the IMAP folder via another client, you'll have to run
 sup-sync --changed on that source before running Sup. Sup should detect
 this and tell you. What "odd" behavior are you seeing?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 09:42:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 06:42:04 -0700
 Subject: [sup-talk] Sup won't save state
 In-Reply-To: <1245026779-sup-3938@andariel>
 References: <1244954212-sup-8783@andariel> <1245026779-sup-3938@andariel>
 Message-ID: <1245073093-sup-5388@entry>
 
 Reformatted excerpts from Arvid Picciani's message of 2009-06-14:
 > "clean shutdown" is one of the reasons I went away from Gui crap.
 
 Clean shutdown has nothing to do with GUI vs not GUI.
 
 > I don't even know how to shut down a Linux computer "cleanly" other
 > then by clicking some button on some Gui menu, which I don't have,
 > so most Gui programs just crash and leave me next time with some
 > ridiculous "recovery assistant".
 > Sup does exactly that and it's highly annoying. It doesn't even work.
 
 It's hard to guess what you're doing here, but it sounds like you're
 pressing ctrl-c to kill Sup and then pressing y at the "die ungracefully
 now?" prompt. You may want to read the new user guide:
 http://sup.rubyforge.org/NewUserGuide.txt.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 09:50:37 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 06:50:37 -0700
 Subject: [sup-talk] [PATCH] Minimalist view
 In-Reply-To: <1244943297-sup-5509@ntdws12.chass.utoronto.ca>
 References: <1244839497-sup-547@tomsk>
 	<1244943297-sup-5509@ntdws12.chass.utoronto.ca>
 Message-ID: <1245073371-sup-3704@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-13:
 > This patch looks sound, but I wonder if a Hook might be in order to
 > make the alternate display customizable?  Not a bad idea at all
 > though.
 
 Yeah, I would generally like to have this type of thing done through
 hooks, but if a lot of people like this mode then I could integrate it
 directly.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Mon Jun 15 09:54:01 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 15 Jun 2009 09:54:01 -0400
 Subject: [sup-talk] [PATCH] Minimalist view
 In-Reply-To: <1245073371-sup-3704@entry>
 References: <1244839497-sup-547@tomsk>
 	<1244943297-sup-5509@ntdws12.chass.utoronto.ca>
 	<1245073371-sup-3704@entry>
 Message-ID: <1245073954-sup-8198@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Mon Jun 15 09:50:37 -0400 2009:
 
 > Yeah, I would generally like to have this type of thing done through
 > hooks, but if a lot of people like this mode then I could integrate it
 > directly.
 
 What about a Hook with this as the default alternate view if the Hook
 isn't set?  I'd also suggest changing the name from minimalist to
 alternate, since if there is a hook available, it may not actually be
 a minimal view?
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090615/82450fd6/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 10:04:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 07:04:52 -0700
 Subject: [sup-talk] sup and ncursesw
 In-Reply-To: <91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com>
 References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
 	<1244836517-sup-5520@entry>
 	<91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com>
 Message-ID: <1245074133-sup-9338@entry>
 
 Reformatted excerpts from J?rg-Hendrik Bach's message of 2009-06-13:
 > After playing around a bit i think the behaviour might be related to a
 > problem with locale.
 
 Yeah, this stuff is all tricky to get working right. I recommend first
 trying to get to the point where you can cat and less files with funny
 characters in them, and then introduce something like Sup. (And that's
 typically the point where you see the difference between ncurses.so with
 and without the patch.)
 
 > Using gnome-terminal or xterm with "TERM=xterm" now lets umlauts etc
 > look like, e.g. "JM-CM-6rg-Hendrik"). The reported character set is
 > "utf8".
 
 Probably the umlauts themselves aren't in utf8. I have had success with
 gnome-terminal and TERM=xterm, so I bet you can get this combo to work.
 Try changing your locale from utf8 to en_GB.iso-8859-15 here (if you're
 using Ubuntu, you can edit /etc/default/locale an re-log in, then
 `locale` to check.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 10:10:30 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 07:10:30 -0700
 Subject: [sup-talk] display_length issue with special-characters on
 	non-UTF8 terminal
 In-Reply-To: <1244891132-sup-2424@valgus>
 References: <1244536704-sup-7027@valgus> <1244834230-sup-1200@entry>
 	<1244891132-sup-2424@valgus>
 Message-ID: <1245074739-sup-3954@entry>
 
 Reformatted excerpts from Tarko Tikan's message of 2009-06-13:
 > Yes it does. To me, this approach felt "hackish" so I didn't come up
 > with a patch :) But I still don't have better idea how to fix it so
 > it'll have to stay like this.
 
 It's hackish because Ruby 1.8 has shitty multibyte support. The only
 reason it works at all is because byte length is character length (at
 least most of the time) in your encoding.
 
 There is a multibyte gem out there that I'm keeping an eye on. Also Ruby
 1.9.1 allegedgly fixes this problem.
 
 > Thats because scan returns a array (hence using the size), without
 > scan you are just invoking on string and it's correct to use length
 > (for some reason size works too, backward compatibility?) 
 
 Size and length are synonmys for both arrays and strings. I used size
 there for symmetry.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From garoth@gmail.com  Mon Jun 15 11:20:58 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 15 Jun 2009 11:20:58 -0400
 Subject: [sup-talk] Sup won't save state
 In-Reply-To: <1245072900-sup-2799@entry>
 References: <1244954212-sup-8783@andariel> <1245072900-sup-2799@entry>
 Message-ID: <80055d7c0906150820o3ef05759j23a54e0f889594b7@mail.gmail.com>
 
 >> 2) when pressing c, to compose a new message, it asks for a Subject.
 >> Later in vim I see the Subject field contains random characters
 >> instead.
 >
 > Strange. Are they related in any way? Can you give an example?
 
 When this happened to me, they were absolutely unrelated, looked like
 trying to vim a bit of a binary file...
 
 But went away randomly a few days later.
 
 -AT
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 12:32:42 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 09:32:42 -0700
 Subject: [sup-talk] [PATCH] fixes for ruby1.9
 In-Reply-To: <1244835352-10370-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1244835352-10370-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245083484-sup-9468@entry>
 
 Reformatted excerpts from Rich Lane's message of 2009-06-12:
 > Change colons in case statements to 'then'
 > Fix a block that didn't take enough arguments
 > Rename variables to avoid shadowing warnings
 > Use String.ord (and define it for 1.8)
 > Use DL::Importer on 1.9
 > Make require 'fastthread' optional
 
 Thanks for this. I've applied it directly to master. Now if someone
 would just upgrade Ferret to 1.9, we might be able to actually run Sup!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 12:53:47 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 09:53:47 -0700
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1244719933-sup-4261@viajero>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 Message-ID: <1245084718-sup-1647@entry>
 
 Reformatted excerpts from Fabio Riga's message of 2009-06-11:
 > All is fine, I just need to remember to launch sup this way. Maybe it
 > needs some work on localization?
 
 Sorry about that. The problem is that Sup was writing an invalid
 sent.mbox file in certain locales, including yours, and then dying when
 it couldn't parse its own file. If you update to the latest git, this
 should be fixed for new messages, and you shouldn't need the LANG=C
 hack.
 
 Please let me know if you have any more problems.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 13:24:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 10:24:08 -0700
 Subject: [sup-talk] lockmanager
 In-Reply-To: <1244595206-sup-6689@ntdws12.chass.utoronto.ca>
 References: <1244595206-sup-6689@ntdws12.chass.utoronto.ca>
 Message-ID: <1245084879-sup-6794@entry>
 
 Hi Ben,
 
 Reformatted excerpts from Ben Walton's message of 2009-06-09:
 > I've attached the base LockManager class that I'm envisioning for sup.
 
 Sorry for the delay. This looks good. Using a mutex to protect the
 file-locking seems like the right idea. Carry on!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Mon Jun 15 13:39:15 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 15 Jun 2009 13:39:15 -0400
 Subject: [sup-talk] lockmanager
 In-Reply-To: <1245084879-sup-6794@entry>
 References: <1244595206-sup-6689@ntdws12.chass.utoronto.ca>
 	<1245084879-sup-6794@entry>
 Message-ID: <1245087383-sup-5205@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Mon Jun 15 13:24:08 -0400 2009:
 
 > Sorry for the delay. This looks good. Using a mutex to protect the
 > file-locking seems like the right idea. Carry on!
 
 Yah, now that 'stupid Kobe' beat the Magic last night, my evenings
 should have more time for completing this.  I'm just about finished
 integrating it with the mbox code.
 
 I've branched this from bw/flexible_sent, since I thought it made more
 sense to go from that than from master w/o the flexible sent
 parts...it should still merge decently for you, I think.
 
 The next hurdle will be testing, which I'll need help for, since my
 only mbox is sup://sent, which is now legacy only (and at some point
 when I'm bored will disappear completely).
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090615/499ca4b3/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 13:44:25 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 10:44:25 -0700
 Subject: [sup-talk] [PATCH] before-search hook
 In-Reply-To: <1244612627-sup-982@javelin>
 References: <1244612627-sup-982@javelin>
 Message-ID: <1245087294-sup-6276@entry>
 
 Hi Edward,
 
 Thanks for the patch. I'm interested in integrating it into Sup
 mainline. A couple comments:
 
 1. Can you rename it to custom-search? I think that's a better
    description.
 
 2. I would rather have the hook return a value. So this:
 > -    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 > +    subs = String.new s
 > +    HookManager.run("before-search", :subs => subs)
   I would rather see as:
     subs = HookManager.run("before-search", :subs => s) || s
 
 3. It's not really an issue of mutation vs no mutation. The problem is
    that the parameter names in hooks are method calls, not variables. So
    while "subs = subs.gsub(...)" causes a 'subs' local variable to be
    created and initialized to nil, both "x = subs.gsub(...)" and "subs =
    self.subs.gsub(...)" work fine.
 
    This is probably less of an issue when the hook is returning a
    values, but if you could change the comments to be a warning about
    shadowing method calls instead that would be better.
 
 Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 13:50:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 10:50:21 -0700
 Subject: [sup-talk] lockmanager
 In-Reply-To: <1245087383-sup-5205@ntdws12.chass.utoronto.ca>
 References: <1244595206-sup-6689@ntdws12.chass.utoronto.ca>
 	<1245084879-sup-6794@entry>
 	<1245087383-sup-5205@ntdws12.chass.utoronto.ca>
 Message-ID: <1245088148-sup-5245@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-06-15:
 > I've branched this from bw/flexible_sent, since I thought it made more
 > sense to go from that than from master w/o the flexible sent
 > parts...it should still merge decently for you, I think.
 
 That's fine. As long as it doesn't branch from next, I'm happy.
 
 > The next hurdle will be testing, which I'll need help for, since my
 > only mbox is sup://sent, which is now legacy only (and at some point
 > when I'm bored will disappear completely).
 
 Although the addressess are (trivially) mangled, you can use something
 like http://rubyforge.org/pipermail/sup-talk/2009-June.txt.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From garoth@gmail.com  Mon Jun 15 14:45:35 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 15 Jun 2009 14:45:35 -0400
 Subject: [sup-talk] [BUG] Sup Overload
 Message-ID: <80055d7c0906151145r493c07c2h7a68d776f49ce91a@mail.gmail.com>
 
 Hello there!
 
 Exciting fresh new sup crash. What's happened is that I just imported
 a zillion new messages from several new sources. I downloaded all the
 mail from 4 mailing lists in my gmail account. Anyway, so they all
 appeared as new in my inbox. I started holding a as they appeared to
 archive them. Sup blew up. See attached exception log.
 
 Cheers.
 
 -AT
 -------------- next part --------------
 --- RuntimeError from thread: poll after loading inbox
 unknown drawable object: nil in #<Redwood::InboxMode:0xb745fc4c> for line 35
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:200:in `draw_line'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/line-cursor-mode.rb:39:in `draw_line'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `draw'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `draw'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/line-cursor-mode.rb:24:in `draw'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:99:in `draw'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:83:in `redraw'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:303:in `draw_screen'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:187:in `handle_added_update'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `relay'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `relay'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:162:in `add_messages_from'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:130:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `upto'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `__pass'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:531:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:141:in `add_messages_from'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:98:in `do_poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `do_poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `synchronize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `do_poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/poll-mode.rb:17:in `poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:53:in `poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:663:in `call'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:663:in `__unprotected_load_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:605:in `call'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:605:in `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 From garoth@gmail.com  Mon Jun 15 14:47:22 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 15 Jun 2009 14:47:22 -0400
 Subject: [sup-talk] [BUG] Can't handle spaces in paths
 Message-ID: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com>
 
 Hey there,
 
 I just downloaded a whole lot of mail from my gmail account via
 offlineimap, and tried to add a source with a space. In short, sup
 doesn't like this. It tries to do a split somewhere and it doesn't
 work out for it so well :)
 
 Not much of a bug, I ln -s'd around it. Maybe something that could be
 handled somehow though? I tried quotes and whitespace backslashing in
 shell, but no go.
 
 Cheers!
 
 -AT
 
 From guillaume.quintard@gmail.com  Mon Jun 15 15:05:37 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 15 Jun 2009 21:05:37 +0200
 Subject: [sup-talk] [BUG] Can't handle spaces in paths
 In-Reply-To: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com>
 References: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com>
 Message-ID: <1245092672-sup-7673@altis>
 
 Excerpts from Andrei Thorp's message of Mon Jun 15 20:47:22 +0200 2009:
 > Not much of a bug, I ln -s'd around it. Maybe something that could be
 > handled somehow though? I tried quotes and whitespace backslashing in
 > shell, but no go.
 >
 Did you put a '\' before the spaces?
 
 -- 
 Guillaume
 
 From garoth@gmail.com  Mon Jun 15 15:07:50 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 15 Jun 2009 15:07:50 -0400
 Subject: [sup-talk] [BUG] Can't handle spaces in paths
 In-Reply-To: <1245092672-sup-7673@altis>
 References: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com>
 	<1245092672-sup-7673@altis>
 Message-ID: <80055d7c0906151207p95bbae4w5846acb8f03044da@mail.gmail.com>
 
 >> I tried quotes and whitespace backslashing in shell, but no go.
 >>
 > Did you put a '\' before the spaces?
 >
 > --
 > Guillaume
 
 That's what I was referring to ^
 
 Also, I should mention that I tried sup-add as well as sup-config for
 this operation.
 
 -AT
 
 From guillaume.quintard@gmail.com  Mon Jun 15 15:11:04 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 15 Jun 2009 21:11:04 +0200
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245084718-sup-1647@entry>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry>
 Message-ID: <1245092885-sup-1794@altis>
 
 Excerpts from William Morgan's message of Mon Jun 15 18:53:47 +0200 2009:
 > Please let me know if you have any more problems.
 
 Still have it here, arg., with next.
 
 There is a sense of tragic in the fact that I know that after sending
 that mail to get help, sup will inevitably crash :-)
 
 -- 
 Guillaume
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 15:17:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 12:17:20 -0700
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245092885-sup-1794@altis>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry> <1245092885-sup-1794@altis>
 Message-ID: <1245093278-sup-4366@entry>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-06-15:
 > Still have it here, arg., with next.
 
 You probably still have broken lines in your sent.mbox. This fix only
 works for new messages, so you'll have to edit sent.mbox by hand. Look
 for "From " lines that have a localized timestamp in them, and change
 them to something that Time.parse can parse. It's probably possible to
 write a script to do this if you have a large number of htem.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 15:18:28 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 12:18:28 -0700
 Subject: [sup-talk] [BUG] Can't handle spaces in paths
 In-Reply-To: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com>
 References: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com>
 Message-ID: <1245093476-sup-4708@entry>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-06-15:
 > I just downloaded a whole lot of mail from my gmail account via
 > offlineimap, and tried to add a source with a space. In short, sup
 > doesn't like this. It tries to do a split somewhere and it doesn't
 > work out for it so well :)
 
 Try putting a %20 instead of a space. A sad consequence of using URIs to
 specify sources.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From garoth@gmail.com  Mon Jun 15 15:44:13 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 15 Jun 2009 15:44:13 -0400
 Subject: [sup-talk] Yet Another Offlineimap Thread (YAOT)
 Message-ID: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
 
 Hello!
 
 So I decided today to finally jump in and try to use sup for my main
 gmail account and not just my work stuff. I've set up offlineimap and
 downloaded the mail that I care for. Questions:
 
  - Does imap support a way to say which mails have been read and not?
 I think it probably does. If this is the case, can sup-sync-back
 somehow do this? It'd be nice if my gmail understood when a mail has
 been read, so when I sync back up with offlineimap, it's all savvy.
  - I vaguely saw some tricks here for how to reply with different
 e-mail addresses and stuff. I'd like to execute a whole different
 command when replying in some situations, so that my mail gets sent
 through gmail's smtp server instead of my work's one, for example. How
 would I achieve this?
  - I don't see a daemon mode for offlineimap. I guess the expected
 usage is to make it quiet and put it in a cron/regular script? Am I
 correct?
 
 Thanks!
 
 -AT
 
 From guillaume.quintard@gmail.com  Mon Jun 15 17:30:13 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 15 Jun 2009 23:30:13 +0200
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245093278-sup-4366@entry>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry> <1245092885-sup-1794@altis>
 	<1245093278-sup-4366@entry>
 Message-ID: <1245101169-sup-9937@altis>
 
 Excerpts from William Morgan's message of Mon Jun 15 21:17:20 +0200 2009:
 > You probably still have broken lines in your sent.mbox. This fix only
 > works for new messages, so you'll have to edit sent.mbox by hand. Look
 > for "From " lines that have a localized timestamp in them, and change
 > them to something that Time.parse can parse. It's probably possible to
 > write a script to do this if you have a large number of htem.
 
 I think I said "save them in the mbox" to sup-config, and I still get
 that behaviour, so what? Do I dig in the 3.2Go .mbox (please, not that one),
 do I change to "save in sup://sent"? BTW, I renamed my sent.mbox, just
 in case.
 
 If I really have to go into the huge mbox, what should I look for
 exactly, I didn't quite get what the parser failed on.
 
 Regards
 
 -- 
 Guillaume
 
 From garoth@gmail.com  Mon Jun 15 21:14:14 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 15 Jun 2009 18:14:14 -0700
 Subject: [sup-talk]  [BUG] Sup Overload
 In-Reply-To: <a412e2a70906151410w307c2f1fnbaf51ea43cc8121f@mail.gmail.com>
 References: <80055d7c0906151145r493c07c2h7a68d776f49ce91a@mail.gmail.com>
 	<a412e2a70906151410w307c2f1fnbaf51ea43cc8121f@mail.gmail.com>
 Message-ID: <80055d7c0906151814u2ab0fdf4n76144e27517870c8@mail.gmail.com>
 
 Forwarding to mailing list.
 
 ---------- Forwarded message ----------
 From: Mark Alexander <marka at pobox.com>
 Date: Mon, Jun 15, 2009 at 2:10 PM
 Subject: Re: [sup-talk] [BUG] Sup Overload
 To: Andrei Thorp <garoth at gmail.com>
 
 This may not be related, but at one point I found that feeding
 input characters to sup too quickly caused it to crash. ?I was using
 X cut-and-paste as a kind of poor-man's macro facility when I ran
 into this. ?If I recall correctly, the string I was cut-and-pasting into
 sup was this:
 
 ? T=N=a$
 
 which was supposed to tag all messages, mark them as read, and archive
 them. ?I think it was crashing when it got to the "$", but it might
 have been the "a" that did it. ?I haven't tried this in a while.
 
 From wmorgan-sup@masanjin.net  Mon Jun 15 22:18:05 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 15 Jun 2009 19:18:05 -0700
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245101169-sup-9937@altis>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry> <1245092885-sup-1794@altis>
 	<1245093278-sup-4366@entry> <1245101169-sup-9937@altis>
 Message-ID: <1245118534-sup-3523@entry>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-06-15:
 > I think I said "save them in the mbox" to sup-config, and I still get
 > that behaviour, so what? Do I dig in the 3.2Go .mbox (please, not that
 > one), do I change to "save in sup://sent"? BTW, I renamed my
 > sent.mbox, just in case.
 
 If you're seeing that error, you should edit the "From " lines in your
 sent.mbox file (which is presumably not the 3.2g one).
 
 You'll see something like:
   From guillaume.quintard at gmail.com <date>
 
 And a couple recent messages (i.e. at the bottom of the file) will have
 a <date> that's been localized to your locale. That's what has to
 change.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Tue Jun 16 04:06:48 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Tue, 16 Jun 2009 10:06:48 +0200
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245118534-sup-3523@entry>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry> <1245092885-sup-1794@altis>
 	<1245093278-sup-4366@entry> <1245101169-sup-9937@altis>
 	<1245118534-sup-3523@entry>
 Message-ID: <1245139562-sup-3587@altis>
 
 Excerpts from William Morgan's message of Tue Jun 16 04:18:05 +0200 2009:
 > If you're seeing that error, you should edit the "From " lines in your
 > sent.mbox file (which is presumably not the 3.2g one).
 > 
 > You'll see something like:
 >   From guillaume.quintard at gmail.com <date>
 > 
 > And a couple recent messages (i.e. at the bottom of the file) will have
 > a <date> that's been localized to your locale. That's what has to
 > change.
 
 So, I grep'ed "save them in the mbox" from the big mbox, and from
 sent.mbox, logically, I should have found 2 occurences, one in my mail,
 one in yours, but found only one :-(.
 
 I re-ran sup-config, told it to save in "sent", and that seems better.
 But I still don't know where the few messages sent during that time are.
 Plus, I sent a mail to one of my alternate addresses, and it popped up
 in the mailbox, without the "Sent" label, is that expected?
 
 -- 
 Guillaume
 
 From bwalton@artsci.utoronto.ca  Tue Jun 16 07:20:41 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 16 Jun 2009 07:20:41 -0400
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245139562-sup-3587@altis>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry> <1245092885-sup-1794@altis>
 	<1245093278-sup-4366@entry> <1245101169-sup-9937@altis>
 	<1245118534-sup-3523@entry> <1245139562-sup-3587@altis>
 Message-ID: <1245150910-sup-3911@ntdws12.chass.utoronto.ca>
 
 Excerpts from Guillaume Quintard's message of Tue Jun 16 04:06:48 -0400 2009:
 
 Hi Guillaume,
 
 > I re-ran sup-config, told it to save in "sent", and that seems better.
 > But I still don't know where the few messages sent during that time are.
 > Plus, I sent a mail to one of my alternate addresses, and it popped up
 > in the mailbox, without the "Sent" label, is that expected?
 
 The patch that allows for using any (most) sources as the outbox
 changed the way the sent label gets applied.  When the message is
 polled, the label 'sent' is applied iff the source of the message
 matches the source uri in config.yaml.  The default sent source
 (outbox) is sup://sent, which translates to $SUB_BASE/sent.mbox
 (normally ~/.sup/sent).
 
 The other small behaviour change that this introduced was that
 depending on poll intervals, sent messages may not be immediately
 added to the index, but instead are picked up on the next run...I see
 this with my Maildir outbox.  The source used as the outbox is logged
 at startup, although if you've restarted sup, that log is lost to you
 now...
 
 HTH
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090616/b648e879/attachment.bin>
 
 From guillaume.quintard@gmail.com  Tue Jun 16 07:52:35 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Tue, 16 Jun 2009 13:52:35 +0200
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245150910-sup-3911@ntdws12.chass.utoronto.ca>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry> <1245092885-sup-1794@altis>
 	<1245093278-sup-4366@entry> <1245101169-sup-9937@altis>
 	<1245118534-sup-3523@entry> <1245139562-sup-3587@altis>
 	<1245150910-sup-3911@ntdws12.chass.utoronto.ca>
 Message-ID: <1245152881-sup-3661@altis>
 
 Excerpts from Ben Walton's message of Tue Jun 16 13:20:41 +0200 2009:
 > The patch that allows for using any (most) sources as the outbox
 > changed the way the sent label gets applied.  When the message is
 > polled, the label 'sent' is applied iff the source of the message
 > matches the source uri in config.yaml.  The default sent source
 > (outbox) is sup://sent, which translates to $SUB_BASE/sent.mbox
 > (normally ~/.sup/sent).
 
 Well, it seems it's not the case, sent messages pop up in the mailbox
 without the sent label, last message got this:
 "From guillaume.quintard at gmail.com Tue Jun 16 13:47:26 +0200 2009"
 as a first line, and it's my main address, yet no label.
 
 Am I misunderstanding something?
 
 -- 
 Guillaume
 
 From marcus-sup@bar-coded.net  Tue Jun 16 08:42:08 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 16 Jun 2009 13:42:08 +0100
 Subject: [sup-talk] [PATCH] Alternative View
 Message-ID: <1245156068-sup-7360@tomsk>
 
 Adds a keypress to toggle to an alternative view in thread index mode.
 By default this removes the date, authors and number of threads from the
 view leaving more room for labels/snippets
 
 This view is extendable via the alternative-view-widget hook. An example
 hook is included in the contrib/hooks directory that implements the
 standard sup view as an example. If you use this example your
 alternative view will not look any different to the standard sup view.
 It is meant to give you a base point for your edits.
 ---
  contrib/hooks/alternate-view-widget.rb |   39 ++++++++++++++++++++++
  lib/sup/modes/thread-index-mode.rb     |   56 ++++++++++++++++++-------------
  2 files changed, 71 insertions(+), 24 deletions(-)
  create mode 100644 contrib/hooks/alternate-view-widget.rb
 
 diff --git a/contrib/hooks/alternate-view-widget.rb b/contrib/hooks/alternate-view-widget.rb
 new file mode 100644
 index 0000000..cf936fd
 --- /dev/null
 +++ b/contrib/hooks/alternate-view-widget.rb
 @@ -0,0 +1,39 @@
 +# This hook recreates the standard sup view as the alternate view
 +# Note that this will mean there is no difference when toggling 
 +# between the standard and alternate views in sup. This is meant to
 +# serve as a starting point for your own view
 +
 +date_width = Time::TO_NICE_S_MAX_LEN
 +date = thread.date.to_nice_s
 +starred = thread.has_label? :starred
 +    
 +dp = thread.direct_participants.any? { |p| AccountManager.is_account? p }
 +p = dp || thread.participants.any? { |p| AccountManager.is_account? p }
 +    
 +snippet = thread.snippet + (thread.snippet.empty? ? "" : "...")
 +
 +subj_color =
 +  if thread.has_label?(:draft)
 +    :index_draft_color
 +  elsif thread.has_label?(:unread)
 +    :index_new_color
 +  elsif starred
 +    :index_starred_color
 +  else 
 +    :index_old_color
 +  end
 +
 +[ 
 +  [:tagged_color, tagged ? ">" : " "],
 +  [:none, sprintf("%#{date_width}s", date)],
 +     (starred ? [:starred_color, "*"] : [:none, " "]),
 +] + from +
 +[
 +  [subj_color, size_widget_text],
 +  [:to_me_color, thread.labels.member?(:attachment) ? "@" : " "],
 +  [:to_me_color, dp ? ">" : (p ? '+' : " ")],
 +] + (thread.labels - hidden_labels).map { |label| [:label_color, "#{label} "] } +
 +[
 +  [subj_color, thread.subj + (thread.subj.empty? ? "" : " ")],
 +  [:snippet_color, snippet],
 +]
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index 5fa4f4c..9124dbd 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -8,6 +8,15 @@ class ThreadIndexMode < LineCursorMode
    MIN_FROM_WIDTH = 15
    LOAD_MORE_THREAD_NUM = 20
  
 +  HookManager.register "alternate-view-widget", <<EOS
 +Generates the per-thread view for each thread.
 +Variables:
 +  thread: The message thread to be formatted.
 +  hidden_labels: the hidden label list
 +  tagged: true if this thread is tagged
 +  from: the sup default from/author list
 +  size_widget_text: the size widget text (from hook or default sup size)
 +EOS
    HookManager.register "index-mode-size-widget", <<EOS
  Generates the per-thread size widget for each thread.
  Variables:
 @@ -45,7 +54,7 @@ EOS
      k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '='
      k.add :join_threads, "Force tagged threads to be joined into the same thread", '#'
      k.add :undo, "Undo the previous action", 'u'
 -    k.add :toggle_minimalist, "Toggle minimalist view", '~'
 +    k.add :toggle_alternative_view, "Toggle alternative view", '~'
    end
  
    def initialize hidden_labels=[], load_thread_opts={}
 @@ -63,7 +72,7 @@ EOS
      @hidden_labels = hidden_labels + LabelManager::HIDDEN_RESERVED_LABELS
      @date_width = DATE_WIDTH
  
 -    @minimal = false
 +    @alternative = false
  
      @interrupt_search = false
      
 @@ -264,8 +273,8 @@ EOS
      end
    end  
  
 -  def toggle_minimalist 
 -    @minimal = !@minimal
 +  def toggle_alternative_view 
 +    @alternative= !@alternative
      regen_text
    end
  
 @@ -841,26 +850,8 @@ protected
  
      size_widget_text = sprintf "%#{ @size_widget_width}s", size_widget
  
 -
 -    if @minimal
 -      if size_widget!=""
 -        size_widget_text = "+" 
 -      else
 -        size_widget_text = " " 
 -      end
 -      line = []
 -    else
 -      line =  [ 
 -                [:tagged_color, @tags.tagged?(t) ? ">" : " "],
 -                [:none, sprintf("%#{@date_width}s", date)],
 -                (starred ? [:starred_color, "*"] : [:none, " "]),
 -              ] + from
 -    end
 -
 -
 -    line +
 -    [
 -      [subj_color, size_widget_text],
 +    alternateView = [
 +      [subj_color, @alternative?(size_widget!=""?"+":" "):size_widget_text],
        [:to_me_color, t.labels.member?(:attachment) ? "@" : " "],
        [:to_me_color, dp ? ">" : (p ? '+' : " ")],
      ] +
 @@ -869,6 +860,23 @@ protected
        [subj_color, t.subj + (t.subj.empty? ? "" : " ")],
        [:snippet_color, snippet],
      ]
 +
 +    defaultView = [ 
 +      [:tagged_color, @tags.tagged?(t) ? ">" : " "],
 +      [:none, sprintf("%#{@date_width}s", date)],
 +         (starred ? [:starred_color, "*"] : [:none, " "]),
 +    ] + from + alternateView
 +
 +    alternateView = [
 +      [:tagged_color, @tags.tagged?(t) ? ">" : " "],
 +    ] + alternateView
 +
 +
 +    if @alternative
 +      HookManager.run("alternate-view-widget", :thread => t, :hidden_labels => @hidden_labels, :tagged => @tags.tagged?(t)?true:false, :from => from, :size_widget_text => size_widget_text) || alternateView
 +    else
 +      defaultView
 +    end
    end
  
    def dirty?; @mutex.synchronize { (@hidden_threads.keys + @threads).any? { |t| t.dirty? } } end
 -- 
 1.5.4.1
 
 From marcus-sup@bar-coded.net  Tue Jun 16 08:45:06 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 16 Jun 2009 13:45:06 +0100
 Subject: [sup-talk] [PATCH] Minimalist view
 In-Reply-To: <1245073371-sup-3704@entry>
 References: <1244839497-sup-547@tomsk>
 	<1244943297-sup-5509@ntdws12.chass.utoronto.ca>
 	<1245073371-sup-3704@entry>
 Message-ID: <1245156233-sup-6049@tomsk>
 
 On 15.6.2009, William Morgan wrote:
 > Yeah, I would generally like to have this type of thing done through
 > hooks, but if a lot of people like this mode then I could integrate it
 > directly.
 
 New patch sent as separate message - renamed to alternative view and
 extendable via the hook mechanism.
 
 Marcus
 
 From bwalton@artsci.utoronto.ca  Tue Jun 16 12:34:40 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 16 Jun 2009 12:34:40 -0400
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245152881-sup-3661@altis>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry> <1245092885-sup-1794@altis>
 	<1245093278-sup-4366@entry> <1245101169-sup-9937@altis>
 	<1245118534-sup-3523@entry> <1245139562-sup-3587@altis>
 	<1245150910-sup-3911@ntdws12.chass.utoronto.ca>
 	<1245152881-sup-3661@altis>
 Message-ID: <1245170025-sup-1339@ntdws12.chass.utoronto.ca>
 
 Excerpts from Guillaume Quintard's message of Tue Jun 16 07:52:35 -0400 2009:
 > Well, it seems it's not the case, sent messages pop up in the mailbox
 > without the sent label, last message got this:
 > "From guillaume.quintard at gmail.com Tue Jun 16 13:47:26 +0200 2009"
 > as a first line, and it's my main address, yet no label.
 
 The sent label is filtered from the inbox view.  Try searching for
 sent mail with the search term: label:sent
 
 > Am I misunderstanding something?
 
 Maybe, but I may be misunderstanding too...
 
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090616/61ef63d0/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Tue Jun 16 20:24:58 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 16 Jun 2009 17:24:58 -0700
 Subject: [sup-talk] [PATCH] index: cleanup interface
 Message-ID: <1245198299-18742-1-git-send-email-rlane@club.cc.cmu.edu>
 
 Added the public methods 'each_docid', 'each_message', and 'optimize' to the
 index. Removed the 'index' and 'ferret' accessors and modified their callers to
 use the new methods. Bonus fixes: sup-dump no longer skips the first message
 and sup_sync --start_at can now delete unseen messages.
 ---
  bin/sup-dump         |    6 ++----
  bin/sup-sync         |   21 +++++++--------------
  bin/sup-tweak-labels |    2 +-
  lib/sup/index.rb     |   27 ++++++++++++++++++++-------
  4 files changed, 30 insertions(+), 26 deletions(-)
 
 diff --git a/bin/sup-dump b/bin/sup-dump
 index 29f6d6e..9b0892e 100755
 --- a/bin/sup-dump
 +++ b/bin/sup-dump
 @@ -24,8 +24,6 @@ end
  index = Redwood::Index.new
  index.load
  
 -(1 ... index.index.reader.max_doc).each do |i|
 -  next if index.index.deleted? i
 -  d = index.index[i]
 -  puts [d[:message_id], "(" + d[:label] + ")"] * " "
 +index.each_message do |m|
 +  puts "#{m.id} (#{m.labels * ' '})"
  end
 diff --git a/bin/sup-sync b/bin/sup-sync
 index 9c342d2..a6e3478 100755
 --- a/bin/sup-sync
 +++ b/bin/sup-sync
 @@ -208,24 +208,17 @@ begin
  
    ## delete any messages in the index that claim they're from one of
    ## these sources, but that we didn't see.
 -  ##
 -  ## kinda crappy code here, because we delve directly into the Ferret
 -  ## API.
 -  ##
 -  ## TODO: move this to Index, i suppose.
 -  if (target == :all || target == :changed) && !opts[:start_at]
 +  if (target == :all || target == :changed)
      $stderr.puts "Deleting missing messages from the index..."
      num_del, num_scanned = 0, 0
      sources.each do |source|
        raise "no source id for #{source}" unless source.id
 -      q = "+source_id:#{source.id}"
 -      q += " +source_info: >= #{opts[:start_at]}" if opts[:start_at]
 -      index.index.search_each(q, :limit => :all) do |docid, score|
 +      index.each_message :source_id => source.id do |m|
          num_scanned += 1
 -        mid = index.index[docid][:message_id]
 -        unless seen[mid]
 -          puts "Deleting #{mid}" if opts[:verbose]
 -          index.index.delete docid unless opts[:dry_run]
 +        unless seen[m.id]
 +          next unless m.source_info >= opts[:start_at] if opts[:start_at]
 +          puts "Deleting #{m.id}" if opts[:verbose]
 +          index.drop_entry m.id unless opts[:dry_run]
            num_del += 1
          end
        end
 @@ -237,7 +230,7 @@ begin
  
    if opts[:optimize]
      $stderr.puts "Optimizing index..."
 -    optt = time { index.index.optimize unless opts[:dry_run] }
 +    optt = time { index.optimize unless opts[:dry_run] }
      $stderr.puts "Optimized index of size #{index.size} in #{optt}s."
    end
  rescue Redwood::FatalSourceError => e
 diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
 index 538db8b..f526a95 100755
 --- a/bin/sup-tweak-labels
 +++ b/bin/sup-tweak-labels
 @@ -118,7 +118,7 @@ begin
  
    unless num_changed == 0
      $stderr.puts "Optimizing index..."
 -    index.ferret.optimize unless opts[:dry_run]
 +    index.optimize unless opts[:dry_run]
    end
  
  rescue Exception => e
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index ca01ee7..037b941 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -24,11 +24,6 @@ class Index
  
    include Singleton
  
 -  ## these two accessors should ONLY be used by single-threaded programs.
 -  ## otherwise you will have a naughty ferret on your hands.
 -  attr_reader :index
 -  alias ferret index
 -
    def initialize dir=BASE_DIR
      @index_mutex = Monitor.new
  
 @@ -151,7 +146,7 @@ EOS
      if File.exists? dir
        Redwood::log "loading index..."
        @index_mutex.synchronize do
 -        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer)
 +        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
          Redwood::log "loaded index of #{@index.size} messages"
        end
      else
 @@ -171,7 +166,7 @@ EOS
          field_infos.add_field :refs
          field_infos.add_field :snippet, :index => :no, :term_vector => :no
          field_infos.create_index dir
 -        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer)
 +        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
        end
      end
    end
 @@ -496,6 +491,22 @@ EOS
      results.hits.map { |hit| hit.doc }
    end
  
 +  def each_docid opts={}
 +    query = build_query opts
 +    results = @index_mutex.synchronize { @index.search query, :limit => (opts[:limit] || :all) }
 +    results.hits.map { |hit| yield hit.doc }
 +  end
 +    
 +  def each_message opts={}
 +    each_docid opts do |docid|
 +      yield build_message(docid)
 +    end
 +  end
 +
 +  def optimize
 +    @index_mutex.synchronize { @index.optimize }
 +  end
 +
  protected
  
    class ParseError < StandardError; end
 @@ -621,6 +632,8 @@ protected
      query.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless opts[:load_spam] || labels.include?(:spam)
      query.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless opts[:load_deleted] || labels.include?(:deleted)
      query.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if opts[:skip_killed]
 +
 +    query.add_query Ferret::Search::TermQuery.new("source_id", opts[:source_id]), :must if opts[:source_id]
      query
    end
  
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Tue Jun 16 20:24:59 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 16 Jun 2009 17:24:59 -0700
 Subject: [sup-talk] [PATCH] index: consistent naming
 In-Reply-To: <1245198299-18742-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245198299-18742-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245198299-18742-2-git-send-email-rlane@club.cc.cmu.edu>
 
 Replaced use of run_query with each_docid
 Rename instances of ferret query objects to 'ferret_query'
 Rename 'build_query' to 'build_ferret_query'
 Rename hashes passed to index methods to 'query'
 Rename 'parse_user_query_string' to 'parse_query'
 Change 'parse_query' to return a query hash
 Rename 'drop_entry' to 'delete' and modify callers to pass msgid
 ---
  bin/sup-sync                         |    2 +-
  bin/sup-tweak-labels                 |    4 +-
  lib/sup/draft.rb                     |    2 +-
  lib/sup/index.rb                     |  108 +++++++++++++++------------------
  lib/sup/modes/search-results-mode.rb |   20 +++----
  5 files changed, 63 insertions(+), 73 deletions(-)
 
 diff --git a/bin/sup-sync b/bin/sup-sync
 index a6e3478..a759cbe 100755
 --- a/bin/sup-sync
 +++ b/bin/sup-sync
 @@ -218,7 +218,7 @@ begin
          unless seen[m.id]
            next unless m.source_info >= opts[:start_at] if opts[:start_at]
            puts "Deleting #{m.id}" if opts[:verbose]
 -          index.drop_entry m.id unless opts[:dry_run]
 +          index.delete m.id unless opts[:dry_run]
            num_del += 1
          end
        end
 diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
 index f526a95..6f603e2 100755
 --- a/bin/sup-tweak-labels
 +++ b/bin/sup-tweak-labels
 @@ -2,6 +2,7 @@
  
  require 'rubygems'
  require 'trollop'
 +require 'enumerator'
  require "sup"
  
  class Float
 @@ -81,7 +82,8 @@ begin
    end
    query += ' ' + opts[:query] if opts[:query]
  
 -  docs = Redwood::Index.run_query query
 +  parsed_query = index.parse_query query
 +  docs = Enumerable::Enumerator.new(index, :each_docid, parsed_query).map
    num_total = docs.size
  
    $stderr.puts "Found #{num_total} documents across #{source_ids.length} sources. Scanning..."
 diff --git a/lib/sup/draft.rb b/lib/sup/draft.rb
 index 32266b5..9127739 100644
 --- a/lib/sup/draft.rb
 +++ b/lib/sup/draft.rb
 @@ -37,7 +37,7 @@ class DraftManager
        return
      end
      raise ArgumentError, "not a draft: source id #{entry[:source_id].inspect}, should be #{DraftManager.source_id.inspect} for #{m.id.inspect} / docno #{docid}" unless entry[:source_id].to_i == DraftManager.source_id
 -    Index.drop_entry docid
 +    Index.delete m.id
      File.delete @source.fn_for_offset(entry[:source_info])
      UpdateManager.relay self, :single_message_deleted, m
    end
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 037b941..d15e7bb 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -279,28 +279,28 @@ EOS
    ## you should probably not call this on a block that doesn't break
    ## rather quickly because the results can be very large.
    EACH_BY_DATE_NUM = 100
 -  def each_id_by_date opts={}
 +  def each_id_by_date query={}
      return if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
 -    query = build_query opts
 +    ferret_query = build_ferret_query query
      offset = 0
      while true
 -      limit = (opts[:limit])? [EACH_BY_DATE_NUM, opts[:limit] - offset].min : EACH_BY_DATE_NUM
 -      results = @index_mutex.synchronize { @index.search query, :sort => "date DESC", :limit => limit, :offset => offset }
 -      Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{query.inspect}"
 +      limit = (query[:limit])? [EACH_BY_DATE_NUM, query[:limit] - offset].min : EACH_BY_DATE_NUM
 +      results = @index_mutex.synchronize { @index.search ferret_query, :sort => "date DESC", :limit => limit, :offset => offset }
 +      Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{ferret_query.inspect}"
        results.hits.each do |hit|
          yield @index_mutex.synchronize { @index[hit.doc][:message_id] }, lambda { build_message hit.doc }
        end
 -      break if opts[:limit] and offset >= opts[:limit] - limit
 +      break if query[:limit] and offset >= query[:limit] - limit
        break if offset >= results.total_hits - limit
        offset += limit
      end
    end
  
 -  def num_results_for opts={}
 +  def num_results_for query={}
      return 0 if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
  
 -    q = build_query opts
 -    @index_mutex.synchronize { @index.search(q, :limit => 1).total_hits }
 +    ferret_query = build_ferret_query query
 +    @index_mutex.synchronize { @index.search(ferret_query, :limit => 1).total_hits }
    end
  
    ## yield all messages in the thread containing 'm' by repeatedly
 @@ -313,7 +313,7 @@ EOS
    ## is found.
    SAME_SUBJECT_DATE_LIMIT = 7
    MAX_CLAUSES = 1000
 -  def each_message_in_thread_for m, opts={}
 +  def each_message_in_thread_for m, query={}
      #Redwood::log "Building thread for #{m.id}: #{m.subj}"
      messages = {}
      searched = {}
 @@ -332,7 +332,7 @@ EOS
        q.add_query sq, :must
        q.add_query Ferret::Search::RangeQuery.new(:date, :>= => date_min.to_indexable_s, :<= => date_max.to_indexable_s), :must
  
 -      q = build_query :qobj => q
 +      q = build_ferret_query :qobj => q
  
        p1 = @index_mutex.synchronize { @index.search(q).hits.map { |hit| @index[hit.doc][:message_id] } }
        Redwood::log "found #{p1.size} results for subject query #{q}"
 @@ -343,7 +343,7 @@ EOS
        pending = (pending + p1 + p2).uniq
      end
  
 -    until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
 +    until pending.empty? || (query[:limit] && messages.size >= query[:limit])
        q = Ferret::Search::BooleanQuery.new true
        # this disappeared in newer ferrets... wtf.
        # q.max_clause_count = 2048
 @@ -356,14 +356,14 @@ EOS
        end
        pending = pending[lim .. -1]
  
 -      q = build_query :qobj => q
 +      q = build_ferret_query :qobj => q
  
        num_queries += 1
        killed = false
        @index_mutex.synchronize do
          @index.search_each(q, :limit => :all) do |docid, score|
 -          break if opts[:limit] && messages.size >= opts[:limit]
 -          if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
 +          break if query[:limit] && messages.size >= query[:limit]
 +          if @index[docid][:label].split(/\s+/).include?("killed") && query[:skip_killed]
              killed = true
              break
            end
 @@ -419,7 +419,7 @@ EOS
    def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
    def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
  
 -  def drop_entry docno; @index_mutex.synchronize { @index.delete docno } end
 +  def delete id; @index_mutex.synchronize { @index.delete id } end
  
    def load_entry_for_id mid
      @index_mutex.synchronize do
 @@ -478,27 +478,14 @@ EOS
      @index_mutex.synchronize { @index.search(q, :limit => 1).total_hits > 0 }
    end
  
 -  ## takes a user query string and returns the list of docids for messages
 -  ## that match the query.
 -  ##
 -  ## messages can then be loaded from the index with #build_message.
 -  ##
 -  ## raises a ParseError if the parsing failed.
 -  def run_query query
 -    qobj, opts = Redwood::Index.parse_user_query_string query
 -    query = Redwood::Index.build_query opts.merge(:qobj => qobj)
 -    results = @index.search query, :limit => (opts[:limit] || :all)
 -    results.hits.map { |hit| hit.doc }
 -  end
 -
 -  def each_docid opts={}
 -    query = build_query opts
 -    results = @index_mutex.synchronize { @index.search query, :limit => (opts[:limit] || :all) }
 +  def each_docid query={}
 +    ferret_query = build_ferret_query query
 +    results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
      results.hits.map { |hit| yield hit.doc }
    end
      
 -  def each_message opts={}
 -    each_docid opts do |docid|
 +  def each_message query={}
 +    each_docid query do |docid|
        yield build_message(docid)
      end
    end
 @@ -507,16 +494,15 @@ EOS
      @index_mutex.synchronize { @index.optimize }
    end
  
 -protected
 -
    class ParseError < StandardError; end
  
 -  ## parse a query string from the user. returns a query object and a set of
 -  ## extra flags; both of these are meant to be passed to #build_query.
 +  ## parse a query string from the user. returns a query object
 +  ## that can be passed to any index method with a 'query' 
 +  ## argument, as well as build_ferret_query.
    ##
    ## raises a ParseError if something went wrong.
 -  def parse_user_query_string s
 -    extraopts = {}
 +  def parse_query s
 +    query = {}
  
      subs = s.gsub(/\b(to|from):(\S+)\b/) do
        field, name = $1, $2
 @@ -542,8 +528,8 @@ protected
      ## final stage of query processing. if the user wants to search spam
      ## messages, not adding that is the right thing; if he doesn't want to
      ## search spam messages, then not adding it won't have any effect.
 -    extraopts[:load_spam] = true if subs =~ /\blabel:spam\b/
 -    extraopts[:load_deleted] = true if subs =~ /\blabel:deleted\b/
 +    query[:load_spam] = true if subs =~ /\blabel:spam\b/
 +    query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
  
      ## gmail style "is" operator
      subs = subs.gsub(/\b(is|has):(\S+)\b/) do
 @@ -552,10 +538,10 @@ protected
        when "read"
          "-label:unread"
        when "spam"
 -        extraopts[:load_spam] = true
 +        query[:load_spam] = true
          "label:spam"
        when "deleted"
 -        extraopts[:load_deleted] = true
 +        query[:load_deleted] = true
          "label:deleted"
        else
          "label:#{$2}"
 @@ -601,7 +587,7 @@ protected
      subs = subs.gsub(/\blimit:(\S+)\b/) do
        lim = $1
        if lim =~ /^\d+$/
 -        extraopts[:limit] = lim.to_i
 +        query[:limit] = lim.to_i
          ''
        else
          raise ParseError, "non-numeric limit #{lim.inspect}"
 @@ -609,32 +595,36 @@ protected
      end
      
      begin
 -      [@qparser.parse(subs), extraopts]
 +      query[:qobj] = @qparser.parse(subs)
 +      query[:text] = s
 +      query
      rescue Ferret::QueryParser::QueryParseException => e
        raise ParseError, e.message
      end
    end
  
 -  def build_query opts
 -    query = Ferret::Search::BooleanQuery.new
 -    query.add_query opts[:qobj], :must if opts[:qobj]
 -    labels = ([opts[:label]] + (opts[:labels] || [])).compact
 -    labels.each { |t| query.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
 -    if opts[:participants]
 +private
 +
 +  def build_ferret_query query
 +    q = Ferret::Search::BooleanQuery.new
 +    q.add_query query[:qobj], :must if query[:qobj]
 +    labels = ([query[:label]] + (query[:labels] || [])).compact
 +    labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
 +    if query[:participants]
        q2 = Ferret::Search::BooleanQuery.new
 -      opts[:participants].each do |p|
 +      query[:participants].each do |p|
          q2.add_query Ferret::Search::TermQuery.new("from", p.email), :should
          q2.add_query Ferret::Search::TermQuery.new("to", p.email), :should
        end
 -      query.add_query q2, :must
 +      q.add_query q2, :must
      end
          
 -    query.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless opts[:load_spam] || labels.include?(:spam)
 -    query.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless opts[:load_deleted] || labels.include?(:deleted)
 -    query.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if opts[:skip_killed]
 +    q.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless query[:load_spam] || labels.include?(:spam)
 +    q.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless query[:load_deleted] || labels.include?(:deleted)
 +    q.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if query[:skip_killed]
  
 -    query.add_query Ferret::Search::TermQuery.new("source_id", opts[:source_id]), :must if opts[:source_id]
 -    query
 +    q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
 +    q
    end
  
    def save_sources fn=Redwood::SOURCE_FN
 diff --git a/lib/sup/modes/search-results-mode.rb b/lib/sup/modes/search-results-mode.rb
 index 227ee9b..121e817 100644
 --- a/lib/sup/modes/search-results-mode.rb
 +++ b/lib/sup/modes/search-results-mode.rb
 @@ -1,11 +1,9 @@
  module Redwood
  
  class SearchResultsMode < ThreadIndexMode
 -  def initialize qobj, qopts = nil
 -    @qobj = qobj
 -    @qopts = qopts
 -
 -    super [], { :qobj => @qobj }.merge(@qopts)
 +  def initialize query
 +    @query = query
 +    super [], query
    end
  
    register_keymap do |k|
 @@ -13,9 +11,9 @@ class SearchResultsMode < ThreadIndexMode
    end
  
    def refine_search
 -    query = BufferManager.ask :search, "refine query: ", (@qobj.to_s + " ")
 -    return unless query && query !~ /^\s*$/
 -    SearchResultsMode.spawn_from_query query
 +    text = BufferManager.ask :search, "refine query: ", (@query[:text] + " ")
 +    return unless text && text !~ /^\s*$/
 +    SearchResultsMode.spawn_from_query text
    end
  
    ## a proper is_relevant? method requires some way of asking ferret
 @@ -26,10 +24,10 @@ class SearchResultsMode < ThreadIndexMode
  
    def self.spawn_from_query text
      begin
 -      qobj, extraopts = Index.parse_user_query_string(text)
 -      return unless qobj
 +      query = Index.parse_query(text)
 +      return unless query
        short_text = text.length < 20 ? text : text[0 ... 20] + "..."
 -      mode = SearchResultsMode.new qobj, extraopts
 +      mode = SearchResultsMode.new query
        BufferManager.spawn "search: \"#{short_text}\"", mode
        mode.load_threads :num => mode.buffer.content_height
      rescue Index::ParseError => e
 -- 
 1.6.0.4
 
 
 From garoth@gmail.com  Wed Jun 17 11:13:07 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Wed, 17 Jun 2009 11:13:07 -0400
 Subject: [sup-talk] Yet Another Offlineimap Thread (YAOT)
 In-Reply-To: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
 References: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
 Message-ID: <80055d7c0906170813t55bd3f7dk1286e68eea9e2ad4@mail.gmail.com>
 
 Anyway, so.
 
 I set up a loop to run offlineimap on 5 minute intervals. Now, every
 so often, sup complains that it's fallen out of sync (I have no other
 clients doing anything there, just sup and offlineimap). I can't
 imagine why this is happening. Hints?
 
 -AT
 
 From ingmar@exherbo.org  Wed Jun 17 11:29:36 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Wed, 17 Jun 2009 17:29:36 +0200
 Subject: [sup-talk] Yet Another Offlineimap Thread (YAOT)
 In-Reply-To: <80055d7c0906170813t55bd3f7dk1286e68eea9e2ad4@mail.gmail.com>
 References: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
 	<80055d7c0906170813t55bd3f7dk1286e68eea9e2ad4@mail.gmail.com>
 Message-ID: <1245252332-sup-8862@cannonball>
 
 Excerpts from Andrei Thorp's message of Wed Jun 17 17:13:07 +0200 2009:
 > Anyway, so.
 > 
 > I set up a loop to run offlineimap on 5 minute intervals. Now, every
 > so often, sup complains that it's fallen out of sync (I have no other
 > clients doing anything there, just sup and offlineimap). I can't
 > imagine why this is happening. Hints?
 > 
 > -AT
 
 Something is changing the state of your IMAP server, offlineimap is
 mirroring that, and sup notices.
 
 Are you running any other client (even using gmail.com) on your gmail
 IMAP?
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From garoth@gmail.com  Wed Jun 17 11:54:44 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Wed, 17 Jun 2009 11:54:44 -0400
 Subject: [sup-talk] Fwd:  Yet Another Offlineimap Thread (YAOT)
 In-Reply-To: <80055d7c0906170854r6ac45e83vea42a3b4866d7c2d@mail.gmail.com>
 References: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
 	<80055d7c0906170813t55bd3f7dk1286e68eea9e2ad4@mail.gmail.com>
 	<1245252332-sup-8862@cannonball>
 	<80055d7c0906170854r6ac45e83vea42a3b4866d7c2d@mail.gmail.com>
 Message-ID: <80055d7c0906170854p214520ck73e8d498f6a0ba1c@mail.gmail.com>
 
 On Wed, Jun 17, 2009 at 11:29 AM, Ingmar Vanhassel <ingmar at exherbo.org> wrote:
 >
 > Excerpts from Andrei Thorp's message of Wed Jun 17 17:13:07 +0200 2009:
 > > Anyway, so.
 > >
 > > I set up a loop to run offlineimap on 5 minute intervals. Now, every
 > > so often, sup complains that it's fallen out of sync (I have no other
 > > clients doing anything there, just sup and offlineimap). I can't
 > > imagine why this is happening. Hints?
 > >
 > > -AT
 >
 > Something is changing the state of your IMAP server, offlineimap is
 > mirroring that, and sup notices.
 >
 > Are you running any other client (even using gmail.com) on your gmail
 > IMAP?
 
 Ahh, yes, I understand. Well, if you read my original post in this
 thread, I've actually not been able to figure out how to get sup to
 send via different servers based on different situations (I'd like it
 to use different send commands for work / gmail).
 
 And yes, I've been using gmail, silly me.
 
 > ?- Does imap support a way to say which mails have been read and not?
 > I think it probably does. If this is the case, can sup-sync-back
 > somehow do this? It'd be nice if my gmail understood when a mail has
 > been read, so when I sync back up with offlineimap, it's all savvy.
 > ?- I vaguely saw some tricks here for how to reply with different
 > e-mail addresses and stuff. I'd like to execute a whole different
 > command when replying in some situations, so that my mail gets sent
 > through gmail's smtp server instead of my work's one, for example. How
 > would I achieve this?
 > ?- I don't see a daemon mode for offlineimap. I guess the expected
 > usage is to make it quiet and put it in a cron/regular script? Am I
 > correct?
 
 Cheers,
 
 -AT
 
 From wmorgan-sup@masanjin.net  Wed Jun 17 12:04:34 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 17 Jun 2009 09:04:34 -0700
 Subject: [sup-talk] display_length issue with special-characters on
 	non-UTF8 terminal
 In-Reply-To: <1244891132-sup-2424@valgus>
 References: <1244536704-sup-7027@valgus> <1244834230-sup-1200@entry>
 	<1244891132-sup-2424@valgus>
 Message-ID: <1245254636-sup-2210@entry>
 
 Reformatted excerpts from Tarko Tikan's message of 2009-06-13:
 > william wrote:
 > > Does this patch fix the issue? If so, I will release an 0.8.1.
 > 
 > Yes it does.  patch :) But I still don't have better idea how to fix
 > it so it'll have to stay like this.
 
 I have released an 0.8.1 which has this patch in it.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jun 17 12:14:56 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 17 Jun 2009 09:14:56 -0700
 Subject: [sup-talk] sup and ncursesw
 In-Reply-To: <1245074133-sup-9338@entry>
 References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
 	<1244836517-sup-5520@entry>
 	<91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com>
 	<1245074133-sup-9338@entry>
 Message-ID: <1245255253-sup-5713@entry>
 
 Reformatted excerpts from William Morgan's message of 2009-06-15:
 > (And that's typically the point where you see the difference between
 > ncurses.so with and without the patch.)
 
 BTW, it looks like the patch will not be necessary if we manage to move
 to 1.9.1:
 
   http://redmine.ruby-lang.org/issues/show/975
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From garoth@gmail.com  Wed Jun 17 12:20:30 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Wed, 17 Jun 2009 12:20:30 -0400
 Subject: [sup-talk] Yet Another Offlineimap Thread (YAOT)
 In-Reply-To: <1245254490-sup-9198@cannonball>
 References: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
 	<80055d7c0906170813t55bd3f7dk1286e68eea9e2ad4@mail.gmail.com>
 	<1245252332-sup-8862@cannonball>
 	<80055d7c0906170854r6ac45e83vea42a3b4866d7c2d@mail.gmail.com>
 	<1245254490-sup-9198@cannonball>
 Message-ID: <80055d7c0906170920p328f6a79ye7e1f40adb2a3e0e@mail.gmail.com>
 
 Forward.
 
 Excerpts from Andrei Thorp's message of Wed Jun 17 17:54:16 +0200 2009:
 > On Wed, Jun 17, 2009 at 11:29 AM, Ingmar Vanhassel <ingmar at exherbo.org> wrote:
 > >
 > > Excerpts from Andrei Thorp's message of Wed Jun 17 17:13:07 +0200 2009:
 > > > Anyway, so.
 > > >
 > > > I set up a loop to run offlineimap on 5 minute intervals. Now, every
 > > > so often, sup complains that it's fallen out of sync (I have no other
 > > > clients doing anything there, just sup and offlineimap). I can't
 > > > imagine why this is happening. Hints?
 > > >
 > > > -AT
 > >
 > > Something is changing the state of your IMAP server, offlineimap is
 > > mirroring that, and sup notices.
 > >
 > > Are you running any other client (even using gmail.com) on your gmail
 > > IMAP?
 >
 > Ahh, yes, I understand. Well, if you read my original post in this
 > thread, I've actually not been able to figure out how to get sup to
 > send via different servers based on different situations (I'd like it
 > to use different send commands for work / gmail).
 
 Yeah, I was try to be lazy ;-)
 
 For using multiple accounts, see
 http://sup.rubyforge.org/wiki/wiki.pl?MultipleAccountsAndReply
 
 I use 'msmtp --account=foo -t' myself, since msmtp was incredibly easy
 to configure.
 - Configure some defaults for all accounts (logging, tls, see `man msmtp`)
 - Write a different account section in your msmtprc, then in sup's
 ?config.yaml, configure those accounts, where the sendmail command to
 ?run has an --acount=foo parameter, corresponding to an account in your
 ?msmtprc
 
 Some people use a reply-from hook for dynamically setting from From:
 header, you may want to search the archives if that's something you'd
 like to use.
 
 --
 Exherbo KDE, X.org maintainer
 
 From garoth@gmail.com  Wed Jun 17 12:22:47 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Wed, 17 Jun 2009 12:22:47 -0400
 Subject: [sup-talk] Yet Another Offlineimap Thread (YAOT)
 In-Reply-To: <1245254490-sup-9198@cannonball>
 References: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com>
 	<80055d7c0906170813t55bd3f7dk1286e68eea9e2ad4@mail.gmail.com>
 	<1245252332-sup-8862@cannonball>
 	<80055d7c0906170854r6ac45e83vea42a3b4866d7c2d@mail.gmail.com>
 	<1245254490-sup-9198@cannonball>
 Message-ID: <80055d7c0906170922o732fc260o3a7bdd5a825ac9c8@mail.gmail.com>
 
 On Wed, Jun 17, 2009 at 12:10 PM, Ingmar Vanhassel <ingmar at exherbo.org> wrote:
 > For using multiple accounts, see
 > http://sup.rubyforge.org/wiki/wiki.pl?MultipleAccountsAndReply
 
 Perfect! So now just the one issue of sup-sync-back. I guess one
 "solution" would be for me to mark things as deleted instead of
 archived/read, and I guess sync-back understands this. I don't love
 this though. Any other suggestions?
 
 -AT
 
 From nicolas.pouillard@gmail.com  Wed Jun 17 14:34:08 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Wed, 17 Jun 2009 20:34:08 +0200
 Subject: [sup-talk] display_length issue with special-characters on
 	non-UTF8 terminal
 In-Reply-To: <1245254636-sup-2210@entry>
 References: <1244536704-sup-7027@valgus> <1244834230-sup-1200@entry>
 	<1244891132-sup-2424@valgus> <1245254636-sup-2210@entry>
 Message-ID: <1245263427-sup-997@ausone.local>
 
 Excerpts from William Morgan's message of Wed Jun 17 18:04:34 +0200 2009:
 > Reformatted excerpts from Tarko Tikan's message of 2009-06-13:
 > > william wrote:
 > > > Does this patch fix the issue? If so, I will release an 0.8.1.
 > > 
 > > Yes it does.  patch :) But I still don't have better idea how to fix
 > > it so it'll have to stay like this.
 > 
 > I have released an 0.8.1 which has this patch in it.
 
 I still have issues with display_length. I use UTF-8, urxvt
 and some characters disappear when a line contains special characters.
 
 For instance in thread-view-mode if a line contains a special character
 then the last character is dropped.
 
 I've "fixed" the issue by reverting a display_length call to a size call
 as in the attached patch.
 
 diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
 index 8eedf96..795b4c9 100644
 --- a/lib/sup/buffer.rb
 +++ b/lib/sup/buffer.rb
 @@ -114,7 +114,7 @@ class Buffer
      stringl += 1 while stringl < s.length && s[0 ... stringl].display_length < maxl
      @w.mvaddstr y, x, s[0 ... stringl]
      unless opts[:no_fill]
 -      l = s.display_length
 +      l = s.size
        unless l >= maxl
          @w.mvaddstr(y, x + l, " " * (maxl - l))
        end
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From jim@gonzul.net  Wed Jun 17 17:39:10 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Thu, 18 Jun 2009 09:39:10 +1200
 Subject: [sup-talk] Character encoding when displaying quoted-printable
 	messages
 Message-ID: <f4cc59760906171439q1b8983adw2008843b1ec02990@mail.gmail.com>
 
 Hi, I've been looking at sup for only a day, as I'm trying to find a
 decent email client. I migrated from mutt to gmail, but now it's time
 to move away from gmail because their client is not smart enough.
 
 Sup has passed my number 1 feature test; I can easily read messages
 while keeping multiple unsent messages available. Mutt does that, but
 it's not easy to see what messages you are currently working on.
 
 However, I'm coming across some character decoding issues with
 quoted-printable that are making some messages hard to read. Any
 advice on how to improve things would be welcome ... In the example
 below, a NBSP entity is showing up as the characters "M-BM-"
 
 I'm on Ubuntu 9.04, with the current master from git. Sup is running
 in GNOME Terminal 2.26.0, with UTF-8 encoding, although unsurprisingly
 switching to ISO-8859-1 makes no difference. $TERM=xterm (or 'screen'.
 vt100 and vt220 cause sup to halt at startup).  This is the text that
 gets displayed for a sample message sent from Yahoo! mail ...
 
 Visible in sup thread-view-mode:
 videos for specific hints regarding the gestures.M-BM-  Do you have a decent
 recording device?M-BM-  Have you seen what's available?M-BM-  Do you have
 editing software?
 
 Message source:
 X-Mailer: YahooMailClassic/5.4.12 YahooMailWebService/0.7.289.15
 MIME-Version: 1.0
 Content-Type: multipart/alternative; boundary="0-1465842634-1245251490=:14771"
 ...
 --0-1465842634-1245251490=:14771
 Content-Type: text/plain; charset=iso-8859-1
 Content-Transfer-Encoding: quoted-printable
 ...
 more videos for specific hints regarding the gestures.=A0 Do you have a dec=
 ent video recording device?=A0 Have you seen what's available?=A0 Do you ha=
 ve any video editing software?
 
 Displayed in Gmail client:
 I was thinking about cleaning up the videos on YouTube, and perhaps
 adding more videos for specific hints regarding the gestures.  Do you
 have a decent video recording device?  Have you seen what's available?
  Do you have any video editing software?
 
 HTML source when viewing the MIME attached message locally:
 I was thinking about cleaning up the videos on YouTube, and perhaps
 adding more videos for specific hints regarding the gestures.&nbsp; Do
 you have a decent video recording device?&nbsp; Have you seen what's
 available?&nbsp; Do you have any video editing software?<br><br>[1]
 
 From usul@aruba.it  Thu Jun 18 05:00:47 2009
 From: usul@aruba.it (Fabio Riga)
 Date: Thu, 18 Jun 2009 11:00:47 +0200
 Subject: [sup-talk] Crash after sending a message
 In-Reply-To: <1245084718-sup-1647@entry>
 References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero>
 	<1245084718-sup-1647@entry>
 Message-ID: <1245315146-sup-2575@viajero>
 
 Excerpts from William Morgan's message of lun giu 15 18:53:47 +0200 2009:
 > Sorry about that. The problem is that Sup was writing an invalid
 > sent.mbox file in certain locales, including yours, and then dying when
 > it couldn't parse its own file. If you update to the latest git, this
 > should be fixed for new messages, and you shouldn't need the LANG=C
 > hack.
 > 
 > Please let me know if you have any more problems.
 
 It seems ok with sup-git. I'd rather prefer to use a "stable" branch
 instead of bleeding-edge, I don't feel like a developer...
 
 Thank you,
 Fabio
 -- 
 Fabio Riga
 
 348 4458014 - fabio at comunicattiva.it
 
 ComunicAttiva S.a.s. di Silvana D'Agata & C.
 via Campestre,189 - Sesto San Giovanni (MI) - Italia
 tel. 02 97373202 - fax 02 97373474
 
 From bachjh@googlemail.com  Thu Jun 18 05:26:03 2009
 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=)
 Date: Thu, 18 Jun 2009 11:26:03 +0200
 Subject: [sup-talk] sup and ncursesw
 In-Reply-To: <1245255253-sup-5713@entry>
 References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com>
 	<1244836517-sup-5520@entry>
 	<91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com>
 	<1245074133-sup-9338@entry> <1245255253-sup-5713@entry>
 Message-ID: <91de50e10906180226sf31cf94m43b18c316e9f898@mail.gmail.com>
 
 2009/6/17 William Morgan <wmorgan-sup at masanjin.net>:
 > Reformatted excerpts from William Morgan's message of 2009-06-15:
 >> (And that's typically the point where you see the difference between
 >> ncurses.so with and without the patch.)
 >
 > BTW, it looks like the patch will not be necessary if we manage to move
 > to 1.9.1:
 
 The patch actually works for me now, and probably had been working all
 the time. Whatever was screwed, after I manually redrew the screen
 _twice_ after the strange chars appeared, it was all fine.
 thanks for the help,
 - JH
 
 From mariano.mara@gmail.com  Thu Jun 18 13:31:45 2009
 From: mariano.mara@gmail.com (Mariano Mara)
 Date: Thu, 18 Jun 2009 14:31:45 -0300
 Subject: [sup-talk] invalid source error
 Message-ID: <20090618173145.GA4186@kafka>
 
 Hi everyone. I have been using sup for quite some time now (great
 software by the way) and although I'm not using it as my main mail
 client I find it really useful to read several mailing lists I'm
 subscribed. 
 I downloaded a few mailman archives and after a little formatting I was
 able to import them in sup as mboxes. One of them, however had a lot of
 errors when trying sup-sync and after a few hours of troubleshooting I
 gave up and remove it (not knowing a better way, I just deleted it from
 my sources.yaml).
 But now, when I try to start sup I'm hitting 
 
 --- RuntimeError from thread: load threads for thread-index-mode
 invalid source 19
 
 Of course source 19 does not exist any more in sources.yaml and I don't
 know what else I can do to fix it.
 If you guys can give an advice I will really appreciate it.
 
 This is my current sup version:
 $ sup --version
 [Thu Jun 18 14:30:08 -0300 2009] using character set encoding "UTF-8"
 sup v0.8.1
 
 and this is the content of exception-log.txt
 
 --- RuntimeError from thread: load threads for thread-index-mode
 invalid source 19
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:403:in
 `build_message'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:399:in
 `build_message'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in
 `each_id_by_date'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `call'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in
 `load_n_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in
 `each_id_by_date'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in
 `each_id_by_date'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:326:in
 `load_n_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:620:in
 `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:604:in
 `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:71:in
 `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in
 `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in
 `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in
 `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:206
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 Mariano
 
 From guillaume.quintard@gmail.com  Fri Jun 19 07:27:50 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Fri, 19 Jun 2009 13:27:50 +0200
 Subject: [sup-talk] Carriage return
 Message-ID: <1245410627-sup-2801@altis>
 
 Sup seems to work smoothly now (no noticeable problem with the sent label, hoorray!!) (not complaining since I'm using the next branch). Now I'd like to fix one little annoying thing: in case of error, messages will use the newline, but not the carriage return, meaning mutiple lines messages will appear like this:
 yadda yadda
            yadda yadda yadda yadda
 		                          yadda yadda
 
 Is there a way to fix that?
 
 -- 
 Guillaume
 
 From mailinglist@flasht.de  Fri Jun 19 08:40:07 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Fri, 19 Jun 2009 14:40:07 +0200
 Subject: [sup-talk] Delete single message in thread-view?
 Message-ID: <1245415127-sup-2107@thinkpad-ubuntu>
 
 Hi!
 Is it possible to delete a single message from a thread?
 I haven't found a way to do this, but maybe I'm just blind.
 
 Cheers,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 
 From garoth@gmail.com  Fri Jun 19 09:51:12 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 19 Jun 2009 09:51:12 -0400
 Subject: [sup-talk] Carriage return
 In-Reply-To: <1245410627-sup-2801@altis>
 References: <1245410627-sup-2801@altis>
 Message-ID: <1245419195-sup-7199@Longbow>
 
 I'm not sure that this is carriage return related (Linux doesn't tend to
 use these, right?). However, I'm certainly getting similar corruption.
 
 This happens with errors, as well as just randomly sometimes after sup
 closes/does something. My entire terminal actaully goes out of whack
 and starts behaving like this.
 
 I acutally just blamed it on my terminal being buggy somehow
 (XFCE Terminal). I still think that's probably it. I'm not sure why sup
 causes it though.
 
 Anyway, reset fixes it when that happens. But yeah.... but yeah.
 
 Cheers :)
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 Resisting temptation is easier when you think you'll probably get
 another chance later on.
 
 From joe@talkhouse.com  Fri Jun 19 12:23:23 2009
 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=)
 Date: Fri, 19 Jun 2009 12:23:23 -0400
 Subject: [sup-talk] [PATCH] Hack that fixes "undefined method multipart?"
 	exception.
 Message-ID: <1245428166-sup-5693@joe-wolfels-power-mac-g5.local>
 
 On sup-sync -c I kept getting an exception on line 372 of message.rb in the
 message_to_chunks function.  The cause was that 'm' was supposed to be a
 message that needed to be converted to chunks.  Instead, it was
 aRedwood::Chunk::CryptoNotice, which didn't have a mulitipart? method.  So it
 crashed on "if m.multipart?".  My assumption is that a
 Redwood::Chunk::CryptoNotice is already a chunk and doesn't need to be
 converted.  So my solution is just to return it.  That fixes the bug.  But
 probably there is a more sensible fix.  Possibly m should never have been a
 chunk in the first place.
 ---
  lib/sup/message.rb |    5 +++++
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index ded577a..caf0cdb 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -369,6 +369,11 @@ private
  
    ## takes a RMail::Message, breaks it into Chunk:: classes.
    def message_to_chunks m, encrypted=false, sibling_types=[]
 +    ## TODO: Replace the following four lines with something more sensible.
 +    unless m.respond_to? :multipart?
 +      puts "I bet this is a Redwood::Chunk::CryptoNotice: \n#{m.class}"
 +      return m
 +    end
      if m.multipart?
        chunks =
          case m.header.content_type
 -- 
 1.6.2.1
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:49:59 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:49:59 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 Message-ID: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 
 This patch series refactors the Index class to remove Ferret-isms and support
 multiple index implementations. The included XapianIndex is a bit faster at
 indexing messages and significantly faster when searching because it
 precomputes thread membership. It also works on Ruby 1.9.1.
 
 You can enable the new index with the environment variable SUP_INDEX=xapian.
 
 It's missing a couple of features, notably threading by subject. I'm sure there
 are many more bugs left, so I'd appreciate any testing or review you all can
 provide.
 
 These patches depend on the two I posted June 16: 'cleanup interface' and 'consistent naming'.
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:00 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:00 -0700
 Subject: [sup-talk] [PATCH 01/18] remove load_entry_for_id call in
 	sup-recover-sources
 In-Reply-To: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup-recover-sources |   12 +++++-------
  lib/sup/index.rb        |    6 ++++++
  2 files changed, 11 insertions(+), 7 deletions(-)
 
 diff --git a/bin/sup-recover-sources b/bin/sup-recover-sources
 index d3b1424..6e3810c 100755
 --- a/bin/sup-recover-sources
 +++ b/bin/sup-recover-sources
 @@ -69,15 +69,14 @@ ARGV.each do |fn|
        Redwood::MBox::Loader.new(fn, nil, !$opts[:unusual], $opts[:archive])
      end
  
 -  source_ids = {}
 +  source_ids = Hash.new 0
    count = 0
    source.each do |offset, labels|
      m = Redwood::Message.new :source => source, :source_info => offset
 -    docid, entry = index.load_entry_for_id m.id
 -    next unless entry
 -    #puts "# #{source} #{offset} #{entry[:source_id]}"
 -
 -    source_ids[entry[:source_id]] = (source_ids[entry[:source_id]] || 0) + 1
 +    m.load_from_source!
 +    source_id = index.source_for_id m.id
 +    next unless source_id
 +    source_ids[source_id] += 1
      count += 1
      break if count == $opts[:scan_num]
    end
 @@ -86,7 +85,6 @@ ARGV.each do |fn|
      id = source_ids.keys.first.to_i
      puts "assigned #{source} to #{source_ids.keys.first}"
      source.id = id
 -    source.seek_to! source.total
      index.add_source source
    else
      puts ">> unable to determine #{source}: #{source_ids.inspect}"
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index d15e7bb..b5d0e5d 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -494,6 +494,12 @@ EOS
      @index_mutex.synchronize { @index.optimize }
    end
  
 +  def source_for_id id
 +    entry = @index[id]
 +    return unless entry
 +    entry[:source_id].to_i
 +  end
 +
    class ParseError < StandardError; end
  
    ## parse a query string from the user. returns a query object
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:01 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:01 -0700
 Subject: [sup-talk] [PATCH 02/18] remove load_entry_for_id call in
 	DraftManager.discard
 In-Reply-To: <1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/draft.rb |    9 ++-------
  1 files changed, 2 insertions(+), 7 deletions(-)
 
 diff --git a/lib/sup/draft.rb b/lib/sup/draft.rb
 index 9127739..1233945 100644
 --- a/lib/sup/draft.rb
 +++ b/lib/sup/draft.rb
 @@ -31,14 +31,9 @@ class DraftManager
    end
  
    def discard m
 -    docid, entry = Index.load_entry_for_id m.id
 -    unless entry
 -      Redwood::log "can't find entry for draft: #{m.id.inspect}. You probably already discarded it."
 -      return
 -    end
 -    raise ArgumentError, "not a draft: source id #{entry[:source_id].inspect}, should be #{DraftManager.source_id.inspect} for #{m.id.inspect} / docno #{docid}" unless entry[:source_id].to_i == DraftManager.source_id
 +    raise ArgumentError, "not a draft: source id #{m.source.id.inspect}, should be #{DraftManager.source_id.inspect} for #{m.id.inspect}" unless m.source.id.to_i == DraftManager.source_id
      Index.delete m.id
 -    File.delete @source.fn_for_offset(entry[:source_info])
 +    File.delete @source.fn_for_offset(m.source_info)
      UpdateManager.relay self, :single_message_deleted, m
    end
  end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:02 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:02 -0700
 Subject: [sup-talk] [PATCH 03/18] remove ferret entry from poll/sync
 	interface
 In-Reply-To: <1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 
 This leads to an extra index lookup in the sup-sync update path, but I think
 it's worth it for the sake of API simplicity.
 ---
  bin/sup-sync       |    8 ++++----
  bin/sup-sync-back  |    6 +++---
  lib/sup/index.rb   |   18 ++++--------------
  lib/sup/message.rb |    6 ++++++
  lib/sup/poll.rb    |   33 ++++++++++++++-------------------
  lib/sup/sent.rb    |    2 +-
  6 files changed, 32 insertions(+), 41 deletions(-)
 
 diff --git a/bin/sup-sync b/bin/sup-sync
 index a759cbe..18a3cab 100755
 --- a/bin/sup-sync
 +++ b/bin/sup-sync
 @@ -137,7 +137,7 @@ begin
      num_added = num_updated = num_scanned = num_restored = 0
      last_info_time = start_time = Time.now
  
 -    Redwood::PollManager.add_messages_from source, :force_overwrite => true do |m, offset, entry|
 +    Redwood::PollManager.add_messages_from source, :force_overwrite => true do |m_old, m, offset|
        num_scanned += 1
        seen[m.id] = true
  
 @@ -153,10 +153,10 @@ begin
        ## skip if we're operating only on changed messages, the message
        ## is in the index, and it's unchanged from what the source is
        ## reporting.
 -      next if target == :changed && entry && entry[:source_id].to_i == source.id && entry[:source_info].to_i == offset
 +      next if target == :changed && m_old && m_old.source.id == source.id && m_old.source_info == offset
  
        ## get the state currently in the index
 -      index_state = entry[:label].symbolistize if entry
 +      index_state = m_old.labels.dup if m_old
  
        ## skip if we're operating on restored messages, and this one
        ## ain't.
 @@ -196,7 +196,7 @@ begin
          puts "Adding message #{source}##{offset} from #{m.from} with state {#{m.labels * ', '}}" if opts[:verbose]
          num_added += 1
        else
 -        puts "Updating message #{source}##{offset}, source #{entry[:source_id]} => #{source.id}, offset #{entry[:source_info]} => #{offset}, state {#{index_state * ', '}} => {#{m.labels * ', '}}" if opts[:verbose]
 +        puts "Updating message #{source}##{offset}, source #{m_old.source.id} => #{source.id}, offset #{m_old.source_info} => #{offset}, state {#{index_state * ', '}} => {#{m.labels * ', '}}" if opts[:verbose]
          num_updated += 1
        end
  
 diff --git a/bin/sup-sync-back b/bin/sup-sync-back
 index 4f1387e..1c746d2 100755
 --- a/bin/sup-sync-back
 +++ b/bin/sup-sync-back
 @@ -105,11 +105,11 @@ EOS
      num_dropped = num_moved = num_scanned = 0
      
      out_fp = Tempfile.new "sup-sync-back-#{source.id}"
 -    Redwood::PollManager.add_messages_from source do |m, offset, entry|
 +    Redwood::PollManager.add_messages_from source do |m_old, m, offset|
        num_scanned += 1
  
 -      if entry
 -        labels = entry[:label].symbolistize.to_boolean_h
 +      if m_old
 +        labels = m_old.labels
  
          if labels.member? :deleted
            if opts[:drop_deleted]
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index b5d0e5d..89795da 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -174,16 +174,10 @@ EOS
    ## Syncs the message to the index, replacing any previous version.  adding
    ## either way. Index state will be determined by the message's #labels
    ## accessor.
 -  ##
 -  ## if need_load is false, docid and entry are assumed to be set to the
 -  ## result of load_entry_for_id (which can be nil).
 -  def sync_message m, need_load=true, docid=nil, entry=nil, opts={}
 -    docid, entry = load_entry_for_id m.id if need_load
 +  def sync_message m, opts={}
 +    entry = @index[m.id]
  
      raise "no source info for message #{m.id}" unless m.source && m.source_info
 -    @index_mutex.synchronize do
 -      raise "trying to delete non-corresponding entry #{docid} with index message-id #{@index[docid][:message_id].inspect} and parameter message id #{m.id.inspect}" if docid && @index[docid][:message_id] != m.id
 -    end
  
      source_id = if m.source.is_a? Integer
        m.source
 @@ -256,13 +250,9 @@ EOS
      }
  
      @index_mutex.synchronize do
 -      @index.delete docid if docid
 +      @index.delete m.id
        @index.add_document d
      end
 -
 -    ## this hasn't been triggered in a long time.
 -    ## docid, entry = load_entry_for_id m.id
 -    ## raise "just added message #{m.id.inspect} but couldn't find it in a search" unless docid
    end
  
    def save_index fn=File.join(@dir, "ferret")
 @@ -391,7 +381,7 @@ EOS
    ## builds a message object from a ferret result
    def build_message docid
      @index_mutex.synchronize do
 -      doc = @index[docid]
 +      doc = @index[docid] or return
  
        source = @source_mutex.synchronize { @sources[doc[:source_id].to_i] }
        raise "invalid source #{doc[:source_id]}" unless source
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 8525fdf..b667cb3 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -288,6 +288,12 @@ EOS
         "Subject: #{@subj}"]
    end
  
 +  def self.build_from_source source, source_info
 +    m = Message.new :source => source, :source_info => source_info
 +    m.load_from_source!
 +    m
 +  end
 +
  private
  
    ## here's where we handle decoding mime attachments. unfortunately
 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
 index 74f7d1c..bbad5f2 100644
 --- a/lib/sup/poll.rb
 +++ b/lib/sup/poll.rb
 @@ -95,11 +95,11 @@ EOS
  
          num = 0
          numi = 0
 -        add_messages_from source do |m, offset, entry|
 +        add_messages_from source do |m_old, m, offset|
            ## always preserve the labels on disk.
 -          m.labels = ((m.labels - [:unread, :inbox]) + entry[:label].symbolistize).uniq if entry
 +          m.labels = ((m.labels - [:unread, :inbox]) + m_old.labels).uniq if m_old
            yield "Found message at #{offset} with labels {#{m.labels * ', '}}"
 -          unless entry
 +          unless m_old
              num += 1
              from_and_subj << [m.from && m.from.longname, m.subj]
              if m.has_label?(:inbox) && ([:spam, :deleted, :killed] & m.labels).empty?
 @@ -138,29 +138,24 @@ EOS
      begin
        return if source.done? || source.has_errors?
  
 -      source.each do |offset, labels|
 +      source.each do |offset, default_labels|
          if source.has_errors?
            Redwood::log "error loading messages from #{source}: #{source.error.message}"
            return
          end
  
 -        labels << :sent if source.uri.eql?(SentManager.source_uri)
 -        labels.each { |l| LabelManager << l }
 -        labels = labels + (source.archived? ? [] : [:inbox])
 +        m_new = Message.build_from_source source, offset
 +        m_old = Index.build_message m_new.id
  
 -        m = Message.new :source => source, :source_info => offset, :labels => labels
 -        m.load_from_source!
 +        m_new.labels = default_labels + (source.archived? ? [] : [:inbox])
 +        m_new.labels << :sent if source.uri.eql?(SentManager.source_uri)
 +        m_new.labels.delete :unread if m_new.source_marked_read?
 +        m_new.labels.each { |l| LabelManager << l }
  
 -        if m.source_marked_read?
 -          m.remove_label :unread
 -          labels.delete :unread
 -        end
 -
 -        docid, entry = Index.load_entry_for_id m.id
 -        HookManager.run "before-add-message", :message => m
 -        m = yield(m, offset, entry) or next if block_given?
 -        times = Index.sync_message m, false, docid, entry, opts
 -        UpdateManager.relay self, :added, m unless entry
 +        HookManager.run "before-add-message", :message => m_new
 +        m_ret = yield(m_old, m_new, offset) or next if block_given?
 +        Index.sync_message m_ret, opts
 +        UpdateManager.relay self, :added, m_ret unless m_old
        end
      rescue SourceError => e
        Redwood::log "problem getting messages from #{source}: #{e.message}"
 diff --git a/lib/sup/sent.rb b/lib/sup/sent.rb
 index e6ae856..b750d71 100644
 --- a/lib/sup/sent.rb
 +++ b/lib/sup/sent.rb
 @@ -30,7 +30,7 @@ class SentManager
    def write_sent_message date, from_email, &block
      @source.store_message date, from_email, &block
  
 -    PollManager.add_messages_from(@source) do |m, o, e|
 +    PollManager.add_messages_from(@source) do |m_old, m, offset|
        m.remove_label :unread
        m
      end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:03 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:03 -0700
 Subject: [sup-talk] [PATCH 04/18] index: remove unused method
 	load_entry_for_id
 In-Reply-To: <1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/index.rb |   11 -----------
  1 files changed, 0 insertions(+), 11 deletions(-)
 
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 89795da..64afbdd 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -411,17 +411,6 @@ EOS
  
    def delete id; @index_mutex.synchronize { @index.delete id } end
  
 -  def load_entry_for_id mid
 -    @index_mutex.synchronize do
 -      results = @index.search Ferret::Search::TermQuery.new(:message_id, mid)
 -      return if results.total_hits == 0
 -      docid = results.hits[0].doc
 -      entry = @index[docid]
 -      entry_dup = entry.fields.inject({}) { |h, f| h[f] = entry[f]; h }
 -      [docid, entry_dup]
 -    end
 -  end
 -
    def load_contacts emails, h={}
      q = Ferret::Search::BooleanQuery.new true
      emails.each do |e|
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:04 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:04 -0700
 Subject: [sup-talk] [PATCH 05/18] switch DraftManager to use
 	Message.build_from_source
 In-Reply-To: <1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/draft.rb |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/draft.rb b/lib/sup/draft.rb
 index 1233945..dd4574d 100644
 --- a/lib/sup/draft.rb
 +++ b/lib/sup/draft.rb
 @@ -21,7 +21,8 @@ class DraftManager
  
      my_message = nil
      @source.each do |thisoffset, theselabels|
 -      m = Message.new :source => @source, :source_info => thisoffset, :labels => theselabels
 +      m = Message.build_from_source @source, thisoffset
 +      m.labels = theselabels
        Index.sync_message m
        UpdateManager.relay self, :added, m
        my_message = m if thisoffset == offset
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:06 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:06 -0700
 Subject: [sup-talk] [PATCH 07/18] move source-related methods to
 	SourceManager
 In-Reply-To: <1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup                 |   10 ++++----
  bin/sup-add             |   10 ++++----
  bin/sup-config          |   14 +++++-----
  bin/sup-recover-sources |    7 +++--
  bin/sup-sync            |    6 ++--
  bin/sup-sync-back       |    4 +-
  bin/sup-tweak-labels    |    4 +-
  lib/sup.rb              |    5 ++-
  lib/sup/index.rb        |   52 ++----------------------------------------
  lib/sup/poll.rb         |    2 +-
  lib/sup/source.rb       |   57 +++++++++++++++++++++++++++++++++++++++++++++++
  11 files changed, 92 insertions(+), 79 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 302ad7c..1febefd 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -160,17 +160,17 @@ begin
    Redwood::start
    Index.load
  
 -  if(s = Index.source_for DraftManager.source_name)
 +  if(s = Redwood::SourceManager.source_for DraftManager.source_name)
      DraftManager.source = s
    else
      Redwood::log "no draft source, auto-adding..."
 -    Index.add_source DraftManager.new_source
 +    Redwood::SourceManager.add_source DraftManager.new_source
    end
  
 -  if(s = Index.source_for SentManager.source_uri)
 +  if(s = Redwood::SourceManager.source_for SentManager.source_uri)
      SentManager.source = s
    else
 -    Index.add_source SentManager.default_source
 +    Redwood::SourceManager.add_source SentManager.default_source
    end
  
    HookManager.run "startup"
 @@ -190,7 +190,7 @@ begin
  
    bm.draw_screen
  
 -  Index.usual_sources.each do |s|
 +  Redwood::SourceManager.usual_sources.each do |s|
      next unless s.respond_to? :connect
      reporting_thread("call #connect on #{s}") do
        begin
 diff --git a/bin/sup-add b/bin/sup-add
 index 50bbb29..c491ca7 100755
 --- a/bin/sup-add
 +++ b/bin/sup-add
 @@ -82,12 +82,12 @@ index = Redwood::Index.new
  index.lock_or_die
  
  begin
 -  index.load_sources
 +  Redwood::SourceManager.load_sources
  
    ARGV.each do |uri|
      labels = $opts[:labels] ? $opts[:labels].split(/\s*,\s*/).uniq : []
  
 -    if !$opts[:force_new] && index.source_for(uri) 
 +    if !$opts[:force_new] && Redwood::SourceManager.source_for(uri) 
        say "Already know about #{uri}; skipping."
        next
      end
 @@ -99,10 +99,10 @@ begin
        when "mbox+ssh"
          say "For SSH connections, if you will use public key authentication, you may leave the username and password blank."
          say ""
 -        username, password = get_login_info uri, index.sources
 +        username, password = get_login_info uri, Redwood::SourceManager.sources
          Redwood::MBox::SSHLoader.new uri, username, password, nil, !$opts[:unusual], $opts[:archive], nil, labels
        when "imap", "imaps"
 -        username, password = get_login_info uri, index.sources
 +        username, password = get_login_info uri, Redwood::SourceManager.sources
          Redwood::IMAP.new uri, username, password, nil, !$opts[:unusual], $opts[:archive], nil, labels
        when "maildir"
          Redwood::Maildir.new uri, nil, !$opts[:unusual], $opts[:archive], nil, labels
 @@ -114,7 +114,7 @@ begin
          Trollop::die "Unknown source type #{parsed_uri.scheme.inspect}"      
        end
      say "Adding #{source}..."
 -    index.add_source source
 +    Redwood::SourceManager.add_source source
    end
  ensure
    index.save
 diff --git a/bin/sup-config b/bin/sup-config
 index 398197f..9fcbee6 100755
 --- a/bin/sup-config
 +++ b/bin/sup-config
 @@ -152,7 +152,7 @@ end
  $terminal.wrap_at = :auto
  Redwood::start
  index = Redwood::Index.new
 -index.load_sources
 +Redwood::SourceManager.load_sources
  
  say <<EOS
  Howdy neighbor! This here's sup-config, ready to help you jack in to
 @@ -191,12 +191,12 @@ $config[:editor] = editor
  done = false
  until done
    say "\nNow, we'll tell Sup where to find all your email."
 -  index.load_sources
 +  Redwood::SourceManager.load_sources
    say "Current sources:"
 -  if index.sources.empty?
 +  if Redwood::SourceManager.sources.empty?
      say "  No sources!"
    else
 -    index.sources.each { |s| puts "* #{s}" }
 +    Redwood::SourceManager.sources.each { |s| puts "* #{s}" }
    end
  
    say "\n"
 @@ -210,8 +210,8 @@ end
  say "\nSup needs to know where to store your sent messages."
  say "Only sources capable of storing mail will be listed.\n\n"
  
 -index.load_sources
 -if index.sources.empty?
 +Redwood::SourceManager.load_sources
 +if Redwood::SourceManager.sources.empty?
    say "\nUsing the default sup://sent, since you haven't configured other sources yet."
    $config[:sent_source] = 'sup://sent'
  else
 @@ -222,7 +222,7 @@ else
    choose do |menu|
      menu.prompt = "Store my sent mail in? "
  
 -    valid_sents = index.sources.each do |s|
 +    valid_sents = Redwood::SourceManager.sources.each do |s|
        have_sup_sent = true if s.to_s.eql?('sup://sent')
  
        menu.choice(s.to_s) { $config[:sent_source] = s.to_s } if s.respond_to? :store_message
 diff --git a/bin/sup-recover-sources b/bin/sup-recover-sources
 index 6e3810c..db75b11 100755
 --- a/bin/sup-recover-sources
 +++ b/bin/sup-recover-sources
 @@ -48,13 +48,14 @@ EOS
  end.parse(ARGV)
  
  require "sup"
 +Redwood::start
  puts "loading index..."
  index = Redwood::Index.new
  index.load
  puts "loaded index of #{index.size} messages"
  
  ARGV.each do |fn|
 -  next if index.source_for fn
 +  next if Redwood::SourceManager.source_for fn
  
    ## TODO: merge this code with the same snippet in import
    source = 
 @@ -74,7 +75,7 @@ ARGV.each do |fn|
    source.each do |offset, labels|
      m = Redwood::Message.new :source => source, :source_info => offset
      m.load_from_source!
 -    source_id = index.source_for_id m.id
 +    source_id = Redwood::SourceManager.source_for_id m.id
      next unless source_id
      source_ids[source_id] += 1
      count += 1
 @@ -85,7 +86,7 @@ ARGV.each do |fn|
      id = source_ids.keys.first.to_i
      puts "assigned #{source} to #{source_ids.keys.first}"
      source.id = id
 -    index.add_source source
 +    Redwood::SourceManager.add_source source
    else
      puts ">> unable to determine #{source}: #{source_ids.inspect}"
    end
 diff --git a/bin/sup-sync b/bin/sup-sync
 index 18a3cab..270524a 100755
 --- a/bin/sup-sync
 +++ b/bin/sup-sync
 @@ -116,11 +116,11 @@ begin
    index.load
  
    sources = ARGV.map do |uri|
 -    index.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
 +    Redwood::SourceManager.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
    end
    
 -  sources = index.usual_sources if sources.empty?
 -  sources = index.sources if opts[:all_sources]
 +  sources = Redwood::SourceManager.usual_sources if sources.empty?
 +  sources = Redwood::SourceManager.sources if opts[:all_sources]
  
    unless target == :new
      if opts[:start_at]
 diff --git a/bin/sup-sync-back b/bin/sup-sync-back
 index 05b9e8c..679e03a 100755
 --- a/bin/sup-sync-back
 +++ b/bin/sup-sync-back
 @@ -80,13 +80,13 @@ begin
    index.load
  
    sources = ARGV.map do |uri|
 -    s = index.source_for(uri) or die "unknown source: #{uri}. Did you add it with sup-add first?"
 +    s = Redwood::SourceManager.source_for(uri) or die "unknown source: #{uri}. Did you add it with sup-add first?"
      s.is_a?(Redwood::MBox::Loader) or die "#{uri} is not an mbox source."
      s
    end
  
    if sources.empty?
 -    sources = index.usual_sources.select { |s| s.is_a? Redwood::MBox::Loader } 
 +    sources = Redwood::SourceManager.usual_sources.select { |s| s.is_a? Redwood::MBox::Loader } 
    end
  
    unless sources.all? { |s| s.file_path.nil? } || File.executable?(dotlockfile) || opts[:dont_use_dotlockfile]
 diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
 index 6f603e2..95a3b03 100755
 --- a/bin/sup-tweak-labels
 +++ b/bin/sup-tweak-labels
 @@ -66,10 +66,10 @@ begin
  
    source_ids = 
      if opts[:all_sources]
 -      index.sources
 +      Redwood::SourceManager.sources
      else
        ARGV.map do |uri|
 -        index.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
 +        Redwood::SourceManager.source_for uri or Trollop::die "Unknown source: #{uri}. Did you add it with sup-add first?"
        end
    end.map { |s| s.id }
    Trollop::die "nothing to do: no sources" if source_ids.empty?
 diff --git a/lib/sup.rb b/lib/sup.rb
 index 8373820..5689c2b 100644
 --- a/lib/sup.rb
 +++ b/lib/sup.rb
 @@ -115,6 +115,7 @@ module Redwood
      Redwood::SuicideManager.new Redwood::SUICIDE_FN
      Redwood::CryptoManager.new
      Redwood::UndoManager.new
 +    Redwood::SourceManager.new
    end
  
    def finish
 @@ -130,7 +131,7 @@ module Redwood
    def report_broken_sources opts={}
      return unless BufferManager.instantiated?
  
 -    broken_sources = Index.sources.select { |s| s.error.is_a? FatalSourceError }
 +    broken_sources = SourceManager.sources.select { |s| s.error.is_a? FatalSourceError }
      unless broken_sources.empty?
        BufferManager.spawn_unless_exists("Broken source notification for #{broken_sources.join(',')}", opts) do
          TextMode.new(<<EOM)
 @@ -147,7 +148,7 @@ EOM
        end
      end
  
 -    desynced_sources = Index.sources.select { |s| s.error.is_a? OutOfSyncSourceError }
 +    desynced_sources = SourceManager.sources.select { |s| s.error.is_a? OutOfSyncSourceError }
      unless desynced_sources.empty?
        BufferManager.spawn_unless_exists("Out-of-sync source notification for #{broken_sources.join(',')}", opts) do
          TextMode.new(<<EOM)
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index b9f4b36..7d6258d 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -26,11 +26,7 @@ class Index
  
    def initialize dir=BASE_DIR
      @index_mutex = Monitor.new
 -
      @dir = dir
 -    @sources = {}
 -    @sources_dirty = false
 -    @source_mutex = Monitor.new
  
      wsa = Ferret::Analysis::WhiteSpaceAnalyzer.new false
      sa = Ferret::Analysis::StandardAnalyzer.new [], true
 @@ -112,36 +108,17 @@ EOS
    end
  
    def load
 -    load_sources
 +    SourceManager.load_sources
      load_index
    end
  
    def save
      Redwood::log "saving index and sources..."
      FileUtils.mkdir_p @dir unless File.exists? @dir
 -    save_sources
 +    SourceManager.save_sources
      save_index
    end
  
 -  def add_source source
 -    @source_mutex.synchronize do
 -      raise "duplicate source!" if @sources.include? source
 -      @sources_dirty = true
 -      max = @sources.max_of { |id, s| s.is_a?(DraftLoader) || s.is_a?(SentLoader) ? 0 : id }
 -      source.id ||= (max || 0) + 1
 -      ##source.id += 1 while @sources.member? source.id
 -      @sources[source.id] = source
 -    end
 -  end
 -
 -  def sources
 -    ## favour the inbox by listing non-archived sources first
 -    @source_mutex.synchronize { @sources.values }.sort_by { |s| s.id }.partition { |s| !s.archived? }.flatten
 -  end
 -
 -  def source_for uri; sources.find { |s| s.is_source_for? uri }; end
 -  def usual_sources; sources.find_all { |s| s.usual? }; end
 -
    def load_index dir=File.join(@dir, "ferret")
      if File.exists? dir
        Redwood::log "loading index..."
 @@ -383,7 +360,7 @@ EOS
      @index_mutex.synchronize do
        doc = @index[docid] or return
  
 -      source = @source_mutex.synchronize { @sources[doc[:source_id].to_i] }
 +      source = SourceManager[doc[:source_id].to_i]
        raise "invalid source #{doc[:source_id]}" unless source
  
        #puts "building message #{doc[:message_id]} (#{source}##{doc[:source_info]})"
 @@ -442,14 +419,6 @@ EOS
      contacts.keys.compact
    end
  
 -  def load_sources fn=Redwood::SOURCE_FN
 -    source_array = (Redwood::load_yaml_obj(fn) || []).map { |o| Recoverable.new o }
 -    @source_mutex.synchronize do
 -      @sources = Hash[*(source_array).map { |s| [s.id, s] }.flatten]
 -      @sources_dirty = false
 -    end
 -  end
 -
    def each_docid query={}
      ferret_query = build_ferret_query query
      results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
 @@ -604,21 +573,6 @@ private
      q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
      q
    end
 -
 -  def save_sources fn=Redwood::SOURCE_FN
 -    @source_mutex.synchronize do
 -      if @sources_dirty || @sources.any? { |id, s| s.dirty? }
 -        bakfn = fn + ".bak"
 -        if File.exists? fn
 -          File.chmod 0600, fn
 -          FileUtils.mv fn, bakfn, :force => true unless File.exists?(bakfn) && File.size(fn) == 0
 -        end
 -        Redwood::save_yaml_obj sources.sort_by { |s| s.id.to_i }, fn, true
 -        File.chmod 0600, fn
 -      end
 -      @sources_dirty = false
 -    end
 -  end
  end
  
  end
 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
 index bbad5f2..c83290c 100644
 --- a/lib/sup/poll.rb
 +++ b/lib/sup/poll.rb
 @@ -83,7 +83,7 @@ EOS
      from_and_subj_inbox = []
  
      @mutex.synchronize do
 -      Index.usual_sources.each do |source|
 +      SourceManager.usual_sources.each do |source|
  #        yield "source #{source} is done? #{source.done?} (cur_offset #{source.cur_offset} >= #{source.end_offset})"
          begin
            yield "Loading from #{source}... " unless source.done? || (source.respond_to?(:has_errors?) && source.has_errors?)
 diff --git a/lib/sup/source.rb b/lib/sup/source.rb
 index fb98dbc..1bb7797 100644
 --- a/lib/sup/source.rb
 +++ b/lib/sup/source.rb
 @@ -155,4 +155,61 @@ protected
    end
  end
  
 +class SourceManager
 +  include Singleton
 +
 +  def initialize
 +    @sources = {}
 +    @sources_dirty = false
 +    @source_mutex = Monitor.new
 +    self.class.i_am_the_instance self
 +  end
 +
 +  def [](id)
 +    @source_mutex.synchronize { @sources[id] }
 +  end
 +
 +  def add_source source
 +    @source_mutex.synchronize do
 +      raise "duplicate source!" if @sources.include? source
 +      @sources_dirty = true
 +      max = @sources.max_of { |id, s| s.is_a?(DraftLoader) || s.is_a?(SentLoader) ? 0 : id }
 +      source.id ||= (max || 0) + 1
 +      ##source.id += 1 while @sources.member? source.id
 +      @sources[source.id] = source
 +    end
 +  end
 +
 +  def sources
 +    ## favour the inbox by listing non-archived sources first
 +    @source_mutex.synchronize { @sources.values }.sort_by { |s| s.id }.partition { |s| !s.archived? }.flatten
 +  end
 +
 +  def source_for uri; sources.find { |s| s.is_source_for? uri }; end
 +  def usual_sources; sources.find_all { |s| s.usual? }; end
 +
 +  def load_sources fn=Redwood::SOURCE_FN
 +    source_array = (Redwood::load_yaml_obj(fn) || []).map { |o| Recoverable.new o }
 +    @source_mutex.synchronize do
 +      @sources = Hash[*(source_array).map { |s| [s.id, s] }.flatten]
 +      @sources_dirty = false
 +    end
 +  end
 +
 +  def save_sources fn=Redwood::SOURCE_FN
 +    @source_mutex.synchronize do
 +      if @sources_dirty || @sources.any? { |id, s| s.dirty? }
 +        bakfn = fn + ".bak"
 +        if File.exists? fn
 +          File.chmod 0600, fn
 +          FileUtils.mv fn, bakfn, :force => true unless File.exists?(bakfn) && File.size(fn) == 0
 +        end
 +        Redwood::save_yaml_obj sources.sort_by { |s| s.id.to_i }, fn, true
 +        File.chmod 0600, fn
 +      end
 +      @sources_dirty = false
 +    end
 +  end
 +end
 +
  end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:05 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:05 -0700
 Subject: [sup-talk] [PATCH 06/18] index: move
 	has_any_from_source_with_label? to sup-sync-back
 In-Reply-To: <1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup-sync-back |    7 ++++++-
  lib/sup/index.rb  |    7 -------
  2 files changed, 6 insertions(+), 8 deletions(-)
 
 diff --git a/bin/sup-sync-back b/bin/sup-sync-back
 index 1c746d2..05b9e8c 100755
 --- a/bin/sup-sync-back
 +++ b/bin/sup-sync-back
 @@ -4,6 +4,7 @@ require 'rubygems'
  require 'uri'
  require 'tempfile'
  require 'trollop'
 +require 'enumerator'
  require "sup"
  
  ## save a message 'm' to an open file pointer 'fp'
 @@ -14,6 +15,10 @@ def die msg
    $stderr.puts "Error: #{msg}"
    exit(-1)
  end
 +def has_any_from_source_with_label? index, source, label
 +  query = { :source_id => source.id, :label => label, :limit => 1 }
 +  not Enumerable::Enumerator.new(index, :each_docid, query).map.empty?
 +end
  
  opts = Trollop::options do
    version "sup-sync-back (sup #{Redwood::VERSION})"
 @@ -96,7 +101,7 @@ EOS
    sources.each do |source|
      $stderr.puts "Scanning #{source}..."
  
 -    unless ((opts[:drop_deleted] || opts[:move_deleted]) && index.has_any_from_source_with_label?(source, :deleted)) || ((opts[:drop_spam] || opts[:move_spam]) && index.has_any_from_source_with_label?(source, :spam))
 +    unless ((opts[:drop_deleted] || opts[:move_deleted]) && has_any_from_source_with_label?(index, source, :deleted)) || ((opts[:drop_spam] || opts[:move_spam]) && has_any_from_source_with_label?(index, source, :spam))
        $stderr.puts "Nothing to do from this source; skipping"
        next
      end
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 64afbdd..b9f4b36 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -450,13 +450,6 @@ EOS
      end
    end
  
 -  def has_any_from_source_with_label? source, label
 -    q = Ferret::Search::BooleanQuery.new
 -    q.add_query Ferret::Search::TermQuery.new("source_id", source.id.to_s), :must
 -    q.add_query Ferret::Search::TermQuery.new("label", label.to_s), :must
 -    @index_mutex.synchronize { @index.search(q, :limit => 1).total_hits > 0 }
 -  end
 -
    def each_docid query={}
      ferret_query = build_ferret_query query
      results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:07 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:07 -0700
 Subject: [sup-talk] [PATCH 08/18] index: remove unused method fresh_thread_id
 In-Reply-To: <1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/index.rb |    1 -
  1 files changed, 0 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 7d6258d..e3f9e69 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -382,7 +382,6 @@ EOS
      end
    end
  
 -  def fresh_thread_id; @next_thread_id += 1; end
    def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
    def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
  
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:09 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:09 -0700
 Subject: [sup-talk] [PATCH 10/18] index: make wrap_subj methods private
 In-Reply-To: <1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/index.rb |    6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 080a4ec..5ddd6ee 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -382,9 +382,6 @@ EOS
      end
    end
  
 -  def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
 -  def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
 -
    def delete id; @index_mutex.synchronize { @index.delete id } end
  
    def load_contacts emails, h={}
 @@ -572,6 +569,9 @@ private
      q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
      q
    end
 +
 +  def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
 +  def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
  end
  
  end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:10 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:10 -0700
 Subject: [sup-talk] [PATCH 11/18] index: move Ferret-specific code to
 	ferret_index.rb
 In-Reply-To: <1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/ferret_index.rb |  463 +++++++++++++++++++++++++++++++++++++++++++++++
  lib/sup/index.rb        |  453 +++++-----------------------------------------
  2 files changed, 509 insertions(+), 407 deletions(-)
  create mode 100644 lib/sup/ferret_index.rb
 
 diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
 new file mode 100644
 index 0000000..53c19e0
 --- /dev/null
 +++ b/lib/sup/ferret_index.rb
 @@ -0,0 +1,463 @@
 +require 'ferret'
 +
 +module Redwood
 +
 +class FerretIndex < BaseIndex
 +
 +  def initialize dir=BASE_DIR
 +    super
 +
 +    @index_mutex = Monitor.new
 +    wsa = Ferret::Analysis::WhiteSpaceAnalyzer.new false
 +    sa = Ferret::Analysis::StandardAnalyzer.new [], true
 +    @analyzer = Ferret::Analysis::PerFieldAnalyzer.new wsa
 +    @analyzer[:body] = sa
 +    @analyzer[:subject] = sa
 +    @qparser ||= Ferret::QueryParser.new :default_field => :body, :analyzer => @analyzer, :or_default => false
 +  end
 +
 +  def load_index dir=File.join(@dir, "ferret")
 +    if File.exists? dir
 +      Redwood::log "loading index..."
 +      @index_mutex.synchronize do
 +        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
 +        Redwood::log "loaded index of #{@index.size} messages"
 +      end
 +    else
 +      Redwood::log "creating index..."
 +      @index_mutex.synchronize do
 +        field_infos = Ferret::Index::FieldInfos.new :store => :yes
 +        field_infos.add_field :message_id, :index => :untokenized
 +        field_infos.add_field :source_id
 +        field_infos.add_field :source_info
 +        field_infos.add_field :date, :index => :untokenized
 +        field_infos.add_field :body
 +        field_infos.add_field :label
 +        field_infos.add_field :attachments
 +        field_infos.add_field :subject
 +        field_infos.add_field :from
 +        field_infos.add_field :to
 +        field_infos.add_field :refs
 +        field_infos.add_field :snippet, :index => :no, :term_vector => :no
 +        field_infos.create_index dir
 +        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
 +      end
 +    end
 +  end
 +
 +  def sync_message m, opts={}
 +    entry = @index[m.id]
 +
 +    raise "no source info for message #{m.id}" unless m.source && m.source_info
 +
 +    source_id = if m.source.is_a? Integer
 +      m.source
 +    else
 +      m.source.id or raise "unregistered source #{m.source} (id #{m.source.id.inspect})"
 +    end
 +
 +    snippet = if m.snippet_contains_encrypted_content? && $config[:discard_snippets_from_encrypted_messages]
 +      ""
 +    else
 +      m.snippet
 +    end
 +
 +    ## write the new document to the index. if the entry already exists in the
 +    ## index, reuse it (which avoids having to reload the entry from the source,
 +    ## which can be quite expensive for e.g. large threads of IMAP actions.)
 +    ##
 +    ## exception: if the index entry belongs to an earlier version of the
 +    ## message, use everything from the new message instead, but union the
 +    ## flags. this allows messages sent to mailing lists to have their header
 +    ## updated and to have flags set properly.
 +    ##
 +    ## minor hack: messages in sources with lower ids have priority over
 +    ## messages in sources with higher ids. so messages in the inbox will
 +    ## override everyone, and messages in the sent box will be overridden
 +    ## by everyone else.
 +    ##
 +    ## written in this manner to support previous versions of the index which
 +    ## did not keep around the entry body. upgrading is thus seamless.
 +    entry ||= {}
 +    labels = m.labels.uniq # override because this is the new state, unless...
 +
 +    ## if we are a later version of a message, ignore what's in the index,
 +    ## but merge in the labels.
 +    if entry[:source_id] && entry[:source_info] && entry[:label] &&
 +      ((entry[:source_id].to_i > source_id) || (entry[:source_info].to_i < m.source_info))
 +      labels = (entry[:label].symbolistize + m.labels).uniq
 +      #Redwood::log "found updated version of message #{m.id}: #{m.subj}"
 +      #Redwood::log "previous version was at #{entry[:source_id].inspect}:#{entry[:source_info].inspect}, this version at #{source_id.inspect}:#{m.source_info.inspect}"
 +      #Redwood::log "merged labels are #{labels.inspect} (index #{entry[:label].inspect}, message #{m.labels.inspect})"
 +      entry = {}
 +    end
 +
 +    ## if force_overwite is true, ignore what's in the index. this is used
 +    ## primarily by sup-sync to force index updates.
 +    entry = {} if opts[:force_overwrite]
 +
 +    d = {
 +      :message_id => m.id,
 +      :source_id => source_id,
 +      :source_info => m.source_info,
 +      :date => (entry[:date] || m.date.to_indexable_s),
 +      :body => (entry[:body] || m.indexable_content),
 +      :snippet => snippet, # always override
 +      :label => labels.uniq.join(" "),
 +      :attachments => (entry[:attachments] || m.attachments.uniq.join(" ")),
 +
 +      ## always override :from and :to.
 +      ## older versions of Sup would often store the wrong thing in the index
 +      ## (because they were canonicalizing email addresses, resulting in the
 +      ## wrong name associated with each.) the correct address is read from
 +      ## the original header when these messages are opened in thread-view-mode,
 +      ## so this allows people to forcibly update the address in the index by
 +      ## marking those threads for saving.
 +      :from => (m.from ? m.from.indexable_content : ""),
 +      :to => (m.to + m.cc + m.bcc).map { |x| x.indexable_content }.join(" "),
 +
 +      :subject => (entry[:subject] || wrap_subj(Message.normalize_subj(m.subj))),
 +      :refs => (entry[:refs] || (m.refs + m.replytos).uniq.join(" ")),
 +    }
 +
 +    @index_mutex.synchronize do
 +      @index.delete m.id
 +      @index.add_document d
 +    end
 +  end
 +
 +  def save_index fn=File.join(@dir, "ferret")
 +    # don't have to do anything, apparently
 +  end
 +
 +  def contains_id? id
 +    @index_mutex.synchronize { @index.search(Ferret::Search::TermQuery.new(:message_id, id)).total_hits > 0 }
 +  end
 +
 +  def size
 +    @index_mutex.synchronize { @index.size }
 +  end
 +
 +  EACH_BY_DATE_NUM = 100
 +  def each_id_by_date query={}
 +    return if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
 +    ferret_query = build_ferret_query query
 +    offset = 0
 +    while true
 +      limit = (query[:limit])? [EACH_BY_DATE_NUM, query[:limit] - offset].min : EACH_BY_DATE_NUM
 +      results = @index_mutex.synchronize { @index.search ferret_query, :sort => "date DESC", :limit => limit, :offset => offset }
 +      Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{ferret_query.inspect}"
 +      results.hits.each do |hit|
 +        yield @index_mutex.synchronize { @index[hit.doc][:message_id] }, lambda { build_message hit.doc }
 +      end
 +      break if query[:limit] and offset >= query[:limit] - limit
 +      break if offset >= results.total_hits - limit
 +      offset += limit
 +    end
 +  end
 +
 +  def num_results_for query={}
 +    return 0 if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
 +    ferret_query = build_ferret_query query
 +    @index_mutex.synchronize { @index.search(ferret_query, :limit => 1).total_hits }
 +  end
 +
 +  SAME_SUBJECT_DATE_LIMIT = 7
 +  MAX_CLAUSES = 1000
 +  def each_message_in_thread_for m, opts={}
 +    #Redwood::log "Building thread for #{m.id}: #{m.subj}"
 +    messages = {}
 +    searched = {}
 +    num_queries = 0
 +
 +    pending = [m.id]
 +    if $config[:thread_by_subject] # do subject queries
 +      date_min = m.date - (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
 +      date_max = m.date + (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
 +
 +      q = Ferret::Search::BooleanQuery.new true
 +      sq = Ferret::Search::PhraseQuery.new(:subject)
 +      wrap_subj(Message.normalize_subj(m.subj)).split.each do |t|
 +        sq.add_term t
 +      end
 +      q.add_query sq, :must
 +      q.add_query Ferret::Search::RangeQuery.new(:date, :>= => date_min.to_indexable_s, :<= => date_max.to_indexable_s), :must
 +
 +      q = build_ferret_query :qobj => q
 +
 +      p1 = @index_mutex.synchronize { @index.search(q).hits.map { |hit| @index[hit.doc][:message_id] } }
 +      Redwood::log "found #{p1.size} results for subject query #{q}"
 +
 +      p2 = @index_mutex.synchronize { @index.search(q.to_s, :limit => :all).hits.map { |hit| @index[hit.doc][:message_id] } }
 +      Redwood::log "found #{p2.size} results in string form"
 +
 +      pending = (pending + p1 + p2).uniq
 +    end
 +
 +    until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
 +      q = Ferret::Search::BooleanQuery.new true
 +      # this disappeared in newer ferrets... wtf.
 +      # q.max_clause_count = 2048
 +
 +      lim = [MAX_CLAUSES / 2, pending.length].min
 +      pending[0 ... lim].each do |id|
 +        searched[id] = true
 +        q.add_query Ferret::Search::TermQuery.new(:message_id, id), :should
 +        q.add_query Ferret::Search::TermQuery.new(:refs, id), :should
 +      end
 +      pending = pending[lim .. -1]
 +
 +      q = build_ferret_query :qobj => q
 +
 +      num_queries += 1
 +      killed = false
 +      @index_mutex.synchronize do
 +        @index.search_each(q, :limit => :all) do |docid, score|
 +          break if opts[:limit] && messages.size >= opts[:limit]
 +          if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
 +            killed = true
 +            break
 +          end
 +          mid = @index[docid][:message_id]
 +          unless messages.member?(mid)
 +            #Redwood::log "got #{mid} as a child of #{id}"
 +            messages[mid] ||= lambda { build_message docid }
 +            refs = @index[docid][:refs].split
 +            pending += refs.select { |id| !searched[id] }
 +          end
 +        end
 +      end
 +    end
 +
 +    if killed
 +      Redwood::log "thread for #{m.id} is killed, ignoring"
 +      false
 +    else
 +      Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
 +      messages.each { |mid, builder| yield mid, builder }
 +      true
 +    end
 +  end
 +
 +  ## builds a message object from a ferret result
 +  def build_message docid
 +    @index_mutex.synchronize do
 +      doc = @index[docid] or return
 +
 +      source = SourceManager[doc[:source_id].to_i]
 +      raise "invalid source #{doc[:source_id]}" unless source
 +
 +      #puts "building message #{doc[:message_id]} (#{source}##{doc[:source_info]})"
 +
 +      fake_header = {
 +        "date" => Time.at(doc[:date].to_i),
 +        "subject" => unwrap_subj(doc[:subject]),
 +        "from" => doc[:from],
 +        "to" => doc[:to].split.join(", "), # reformat
 +        "message-id" => doc[:message_id],
 +        "references" => doc[:refs].split.map { |x| "<#{x}>" }.join(" "),
 +      }
 +
 +      m = Message.new :source => source, :source_info => doc[:source_info].to_i,
 +                  :labels => doc[:label].symbolistize,
 +                  :snippet => doc[:snippet]
 +      m.parse_header fake_header
 +      m
 +    end
 +  end
 +
 +  def delete id
 +    @index_mutex.synchronize { @index.delete id }
 +  end
 +
 +  def load_contacts emails, h={}
 +    q = Ferret::Search::BooleanQuery.new true
 +    emails.each do |e|
 +      qq = Ferret::Search::BooleanQuery.new true
 +      qq.add_query Ferret::Search::TermQuery.new(:from, e), :should
 +      qq.add_query Ferret::Search::TermQuery.new(:to, e), :should
 +      q.add_query qq
 +    end
 +    q.add_query Ferret::Search::TermQuery.new(:label, "spam"), :must_not
 +    
 +    Redwood::log "contact search: #{q}"
 +    contacts = {}
 +    num = h[:num] || 20
 +    @index_mutex.synchronize do
 +      @index.search_each q, :sort => "date DESC", :limit => :all do |docid, score|
 +        break if contacts.size >= num
 +        #Redwood::log "got message #{docid} to: #{@index[docid][:to].inspect} and from: #{@index[docid][:from].inspect}"
 +        f = @index[docid][:from]
 +        t = @index[docid][:to]
 +
 +        if AccountManager.is_account_email? f
 +          t.split(" ").each { |e| contacts[Person.from_address(e)] = true }
 +        else
 +          contacts[Person.from_address(f)] = true
 +        end
 +      end
 +    end
 +
 +    contacts.keys.compact
 +  end
 +
 +  def each_docid query={}
 +    ferret_query = build_ferret_query query
 +    results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
 +    results.hits.map { |hit| yield hit.doc }
 +  end
 +    
 +  def each_message query={}
 +    each_docid query do |docid|
 +      yield build_message(docid)
 +    end
 +  end
 +
 +  def optimize
 +    @index_mutex.synchronize { @index.optimize }
 +  end
 +
 +  def source_for_id id
 +    entry = @index[id]
 +    return unless entry
 +    entry[:source_id].to_i
 +  end
 +
 +  class ParseError < StandardError; end
 +
 +  ## parse a query string from the user. returns a query object
 +  ## that can be passed to any index method with a 'query' 
 +  ## argument, as well as build_ferret_query.
 +  ##
 +  ## raises a ParseError if something went wrong.
 +  def parse_query s
 +    query = {}
 +
 +    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 +      field, name = $1, $2
 +      if(p = ContactManager.contact_for(name))
 +        [field, p.email]
 +      elsif name == "me"
 +        [field, "(" + AccountManager.user_emails.join("||") + ")"]
 +      else
 +        [field, name]
 +      end.join(":")
 +    end
 +
 +    ## if we see a label:deleted or a label:spam term anywhere in the query
 +    ## string, we set the extra load_spam or load_deleted options to true.
 +    ## bizarre? well, because the query allows arbitrary parenthesized boolean
 +    ## expressions, without fully parsing the query, we can't tell whether
 +    ## the user is explicitly directing us to search spam messages or not.
 +    ## e.g. if the string is -(-(-(-(-label:spam)))), does the user want to
 +    ## search spam messages or not?
 +    ##
 +    ## so, we rely on the fact that turning these extra options ON turns OFF
 +    ## the adding of "-label:deleted" or "-label:spam" terms at the very
 +    ## final stage of query processing. if the user wants to search spam
 +    ## messages, not adding that is the right thing; if he doesn't want to
 +    ## search spam messages, then not adding it won't have any effect.
 +    query[:load_spam] = true if subs =~ /\blabel:spam\b/
 +    query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
 +
 +    ## gmail style "is" operator
 +    subs = subs.gsub(/\b(is|has):(\S+)\b/) do
 +      field, label = $1, $2
 +      case label
 +      when "read"
 +        "-label:unread"
 +      when "spam"
 +        query[:load_spam] = true
 +        "label:spam"
 +      when "deleted"
 +        query[:load_deleted] = true
 +        "label:deleted"
 +      else
 +        "label:#{$2}"
 +      end
 +    end
 +
 +    ## gmail style attachments "filename" and "filetype" searches
 +    subs = subs.gsub(/\b(filename|filetype):(\((.+?)\)\B|(\S+)\b)/) do
 +      field, name = $1, ($3 || $4)
 +      case field
 +      when "filename"
 +        Redwood::log "filename - translated #{field}:#{name} to attachments:(#{name.downcase})"
 +        "attachments:(#{name.downcase})"
 +      when "filetype"
 +        Redwood::log "filetype - translated #{field}:#{name} to attachments:(*.#{name.downcase})"
 +        "attachments:(*.#{name.downcase})"
 +      end
 +    end
 +
 +    if $have_chronic
 +      subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do
 +        field, datestr = $1, ($3 || $4)
 +        realdate = Chronic.parse datestr, :guess => false, :context => :past
 +        if realdate
 +          case field
 +          when "after"
 +            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.end}"
 +            "date:(>= #{sprintf "%012d", realdate.end.to_i})"
 +          when "before"
 +            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.begin}"
 +            "date:(<= #{sprintf "%012d", realdate.begin.to_i})"
 +          else
 +            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate}"
 +            "date:(<= #{sprintf "%012d", realdate.end.to_i}) date:(>= #{sprintf "%012d", realdate.begin.to_i})"
 +          end
 +        else
 +          raise ParseError, "can't understand date #{datestr.inspect}"
 +        end
 +      end
 +    end
 +
 +    ## limit:42 restrict the search to 42 results
 +    subs = subs.gsub(/\blimit:(\S+)\b/) do
 +      lim = $1
 +      if lim =~ /^\d+$/
 +        query[:limit] = lim.to_i
 +        ''
 +      else
 +        raise ParseError, "non-numeric limit #{lim.inspect}"
 +      end
 +    end
 +    
 +    begin
 +      query[:qobj] = @qparser.parse(subs)
 +      query[:text] = s
 +      query
 +    rescue Ferret::QueryParser::QueryParseException => e
 +      raise ParseError, e.message
 +    end
 +  end
 +
 +private
 +
 +  def build_ferret_query query
 +    q = Ferret::Search::BooleanQuery.new
 +    q.add_query query[:qobj], :must if query[:qobj]
 +    labels = ([query[:label]] + (query[:labels] || [])).compact
 +    labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
 +    if query[:participants]
 +      q2 = Ferret::Search::BooleanQuery.new
 +      query[:participants].each do |p|
 +        q2.add_query Ferret::Search::TermQuery.new("from", p.email), :should
 +        q2.add_query Ferret::Search::TermQuery.new("to", p.email), :should
 +      end
 +      q.add_query q2, :must
 +    end
 +        
 +    q.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless query[:load_spam] || labels.include?(:spam)
 +    q.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless query[:load_deleted] || labels.include?(:deleted)
 +    q.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if query[:skip_killed]
 +
 +    q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
 +    q
 +  end
 +
 +  def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
 +  def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
 +end
 +
 +end
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 5ddd6ee..be0e870 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -1,7 +1,6 @@
 -## the index structure for redwood. interacts with ferret.
 +## Index interface, subclassed by Ferret indexer.
  
  require 'fileutils'
 -require 'ferret'
  
  begin
    require 'chronic'
 @@ -13,7 +12,7 @@ end
  
  module Redwood
  
 -class Index
 +class BaseIndex
    class LockError < StandardError
      def initialize h
        @h = h
 @@ -25,17 +24,8 @@ class Index
    include Singleton
  
    def initialize dir=BASE_DIR
 -    @index_mutex = Monitor.new
      @dir = dir
 -
 -    wsa = Ferret::Analysis::WhiteSpaceAnalyzer.new false
 -    sa = Ferret::Analysis::StandardAnalyzer.new [], true
 -    @analyzer = Ferret::Analysis::PerFieldAnalyzer.new wsa
 -    @analyzer[:body] = sa
 -    @analyzer[:subject] = sa
 -    @qparser ||= Ferret::QueryParser.new :default_field => :body, :analyzer => @analyzer, :or_default => false
      @lock = Lockfile.new lockfile, :retries => 0, :max_age => nil
 -
      self.class.i_am_the_instance self
    end
  
 @@ -119,155 +109,44 @@ EOS
      save_index
    end
  
 -  def load_index dir=File.join(@dir, "ferret")
 -    if File.exists? dir
 -      Redwood::log "loading index..."
 -      @index_mutex.synchronize do
 -        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
 -        Redwood::log "loaded index of #{@index.size} messages"
 -      end
 -    else
 -      Redwood::log "creating index..."
 -      @index_mutex.synchronize do
 -        field_infos = Ferret::Index::FieldInfos.new :store => :yes
 -        field_infos.add_field :message_id, :index => :untokenized
 -        field_infos.add_field :source_id
 -        field_infos.add_field :source_info
 -        field_infos.add_field :date, :index => :untokenized
 -        field_infos.add_field :body
 -        field_infos.add_field :label
 -        field_infos.add_field :attachments
 -        field_infos.add_field :subject
 -        field_infos.add_field :from
 -        field_infos.add_field :to
 -        field_infos.add_field :refs
 -        field_infos.add_field :snippet, :index => :no, :term_vector => :no
 -        field_infos.create_index dir
 -        @index = Ferret::Index::Index.new(:path => dir, :analyzer => @analyzer, :id_field => 'message_id')
 -      end
 -    end
 +  def load_index
 +    unimplemented
    end
  
    ## Syncs the message to the index, replacing any previous version.  adding
    ## either way. Index state will be determined by the message's #labels
    ## accessor.
    def sync_message m, opts={}
 -    entry = @index[m.id]
 -
 -    raise "no source info for message #{m.id}" unless m.source && m.source_info
 -
 -    source_id = if m.source.is_a? Integer
 -      m.source
 -    else
 -      m.source.id or raise "unregistered source #{m.source} (id #{m.source.id.inspect})"
 -    end
 -
 -    snippet = if m.snippet_contains_encrypted_content? && $config[:discard_snippets_from_encrypted_messages]
 -      ""
 -    else
 -      m.snippet
 -    end
 -
 -    ## write the new document to the index. if the entry already exists in the
 -    ## index, reuse it (which avoids having to reload the entry from the source,
 -    ## which can be quite expensive for e.g. large threads of IMAP actions.)
 -    ##
 -    ## exception: if the index entry belongs to an earlier version of the
 -    ## message, use everything from the new message instead, but union the
 -    ## flags. this allows messages sent to mailing lists to have their header
 -    ## updated and to have flags set properly.
 -    ##
 -    ## minor hack: messages in sources with lower ids have priority over
 -    ## messages in sources with higher ids. so messages in the inbox will
 -    ## override everyone, and messages in the sent box will be overridden
 -    ## by everyone else.
 -    ##
 -    ## written in this manner to support previous versions of the index which
 -    ## did not keep around the entry body. upgrading is thus seamless.
 -    entry ||= {}
 -    labels = m.labels.uniq # override because this is the new state, unless...
 -
 -    ## if we are a later version of a message, ignore what's in the index,
 -    ## but merge in the labels.
 -    if entry[:source_id] && entry[:source_info] && entry[:label] &&
 -      ((entry[:source_id].to_i > source_id) || (entry[:source_info].to_i < m.source_info))
 -      labels = (entry[:label].symbolistize + m.labels).uniq
 -      #Redwood::log "found updated version of message #{m.id}: #{m.subj}"
 -      #Redwood::log "previous version was at #{entry[:source_id].inspect}:#{entry[:source_info].inspect}, this version at #{source_id.inspect}:#{m.source_info.inspect}"
 -      #Redwood::log "merged labels are #{labels.inspect} (index #{entry[:label].inspect}, message #{m.labels.inspect})"
 -      entry = {}
 -    end
 -
 -    ## if force_overwite is true, ignore what's in the index. this is used
 -    ## primarily by sup-sync to force index updates.
 -    entry = {} if opts[:force_overwrite]
 -
 -    d = {
 -      :message_id => m.id,
 -      :source_id => source_id,
 -      :source_info => m.source_info,
 -      :date => (entry[:date] || m.date.to_indexable_s),
 -      :body => (entry[:body] || m.indexable_content),
 -      :snippet => snippet, # always override
 -      :label => labels.uniq.join(" "),
 -      :attachments => (entry[:attachments] || m.attachments.uniq.join(" ")),
 -
 -      ## always override :from and :to.
 -      ## older versions of Sup would often store the wrong thing in the index
 -      ## (because they were canonicalizing email addresses, resulting in the
 -      ## wrong name associated with each.) the correct address is read from
 -      ## the original header when these messages are opened in thread-view-mode,
 -      ## so this allows people to forcibly update the address in the index by
 -      ## marking those threads for saving.
 -      :from => (m.from ? m.from.indexable_content : ""),
 -      :to => (m.to + m.cc + m.bcc).map { |x| x.indexable_content }.join(" "),
 -
 -      :subject => (entry[:subject] || wrap_subj(Message.normalize_subj(m.subj))),
 -      :refs => (entry[:refs] || (m.refs + m.replytos).uniq.join(" ")),
 -    }
 -
 -    @index_mutex.synchronize do
 -      @index.delete m.id
 -      @index.add_document d
 -    end
 +    unimplemented
    end
  
 -  def save_index fn=File.join(@dir, "ferret")
 -    # don't have to do anything, apparently
 +  def save_index fn
 +    unimplemented
    end
  
    def contains_id? id
 -    @index_mutex.synchronize { @index.search(Ferret::Search::TermQuery.new(:message_id, id)).total_hits > 0 }
 +    unimplemented
    end
 +
    def contains? m; contains_id? m.id end
 -  def size; @index_mutex.synchronize { @index.size } end
 +
 +  def size
 +    unimplemented
 +  end
 +
    def empty?; size == 0 end
  
 -  ## you should probably not call this on a block that doesn't break
 +  ## Yields a message-id and message-building lambda for each
 +  ## message that matches the given query, in descending date order.
 +  ## You should probably not call this on a block that doesn't break
    ## rather quickly because the results can be very large.
 -  EACH_BY_DATE_NUM = 100
    def each_id_by_date query={}
 -    return if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
 -    ferret_query = build_ferret_query query
 -    offset = 0
 -    while true
 -      limit = (query[:limit])? [EACH_BY_DATE_NUM, query[:limit] - offset].min : EACH_BY_DATE_NUM
 -      results = @index_mutex.synchronize { @index.search ferret_query, :sort => "date DESC", :limit => limit, :offset => offset }
 -      Redwood::log "got #{results.total_hits} results for query (offset #{offset}) #{ferret_query.inspect}"
 -      results.hits.each do |hit|
 -        yield @index_mutex.synchronize { @index[hit.doc][:message_id] }, lambda { build_message hit.doc }
 -      end
 -      break if query[:limit] and offset >= query[:limit] - limit
 -      break if offset >= results.total_hits - limit
 -      offset += limit
 -    end
 +    unimplemented
    end
  
 +  ## Return the number of matches for query in the index
    def num_results_for query={}
 -    return 0 if empty? # otherwise ferret barfs ###TODO: remove this once my ferret patch is accepted
 -
 -    ferret_query = build_ferret_query query
 -    @index_mutex.synchronize { @index.search(ferret_query, :limit => 1).total_hits }
 +    unimplemented
    end
  
    ## yield all messages in the thread containing 'm' by repeatedly
 @@ -278,300 +157,60 @@ EOS
    ## only two options, :limit and :skip_killed. if :skip_killed is
    ## true, stops loading any thread if a message with a :killed flag
    ## is found.
 -  SAME_SUBJECT_DATE_LIMIT = 7
 -  MAX_CLAUSES = 1000
    def each_message_in_thread_for m, opts={}
 -    #Redwood::log "Building thread for #{m.id}: #{m.subj}"
 -    messages = {}
 -    searched = {}
 -    num_queries = 0
 -
 -    pending = [m.id]
 -    if $config[:thread_by_subject] # do subject queries
 -      date_min = m.date - (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
 -      date_max = m.date + (SAME_SUBJECT_DATE_LIMIT * 12 * 3600)
 -
 -      q = Ferret::Search::BooleanQuery.new true
 -      sq = Ferret::Search::PhraseQuery.new(:subject)
 -      wrap_subj(Message.normalize_subj(m.subj)).split.each do |t|
 -        sq.add_term t
 -      end
 -      q.add_query sq, :must
 -      q.add_query Ferret::Search::RangeQuery.new(:date, :>= => date_min.to_indexable_s, :<= => date_max.to_indexable_s), :must
 -
 -      q = build_ferret_query :qobj => q
 -
 -      p1 = @index_mutex.synchronize { @index.search(q).hits.map { |hit| @index[hit.doc][:message_id] } }
 -      Redwood::log "found #{p1.size} results for subject query #{q}"
 -
 -      p2 = @index_mutex.synchronize { @index.search(q.to_s, :limit => :all).hits.map { |hit| @index[hit.doc][:message_id] } }
 -      Redwood::log "found #{p2.size} results in string form"
 -
 -      pending = (pending + p1 + p2).uniq
 -    end
 -
 -    until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
 -      q = Ferret::Search::BooleanQuery.new true
 -      # this disappeared in newer ferrets... wtf.
 -      # q.max_clause_count = 2048
 -
 -      lim = [MAX_CLAUSES / 2, pending.length].min
 -      pending[0 ... lim].each do |id|
 -        searched[id] = true
 -        q.add_query Ferret::Search::TermQuery.new(:message_id, id), :should
 -        q.add_query Ferret::Search::TermQuery.new(:refs, id), :should
 -      end
 -      pending = pending[lim .. -1]
 -
 -      q = build_ferret_query :qobj => q
 -
 -      num_queries += 1
 -      killed = false
 -      @index_mutex.synchronize do
 -        @index.search_each(q, :limit => :all) do |docid, score|
 -          break if opts[:limit] && messages.size >= opts[:limit]
 -          if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
 -            killed = true
 -            break
 -          end
 -          mid = @index[docid][:message_id]
 -          unless messages.member?(mid)
 -            #Redwood::log "got #{mid} as a child of #{id}"
 -            messages[mid] ||= lambda { build_message docid }
 -            refs = @index[docid][:refs].split
 -            pending += refs.select { |id| !searched[id] }
 -          end
 -        end
 -      end
 -    end
 -
 -    if killed
 -      Redwood::log "thread for #{m.id} is killed, ignoring"
 -      false
 -    else
 -      Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
 -      messages.each { |mid, builder| yield mid, builder }
 -      true
 -    end
 +    unimplemented
    end
  
 -  ## builds a message object from a ferret result
 -  def build_message docid
 -    @index_mutex.synchronize do
 -      doc = @index[docid] or return
 -
 -      source = SourceManager[doc[:source_id].to_i]
 -      raise "invalid source #{doc[:source_id]}" unless source
 -
 -      #puts "building message #{doc[:message_id]} (#{source}##{doc[:source_info]})"
 -
 -      fake_header = {
 -        "date" => Time.at(doc[:date].to_i),
 -        "subject" => unwrap_subj(doc[:subject]),
 -        "from" => doc[:from],
 -        "to" => doc[:to].split.join(", "), # reformat
 -        "message-id" => doc[:message_id],
 -        "references" => doc[:refs].split.map { |x| "<#{x}>" }.join(" "),
 -      }
 -
 -      m = Message.new :source => source, :source_info => doc[:source_info].to_i,
 -                  :labels => doc[:label].symbolistize,
 -                  :snippet => doc[:snippet]
 -      m.parse_header fake_header
 -      m
 -    end
 +  ## Load message with the given message-id from the index
 +  def build_message id
 +    unimplemented
    end
  
 -  def delete id; @index_mutex.synchronize { @index.delete id } end
 -
 -  def load_contacts emails, h={}
 -    q = Ferret::Search::BooleanQuery.new true
 -    emails.each do |e|
 -      qq = Ferret::Search::BooleanQuery.new true
 -      qq.add_query Ferret::Search::TermQuery.new(:from, e), :should
 -      qq.add_query Ferret::Search::TermQuery.new(:to, e), :should
 -      q.add_query qq
 -    end
 -    q.add_query Ferret::Search::TermQuery.new(:label, "spam"), :must_not
 -    
 -    Redwood::log "contact search: #{q}"
 -    contacts = {}
 -    num = h[:num] || 20
 -    @index_mutex.synchronize do
 -      @index.search_each q, :sort => "date DESC", :limit => :all do |docid, score|
 -        break if contacts.size >= num
 -        #Redwood::log "got message #{docid} to: #{@index[docid][:to].inspect} and from: #{@index[docid][:from].inspect}"
 -        f = @index[docid][:from]
 -        t = @index[docid][:to]
 -
 -        if AccountManager.is_account_email? f
 -          t.split(" ").each { |e| contacts[Person.from_address(e)] = true }
 -        else
 -          contacts[Person.from_address(f)] = true
 -        end
 -      end
 -    end
 +  ## Delete message with the given message-id from the index
 +  def delete id
 +    unimplemented
 +  end
  
 -    contacts.keys.compact
 +  ## Given an array of email addresses, return an array of Person objects that
 +  ## have sent mail to or received mail from any of the given addresses.
 +  def load_contacts email_addresses, h={}
 +    unimplemented
    end
  
 +  ## Yield each docid matching query
    def each_docid query={}
 -    ferret_query = build_ferret_query query
 -    results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
 -    results.hits.map { |hit| yield hit.doc }
 +    unimplemented
    end
      
 +  ## Yield each messages matching query
    def each_message query={}
 -    each_docid query do |docid|
 -      yield build_message(docid)
 -    end
 +    unimplemented
    end
  
 +  ## Implementation-specific optimization step
    def optimize
 -    @index_mutex.synchronize { @index.optimize }
 +    unimplemented
    end
  
 +  ## Return the id source of the source the message with the given message-id
 +  ## was synced from
    def source_for_id id
 -    entry = @index[id]
 -    return unless entry
 -    entry[:source_id].to_i
 +    unimplemented
    end
  
    class ParseError < StandardError; end
  
    ## parse a query string from the user. returns a query object
    ## that can be passed to any index method with a 'query' 
 -  ## argument, as well as build_ferret_query.
 +  ## argument.
    ##
    ## raises a ParseError if something went wrong.
    def parse_query s
 -    query = {}
 -
 -    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 -      field, name = $1, $2
 -      if(p = ContactManager.contact_for(name))
 -        [field, p.email]
 -      elsif name == "me"
 -        [field, "(" + AccountManager.user_emails.join("||") + ")"]
 -      else
 -        [field, name]
 -      end.join(":")
 -    end
 -
 -    ## if we see a label:deleted or a label:spam term anywhere in the query
 -    ## string, we set the extra load_spam or load_deleted options to true.
 -    ## bizarre? well, because the query allows arbitrary parenthesized boolean
 -    ## expressions, without fully parsing the query, we can't tell whether
 -    ## the user is explicitly directing us to search spam messages or not.
 -    ## e.g. if the string is -(-(-(-(-label:spam)))), does the user want to
 -    ## search spam messages or not?
 -    ##
 -    ## so, we rely on the fact that turning these extra options ON turns OFF
 -    ## the adding of "-label:deleted" or "-label:spam" terms at the very
 -    ## final stage of query processing. if the user wants to search spam
 -    ## messages, not adding that is the right thing; if he doesn't want to
 -    ## search spam messages, then not adding it won't have any effect.
 -    query[:load_spam] = true if subs =~ /\blabel:spam\b/
 -    query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
 -
 -    ## gmail style "is" operator
 -    subs = subs.gsub(/\b(is|has):(\S+)\b/) do
 -      field, label = $1, $2
 -      case label
 -      when "read"
 -        "-label:unread"
 -      when "spam"
 -        query[:load_spam] = true
 -        "label:spam"
 -      when "deleted"
 -        query[:load_deleted] = true
 -        "label:deleted"
 -      else
 -        "label:#{$2}"
 -      end
 -    end
 -
 -    ## gmail style attachments "filename" and "filetype" searches
 -    subs = subs.gsub(/\b(filename|filetype):(\((.+?)\)\B|(\S+)\b)/) do
 -      field, name = $1, ($3 || $4)
 -      case field
 -      when "filename"
 -        Redwood::log "filename - translated #{field}:#{name} to attachments:(#{name.downcase})"
 -        "attachments:(#{name.downcase})"
 -      when "filetype"
 -        Redwood::log "filetype - translated #{field}:#{name} to attachments:(*.#{name.downcase})"
 -        "attachments:(*.#{name.downcase})"
 -      end
 -    end
 -
 -    if $have_chronic
 -      subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do
 -        field, datestr = $1, ($3 || $4)
 -        realdate = Chronic.parse datestr, :guess => false, :context => :past
 -        if realdate
 -          case field
 -          when "after"
 -            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.end}"
 -            "date:(>= #{sprintf "%012d", realdate.end.to_i})"
 -          when "before"
 -            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.begin}"
 -            "date:(<= #{sprintf "%012d", realdate.begin.to_i})"
 -          else
 -            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate}"
 -            "date:(<= #{sprintf "%012d", realdate.end.to_i}) date:(>= #{sprintf "%012d", realdate.begin.to_i})"
 -          end
 -        else
 -          raise ParseError, "can't understand date #{datestr.inspect}"
 -        end
 -      end
 -    end
 -
 -    ## limit:42 restrict the search to 42 results
 -    subs = subs.gsub(/\blimit:(\S+)\b/) do
 -      lim = $1
 -      if lim =~ /^\d+$/
 -        query[:limit] = lim.to_i
 -        ''
 -      else
 -        raise ParseError, "non-numeric limit #{lim.inspect}"
 -      end
 -    end
 -    
 -    begin
 -      query[:qobj] = @qparser.parse(subs)
 -      query[:text] = s
 -      query
 -    rescue Ferret::QueryParser::QueryParseException => e
 -      raise ParseError, e.message
 -    end
 -  end
 -
 -private
 -
 -  def build_ferret_query query
 -    q = Ferret::Search::BooleanQuery.new
 -    q.add_query query[:qobj], :must if query[:qobj]
 -    labels = ([query[:label]] + (query[:labels] || [])).compact
 -    labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
 -    if query[:participants]
 -      q2 = Ferret::Search::BooleanQuery.new
 -      query[:participants].each do |p|
 -        q2.add_query Ferret::Search::TermQuery.new("from", p.email), :should
 -        q2.add_query Ferret::Search::TermQuery.new("to", p.email), :should
 -      end
 -      q.add_query q2, :must
 -    end
 -        
 -    q.add_query Ferret::Search::TermQuery.new("label", "spam"), :must_not unless query[:load_spam] || labels.include?(:spam)
 -    q.add_query Ferret::Search::TermQuery.new("label", "deleted"), :must_not unless query[:load_deleted] || labels.include?(:deleted)
 -    q.add_query Ferret::Search::TermQuery.new("label", "killed"), :must_not if query[:skip_killed]
 -
 -    q.add_query Ferret::Search::TermQuery.new("source_id", query[:source_id]), :must if query[:source_id]
 -    q
 +    unimplemented
    end
 -
 -  def wrap_subj subj; "__START_SUBJECT__ #{subj} __END_SUBJECT__"; end
 -  def unwrap_subj subj; subj =~ /__START_SUBJECT__ (.*?) __END_SUBJECT__/ && $1; end
  end
  
  end
 +
 +require 'lib/sup/ferret_index'
 +Redwood::Index = Redwood::FerretIndex
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:11 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:11 -0700
 Subject: [sup-talk] [PATCH 12/18] remove last external uses of ferret docid
 In-Reply-To: <1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup-sync-back       |    2 +-
  bin/sup-tweak-labels    |    6 +++---
  lib/sup/ferret_index.rb |   10 ++--------
  lib/sup/index.rb        |   12 +++++++-----
  4 files changed, 13 insertions(+), 17 deletions(-)
 
 diff --git a/bin/sup-sync-back b/bin/sup-sync-back
 index 679e03a..8aa2039 100755
 --- a/bin/sup-sync-back
 +++ b/bin/sup-sync-back
 @@ -17,7 +17,7 @@ def die msg
  end
  def has_any_from_source_with_label? index, source, label
    query = { :source_id => source.id, :label => label, :limit => 1 }
 -  not Enumerable::Enumerator.new(index, :each_docid, query).map.empty?
 +  not Enumerable::Enumerator.new(index, :each_id, query).map.empty?
  end
  
  opts = Trollop::options do
 diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
 index 95a3b03..a8115ea 100755
 --- a/bin/sup-tweak-labels
 +++ b/bin/sup-tweak-labels
 @@ -83,14 +83,14 @@ begin
    query += ' ' + opts[:query] if opts[:query]
  
    parsed_query = index.parse_query query
 -  docs = Enumerable::Enumerator.new(index, :each_docid, parsed_query).map
 -  num_total = docs.size
 +  ids = Enumerable::Enumerator.new(index, :each_id, parsed_query).map
 +  num_total = ids.size
  
    $stderr.puts "Found #{num_total} documents across #{source_ids.length} sources. Scanning..."
  
    num_changed = num_scanned = 0
    last_info_time = start_time = Time.now
 -  docs.each do |id|
 +  ids.each do |id|
      num_scanned += 1
  
      m = index.build_message id
 diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
 index 53c19e0..a2c30ab 100644
 --- a/lib/sup/ferret_index.rb
 +++ b/lib/sup/ferret_index.rb
 @@ -301,16 +301,10 @@ class FerretIndex < BaseIndex
      contacts.keys.compact
    end
  
 -  def each_docid query={}
 +  def each_id query={}
      ferret_query = build_ferret_query query
      results = @index_mutex.synchronize { @index.search ferret_query, :limit => (query[:limit] || :all) }
 -    results.hits.map { |hit| yield hit.doc }
 -  end
 -    
 -  def each_message query={}
 -    each_docid query do |docid|
 -      yield build_message(docid)
 -    end
 +    results.hits.map { |hit| yield @index[hit.doc][:message_id] }
    end
  
    def optimize
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index be0e870..45382f1 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -177,14 +177,16 @@ EOS
      unimplemented
    end
  
 -  ## Yield each docid matching query
 -  def each_docid query={}
 +  ## Yield each message-id matching query
 +  def each_id query={}
      unimplemented
    end
      
 -  ## Yield each messages matching query
 -  def each_message query={}
 -    unimplemented
 +  ## Yield each message matching query
 +  def each_message query={}, &b
 +    each_id query do |id|
 +      yield build_message(id)
 +    end
    end
  
    ## Implementation-specific optimization step
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:08 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:08 -0700
 Subject: [sup-talk] [PATCH 09/18] index: revert overeager opts->query rename
 	in each_message_in_thread_for
 In-Reply-To: <1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/index.rb |    8 ++++----
  1 files changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index e3f9e69..080a4ec 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -280,7 +280,7 @@ EOS
    ## is found.
    SAME_SUBJECT_DATE_LIMIT = 7
    MAX_CLAUSES = 1000
 -  def each_message_in_thread_for m, query={}
 +  def each_message_in_thread_for m, opts={}
      #Redwood::log "Building thread for #{m.id}: #{m.subj}"
      messages = {}
      searched = {}
 @@ -310,7 +310,7 @@ EOS
        pending = (pending + p1 + p2).uniq
      end
  
 -    until pending.empty? || (query[:limit] && messages.size >= query[:limit])
 +    until pending.empty? || (opts[:limit] && messages.size >= opts[:limit])
        q = Ferret::Search::BooleanQuery.new true
        # this disappeared in newer ferrets... wtf.
        # q.max_clause_count = 2048
 @@ -329,8 +329,8 @@ EOS
        killed = false
        @index_mutex.synchronize do
          @index.search_each(q, :limit => :all) do |docid, score|
 -          break if query[:limit] && messages.size >= query[:limit]
 -          if @index[docid][:label].split(/\s+/).include?("killed") && query[:skip_killed]
 +          break if opts[:limit] && messages.size >= opts[:limit]
 +          if @index[docid][:label].split(/\s+/).include?("killed") && opts[:skip_killed]
              killed = true
              break
            end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:13 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:13 -0700
 Subject: [sup-talk] [PATCH 14/18] index: choose index implementation with
 	config entry or environment variable
 In-Reply-To: <1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup.rb       |    2 ++
  lib/sup/index.rb |   10 ++++++++--
  2 files changed, 10 insertions(+), 2 deletions(-)
 
 diff --git a/lib/sup.rb b/lib/sup.rb
 index 5689c2b..54de73f 100644
 --- a/lib/sup.rb
 +++ b/lib/sup.rb
 @@ -54,6 +54,8 @@ module Redwood
    YAML_DOMAIN = "masanjin.net"
    YAML_DATE = "2006-10-01"
  
 +  DEFAULT_INDEX = 'ferret'
 +
    ## record exceptions thrown in threads nicely
    @exceptions = []
    @exception_mutex = Mutex.new
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 45382f1..df428f7 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -212,7 +212,13 @@ EOS
    end
  end
  
 +index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX
 +begin
 +  require "sup/#{index_name}_index"
 +rescue LoadError
 +  fail "invalid index name #{index_name.inspect}"
  end
 +Index = Redwood.const_get "#{index_name.capitalize}Index"
 +Redwood::log "using index #{Index.name}"
  
 -require 'lib/sup/ferret_index'
 -Redwood::Index = Redwood::FerretIndex
 +end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:12 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:12 -0700
 Subject: [sup-talk] [PATCH 13/18] add Message.indexable_{body, chunks,
 	subject}
 In-Reply-To: <1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/message.rb |   16 ++++++++++++++--
  1 files changed, 14 insertions(+), 2 deletions(-)
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index b667cb3..2999986 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -270,11 +270,23 @@ EOS
        to.map { |p| p.indexable_content },
        cc.map { |p| p.indexable_content },
        bcc.map { |p| p.indexable_content },
 -      chunks.select { |c| c.is_a? Chunk::Text }.map { |c| c.lines },
 -      Message.normalize_subj(subj),
 +      indexable_chunks.map { |c| c.lines },
 +      indexable_subject,
      ].flatten.compact.join " "
    end
  
 +  def indexable_body
 +    indexable_chunks.map { |c| c.lines }.flatten.compact.join " "
 +  end
 +
 +  def indexable_chunks
 +    chunks.select { |c| c.is_a? Chunk::Text }
 +  end
 +
 +  def indexable_subject
 +    Message.normalize_subj(subj)
 +  end
 +
    def quotable_body_lines
      chunks.find_all { |c| c.quotable? }.map { |c| c.lines }.flatten
    end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:14 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:14 -0700
 Subject: [sup-talk] [PATCH 15/18] index: add xapian implementation
 In-Reply-To: <1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-16-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/poll.rb         |    2 +-
  lib/sup/xapian_index.rb |  483 +++++++++++++++++++++++++++++++++++++++++++++++
  2 files changed, 484 insertions(+), 1 deletions(-)
  create mode 100644 lib/sup/xapian_index.rb
 
 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
 index c83290c..8a9d218 100644
 --- a/lib/sup/poll.rb
 +++ b/lib/sup/poll.rb
 @@ -147,7 +147,7 @@ EOS
          m_new = Message.build_from_source source, offset
          m_old = Index.build_message m_new.id
  
 -        m_new.labels = default_labels + (source.archived? ? [] : [:inbox])
 +        m_new.labels += default_labels + (source.archived? ? [] : [:inbox])
          m_new.labels << :sent if source.uri.eql?(SentManager.source_uri)
          m_new.labels.delete :unread if m_new.source_marked_read?
          m_new.labels.each { |l| LabelManager << l }
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 new file mode 100644
 index 0000000..7faa64d
 --- /dev/null
 +++ b/lib/sup/xapian_index.rb
 @@ -0,0 +1,483 @@
 +require 'xapian'
 +require 'gdbm'
 +require 'set'
 +
 +module Redwood
 +
 +# This index implementation uses Xapian for searching and GDBM for storage. It
 +# tends to be slightly faster than Ferret for indexing and significantly faster
 +# for searching due to precomputing thread membership.
 +class XapianIndex < BaseIndex
 +  STEM_LANGUAGE = "english"
 +
 +  def initialize dir=BASE_DIR
 +    super
 +
 +    @index_mutex = Monitor.new
 +
 +    @entries = MarshalledGDBM.new File.join(dir, "entries.db")
 +    @docids = MarshalledGDBM.new File.join(dir, "docids.db")
 +    @thread_members = MarshalledGDBM.new File.join(dir, "thread_members.db")
 +    @thread_ids = MarshalledGDBM.new File.join(dir, "thread_ids.db")
 +    @assigned_docids = GDBM.new File.join(dir, "assigned_docids.db")
 +
 +    @xapian = Xapian::WritableDatabase.new(File.join(dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
 +    @term_generator = Xapian::TermGenerator.new()
 +    @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
 +    @enquire = Xapian::Enquire.new @xapian
 +    @enquire.weighting_scheme = Xapian::BoolWeight.new
 +    @enquire.docid_order = Xapian::Enquire::ASCENDING
 +  end
 +
 +  def load_index
 +  end
 +
 +  def save_index
 +  end
 +
 +  def optimize
 +  end
 +
 +  def size
 +    synchronize { @xapian.doccount }
 +  end
 +
 +  def contains_id? id
 +    synchronize { @entries.member? id }
 +  end
 +
 +  def source_for_id id
 +    synchronize { @entries[id][:source_id] }
 +  end
 +
 +  def delete id
 +    synchronize { @xapian.delete_document @docids[id] }
 +  end
 +
 +  def build_message id
 +    entry = synchronize { @entries[id] }
 +    return unless entry
 +
 +    source = SourceManager[entry[:source_id]]
 +    raise "invalid source #{entry[:source_id]}" unless source
 +
 +    mk_addrs = lambda { |l| l.map { |e,n| "#{n} <#{e}>" } * ', ' }
 +    mk_refs = lambda { |l| l.map { |r| "<#{r}>" } * ' ' }
 +    fake_header = {
 +      'message-id' => entry[:message_id],
 +      'date' => Time.at(entry[:date]),
 +      'subject' => entry[:subject],
 +      'from' => mk_addrs[[entry[:from]]],
 +      'to' => mk_addrs[[entry[:to]]],
 +      'cc' => mk_addrs[[entry[:cc]]],
 +      'bcc' => mk_addrs[[entry[:bcc]]],
 +      'reply-tos' => mk_refs[entry[:replytos]],
 +      'references' => mk_refs[entry[:refs]],
 +     }
 +
 +      m = Message.new :source => source, :source_info => entry[:source_info],
 +                  :labels => entry[:labels],
 +                  :snippet => entry[:snippet]
 +      m.parse_header fake_header
 +      m
 +  end
 +
 +  def sync_message m, opts={}
 +    entry = synchronize { @entries[m.id] }
 +    snippet = m.snippet
 +    entry ||= {}
 +    labels = m.labels
 +    entry = {} if opts[:force_overwrite]
 +
 +    d = {
 +      :message_id => m.id,
 +      :source_id => m.source.id,
 +      :source_info => m.source_info,
 +      :date => (entry[:date] || m.date),
 +      :snippet => snippet,
 +      :labels => labels.uniq,
 +      :from => (entry[:from] || [m.from.email, m.from.name]),
 +      :to => (entry[:to] || m.to.map { |p| [p.email, p.name] }),
 +      :cc => (entry[:cc] || m.cc.map { |p| [p.email, p.name] }),
 +      :bcc => (entry[:bcc] || m.bcc.map { |p| [p.email, p.name] }),
 +      :subject => m.subj,
 +      :refs => (entry[:refs] || m.refs),
 +      :replytos => (entry[:replytos] || m.replytos),
 +    }
 +
 +    m.labels.each { |l| LabelManager << l }
 +
 +    synchronize do
 +      index_message m, opts
 +      union_threads([m.id] + m.refs + m.replytos)
 +      @entries[m.id] = d
 +    end
 +    true
 +  end
 +
 +  def num_results_for query={}
 +    xapian_query = build_xapian_query query
 +    matchset = run_query xapian_query, 0, 0, 100
 +    matchset.matches_estimated
 +  end
 +
 +  EACH_ID_PAGE = 100
 +  def each_id query={}
 +    offset = 0
 +    page = EACH_ID_PAGE
 +
 +    xapian_query = build_xapian_query query
 +    while true
 +      ids = run_query_ids xapian_query, offset, (offset+page)
 +      ids.each { |id| yield id }
 +      break if ids.size < page
 +      offset += page
 +    end
 +  end
 +
 +  def each_id_by_date query={}
 +    each_id(query) { |id| yield id, lambda { build_message id } }
 +  end
 +
 +  def each_message_in_thread_for m, opts={}
 +    # TODO thread by subject
 +    # TODO handle killed threads
 +    ids = synchronize { @thread_members[@thread_ids[m.id]] } || []
 +    ids.select { |id| contains_id? id }.each { |id| yield id, lambda { build_message id } }
 +    true
 +  end
 +
 +  def load_contacts emails, opts={}
 +    contacts = Set.new
 +    num = opts[:num] || 20
 +    each_id_by_date :participants => emails do |id,b|
 +      break if contacts.size >= num
 +      m = b.call
 +      ([m.from]+m.to+m.cc+m.bcc).compact.each { |p| contacts << [p.name, p.email] }
 +    end
 +    contacts.to_a.compact.map { |n,e| Person.new n, e }[0...num]
 +  end
 +
 +  # TODO share code with the Ferret index
 +  def parse_query s
 +    query = {}
 +
 +    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 +      field, name = $1, $2
 +      if(p = ContactManager.contact_for(name))
 +        [field, p.email]
 +      elsif name == "me"
 +        [field, "(" + AccountManager.user_emails.join("||") + ")"]
 +      else
 +        [field, name]
 +      end.join(":")
 +    end
 +
 +    ## if we see a label:deleted or a label:spam term anywhere in the query
 +    ## string, we set the extra load_spam or load_deleted options to true.
 +    ## bizarre? well, because the query allows arbitrary parenthesized boolean
 +    ## expressions, without fully parsing the query, we can't tell whether
 +    ## the user is explicitly directing us to search spam messages or not.
 +    ## e.g. if the string is -(-(-(-(-label:spam)))), does the user want to
 +    ## search spam messages or not?
 +    ##
 +    ## so, we rely on the fact that turning these extra options ON turns OFF
 +    ## the adding of "-label:deleted" or "-label:spam" terms at the very
 +    ## final stage of query processing. if the user wants to search spam
 +    ## messages, not adding that is the right thing; if he doesn't want to
 +    ## search spam messages, then not adding it won't have any effect.
 +    query[:load_spam] = true if subs =~ /\blabel:spam\b/
 +    query[:load_deleted] = true if subs =~ /\blabel:deleted\b/
 +
 +    ## gmail style "is" operator
 +    subs = subs.gsub(/\b(is|has):(\S+)\b/) do
 +      field, label = $1, $2
 +      case label
 +      when "read"
 +        "-label:unread"
 +      when "spam"
 +        query[:load_spam] = true
 +        "label:spam"
 +      when "deleted"
 +        query[:load_deleted] = true
 +        "label:deleted"
 +      else
 +        "label:#{$2}"
 +      end
 +    end
 +
 +    ## gmail style attachments "filename" and "filetype" searches
 +    subs = subs.gsub(/\b(filename|filetype):(\((.+?)\)\B|(\S+)\b)/) do
 +      field, name = $1, ($3 || $4)
 +      case field
 +      when "filename"
 +        Redwood::log "filename - translated #{field}:#{name} to attachment:\"#{name.downcase}\""
 +        "attachment:\"#{name.downcase}\""
 +      when "filetype"
 +        Redwood::log "filetype - translated #{field}:#{name} to attachment_extension:#{name.downcase}"
 +        "attachment_extension:#{name.downcase}"
 +      end
 +    end
 +
 +    if $have_chronic
 +      lastdate = 2<<32 - 1
 +      firstdate = 0
 +      subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do
 +        field, datestr = $1, ($3 || $4)
 +        realdate = Chronic.parse datestr, :guess => false, :context => :past
 +        if realdate
 +          case field
 +          when "after"
 +            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.end}"
 +            "date:#{realdate.end.to_i}..#{lastdate}"
 +          when "before"
 +            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate.begin}"
 +            "date:#{firstdate}..#{realdate.end.to_i}"
 +          else
 +            Redwood::log "chronic: translated #{field}:#{datestr} to #{realdate}"
 +            "date:#{realdate.begin.to_i}..#{realdate.end.to_i}"
 +          end
 +        else
 +          raise ParseError, "can't understand date #{datestr.inspect}"
 +        end
 +      end
 +    end
 +
 +    ## limit:42 restrict the search to 42 results
 +    subs = subs.gsub(/\blimit:(\S+)\b/) do
 +      lim = $1
 +      if lim =~ /^\d+$/
 +        query[:limit] = lim.to_i
 +        ''
 +      else
 +        raise ParseError, "non-numeric limit #{lim.inspect}"
 +      end
 +    end
 +
 +    qp = Xapian::QueryParser.new
 +    qp.database = @xapian
 +    qp.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
 +    qp.stemming_strategy = Xapian::QueryParser::STEM_SOME
 +    qp.default_op = Xapian::Query::OP_AND
 +    qp.add_valuerangeprocessor(Xapian::NumberValueRangeProcessor.new(DATE_VALUENO, 'date:', true))
 +    NORMAL_PREFIX.each { |k,v| qp.add_prefix k, v }
 +    BOOLEAN_PREFIX.each { |k,v| qp.add_boolean_prefix k, v }
 +    xapian_query = qp.parse_query(subs, Xapian::QueryParser::FLAG_PHRASE|Xapian::QueryParser::FLAG_BOOLEAN|Xapian::QueryParser::FLAG_LOVEHATE|Xapian::QueryParser::FLAG_WILDCARD, PREFIX['body'])
 +
 +    raise ParseError if xapian_query.nil? or xapian_query.empty?
 +    query[:qobj] = xapian_query
 +    query[:text] = s
 +    query
 +  end
 +
 +  private
 +
 +  # Stemmed
 +  NORMAL_PREFIX = {
 +    'subject' => 'S',
 +    'body' => 'B',
 +    'from_name' => 'FN',
 +    'to_name' => 'TN',
 +    'name' => 'N',
 +    'attachment' => 'A',
 +  }
 +
 +  # Unstemmed
 +  BOOLEAN_PREFIX = {
 +    'type' => 'K',
 +    'from_email' => 'FE',
 +    'to_email' => 'TE',
 +    'email' => 'E',
 +    'date' => 'D',
 +    'label' => 'L',
 +    'source_id' => 'I',
 +    'attachment_extension' => 'O',
 +  }
 +
 +  PREFIX = NORMAL_PREFIX.merge BOOLEAN_PREFIX
 +
 +  DATE_VALUENO = 0
 +
 +  # Xapian can very efficiently sort in ascending docid order. Sup always wants
 +  # to sort by descending date, so this method maps between them. In order to
 +  # handle multiple messages per second, we use a logistic curve centered
 +  # around MIDDLE_DATE so that the slope (docid/s) is greatest in this time
 +  # period. A docid collision is not an error - the code will pick the next
 +  # smallest unused one.
 +  DOCID_SCALE = 2.0**32
 +  TIME_SCALE = 2.0**27
 +  MIDDLE_DATE = Time.gm(2011)
 +  def assign_docid m
 +    t = (m.date.to_i - MIDDLE_DATE.to_i).to_f
 +    docid = (DOCID_SCALE - DOCID_SCALE/(Math::E**(-(t/TIME_SCALE)) + 1)).to_i
 +    begin
 +      while @assigned_docids.member? [docid].pack("N")
 +        docid -= 1
 +      end
 +    rescue
 +    end
 +    @assigned_docids[[docid].pack("N")] = ''
 +    docid
 +  end
 +
 +  def synchronize &b
 +    @index_mutex.synchronize &b
 +  end
 +
 +  def run_query xapian_query, offset, limit, checkatleast=0
 +    synchronize do
 +      @enquire.query = xapian_query
 +      @enquire.mset(offset, limit-offset, checkatleast)
 +    end
 +  end
 +
 +  def run_query_ids xapian_query, offset, limit
 +    matchset = run_query xapian_query, offset, limit
 +    matchset.matches.map { |r| r.document.data }
 +  end
 +
 +  Q = Xapian::Query
 +  def build_xapian_query opts
 +    labels = ([opts[:label]] + (opts[:labels] || [])).compact
 +    neglabels = [:spam, :deleted, :killed].reject { |l| (labels.include? l) || opts.member?("load_#{l}".intern) }
 +    pos_terms, neg_terms = [], []
 +
 +    pos_terms << mkterm(:type, 'mail')
 +    pos_terms.concat(labels.map { |l| mkterm(:label,l) })
 +    pos_terms << opts[:qobj] if opts[:qobj]
 +    pos_terms << mkterm(:source_id, opts[:source_id]) if opts[:source_id]
 +
 +    if opts[:participants]
 +      participant_terms = opts[:participants].map { |p| mkterm(:email,:any, (Redwood::Person === p) ? p.email : p) }
 +      pos_terms << Q.new(Q::OP_OR, participant_terms)
 +    end
 +
 +    neg_terms.concat(neglabels.map { |l| mkterm(:label,l) })
 +
 +    pos_query = Q.new(Q::OP_AND, pos_terms)
 +    neg_query = Q.new(Q::OP_OR, neg_terms)
 +
 +    if neg_query.empty?
 +      pos_query
 +    else
 +      Q.new(Q::OP_AND_NOT, [pos_query, neg_query])
 +    end
 +  end
 +
 +  def index_message m, opts
 +    terms = []
 +    text = []
 +
 +    subject_text = m.indexable_subject
 +    body_text = m.indexable_body
 +
 +    # Person names are indexed with several prefixes
 +    person_termer = lambda do |d|
 +      lambda do |p|
 +        ["#{d}_name", "name", "body"].each do |x|
 +          text << [p.name, PREFIX[x]]
 +        end if p.name
 +        [d, :any].each { |x| terms << mkterm(:email, x, p.email) }
 +      end
 +    end
 +
 +    person_termer[:from][m.from] if m.from
 +    (m.to+m.cc+m.bcc).each(&(person_termer[:to]))
 +
 +    terms << mkterm(:date,m.date) if m.date
 +    m.labels.each { |t| terms << mkterm(:label,t) }
 +    terms << mkterm(:type, 'mail')
 +    terms << mkterm(:source_id, m.source.id)
 +    m.attachments.each do |a|
 +      a =~ /\.(\w+)$/ or next
 +      t = mkterm(:attachment_extension, $1)
 +      terms << t
 +    end
 +
 +    # Full text search content
 +    text << [subject_text, PREFIX['subject']]
 +    text << [subject_text, PREFIX['body']]
 +    text << [body_text, PREFIX['body']]
 +    m.attachments.each { |a| text << [a, PREFIX['attachment']] }
 +
 +    # Date value for range queries
 +    date_value = Xapian.sortable_serialise(m.date.to_i)
 +
 +    doc = Xapian::Document.new
 +    docid = @docids[m.id] || assign_docid(m)
 +
 +    @term_generator.document = doc
 +    text.each { |text,prefix| @term_generator.index_text text, 1, prefix }
 +    terms.each { |term| doc.add_term term }
 +    doc.add_value DATE_VALUENO, date_value
 +    doc.data = m.id
 +
 +    @xapian.replace_document docid, doc
 +    @docids[m.id] = docid
 +  end
 +
 +  # Construct a Xapian term
 +  def mkterm type, *args
 +    case type
 +    when :label
 +      PREFIX['label'] + args[0].to_s.downcase
 +    when :type
 +      PREFIX['type'] + args[0].to_s.downcase
 +    when :date
 +      PREFIX['date'] + args[0].getutc.strftime("%Y%m%d%H%M%S")
 +    when :email
 +      case args[0]
 +      when :from then PREFIX['from_email']
 +      when :to then PREFIX['to_email']
 +      when :any then PREFIX['email']
 +      else raise "Invalid email term type #{args[0]}"
 +      end + args[1].to_s.downcase
 +    when :source_id
 +      PREFIX['source_id'] + args[0].to_s.downcase
 +    when :attachment_extension
 +      PREFIX['attachment_extension'] + args[0].to_s.downcase
 +    else
 +      raise "Invalid term type #{type}"
 +    end
 +  end
 +
 +  # Join all the given message-ids into a single thread
 +  def union_threads ids
 +    seen_threads = Set.new
 +    related = Set.new
 +
 +    # Get all the ids that will be in the new thread
 +    ids.each do |id|
 +      related << id
 +      thread_id = @thread_ids[id]
 +      if thread_id && !seen_threads.member?(thread_id)
 +        thread_members = @thread_members[thread_id]
 +        related.merge thread_members
 +        seen_threads << thread_id
 +      end
 +    end
 +    
 +    # Pick a leader and move all the others to its thread
 +    a = related.to_a
 +    best, *rest = a.sort_by { |x| x.hash }
 +    @thread_members[best] = a
 +    @thread_ids[best] = best
 +    rest.each do |x|
 +      @thread_members.delete x
 +      @thread_ids[x] = best
 +    end
 +  end
 +end
 +
 +end
 +
 +class MarshalledGDBM < GDBM
 +  def []= k, v
 +    super k, Marshal.dump(v)
 +  end
 +
 +  def [] k
 +    v = super k
 +    v ? Marshal.load(v) : nil
 +  end
 +end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:16 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:16 -0700
 Subject: [sup-talk] [PATCH 17/18] add limit argument to
 	author_names_and_newness_for_thread
 In-Reply-To: <1245531017-9907-17-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-16-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-17-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-18-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/modes/thread-index-mode.rb |   15 ++++++++++-----
  1 files changed, 10 insertions(+), 5 deletions(-)
 
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index 0bd8110..b671119 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -1,3 +1,5 @@
 +require 'set'
 +
  module Redwood
  
  ## subclasses should implement:
 @@ -757,10 +759,12 @@ protected
    
    def authors; map { |m, *o| m.from if m }.compact.uniq; end
  
 -  def author_names_and_newness_for_thread t
 +  def author_names_and_newness_for_thread t, limit=nil
      new = {}
 -    authors = t.map do |m, *o|
 +    authors = Set.new
 +    t.each do |m, *o|
        next unless m
 +      break if limit and authors.size >= limit
  
        name = 
          if AccountManager.is_account?(m.from)
 @@ -772,12 +776,13 @@ protected
          end
  
        new[name] ||= m.has_label?(:unread)
 -      name
 +      authors << name
      end
  
 -    authors.compact.uniq.map { |a| [a, new[a]] }
 +    authors.to_a.map { |a| [a, new[a]] }
    end
  
 +  AUTHOR_LIMIT = 5
    def text_for_thread_at line
      t, size_widget = @mutex.synchronize { [@threads[line], @size_widgets[line]] }
  
 @@ -787,7 +792,7 @@ protected
  
      ## format the from column
      cur_width = 0
 -    ann = author_names_and_newness_for_thread t
 +    ann = author_names_and_newness_for_thread t, AUTHOR_LIMIT
      from = []
      ann.each_with_index do |(name, newness), i|
        break if cur_width >= from_width
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:15 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:15 -0700
 Subject: [sup-talk] [PATCH 16/18] fix String#ord monkeypatch
 In-Reply-To: <1245531017-9907-16-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-16-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-17-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/util.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/util.rb b/lib/sup/util.rb
 index 8f60cc4..0609908 100644
 --- a/lib/sup/util.rb
 +++ b/lib/sup/util.rb
 @@ -282,7 +282,7 @@ class String
      gsub(/\t/, "    ").gsub(/\r/, "")
    end
  
 -  if not defined? ord
 +  unless method_defined? :ord
      def ord
        self[0]
      end
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jun 20 16:50:17 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 20 Jun 2009 13:50:17 -0700
 Subject: [sup-talk] [PATCH 18/18] dont using SavingHash#[] for membership
 	test
 In-Reply-To: <1245531017-9907-18-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-16-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-17-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-18-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245531017-9907-19-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/thread.rb |    8 +++++---
  1 files changed, 5 insertions(+), 3 deletions(-)
 
 diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb
 index 99f21dc..d395c35 100644
 --- a/lib/sup/thread.rb
 +++ b/lib/sup/thread.rb
 @@ -310,13 +310,15 @@ class ThreadSet
    private :prune_thread_of
  
    def remove_id mid
 -    return unless(c = @messages[mid])
 +    return unless @messages.member?(mid)
 +    c = @messages[mid]
      remove_container c
      prune_thread_of c
    end
  
    def remove_thread_containing_id mid
 -    c = @messages[mid] or return
 +    return unless @messages.member?(mid)
 +    c = @messages[mid]
      t = c.root.thread
      @threads.delete_if { |key, thread| t == thread }
    end
 @@ -355,7 +357,7 @@ class ThreadSet
      return if threads.size < 2
  
      containers = threads.map do |t|
 -      c = @messages[t.first.id]
 +      c = @messages.member?(c) ? @messages[t.first.id] : nil
        raise "not in threadset: #{t.first.id}" unless c && c.message
        c
      end
 -- 
 1.6.0.4
 
 
 From garoth@gmail.com  Mon Jun 22 10:46:10 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 22 Jun 2009 10:46:10 -0400
 Subject: [sup-talk] [PATCH 18/18] dont using SavingHash#[] for
 	membership test
 In-Reply-To: <1245531017-9907-19-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-4-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-5-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-6-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-7-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-8-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-9-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-10-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-11-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-12-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-13-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-14-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-15-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-16-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-17-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-18-git-send-email-rlane@club.cc.cmu.edu>
 	<1245531017-9907-19-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245681928-sup-3077@Longbow>
 
 Wow, that's one heck of a set of patches... good work dude :)
 
 -AT
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 Make it idiot-proof, and someone will breed a better idiot.
 	-- Oliver Elphick
 
 From wmorgan-sup@masanjin.net  Wed Jun 24 12:30:39 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 24 Jun 2009 09:30:39 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1245854803-sup-4481@entry>
 
 Hi Rich,
 
 Reformatted excerpts from Rich Lane's message of 2009-06-20:
 > This patch series refactors the Index class to remove Ferret-isms and
 > support multiple index implementations. The included XapianIndex is a
 > bit faster at indexing messages and significantly faster when
 > searching because it precomputes thread membership. It also works on
 > Ruby 1.9.1.
 
 This is great. Really, really great. You've refactored a crufty
 interface that's been growing untamed over the past three years, you've
 gotten us away from the unmaintained scariness that is Ferret, you've
 fixed the largest source of interface slowness (thread recomputation),
 and you've enabled us to move to the beautiful, speedy, encoding-aware
 world of Ruby 1.9. Thank you for satisfying all of my Sup-related
 desires in one fell swoop. From my lofty throne, I commend thee.
 
 Once the bugs are ironed out, I would like to make this the default
 index format and eventually deprecate Ferret.
 
 In the mean time, I've placed your patches on a branch called xapian. If
 anyone wants to play with this, here's what you do:
 
 1. install the ruby xapian library and the ruby gdbm library, if you
    don't have them. These are packaged by your distro, and are not gems.
 2. git fetch
 3. git checkout -b xapian origin/xapian
 4. cp ~/.sup/sources.yaml /tmp # just in case
 5. sup-dump > dumpfile
 6. SUP_INDEX=xapian sup-sync --all --all-sources --restore dumpfile
 7. SUP_INDEX=xapian bin/sup -o
 8. Oooh, fast.
 
 This should not disturb your Ferret index, so you can switch back and
 forth between the two. (Message state, of course, is not shared.)
 However, adding new messages to one index will prevent it from being
 automatically added to the other, so I recommend running in Xapian mode
 with -o and not pressing 'P'.
 
 > It's missing a couple of features, notably threading by subject.
 
 FWIW, I've been thinking about deprecating that particular feature for
 quite some time.
 
 > I'm sure there are many more bugs left, so I'd appreciate any testing
 > or review you all can provide.
 
 sup-sync crashes for me fairly systematically with this error:
 
 ./lib/sup/xapian_index.rb:404:in `sortable_serialise': Expected argument 0 of type double, but got Fixnum 51767811298 (TypeError)
   in SWIG method 'Xapian::sortable_serialise'
   from ./lib/sup/xapian_index.rb:404:in `index_message'
   from ./lib/sup/xapian_index.rb:111:in `sync_message'
   from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
   from ./lib/sup/xapian_index.rb:324:in `synchronize'
   from ./lib/sup/xapian_index.rb:110:in `sync_message'
   from ./lib/sup/util.rb:519:in `send'
   from ./lib/sup/util.rb:519:in `method_missing'
   from ./lib/sup/poll.rb:157:in `add_messages_from'
   from ./lib/sup/source.rb:100:in `each'
   from ./lib/sup/util.rb:558:in `send'
   from ./lib/sup/util.rb:558:in `__pass'
   from ./lib/sup/util.rb:545:in `method_missing'
   from ./lib/sup/poll.rb:141:in `add_messages_from'
   from ./lib/sup/util.rb:519:in `send'
   from ./lib/sup/util.rb:519:in `method_missing'
   from bin/sup-sync:140
   from bin/sup-sync:135:in `each'
   from bin/sup-sync:135
 
 I haven't spent any time tracking it down. Other than that, so far so
 good.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jun 24 13:33:46 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 24 Jun 2009 10:33:46 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1245854803-sup-4481@entry>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry>
 Message-ID: <1245864733-sup-1216@entry>
 
 Reformatted excerpts from William Morgan's message of 2009-06-24:
 > sup-sync crashes for me fairly systematically with this error:
 > 
 > ./lib/sup/xapian_index.rb:404:in `sortable_serialise': Expected argument 0 of
 > type double, but got Fixnum 51767811298 (TypeError)
 
 This turns out to be due to dates being far in the future (e.g. on spam
 messages). I'm using the attached patch, which is pretty much a hack, to
 force them to be between 1969 and 2038. Better solutions welcome. (I
 haven't committed this.)
 -- 
 William <wmorgan-sup at masanjin.net>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-bugfix-dates-need-to-be-truncated-for-xapian-to-ind.patch
 Type: application/octet-stream
 Size: 2484 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090624/fae22ca3/attachment.obj>
 
 From olly@survex.com  Thu Jun 25 22:00:57 2009
 From: olly@survex.com (Olly Betts)
 Date: Fri, 26 Jun 2009 02:00:57 +0000 (UTC)
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 Message-ID: <loom.20090625T222159-861@post.gmane.org>
 
 William Morgan <wmorgan-sup at masanjin.net> writes:
 > Reformatted excerpts from William Morgan's message of 2009-06-24:
 > > sup-sync crashes for me fairly systematically with this error:
 > > 
 > > ./lib/sup/xapian_index.rb:404:in `sortable_serialise': Expected argument 0 of
 > > type double, but got Fixnum 51767811298 (TypeError)
 > 
 > This turns out to be due to dates being far in the future (e.g. on spam
 > messages). I'm using the attached patch, which is pretty much a hack, to
 > force them to be between 1969 and 2038. Better solutions welcome. (I
 > haven't committed this.)
 
 The error you get here is actually a bug in SWIG (http://www.swig.org/).  Xapian
 uses SWIG to generate the wrappers for Ruby.
 
 The code SWIG currently uses to convert a parameter when a C/C++ function
 takes a double doesn't handle a "fixnum" which is larger than MAXINT.  I've
 just applied a fix to SWIG SVN:
 
 http://swig.svn.sourceforge.net/viewvc/swig?view=rev&revision=11320
 
 I'll make sure this fix makes it into the next Xapian release (which will be
 1.0.14).
 
 Cheers,
     Olly
 
 
 From wmorgan-sup@masanjin.net  Fri Jun 26 09:49:40 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 26 Jun 2009 06:49:40 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <loom.20090625T222159-861@post.gmane.org>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 Message-ID: <1246022094-sup-3336@entry>
 
 Reformatted excerpts from Olly Betts's message of 2009-06-25:
 > I'll make sure this fix makes it into the next Xapian release (which
 > will be 1.0.14).
 
 Awesome, thanks!
 
 Though even with SWIG fixed there will still be some tweaking necessary
 in Sup because the logistic function used for generating Xapian docids
 still has trouble with extreme dates.
 
 BTW, more kudos to Rich for somehow finding a way to use a logistic
 function in an email client.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Fri Jun 26 13:10:01 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 26 Jun 2009 13:10:01 -0400
 Subject: [sup-talk] [PATCH] before-search hook
 In-Reply-To: <1245087294-sup-6276@entry>
 References: <1244612627-sup-982@javelin> <1245087294-sup-6276@entry>
 Message-ID: <1246035946-sup-7069@javelin>
 
 Done.
 
 
 >From 19f9da29020f1dfa97a4e6d0e4866cec840cfddc Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <edwardzyang at thewritingpot.com>
 Date: Wed, 10 Jun 2009 01:42:50 -0400
 Subject: [PATCH 1/2] Add custom-search hook, for shortcuts for custom search queries.
  Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
 
 ---
  lib/sup/hook.rb  |    5 +++++
  lib/sup/index.rb |   14 +++++++++++++-
  2 files changed, 18 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
 index 0a0a2f6..33a97b2 100644
 --- a/lib/sup/hook.rb
 +++ b/lib/sup/hook.rb
 @@ -19,6 +19,11 @@ class HookManager
  
      attr_writer :__locals
  
 +    ## an annoying gotcha here is that if you try something
 +    ## like var = var.foo(), var will magically get allocated
 +    ## to Nil and method_missing will never get called.  You
 +    ## can work around this by calling self.var or simply
 +    ## not assigning it to itself.
      def method_missing m, *a
        case @__locals[m]
        when Proc
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index ca01ee7..9c985d9 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -24,6 +24,16 @@ class Index
  
    include Singleton
  
 +  HookManager.register "custom-search", <<EOS
 +Executes before a string search is applied to the index,
 +returning a new search string.
 +Variables:
 +  subs: The string being searched. Be careful about shadowing:
 +    this variable is actually a method, so use a temporary variable
 +    or explicitly call self.subs; the substitutions in index.rb
 +    don't actually work.
 +EOS
 +
    ## these two accessors should ONLY be used by single-threaded programs.
    ## otherwise you will have a naughty ferret on your hands.
    attr_reader :index
 @@ -507,7 +517,9 @@ protected
    def parse_user_query_string s
      extraopts = {}
  
 -    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 +    subs = HookManager.run("custom-search", :subs => s) || s
 +
 +    subs = subs.gsub(/\b(to|from):(\S+)\b/) do
        field, name = $1, $2
        if(p = ContactManager.contact_for(name))
          [field, p.email]
 -- 
 1.6.3.2
 
 From me@nicholasbs.net  Sun Jun 28 22:32:02 2009
 From: me@nicholasbs.net (Nicholas Bergson-Shilcock)
 Date: Sun, 28 Jun 2009 22:32:02 -0400
 Subject: [sup-talk] Transitioning to OfflineIMAP
 In-Reply-To: <1244852427-sup-5831@entry>
 References: <1244844014-sup-6606@twoface> <1244852427-sup-5831@entry>
 Message-ID: <1246242608-sup-3151@twoface>
 
 Excerpts from William Morgan's message of Fri Jun 12 20:24:44 -0400 2009:
 > Reformatted excerpts from Nicholas Bergson-Shilcock's message of 2009-06-12:
 > > Before I go any further, I wanted to know if sup supported any sort of
 > > "graceful" account transitioning --  I'd ideally like to switch to my
 > > new maildir source without losing the index information I have for my
 > > IMAP source. The obvious way of switching over (removing my old source
 > > and adding the new one) would mean essentially starting over. Is this
 > > what I have to do or is there another way for me to switch?
 > 
 > I wouldn't call it graceful, exactly, but you should be able to preserve
 > state by running sup-dump on the original source, drop the index (move
 > your ~/.sup/ferret directory somewhere else), edit your source.yaml
 > file, and use sup-sync --restored --restore <dumpfile> to scan over the
 > new source and restore the state for each message.
 > 
 > It will take a while. Try it on a subset of messages first if possible
 > to make sure it's working. Post any questions and I'll try and help you.
 
 I just finally got around to trying this and it worked perfectly on the
 first try. Thank you, thank you, thank you! My mail is now about an
 order of magnitude faster.
 
 Keep up the awesome work,
   -Nick