sup

community/pipermail-archives/sup-talk/2009-08.txt (446072B) - raw

 From rlane@club.cc.cmu.edu  Sat Aug  1 02:28:19 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 01 Aug 2009 02:28:19 -0400
 Subject: [sup-talk] xapian question
 In-Reply-To: <1248807365-sup-4965@masanjin.net>
 References: <1248716325-sup-7534@masanjin.net>
 	<1248795865-sup-6634@pion.club.cc.cmu.edu>
 	<1248807365-sup-4965@masanjin.net>
 Message-ID: <1249098509-sup-6664@pion.club.cc.cmu.edu>
 
 I tried out using add_term/remove_term for immediate label changes. It's
 significantly faster than sync_message, but it still makes the interface
 feel laggy. There's known room for improvement in Xapian's
 replace_document. However, we'll still have a lot of latency when we
 start using remote sup-servers, so I don't think it's a good idea to do
 these index operations synchronously with the UI.
 
 We could queue up index writes and execute them in a background thread.
 We'd want label additions to show up immediately in a search, though.
 This is easy to do for inbox-mode and label-view-mode, which covers most
 of my daily usage. If/when we support multiple clients connecting to a
 sup-server, we'll need a way to notify them that someone else modified a
 message. We can implement a simple version of this now that notifies
 search-results-mode after the write completes.
 
 If we're getting rid of buffer saving, it'd probably be easiest to use a
 weak-ref table so we keep at most 1 copy of each message in memory -
 this would make updating messages across buffers simpler.
 
 How is sup-server development going?
 
 From mailinglist@flasht.de  Sat Aug  1 05:26:25 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Sat, 01 Aug 2009 11:26:25 +0200
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249055039-sup-8105@masanjin.net>
 References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net>
 Message-ID: <1249118728-sup-5483@thinkpad-debian>
 
 Excerpts from William Morgan's message of Fr Jul 31 17:44:25 +0200 2009:
 > Have you tried J and K vs j and k to scroll?
 
 Wow, cool. :) 
 Good to know.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 
 From guillaume.quintard@gmail.com  Sat Aug  1 13:44:50 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sat, 1 Aug 2009 19:44:50 +0200
 Subject: [sup-talk] Fwd:  xapian merged into next
 In-Reply-To: <1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 	<1248713360-sup-5448@entry>
 	<1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 	<1248716073-sup-7443@masanjin.net>
 	<1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com>
 Message-ID: <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com>
 
 I get this when I run "SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all
 --all-sources --restore dumpfile" (only had the time to do it today):
 
 ./lib/sup/xapian_index.rb:435:in `replace_document':
 InvalidArgumentError: Term too long (> 245):
 E"name.surname at enst-bretagne.fr,
 my_name.my_surname at enst-bretagne.fr, name.surname at enst-bretagne.fr,
 name.surname at enst-bretagne.fr,
 name.surname at telecom-bretagne.eu,
 name.surname at telecom-bretagne.eu,
 name.surname at telecom-bretagne.eu, name.surname"@telecom-bretagne.eu
 (ArgumentError)
 ? ? ? ?from ./lib/sup/xapian_index.rb:435:in `index_message'
 ? ? ? ?from ./lib/sup/xapian_index.rb:117:in `sync_message'
 ? ? ? ?from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 ? ? ? ?from ./lib/sup/xapian_index.rb:330:in `synchronize'
 ? ? ? ?from ./lib/sup/xapian_index.rb:116: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
 
 Cheers!
 
 -- 
 Guillaume
 
 From rlane@club.cc.cmu.edu  Sat Aug  1 14:14:34 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 01 Aug 2009 14:14:34 -0400
 Subject: [sup-talk] Fwd: xapian merged into next
 In-Reply-To: <1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 	<1248713360-sup-5448@entry>
 	<1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 	<1248716073-sup-7443@masanjin.net>
 	<1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com>
 	<1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com>
 Message-ID: <1249149855-sup-2211@pion.club.cc.cmu.edu>
 
 Excerpts from Guillaume Quintard's message of Sat Aug 01 13:44:50 -0400 2009:
 > E"name.surname at enst-bretagne.fr,
 > my_name.my_surname at enst-bretagne.fr, name.surname at enst-bretagne.fr,
 > name.surname at enst-bretagne.fr,
 > name.surname at telecom-bretagne.eu,
 > name.surname at telecom-bretagne.eu,
 > name.surname at telecom-bretagne.eu, name.surname"@telecom-bretagne.eu
 
 That's a very strange email address :). Could you track down the message
 causing this and post the headers? It looks like it's getting parsed
 incorrectly.
 
 I think we'd be safe not adding terms for email addresses longer than
 244 characters on the assumption that the user isn't going to want to
 search for them.
 
 From guillaume.quintard@gmail.com  Sat Aug  1 14:31:55 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sat, 01 Aug 2009 20:31:55 +0200
 Subject: [sup-talk] Fwd: xapian merged into next
 In-Reply-To: <1249149855-sup-2211@pion.club.cc.cmu.edu>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 	<1248713360-sup-5448@entry>
 	<1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 	<1248716073-sup-7443@masanjin.net>
 	<1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com>
 	<1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com>
 	<1249149855-sup-2211@pion.club.cc.cmu.edu>
 Message-ID: <1249151189-sup-3864@altis>
 
 Excerpts from Rich Lane's message of Sat Aug 01 20:14:34 +0200 2009:
 > I think we'd be safe not adding terms for email addresses longer than
 > 244 characters on the assumption that the user isn't going to want to
 > search for them.
 
 http://files.getdropbox.com/u/155904/grepped
 
 I did a simple grep, tell me if it's not enough (I'd rather not dive
 into the humongous mbox file).
 The mails come from the mailing-list admin tool (sympa), encoding
 problem it looks, the mangled part is "Propri?taires de liste" (list
 owners in french)
 
 -- 
 Guillaume
 
 From vasudeva@linkswarm.com  Sat Aug  1 17:58:13 2009
 From: vasudeva@linkswarm.com (vasudeva)
 Date: Sat, 01 Aug 2009 17:58:13 -0400
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249118728-sup-5483@thinkpad-debian>
 References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net>
 	<1249118728-sup-5483@thinkpad-debian>
 Message-ID: <1249163726-sup-5839@lenin>
 
 Excerpts from Christopher Bertels's message of Sat Aug 01 05:26:25 -0400 2009:
 > Excerpts from William Morgan's message of Fr Jul 31 17:44:25 +0200 2009:
 > > Have you tried J and K vs j and k to scroll?
 > 
 > Wow, cool. :) 
 > Good to know.
 
 That is nifty -- I didn't know it existed either. It seems slow on this machine though, and after using it in thread-view-mode, inbox-mode seems to have lost its mind a bit.
 
 I had wondered if the behavior the original poster was after might be akin to vim's 'scrolloff' setting. 
 
 Setting scrolloff=10 in vim means the selected line moves freely up and down but you're always going to have 10 lines of context at the edges; that is, the text starts scrolling upward when the selected line reaches 10 lines from the bottom. It kind of applies a 'force field' to the top and bottom edges of the page view so you never hit top or bottom of the viewport until you're at the top or bottom of the file itself.
 -- 
 linkswarm.com :: Collaborative Insolence
 vasudeva.linkswarm.com/gallery2 :: For The Faint of Heart
 
 
 From rlane@club.cc.cmu.edu  Sat Aug  1 18:56:09 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat,  1 Aug 2009 15:56:09 -0700
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 Message-ID: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |    4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 6358a20..5a5dfc1 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -304,6 +304,8 @@ class XapianIndex < BaseIndex
  
    DATE_VALUENO = 0
  
 +  MAX_TERM_LENGTH = 245
 +
    # 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
 @@ -428,7 +430,7 @@ class XapianIndex < BaseIndex
  
      @term_generator.document = doc
      text.each { |text,prefix| @term_generator.index_text text, 1, prefix }
 -    terms.each { |term| doc.add_term term }
 +    terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH }
      doc.add_value DATE_VALUENO, date_value
      doc.data = m.id
  
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Aug  1 19:03:06 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 01 Aug 2009 19:03:06 -0400
 Subject: [sup-talk] Fwd: xapian merged into next
 In-Reply-To: <1249151189-sup-3864@altis>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 	<1248713360-sup-5448@entry>
 	<1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 	<1248716073-sup-7443@masanjin.net>
 	<1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com>
 	<1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com>
 	<1249149855-sup-2211@pion.club.cc.cmu.edu>
 	<1249151189-sup-3864@altis>
 Message-ID: <1249167402-sup-6423@pion.club.cc.cmu.edu>
 
 Excerpts from Guillaume Quintard's message of Sat Aug 01 14:31:55 -0400 2009:
 > Excerpts from Rich Lane's message of Sat Aug 01 20:14:34 +0200 2009:
 > > I think we'd be safe not adding terms for email addresses longer than
 > > 244 characters on the assumption that the user isn't going to want to
 > > search for them.
 > 
 > http://files.getdropbox.com/u/155904/grepped
 > 
 > I did a simple grep, tell me if it's not enough (I'd rather not dive
 > into the humongous mbox file).
 > The mails come from the mailing-list admin tool (sympa), encoding
 > problem it looks, the mangled part is "Propri?taires de liste" (list
 > owners in french)
 > 
 
 I posted a patch that should keep Xapian from throwing an exception
 with long email addresses. I'm not any sort of encoding expert, but I'd
 guess that sup isn't responsible for the mangling.
 
 From guillaume.quintard@gmail.com  Sat Aug  1 19:35:25 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sun, 02 Aug 2009 01:35:25 +0200
 Subject: [sup-talk] Fwd: xapian merged into next
 In-Reply-To: <1249167402-sup-6423@pion.club.cc.cmu.edu>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 	<1248713360-sup-5448@entry>
 	<1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 	<1248716073-sup-7443@masanjin.net>
 	<1e5fdab70908010934l30373447r4a405c5ca0e406f9@mail.gmail.com>
 	<1e5fdab70908011044q6743d213o554a7bd039e237c2@mail.gmail.com>
 	<1249149855-sup-2211@pion.club.cc.cmu.edu>
 	<1249151189-sup-3864@altis>
 	<1249167402-sup-6423@pion.club.cc.cmu.edu>
 Message-ID: <1249169629-sup-5176@altis>
 
 Excerpts from Rich Lane's message of Sun Aug 02 01:03:06 +0200 2009:
 > with long email addresses. I'm not any sort of encoding expert, but I'd
 > guess that sup isn't responsible for the mangling.
 
 it isn't, the mangling comes from the mbox file, yet sup was able to
 import it at some point. I guesse the quotes don't really help.
 
 -- 
 Guillaume
 
 From mailinglist@flasht.de  Sat Aug  1 19:51:06 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Sun, 02 Aug 2009 01:51:06 +0200
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249163726-sup-5839@lenin>
 References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net>
 	<1249118728-sup-5483@thinkpad-debian> <1249163726-sup-5839@lenin>
 Message-ID: <1249170613-sup-5276@thinkpad-debian>
 
 Excerpts from vasudeva's message of Sa Aug 01 23:58:13 +0200 2009:
 > I had wondered if the behavior the original poster was after might be akin to
 > vim's 'scrolloff' setting. 
 > 
 > Setting scrolloff=10 in vim means the selected line moves freely up and down
 > but you're always going to have 10 lines of context at the edges; that is, the
 > text starts scrolling upward when the selected line reaches 10 lines from the
 > bottom. It kind of applies a 'force field' to the top and bottom edges of the
 > page view so you never hit top or bottom of the viewport until you're at the
 > top or bottom of the file itself.
 
 I'd actually love to see something like this in sup as well.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 
 From benoit.pierre@gmail.com  Sun Aug  2 11:23:47 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Sun, 02 Aug 2009 17:23:47 +0200
 Subject: [sup-talk] [PATCH] run-mailcap fix
 Message-ID: <1249226521-sup-4719@localdomain>
 
 I use this line in my ~/.mailcap to view HTML attachements in Mutt:
 
 text/html; w3m -dump -T text/html %s | pager; needsterminal; description=HTML Text; nametemplate=%s.html
 
 which doesn't work with Sup. The attached patch fix this by not redirecting
 stderr to /dev/null.  It also restores the correct ncurses state (including
 arrow keypresses, thanks to Edward Z. Yang recent patch).
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-run-mailcap.patch
 Type: application/octet-stream
 Size: 704 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090802/1fa7b4f6/attachment.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090802/1fa7b4f6/attachment.bin>
 
 From mark@markdrayton.info  Mon Aug  3 04:16:24 2009
 From: mark@markdrayton.info (Mark Drayton)
 Date: Mon, 3 Aug 2009 09:16:24 +0100
 Subject: [sup-talk] Stack overflow in regexp matcher
 Message-ID: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com>
 
 Hi there
 
 I'm trying to run sup 0.8.1 on Mac OS 10.5.6, Ruby 1.8.6 but sup-sync
 is repeatedly dying:
 
 MC-S001930:~ draytm01$ sup-sync -c
 [..]
 [Mon Aug 03 08:45:18 +0100 2009] Connecting to IMAP server foo:143...
 [Mon Aug 03 08:45:18 +0100 2009] Logging in...
 [..]
 [Mon Aug 03 08:45:19 +0100 2009] fetching IMAP headers 1..1002
 [Mon Aug 03 08:45:20 +0100 2009] done fetching IMAP headers
 Scanning imap://foo/INBOX...
 [..]
 ## read 440m (about 52%) @ 2.2m/s. 0:03:19 elapsed, about 0:03:03 remaining
 [Mon Aug 03 08:48:49 +0100 2009] unlocking /Users/draytm01/.sup/lock...
 /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:204:in `split':
 Stack overflow in regexp matcher:
 /,\s*(?=(?:[^"]*"[^"]*")*(?![^"]*"))/ (RegexpError)
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:204:in
 `split_on_commas'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/person.rb:110:in
 `from_address_list'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/message.rb:104:in
 `parse_header'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/message.rb:208:in
 `load_from_source!'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/poll.rb:151:in
 `add_messages_from'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:187:in `each'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:175:in `upto'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:175:in `each'
 	 ... 7 levels...
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/bin/sup-sync:135:in `each'
 	from /Library/Ruby/Gems/1.8/gems/sup-0.8.1/bin/sup-sync:135
 	from /usr/bin/sup-sync:19:in `load'
 	from /usr/bin/sup-sync:19
 
 This error seems to have cropped up in other software so I suspect
 it's a problem with Ruby, not sup. Anyone able to confirm this?
 
 Cheers,
 
 Mark
 
 From wmorgan-sup@masanjin.net  Mon Aug  3 13:18:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 03 Aug 2009 10:18:50 -0700
 Subject: [sup-talk] Odd bug with lazy-loaded messages
 In-Reply-To: <1248716007-sup-5156@javelin>
 References: <1248716007-sup-5156@javelin>
 Message-ID: <1249319474-sup-8322@masanjin.net>
 
 Sorry I didn't respond to this earlier.
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
 > Specifically, the "default" opened message when I open a thread
 > gets a weird misrendering of the headers that looks like:
 > 
 > To: foo
 >     foo <foo at example.com>
 >     foo
 > 
 > And so forth, for all lines in To and Cc.
 
 This is because we store a couple variants of the address in the index
 (e.g. the email address to the left of the @), so that a search on any
 of them will bring up the message. Without #load_from_source!, the
 message is loaded from the index, so it reflects those fields. So it's
 basically a hack at this point. You could further hack it by undoing
 that transformation. Or we could add the original version of the fields
 to the index in a separate, non-searchable field, incurring the
 associated storage penalties.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug  3 13:31:34 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 03 Aug 2009 10:31:34 -0700
 Subject: [sup-talk] Handling big mailing lists
 In-Reply-To: <m3prbjwgf8.fsf@iny.iki.fi>
 References: <m3zlaovx3t.fsf@iny.iki.fi> <1248874122-sup-3830@masanjin.net>
 	<m3prbjwgf8.fsf@iny.iki.fi>
 Message-ID: <1249320458-sup-6019@masanjin.net>
 
 Reformatted excerpts from iny+dev's message of 2009-07-29:
 > I guess so. How long it takes to index few months of ruby-talk?
 
 Offhand I see index speeds of 50-80 messages/s depending on index size,
 backend, etc.
 
 > Could Sup use IMAP search features?
 
 No, that would require a very different architecture and philosophy.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug  3 14:03:54 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 03 Aug 2009 11:03:54 -0700
 Subject: [sup-talk] xapian question
 In-Reply-To: <1249098509-sup-6664@pion.club.cc.cmu.edu>
 References: <1248716325-sup-7534@masanjin.net>
 	<1248795865-sup-6634@pion.club.cc.cmu.edu>
 	<1248807365-sup-4965@masanjin.net>
 	<1249098509-sup-6664@pion.club.cc.cmu.edu>
 Message-ID: <1249320789-sup-2608@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-07-31:
 > I tried out using add_term/remove_term for immediate label changes.
 > It's significantly faster than sync_message,
 
 Excellent.
 
 > but it still makes the interface feel laggy.  There's known room for
 > improvement in Xapian's replace_document.  However, we'll still have a
 > lot of latency when we start using remote sup-servers, so I don't
 > think it's a good idea to do these index operations synchronously with
 > the UI.
 
 I agree, synchronous is not an option.
 
 > We could queue up index writes and execute them in a background
 > thread. We'd want label additions to show up immediately in a search,
 > though. This is easy to do for inbox-mode and label-view-mode, which
 > covers most of my daily usage.
 
 I'm fine with queuing up index writes and letting the user continue
 while they take effect in the background. I'm also fine with the easier
 option of just blocking during a search until the writes are complete.
 
 > If/when we support multiple clients connecting to a sup-server, we'll
 > need a way to notify them that someone else modified a message.
 
 I think this is more of a nice-to-have than a necessity, but it would be
 nice to have, even if it was a "we've detected a change somewhere on the
 internet; reload? (y/n)"-kinda thing.
 
 > How is sup-server development going?
 
 Well. I have a simple version that stores "items" to files on disk, and
 uses Ferret to provide the search semantics. It's modular enough that
 upgrading to Xapian shouldn't be as painful as it was with Sup. There
 are even unit tests that enforce the semantics of the modules. Go me.
 
 I'm going to make a couple internal API changes in Sup and then try
 throwing the code together.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From tom@dbservice.com  Tue Aug  4 05:56:11 2009
 From: tom@dbservice.com (Tomas Carnecky)
 Date: Tue, 4 Aug 2009 11:56:11 +0200
 Subject: [sup-talk] sup on opensolaris
 In-Reply-To: <1249059559-sup-8960@matrix>
 References: <1249059559-sup-8960@matrix>
 Message-ID: <F8547FC4-8D0A-40AB-9604-7CB49BED27EC@dbservice.com>
 
 I hate mailing lists that force me to subscribe. Luckily I have a  
 friend who was already subscribed and forwarded me the emails.
 
 >
 >> I have an ugly patch for lib/sup/textfield.rb that uses its own  
 >> string
 >> buffer instead of relying on field_buffer(). It's not perfect, but it
 >> at least allows me to write emails and assign tags.
 >
 > If it's not too much work to clean up, I'd be interested in this  
 > patch.
 > The field buffer stuff is broken in weird ways anyways (the history
 > never seems to be quite right), and anything that reduces the reliance
 > on ncurses is always the right approach.
 
 I never programed in ruby before and I don't intend to learn it. Feel  
 free to look at the last commit in the solaris-fixes:curses-form- 
 buffer branch. It is the simplest possible solution to the problem at  
 hand that didn't require me to learn too much ruby. It still needs a  
 considerable amount of work before it is useful (like, being able to  
 delete characters in the stringio buffer etc). I'm not planing to work  
 on the patch in the foreseeable future, but someone else might find  
 the patch useful as a starting point.
 
 >
 >>  - strftime("%P") is a GNU extension, I work around this by using
 >> strftime("%p").downcase.
 >
 > Submit a patch! I'm fine with this.
 >
 >>  - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "//
 >> IGNORE" is causing an InvalidEncoding exception, removing it didn't
 >> seem to cause any regressions
 >
 > Hm, this is a trickier one. Allegedly the //IGNORE reduces the
 > exceptions thrown by Iconv, but since we're catching them all anyways,
 > we might be able to get away with removing this. Or we could
 > special-case it to your arch.
 
 
 Both patches are available in the solaris-fixes master branch.
 
 tom
 
 
 From wmorgan-sup@masanjin.net  Wed Aug  5 09:55:47 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 05 Aug 2009 06:55:47 -0700
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1249480531-sup-9805@masanjin.net>
 
 Applied, thanks!
 
 BTW I've merged the xapian stuff into master.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From dato@net.com.org.es  Wed Aug  5 10:09:26 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato_Sim=C3=B3?=)
 Date: Wed, 05 Aug 2009 16:09:26 +0200
 Subject: [sup-talk] sup ignoring SIGTERM?
 Message-ID: <1249481294-sup-9967@chistera.yi.org>
 
 Hello,
 
 it is my impression that sup is ignoring SIGTERM, whereas I would be
 expecting for sup to clean up (including removal of the lock file) and
 exit normally upon receiving this signal.
 
 Any clues about this? (I tried inserting a "trap", but it didn't seem to
 help.)
 
 Thanks,
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From ezyang@MIT.EDU  Wed Aug  5 10:54:31 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 05 Aug 2009 10:54:31 -0400
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249480531-sup-9805@masanjin.net>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1249480531-sup-9805@masanjin.net>
 Message-ID: <1249484040-sup-1879@javelin>
 
 Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009:
 > BTW I've merged the xapian stuff into master.
 
 Exciting days we live in. :-) Maybe I'll wait another week and update my local
 checkout.
 
 Cheers,
 Edward
 
 From wmorgan-sup@masanjin.net  Wed Aug  5 11:29:27 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 05 Aug 2009 08:29:27 -0700
 Subject: [sup-talk] sup crashing after sending mail
 In-Reply-To: <CBBB81512D1FE445823400465FCCFFF2D8AA45@sluga.fer.hr>
 References: <CBBB81512D1FE445823400465FCCFFF2D8AA45@sluga.fer.hr>
 Message-ID: <1249486021-sup-1246@masanjin.net>
 
 Hi Igor,
 
 Reformatted excerpts from Igor Brkic's message of 2009-08-02:
 > For mail sending I use sSMTP and my ISP's SMTP server. When I try to
 > send mail from sup, after pressing y on keyboard, mail gets sent but
 > sup crashes (exception-log_0.txt in attachment).
 
 A few people have reported this and I'm trying to track it down. Would
 you mind applying the following patch, and then running:
   sup-sync -a sup://sent
 
 Hopefully that will generate a little debugging output I can use. Thanks!
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 5372fc7..fc9af59 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -92,11 +92,11 @@ class Message
        begin
          Time.parse date
        rescue ArgumentError => e
 -        #Redwood::log "faking mangled date header for #{@id} (orig #{header['date']
 +        Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].
          Time.now
        end
      else
 -      #Redwood::log "faking non-existent date header for #{@id}"
 +      Redwood::log "faking non-existent date header for #{@id}"
        Time.now
      end
  
 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
 index 354bd21..365f828 100644
 --- a/lib/sup/poll.rb
 +++ b/lib/sup/poll.rb
 @@ -148,7 +148,9 @@ EOS
          labels = labels + (source.archived? ? [] : [:inbox])
  
          m = Message.new :source => source, :source_info => offset, :labels => label
 +        Redwood::log "XX before load: #{m.date.inspect}"
          m.load_from_source!
 +        Redwood::log "XX after load: #{m.date.inspect}"
  
          if m.source_marked_read?
            m.remove_label :unread
 @@ -157,7 +159,9 @@ EOS
  
          docid, entry = Index.load_entry_for_id m.id
          HookManager.run "before-add-message", :message => m
 +        Redwood::log "XX after add-message: #{m.date.inspect}"
          m = yield(m, offset, entry) or next if block_given?
 +        Redwood::log "XX after yield: #{m.date.inspect}"
          times = Index.sync_message m, false, docid, entry, opts
          UpdateManager.relay self, :added, m unless entry
        end
 
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Wed Aug  5 11:36:19 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 05 Aug 2009 11:36:19 -0400
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249480531-sup-9805@masanjin.net>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1249480531-sup-9805@masanjin.net>
 Message-ID: <1249485678-sup-4545@pion.club.cc.cmu.edu>
 
 Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009:
 > BTW I've merged the xapian stuff into master.
 
 Let's not advertise this as stable just yet - I've got a patchset that
 removes the GDBM databases which will break compatibility. Using just
 Xapian means better consistency if your kernel panics and potentially
 better performance. However, I have some Xapian bugs to squash before
 it's usable.
 
 From wmorgan-sup@masanjin.net  Wed Aug  5 11:48:35 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 05 Aug 2009 08:48:35 -0700
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249485678-sup-4545@pion.club.cc.cmu.edu>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1249480531-sup-9805@masanjin.net>
 	<1249485678-sup-4545@pion.club.cc.cmu.edu>
 Message-ID: <1249487110-sup-1824@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-05:
 > Let's not advertise this as stable just yet - I've got a patchset that
 > removes the GDBM databases which will break compatibility.
 
 Since the xapian stuff is only enabled via an obscure environment
 variable, I'm not too concerned about it being uber-stable. I've merged
 this more for the internal API changes, which seem stable and which I'm
 now building off of.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Wed Aug  5 13:29:48 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Wed, 05 Aug 2009 19:29:48 +0200
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249485678-sup-4545@pion.club.cc.cmu.edu>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1249480531-sup-9805@masanjin.net>
 	<1249485678-sup-4545@pion.club.cc.cmu.edu>
 Message-ID: <1249493306-sup-4994@ausone.home>
 
 Excerpts from Rich Lane's message of Wed Aug 05 17:36:19 +0200 2009:
 > Excerpts from William Morgan's message of Wed Aug 05 09:55:47 -0400 2009:
 > > BTW I've merged the xapian stuff into master.
 > 
 > Let's not advertise this as stable just yet -
 
 > I've got a patchset that
 > removes the GDBM databases which will break compatibility.
 
 I was planning to try a migration today, should I better wait a little?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From rlane@club.cc.cmu.edu  Wed Aug  5 13:48:11 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 05 Aug 2009 13:48:11 -0400
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249493306-sup-4994@ausone.home>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1249480531-sup-9805@masanjin.net>
 	<1249485678-sup-4545@pion.club.cc.cmu.edu>
 	<1249493306-sup-4994@ausone.home>
 Message-ID: <1249493896-sup-7335@pion.club.cc.cmu.edu>
 
 Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009:
 > I was planning to try a migration today, should I better wait a little?
 
 I'd say go for it, just be aware you'll need to reindex soon. For the
 full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1.
 
 From nicolas.pouillard@gmail.com  Wed Aug  5 13:58:43 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Wed, 05 Aug 2009 19:58:43 +0200
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249493896-sup-7335@pion.club.cc.cmu.edu>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1249480531-sup-9805@masanjin.net>
 	<1249485678-sup-4545@pion.club.cc.cmu.edu>
 	<1249493306-sup-4994@ausone.home>
 	<1249493896-sup-7335@pion.club.cc.cmu.edu>
 Message-ID: <1249495000-sup-6057@ausone.home>
 
 Excerpts from Rich Lane's message of Wed Aug 05 19:48:11 +0200 2009:
 > Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009:
 > > I was planning to try a migration today, should I better wait a little?
 > 
 > I'd say go for it, just be aware you'll need to reindex soon. For the
 > full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1.
 
 When you say the svn version you mean the trunk or the 1.0-branch ?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From rlane@club.cc.cmu.edu  Wed Aug  5 14:06:39 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 05 Aug 2009 14:06:39 -0400
 Subject: [sup-talk] [PATCH] xapian: drop excessively long terms
 In-Reply-To: <1249495000-sup-6057@ausone.home>
 References: <1249167369-16043-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1249480531-sup-9805@masanjin.net>
 	<1249485678-sup-4545@pion.club.cc.cmu.edu>
 	<1249493306-sup-4994@ausone.home>
 	<1249493896-sup-7335@pion.club.cc.cmu.edu>
 	<1249495000-sup-6057@ausone.home>
 Message-ID: <1249495530-sup-6312@pion.club.cc.cmu.edu>
 
 Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:58:43 -0400 2009:
 > Excerpts from Rich Lane's message of Wed Aug 05 19:48:11 +0200 2009:
 > > Excerpts from Nicolas Pouillard's message of Wed Aug 05 13:29:48 -0400 2009:
 > > > I was planning to try a migration today, should I better wait a little?
 > > 
 > > I'd say go for it, just be aware you'll need to reindex soon. For the
 > > full experience compile svn xapian and export XAPIAN_PREFER_CHERT=1.
 > 
 > When you say the svn version you mean the trunk or the 1.0-branch ?
 
 Trunk.
 
 From wmorgan-sup@masanjin.net  Wed Aug  5 16:03:09 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 05 Aug 2009 13:03:09 -0700
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249481294-sup-9967@chistera.yi.org>
 References: <1249481294-sup-9967@chistera.yi.org>
 Message-ID: <1249502171-sup-8079@masanjin.net>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
 > it is my impression that sup is ignoring SIGTERM, whereas I would be
 > expecting for sup to clean up (including removal of the lock file) and
 > exit normally upon receiving this signal.
 
 Good point. I've fixed that in branch ncurses-fixes, which I've merged
 into next. Let me know if it works for you.
 
 I'm also happy to report that I've finally managed to get Sup to deal
 with screen resizes, which, oddly enough, was a related problem. Go me!
 Steps closer to curses-induced insanity: 4!
 
 Available on next or ncurses-fixes branches.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Wed Aug  5 16:25:49 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Wed, 05 Aug 2009 22:25:49 +0200
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249502171-sup-8079@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 Message-ID: <1249503870-sup-1415@ausone.home>
 
 Excerpts from William Morgan's message of Wed Aug 05 22:03:09 +0200 2009:
 > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
 > > it is my impression that sup is ignoring SIGTERM, whereas I would be
 > > expecting for sup to clean up (including removal of the lock file) and
 > > exit normally upon receiving this signal.
 > 
 > Good point. I've fixed that in branch ncurses-fixes, which I've merged
 > into next. Let me know if it works for you.
 > 
 > I'm also happy to report that I've finally managed to get Sup to deal
 > with screen resizes, which, oddly enough, was a related problem. Go me!
 > Steps closer to curses-induced insanity: 4!
 > 
 > Available on next or ncurses-fixes branches.
 
 With the ncurses-fixes branch (even with the last patch), when I launch sup
 I get a blank screen (with the status bar saying "Searching for threads...".
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From bwalton@artsci.utoronto.ca  Wed Aug  5 16:35:51 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 05 Aug 2009 16:35:51 -0400
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249502171-sup-8079@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 Message-ID: <1249504381-sup-8445@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009:
 
 > Good point. I've fixed that in branch ncurses-fixes, which I've merged
 > into next. Let me know if it works for you.
 
 I just pulled next and fired it up.  It was _hoooooribly_,
 _bruuuutallly_ slow to load the index.  I git bisected between my
 previous running ORIG_HEAD and HEAD.  I came up with 75d9f5e3db as the
 offender.  It seems to do what you intend but (for me, anyway) at the
 expense of really bad interactivity.  [We're talking 10+ minutes to
 load the index part way...]
 
 This doesn't help identify the problem, but I'd be looking at the
 Ncurses.nodelay bits...
 
 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/20090805/b4062212/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Wed Aug  5 17:24:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 05 Aug 2009 14:24:49 -0700
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249503870-sup-1415@ausone.home>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<1249503870-sup-1415@ausone.home>
 Message-ID: <1249507336-sup-7887@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-08-05:
 > With the ncurses-fixes branch (even with the last patch), when I
 > launch sup I get a blank screen (with the status bar saying "Searching
 > for threads...".
 
 Dammit. I see that too, on some computers. The problem is that
 Ncurses.getch is actually blocking the background threads from working.
 (You can tell because threads will start loading when you press lots of
 keys.)
 
 I've unmerged the branch from next for the time being.
 
 The problem is the removal of the select() in nonblocking_getch
 (buffer.rb circa line 25). With it in, resizes don't work right. With it
 removed, background threads are blocked on some computers. Not sure what
 makes the difference. Sigh...
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Wed Aug  5 17:28:43 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 05 Aug 2009 17:28:43 -0400
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249502171-sup-8079@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 Message-ID: <1249507702-sup-8439@javelin>
 
 Excerpts from William Morgan's message of Wed Aug 05 16:03:09 -0400 2009:
 > I'm also happy to report that I've finally managed to get Sup to deal
 > with screen resizes, which, oddly enough, was a related problem. Go me!
 > Steps closer to curses-induced insanity: 4!
 
 Sounds exciting. What was the fix?
 
 Cheers,
 Edward
 
 From igor.brkic@fer.hr  Wed Aug  5 19:24:38 2009
 From: igor.brkic@fer.hr (Igor Brkic)
 Date: Thu, 06 Aug 2009 01:24:38 +0200
 Subject: [sup-talk] sup crashing after sending mail
 In-Reply-To: <1249486021-sup-1246@masanjin.net>
 References: <CBBB81512D1FE445823400465FCCFFF2D8AA45@sluga.fer.hr>
 	<1249486021-sup-1246@masanjin.net>
 Message-ID: <1249514106-sup-9112@xps>
 
 Excerpts from William Morgan's message of Sri Kol 05 17:29:27 +0200 2009:
 > A few people have reported this and I'm trying to track it down. Would
 > you mind applying the following patch, and then running:
 >   sup-sync -a sup://sent
 > 
 > Hopefully that will generate a little debugging output I can use. Thanks!
 
 I (partially) solved/hacked the problem. The problem was (I think) in wrong
 set locale and Sup not being able to recognize and compare sending date
 (which had croatian tags for month and day of the week) and Time.now (which
 was whole in english/universal format).
 
 I solved the problem by commenting out the "Time.parse time, 0" (line 15 in
 file lib/sup/mbox.rb).
 
 It's not perfect solution (if that line should be commented out, it would
 be :D), but for me it works for now (I'm writing this mail from it).
 
 Cheers!
 Igor Brkic
 
 From wmorgan-sup@masanjin.net  Thu Aug  6 10:40:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 06 Aug 2009 07:40:08 -0700
 Subject: [sup-talk] sup crashing after sending mail
 In-Reply-To: <1249514106-sup-9112@xps>
 References: <CBBB81512D1FE445823400465FCCFFF2D8AA45@sluga.fer.hr>
 	<1249486021-sup-1246@masanjin.net> <1249514106-sup-9112@xps>
 Message-ID: <1249568949-sup-3922@masanjin.net>
 
 Reformatted excerpts from Igor Brkic's message of 2009-08-05:
 > I solved the problem by commenting out the "Time.parse time, 0" (line
 > 15 in file lib/sup/mbox.rb).
 
 I'm glad that works, but I have a hard time understanding why.
 
 That line is for parsing the mbox "From " separator line (which has a
 date on it). It has nothing to do with the date field in the message,
 which is what isn't being set (and thus raising the exception).
 
 If the date parsing on that line is screwed up, then I would except to
 see an out-of-sync error raised by Sup, since it would be expecting an
 mbox "From " separator line and wouldn't detect the line as such.
 
 If you feel like it, send me a small mbox file (possible your
 ~/.sup/sent.mbox after being censored) and I can take a look.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From igor.brkic@fer.hr  Thu Aug  6 12:57:03 2009
 From: igor.brkic@fer.hr (Igor Brkic)
 Date: Thu, 06 Aug 2009 18:57:03 +0200
 Subject: [sup-talk] sup crashing after sending mail
 In-Reply-To: <1249568949-sup-3922@masanjin.net>
 References: <CBBB81512D1FE445823400465FCCFFF2D8AA45@sluga.fer.hr>
 	<1249486021-sup-1246@masanjin.net> <1249514106-sup-9112@xps>
 	<1249568949-sup-3922@masanjin.net>
 Message-ID: <1249576777-sup-3885@xps>
 
 Excerpts from William Morgan's message of ?et Kol 06 16:40:08 +0200 2009:
 > 
 > If you feel like it, send me a small mbox file (possible your
 > ~/.sup/sent.mbox after being censored) and I can take a look.
 
 This is weird... For the last hour and a half I've been trying to
 reproduce the error I was having - I uncommented the line in mbox.rb,
 returned locale settings to previous state - but everything is working 
 flawless. Whatever I make, it won't crash. I'll keep trying, though :)
 
 I'm afraid I can't send you the mbox file that is causing sup to crash
 because I deleted all logs and sent.mbox files the moment all started
 to work.
 
 
 From wmorgan-sup@masanjin.net  Thu Aug  6 13:45:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 06 Aug 2009 10:45:50 -0700
 Subject: [sup-talk] sup crashing after sending mail
 In-Reply-To: <1249579173-sup-573@xps>
 References: <CBBB81512D1FE445823400465FCCFFF2D8AA45@sluga.fer.hr>
 	<1249486021-sup-1246@masanjin.net> <1249514106-sup-9112@xps>
 	<1249568949-sup-3922@masanjin.net> <1249576777-sup-3885@xps>
 	<1249579173-sup-573@xps>
 Message-ID: <1249580716-sup-6413@masanjin.net>
 
 Reformatted excerpts from Igor Brkic's message of 2009-08-06:
 > I attached output of "sup-sync -a sup://sent" with patch you sent me
 > applyed (sync-log.txt).
 
 Awesome. This looks very juicy. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Aug  6 13:53:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 06 Aug 2009 10:53:43 -0700
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249507336-sup-7887@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<1249503870-sup-1415@ausone.home>
 	<1249507336-sup-7887@masanjin.net>
 Message-ID: <1249581215-sup-2548@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-08-05:
 > The problem is the removal of the select() in nonblocking_getch
 > (buffer.rb circa line 25). With it in, resizes don't work right. With
 > it removed, background threads are blocked on some computers. Not sure
 > what makes the difference. Sigh...
 
 Ok, I've tracked this down. FWIW, this is a problem that's been around
 in ruby ncurses libraries since at least 2005, when I complained about
 it on ruby-core.
 
 In many ruby ncurses libraries, including the most recent gem,
 Ncurses.getch blocks all Ruby threads from running. That's a bug. The
 workaround is to wrap it in a select() call. But then you have to handle
 sigwinch manually (i.e via Kernel#trap), because getch won't return a
 resize "keystroke" until the user hits an actual key.
 
 The libncurses-ruby library on modern Ubuntu systems actually doesn't
 have this problem. You can set nodelay false, throw out the select call,
 and everything works the way it's supposed to: background threads run,
 and you get a resize keystroke when a sigwinch happens without you
 having to install your own handler. And that's the library I had been
 developing against, which is why everything worked on one computer but
 didn't work on the others.
 
 Anyways, for those who were having problems with this branch before,
 please try the most recent version and confirm that:
 1. Email threads load as normal, i.e. in the background.
 2. Resizing the terminal refreshes the screen without you having to
   press any keys.
 3. Ctrl-l still works.
 4. Ctrl-c still works (prompts you, and y/n do the right thing).
 5. Killing Sup works.
 
 If everyone's happy, I'll merge this branch into next.
 
 If you're curious about whether you have a good or bad ncurses library,
 run this program: (But either should work correctly with Sup.)
 
   require 'rubygems'
   require 'ncurses'
   require 'thread'
 
   Ncurses.initscr
   Ncurses.noecho
   Ncurses.cbreak
   Ncurses.curs_set 0
 
   Thread.new do
     sleep 0.1
     Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is GOOD."
   end
 
   begin
     Ncurses.stdscr.mvaddstr 0, 0, "ncurses library is BAD."
     Ncurses.getch
   ensure
     Ncurses.curs_set 1
     Ncurses.endwin
     puts "bye"
   end
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Thu Aug  6 14:09:35 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Thu, 06 Aug 2009 20:09:35 +0200
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249581215-sup-2548@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<1249503870-sup-1415@ausone.home>
 	<1249507336-sup-7887@masanjin.net>
 	<1249581215-sup-2548@masanjin.net>
 Message-ID: <1249582142-sup-9952@ausone.home>
 
 Excerpts from William Morgan's message of Thu Aug 06 19:53:43 +0200 2009:
 > Reformatted excerpts from William Morgan's message of 2009-08-05:
 > > The problem is the removal of the select() in nonblocking_getch
 > > (buffer.rb circa line 25). With it in, resizes don't work right. With
 > > it removed, background threads are blocked on some computers. Not sure
 > > what makes the difference. Sigh...
 [...]
 > If everyone's happy, I'll merge this branch into next.
 
 Works just great! Thanks.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From dato@net.com.org.es  Thu Aug  6 14:37:25 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Thu, 6 Aug 2009 20:37:25 +0200
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249502171-sup-8079@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 Message-ID: <20090806183725.GA8363@chistera.yi.org>
 
 + William Morgan (Wed, 05 Aug 2009 13:03:09 -0700):
 
 > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-05:
 > > it is my impression that sup is ignoring SIGTERM, whereas I would be
 > > expecting for sup to clean up (including removal of the lock file) and
 > > exit normally upon receiving this signal.
 
 > Good point. I've fixed that in branch ncurses-fixes, which I've merged
 > into next. Let me know if it works for you.
 
 Everything seems to work fine as of 3478e40, including sup terminating
 upon SIGTERM. If I may, I'd suggest normal termination instead of
 raising an exception. IMHO, it is expected that programs that capture
 SIGTERM, will do cleanup and exit normally, rather than behave as if an
 error had happened. (Perhaps it'd be difficult to exit sup cleanly from
 the handler in any other way than an exception: that, I don't know.)
 
 Thanks, in any case.
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From bwalton@artsci.utoronto.ca  Thu Aug  6 19:56:51 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 06 Aug 2009 19:56:51 -0400
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249581215-sup-2548@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<1249503870-sup-1415@ausone.home>
 	<1249507336-sup-7887@masanjin.net>
 	<1249581215-sup-2548@masanjin.net>
 Message-ID: <1249602985-sup-8547@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Thu Aug 06 13:53:43 -0400 2009:
 > Ok, I've tracked this down. FWIW, this is a problem that's been around
 > in ruby ncurses libraries since at least 2005, when I complained about
 > it on ruby-core.
 
 ...yup, looks like you stuck the landing this time! :)
 
 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/20090806/72c6f045/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Thu Aug  6 21:38:53 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 06 Aug 2009 18:38:53 -0700
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <20090806183725.GA8363@chistera.yi.org>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<20090806183725.GA8363@chistera.yi.org>
 Message-ID: <1249609105-sup-5858@masanjin.net>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06:
 > Everything seems to work fine as of 3478e40, including sup terminating
 > upon SIGTERM. If I may, I'd suggest normal termination instead of
 > raising an exception. IMHO, it is expected that programs that capture
 > SIGTERM, will do cleanup and exit normally, rather than behave as if
 > an error had happened.
 
 Good idea. Try it now.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From dato@net.com.org.es  Fri Aug  7 06:31:51 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Fri, 7 Aug 2009 12:31:51 +0200
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249609105-sup-5858@masanjin.net>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<20090806183725.GA8363@chistera.yi.org>
 	<1249609105-sup-5858@masanjin.net>
 Message-ID: <20090807103151.GA20799@chistera.yi.org>
 
 + William Morgan (Thu, 06 Aug 2009 18:38:53 -0700):
 
 > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-06:
 > > Everything seems to work fine as of 3478e40, including sup terminating
 > > upon SIGTERM. If I may, I'd suggest normal termination instead of
 > > raising an exception. IMHO, it is expected that programs that capture
 > > SIGTERM, will do cleanup and exit normally, rather than behave as if
 > > an error had happened.
 
 > Good idea. Try it now.
 
 Ah, excellent: works as suggested now.
 
 Regarding 57dea7a (refactor index locking interaction and replace
 suicidemanager), I'll note that at least on my system, and after having
 moved to Xapian, those codepaths no longer execute. That is, if a sup is
 running and a second one is started, it never gets to ask whether to
 suggest dieing to the first one, because this second one dies with:
 
 [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
 [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
 [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
 [Fri Aug 07 12:31:05 +0200 2009] setting locale...
 .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
         from .../lib/sup/xapian_index.rb:24:in `new'
         from .../lib/sup/xapian_index.rb:24:in `initialize'
         from .../bin/sup:132:in `new'
         from .../bin/sup:132
 
 Thanks!
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From rlane@club.cc.cmu.edu  Thu Aug  6 15:32:44 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu,  6 Aug 2009 12:32:44 -0700
 Subject: [sup-talk] [PATCH] move xapian index loading into load_index
 Message-ID: <1249587164-14080-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |   17 ++++++++---------
  1 files changed, 8 insertions(+), 9 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 5a5dfc1..861c2a3 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -20,14 +20,16 @@ class XapianIndex < BaseIndex
      super
  
      @index_mutex = Monitor.new
 +  end
  
 -    @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")
 +  def load_index
 +    @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)
 +    @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
 @@ -35,9 +37,6 @@ class XapianIndex < BaseIndex
      @enquire.docid_order = Xapian::Enquire::ASCENDING
    end
  
 -  def load_index
 -  end
 -
    def save_index
    end
  
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Fri Aug  7 12:40:18 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 07 Aug 2009 12:40:18 -0400
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <20090807103151.GA20799@chistera.yi.org>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<20090806183725.GA8363@chistera.yi.org>
 	<1249609105-sup-5858@masanjin.net>
 	<20090807103151.GA20799@chistera.yi.org>
 Message-ID: <1249662782-sup-638@pion.club.cc.cmu.edu>
 
 Excerpts from Adeodato Sim?'s message of Fri Aug 07 06:31:51 -0400 2009:
 > Regarding 57dea7a (refactor index locking interaction and replace
 > suicidemanager), I'll note that at least on my system, and after having
 > moved to Xapian, those codepaths no longer execute. That is, if a sup is
 > running and a second one is started, it never gets to ask whether to
 > suggest dieing to the first one, because this second one dies with:
 > 
 > [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
 > [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
 > [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
 > [Fri Aug 07 12:31:05 +0200 2009] setting locale...
 > .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily
 > unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
 >         from .../lib/sup/xapian_index.rb:24:in `new'
 >         from .../lib/sup/xapian_index.rb:24:in `initialize'
 >         from .../bin/sup:132:in `new'
 >         from .../bin/sup:132
 
 I've just posted a patch that should fix this.
 
 From ezyang@MIT.EDU  Sat Aug  8 02:07:22 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 08 Aug 2009 02:07:22 -0400
 Subject: [sup-talk] Odd bug with lazy-loaded messages
 In-Reply-To: <1249319474-sup-8322@masanjin.net>
 References: <1248716007-sup-5156@javelin> <1249319474-sup-8322@masanjin.net>
 Message-ID: <1249711570-sup-2277@javelin>
 
 Excerpts from William Morgan's message of Mon Aug 03 13:18:50 -0400 2009:
 > This is because we store a couple variants of the address in the index
 > (e.g. the email address to the left of the @), so that a search on any
 > of them will bring up the message. Without #load_from_source!, the
 > message is loaded from the index, so it reflects those fields. So it's
 > basically a hack at this point. You could further hack it by undoing
 > that transformation. Or we could add the original version of the fields
 > to the index in a separate, non-searchable field, incurring the
 > associated storage penalties.
 
 Great.  I sprinkled a few extra load_from_source! calls and I think
 I made the weird behavior go away.  It's kind of sketchy though.
 
 >From 6c539b9c0fb952b0cc10c121cb906b1aefd58c31 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 1/3] Remove message pre-loading; optimizes for the common case.
 
 There are some load_from_source! calls to flush away extra
 header info that we don't want displayed.  We may need to add
 this in more/less places.
 
 Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
 ---
  lib/sup/modes/thread-index-mode.rb |    1 -
  lib/sup/modes/thread-view-mode.rb  |    2 ++
  2 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index b671119..5e58072 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -105,7 +105,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
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 737f6f1..94e3ed7 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -124,6 +124,7 @@ EOS
        end
      end
  
 +    latest.load_from_source!
      @layout[latest].state = :open if @layout[latest].state == :closed
      @layout[earliest].state = :detailed if earliest.has_label?(:unread) || @thread.size == 1
  
 @@ -555,6 +556,7 @@ private
  
    def initial_state_for m
      if m.has_label?(:starred) || m.has_label?(:unread)
 +      m.load_from_source!
        :open
      else
        :closed
 -- 
 1.6.3.3
 
 From dato@net.com.org.es  Sat Aug  8 05:23:25 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Sat, 8 Aug 2009 11:23:25 +0200
 Subject: [sup-talk] sup ignoring SIGTERM?
 In-Reply-To: <1249662782-sup-638@pion.club.cc.cmu.edu>
 References: <1249481294-sup-9967@chistera.yi.org>
 	<1249502171-sup-8079@masanjin.net>
 	<20090806183725.GA8363@chistera.yi.org>
 	<1249609105-sup-5858@masanjin.net>
 	<20090807103151.GA20799@chistera.yi.org>
 	<1249662782-sup-638@pion.club.cc.cmu.edu>
 Message-ID: <20090808092325.GA2392@chistera.yi.org>
 
 + Rich Lane (Fri, 07 Aug 2009 12:40:18 -0400):
 > > [Fri Aug 07 12:31:05 +0200 2009] using character set encoding "UTF-8"
 > > [Fri Aug 07 12:31:05 +0200 2009] using index Redwood::XapianIndex
 > > [Fri Aug 07 12:31:05 +0200 2009] dynamically loading setlocale() from libc.so.6
 > > [Fri Aug 07 12:31:05 +0200 2009] setting locale...
 > > .../lib/sup/xapian_index.rb:24:in `initialize': Resource temporarily
 > > unavailable - /home/adeodato/.sup/entries.db (Errno::EAGAIN)
 > >         from .../lib/sup/xapian_index.rb:24:in `new'
 > >         from .../lib/sup/xapian_index.rb:24:in `initialize'
 > >         from .../bin/sup:132:in `new'
 > >         from .../bin/sup:132
 
 > I've just posted a patch that should fix this.
 
 It works, thank you!
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From ezyang@MIT.EDU  Sun Aug  9 04:40:33 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sun, 09 Aug 2009 04:40:33 -0400
 Subject: [sup-talk] Odd bug with lazy-loaded messages
 In-Reply-To: <1249711570-sup-2277@javelin>
 References: <1248716007-sup-5156@javelin> <1249319474-sup-8322@masanjin.net>
 	<1249711570-sup-2277@javelin>
 Message-ID: <1249807206-sup-55@javelin>
 
 Excerpts from Edward Z. Yang's message of Sat Aug 08 02:07:22 -0400 2009:
 > Great.  I sprinkled a few extra load_from_source! calls and I think
 > I made the weird behavior go away.  It's kind of sketchy though.
 
 It looks like it's still a problem in some sporadic cases.  Going to
 submit a more thorough patch soon.
 
 Cheers,
 Edward
 
 From jstewart@fusionary.com  Mon Aug 10 09:22:43 2009
 From: jstewart@fusionary.com (Jason Stewart)
 Date: Mon, 10 Aug 2009 09:22:43 -0400
 Subject: [sup-talk] Starring messages in a hook
 Message-ID: <1249910430-sup-4573@JasonsComputer-3.local>
 
 Hello,
 
 New sup user here and I have to say that I'm very impressed with it even
 though I've only been using it for a few days. 
 
 I'm using a before-add-message to label messages, and was wondering if
 there's a way to star them in this hook? Looking at the source for
 message.rb I see an add_label, but no add_star.
 
 From ismith@MIT.EDU  Mon Aug 10 11:07:38 2009
 From: ismith@MIT.EDU (Ian Smith)
 Date: Mon, 10 Aug 2009 11:07:38 -0400
 Subject: [sup-talk] Starring messages in a hook
 In-Reply-To: <1249910430-sup-4573@JasonsComputer-3.local>
 References: <1249910430-sup-4573@JasonsComputer-3.local>
 Message-ID: <1249916791-sup-4269@baad>
 
 Hi Jason,
 
 Starred messages are labeled "Starred"; presumably just adding this
 label to the message would do what you want.
 
 Ian
 
 Excerpts from Jason Stewart's message of Mon Aug 10 09:22:43 -0400 2009:
 > Hello,
 > 
 > New sup user here and I have to say that I'm very impressed with it even
 > though I've only been using it for a few days. 
 > 
 > I'm using a before-add-message to label messages, and was wondering if
 > there's a way to star them in this hook? Looking at the source for
 > message.rb I see an add_label, but no add_star.
 -- 
 Ian Smith
 ismith at mit.edu
 ismith at bostonaccess.org
 
 From wmorgan-sup@masanjin.net  Tue Aug 11 16:14:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 11 Aug 2009 13:14:44 -0700
 Subject: [sup-talk] some internal api refactors
 Message-ID: <1250021119-sup-4253@masanjin.net>
 
 Hi Rich, and others,
 
 In the branch various-api-refactors I've made a couple significant
 genotypic changes to the index and polling API that I want to make sure
 are in line with your evil plans. Commit 8aa1370d in particular replaces
 Index.sync_message with three methods, one for adding new messages, one
 for updating existing messages, and one for just tweaking the labels.
 The current implementation just calls the original sync_message
 implementation for all three. The rest of the changes are tweaks in the
 various consumers of these messages.
 
 The intention is that this will be useful both for Xapian and Sup the
 server, which may need to distinguish between these three methods of
 index access (or may simply want to for speed).
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Aug 11 16:18:15 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 11 Aug 2009 13:18:15 -0700
 Subject: [sup-talk] [PATCH] move xapian index loading into load_index
 In-Reply-To: <1249587164-14080-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1249587164-14080-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250021889-sup-3224@masanjin.net>
 
 Applied, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Aug 11 16:22:30 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 11 Aug 2009 13:22:30 -0700
 Subject: [sup-talk] Stack overflow in regexp matcher
 In-Reply-To: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com>
 References: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com>
 Message-ID: <1250021966-sup-933@masanjin.net>
 
 Hi Mark,
 
 Reformatted excerpts from Mark Drayton's message of 2009-08-03:
 > ## read 440m (about 52%) @ 2.2m/s. 0:03:19 elapsed, about 0:03:03 remaining
 > Stack overflow in regexp matcher:
 > /,\s*(?=(?:[^"]*"[^"]*")*(?![^"]*"))/ (RegexpError)
 
 Interesting. Looks like Sup is trying to split a header line into
 multiple email addresses and something's causing it to bomb. Are you
 able to identify the line that's causing this problem? That would be
 helpful to know.
 
 > This error seems to have cropped up in other software so I suspect
 > it's a problem with Ruby, not sup. Anyone able to confirm this?
 
 It's a problem with Ruby's regular expression implementation, I suppose,
 but we've never seen it before. The solution is to either tweak the
 regexp until it starts working, or implement a custom parsing solution,
 neither of which sounds that entertaining...
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Aug 11 16:28:46 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 11 Aug 2009 13:28:46 -0700
 Subject: [sup-talk] [PATCH] run-mailcap fix
 In-Reply-To: <1249226521-sup-4719@localdomain>
 References: <1249226521-sup-4719@localdomain>
 Message-ID: <1250022259-sup-8328@masanjin.net>
 
 Hi Beno?t,
 
 Reformatted excerpts from Beno?t PIERRE's message of 2009-08-02:
 > The attached patch fix this by not redirecting stderr to /dev/null.
 > It also restores the correct ncurses state (including arrow
 > keypresses, thanks to Edward Z. Yang recent patch).
 
 Thanks! Not redirecting stderr to /dev/null is probably fine. But how
 about calling BufferManager.shell_out instead?
 
 If you want to submit a proper git commit via git-format-email, I will
 be happy to apply it and you can get your name in the illustrious Sup
 contributor roster. Otherwise I will make this change for you.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From benoit.pierre@gmail.com  Tue Aug 11 18:09:40 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt=20PIERRE?=)
 Date: Wed, 12 Aug 2009 00:09:40 +0200
 Subject: [sup-talk] [PATCH run-mailcap 1/2] Don't redirect stderr to
 	/dev/null when calling run-mailcap.
 In-Reply-To: <1250022259-sup-8328@masanjin.net>
 References: <1250022259-sup-8328@masanjin.net>
 Message-ID: <1250028581-15826-1-git-send-email-benoit.pierre@gmail.com>
 
 Some programs will fail to work correctly if this is done, like for
 example: w3m --dump, to view HTML files.
 ---
  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 0d742d9..4c947e1 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -131,7 +131,7 @@ EOS
      def initial_state; :open end
      def viewable?; @lines.nil? end
      def view_default! path
 -      cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}' 2>/dev/null"
 +      cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'"
        Redwood::log "running: #{cmd.inspect}"
        system cmd
        $? == 0
 -- 
 1.6.3.3
 
 
 From benoit.pierre@gmail.com  Tue Aug 11 18:09:41 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt=20PIERRE?=)
 Date: Wed, 12 Aug 2009 00:09:41 +0200
 Subject: [sup-talk] [PATCH run-mailcap 2/2] Use BufferManager.shell_out to
 	call run-mailcap instead of system.
 In-Reply-To: <1250028581-15826-1-git-send-email-benoit.pierre@gmail.com>
 References: <1250028581-15826-1-git-send-email-benoit.pierre@gmail.com>
 Message-ID: <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com>
 
 This ensure ncurses state is correctly restored upon command completion.
 ---
  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 4c947e1..1910abd 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -133,7 +133,7 @@ EOS
      def view_default! path
        cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'"
        Redwood::log "running: #{cmd.inspect}"
 -      system cmd
 +      BufferManager.shell_out(cmd)
        $? == 0
      end
  
 -- 
 1.6.3.3
 
 
 From rlane@club.cc.cmu.edu  Wed Aug 12 01:26:53 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 12 Aug 2009 01:26:53 -0400
 Subject: [sup-talk] some internal api refactors
 In-Reply-To: <1250021119-sup-4253@masanjin.net>
 References: <1250021119-sup-4253@masanjin.net>
 Message-ID: <1250054282-sup-9053@pion.club.cc.cmu.edu>
 
 It's worth noting that update_message_state needs to handle modified
 refs and snippets as well as labels. Maybe add a comment about this in
 BaseIndex?
 
 From mark@markdrayton.info  Wed Aug 12 04:45:01 2009
 From: mark@markdrayton.info (Mark Drayton)
 Date: Wed, 12 Aug 2009 09:45:01 +0100
 Subject: [sup-talk] Stack overflow in regexp matcher
 In-Reply-To: <1250021966-sup-933@masanjin.net>
 References: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com>
 	<1250021966-sup-933@masanjin.net>
 Message-ID: <92457f310908120145n453d6639mf22fe68b62054392@mail.gmail.com>
 
 Hi William
 
 On Tue, Aug 11, 2009 at 9:22 PM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 > Interesting. Looks like Sup is trying to split a header line into
 > multiple email addresses and something's causing it to bomb. Are you
 > able to identify the line that's causing this problem? That would be
 > helpful to know.
 
 Sorry, I should have dug a bit deeper before reporting this. I was
 naively assuming it was a known problem (though Google didn't know, so
 I guess it's not) and that the answer would be "upgrade foo".
 
 The line it's choking on is 284058 bytes long and contains ~6400
 addresses. (gotta love mail from "internal communications"). If I
 halve the number of addresses it works, so perhaps this isn't worth
 fixing at all. If you do want to tackle it I'm happy to help off-list.
 
 Cheers,
 
 Mark
 
 From ingmar@exherbo.org  Wed Aug 12 09:05:35 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Wed, 12 Aug 2009 15:05:35 +0200
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1249056691-sup-9011@pion.club.cc.cmu.edu>
 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>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 	<1248709681-sup-4141@entry>
 	<1248710432-sup-1734@pion.club.cc.cmu.edu>
 	<1249056691-sup-9011@pion.club.cc.cmu.edu>
 Message-ID: <1250082297-sup-6018@cannonball>
 
 Excerpts from Rich Lane's message of Fri Jul 31 18:20:41 +0200 2009:
 > Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009:
 > > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
 > > > Reformatted excerpts from Rich Lane's message of 2009-07-25:
 > > > > One issue I've noticed is that removing labels from messages doesn't
 > > > > always immediately work.
 > > > 
 > > > Is this true even after you sync changes to the index? What about if you
 > > > reload the label list buffer? ('@')
 > > 
 > > Yes. This is looking like a Xapian bug - I've reproduced it without any
 > > Sup code. I'm working on a fix.
 > 
 > I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian
 > SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1).
 
 Could you point me to the SVN revision containing the fix? I'd like to
 backport the fix to my Xapian 1.0.14 packages, pending 1.0.15 release.
 
 Thanks!
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From nicolas.pouillard@gmail.com  Wed Aug 12 10:32:04 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Wed, 12 Aug 2009 16:32:04 +0200
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1250082297-sup-6018@cannonball>
 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>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 	<1248709681-sup-4141@entry>
 	<1248710432-sup-1734@pion.club.cc.cmu.edu>
 	<1249056691-sup-9011@pion.club.cc.cmu.edu>
 	<1250082297-sup-6018@cannonball>
 Message-ID: <1250087467-sup-6888@ausone.inria.fr>
 
 Excerpts from Ingmar Vanhassel's message of Wed Aug 12 15:05:35 +0200 2009:
 > Excerpts from Rich Lane's message of Fri Jul 31 18:20:41 +0200 2009:
 > > Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009:
 > > > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
 > > > > Reformatted excerpts from Rich Lane's message of 2009-07-25:
 > > > > > One issue I've noticed is that removing labels from messages doesn't
 > > > > > always immediately work.
 > > > > 
 > > > > Is this true even after you sync changes to the index? What about if you
 > > > > reload the label list buffer? ('@')
 > > > 
 > > > Yes. This is looking like a Xapian bug - I've reproduced it without any
 > > > Sup code. I'm working on a fix.
 > > 
 > > I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian
 > > SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1).
 
 BTW, does someone have successfully built Xapian under Mac OS X ?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From taruti@taruti.net  Thu Aug 13 03:32:02 2009
 From: taruti@taruti.net (Taru Karttunen)
 Date: Thu, 13 Aug 2009 10:32:02 +0300
 Subject: [sup-talk] Sup crashing
 Message-ID: <1250148617-sup-6053@oz.taruti.net>
 
 Hello
 
 I am using Sup git master version and it started to crash today
 when viewing messages with a label. Any hints how to fix this?
 
 --- ArgumentError from thread: load threads for thread-index-mode
 :93349 is out of range [0..93204] for IndexReader#[]
 /usr/lib/ruby/1.8/ferret/index.rb:421:in `[]'
 /usr/lib/ruby/1.8/ferret/index.rb:421:in `[]'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /usr/lib/ruby/1.8/ferret/index.rb:413:in `[]'
 ./lib/sup/ferret_index.rb:151:in `each_id_by_date'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 ./lib/sup/ferret_index.rb:151:in `each_id_by_date'
 ./lib/sup/ferret_index.rb:150:in `each'
 ./lib/sup/ferret_index.rb:150:in `each_id_by_date'
 ./lib/sup/thread.rb:328:in `load_n_threads'
 ./lib/sup/modes/thread-index-mode.rb:623:in `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 ./lib/sup/modes/thread-index-mode.rb:607:in `load_n_threads_background'
 ./lib/sup.rb:77:in `reporting_thread'
 ./lib/sup.rb:75:in `initialize'
 ./lib/sup.rb:75:in `new'
 ./lib/sup.rb:75:in `reporting_thread'
 ./lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background'
 ./lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 ./lib/sup/modes/label-search-results-mode.rb:33:in `spawn_nicely'
 ./lib/sup/modes/label-list-mode.rb:93:in `select_label'
 ./lib/sup/mode.rb:50:in `send'
 ./lib/sup/mode.rb:50:in `handle_input'
 ./lib/sup/buffer.rb:249:in `handle_input'
 bin/sup:236
 
 - Taru Karttunen
 
 From rlane@club.cc.cmu.edu  Fri Aug 14 01:23:21 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 14 Aug 2009 01:23:21 -0400
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1250082297-sup-6018@cannonball>
 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>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 	<1248709681-sup-4141@entry>
 	<1248710432-sup-1734@pion.club.cc.cmu.edu>
 	<1249056691-sup-9011@pion.club.cc.cmu.edu>
 	<1250082297-sup-6018@cannonball>
 Message-ID: <1250227281-sup-8626@pion.club.cc.cmu.edu>
 
 Excerpts from Ingmar Vanhassel's message of Wed Aug 12 09:05:35 -0400 2009:
 > Could you point me to the SVN revision containing the fix? I'd like to
 > backport the fix to my Xapian 1.0.14 packages, pending 1.0.15 release.
 
 Revision 13219.
 
 From guillaume.quintard@gmail.com  Fri Aug 14 06:18:25 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Fri, 14 Aug 2009 12:18:25 +0200
 Subject: [sup-talk] Poll delay and states not really saved
 Message-ID: <1250244850-sup-5869@altis>
 
 Hi,
 Two things:
 - I'm using xapian (git) and it seems that staates are only saved during
 exits. Meaning that if I clean my inbox with A, then save with $, and
 then refresh with @., all the messages are still here (as read, though).
 
 - Can we have a config options for the time between poll, currently it's
 hardcoded to 300s but I like to hammer my gmail box with requests.
 
 Apart from that, sup works pretty well with xapian.
 
 Cheers,
 
 -- 
 Guillaume
 
 From ingmar@exherbo.org  Fri Aug 14 07:12:04 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Fri, 14 Aug 2009 13:12:04 +0200
 Subject: [sup-talk] Poll delay and states not really saved
 In-Reply-To: <1250244850-sup-5869@altis>
 References: <1250244850-sup-5869@altis>
 Message-ID: <1250248287-sup-2973@cannonball>
 
 Excerpts from Guillaume Quintard's message of Fri Aug 14 12:18:25 +0200 2009:
 > Hi,
 > Two things:
 > - I'm using xapian (git) and it seems that staates are only saved during
 > exits. Meaning that if I clean my inbox with A, then save with $, and
 > then refresh with @., all the messages are still here (as read, though).
 > 
 > - Can we have a config options for the time between poll, currently it's
 > hardcoded to 300s but I like to hammer my gmail box with requests.
 > 
 > Apart from that, sup works pretty well with xapian.
 > 
 > Cheers,
 > 
 
 See http://mid.gmane.org/1248710432-sup-1734 at pion.club.cc.cmu.edu
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From guillaume.quintard@gmail.com  Fri Aug 14 07:18:44 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Fri, 14 Aug 2009 13:18:44 +0200
 Subject: [sup-talk] Poll delay and states not really saved
 In-Reply-To: <1250248287-sup-2973@cannonball>
 References: <1250244850-sup-5869@altis> <1250248287-sup-2973@cannonball>
 Message-ID: <1250248660-sup-2819@altis>
 
 Excerpts from Ingmar Vanhassel's message of Fri Aug 14 13:12:04 +0200 2009:
 > See http://mid.gmane.org/1248710432-sup-1734 at pion.club.cc.cmu.edu
 > 
 
 ah thanks, didn't remember that mail.
 
 but the poll delay still stands :-)
 
 -- 
 Guillaume
 
 From wmorgan-sup@masanjin.net  Fri Aug 14 16:17:38 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 14 Aug 2009 13:17:38 -0700
 Subject: [sup-talk] [PATCH run-mailcap 2/2] Use BufferManager.shell_out
 	to call run-mailcap instead of system.
 In-Reply-To: <1250028581-15826-2-git-send-email-benoit.pierre@gmail.com>
 References: <1250022259-sup-8328@masanjin.net>
 	<1250028581-15826-2-git-send-email-benoit.pierre@gmail.com>
 Message-ID: <1250281039-sup-2788@masanjin.net>
 
 Reformatted excerpts from Beno?t PIERRE's message of 2009-08-11:
 > This ensure ncurses state is correctly restored upon command completion.
 
 Both patches applies to branch run-mailcap-fixes, merged into next.
 Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Aug 14 16:20:28 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 14 Aug 2009 13:20:28 -0700
 Subject: [sup-talk] Sup crashing
 In-Reply-To: <1250148617-sup-6053@oz.taruti.net>
 References: <1250148617-sup-6053@oz.taruti.net>
 Message-ID: <1250281208-sup-4199@masanjin.net>
 
 Reformatted excerpts from Taru Karttunen's message of 2009-08-13:
 > --- ArgumentError from thread: load threads for thread-index-mode
 > :93349 is out of range [0..93204] for IndexReader#[]
 
 Weird. Does sup-sync --optimize fix anything?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From benoit.pierre@gmail.com  Fri Aug 14 18:37:21 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Sat, 15 Aug 2009 00:37:21 +0200
 Subject: [sup-talk] [PATCH run-mailcap 2/2] Use BufferManager.shell_out
 	to call run-mailcap instead of system.
 In-Reply-To: <1250281039-sup-2788@masanjin.net>
 References: <1250022259-sup-8328@masanjin.net>
 	<1250028581-15826-2-git-send-email-benoit.pierre@gmail.com>
 	<1250281039-sup-2788@masanjin.net>
 Message-ID: <1250289386-sup-7331@localdomain>
 
 Excerpts from William Morgan's message of Fri Aug 14 22:17:38 +0200 2009:
 > Reformatted excerpts from Beno?t PIERRE's message of 2009-08-11:
 > > This ensure ncurses state is correctly restored upon command completion.
 > 
 > Both patches applies to branch run-mailcap-fixes, merged into next.
 
 Great!
 
 One problem though, I tested next, and 3478e400ae31b459b2875cc226796a6d4bba11f9
 (rewrap getch in select, handle sigwinch manually) introduced a regression: I
 get some 'key not handled' errors after run-mail has been called when sup is
 getting back control if I press for example an arrow... ;(
 
 Arrows become usable again after I press a "normal" key (like 'a').
 
 Cheers,
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 
 From benoit.pierre@gmail.com  Fri Aug 14 19:08:48 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Sat, 15 Aug 2009 01:08:48 +0200
 Subject: [sup-talk] [PATCH] Restore keypad mode after we force ncurses to
 	refresh the whole screen.
 In-Reply-To: <1250289386-sup-7331@localdomain>
 References: <1250022259-sup-8328@masanjin.net>
 	<1250028581-15826-2-git-send-email-benoit.pierre@gmail.com>
 	<1250281039-sup-2788@masanjin.net>
 	<1250289386-sup-7331@localdomain>
 Message-ID: <1250291137-sup-2796@localdomain>
 
 This also happen to fix a regression after a call to run-mailcap, since
 for some reason a screen resize event is triggered when we get control
 back...
 ---
  lib/sup/buffer.rb |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
 index b3a256f..09281e9 100644
 --- a/lib/sup/buffer.rb
 +++ b/lib/sup/buffer.rb
 @@ -270,6 +270,7 @@ EOS
  
      ## this magic makes Ncurses get the new size of the screen
      Ncurses.endwin
 +    Ncurses.stdscr.keypad 1
      Ncurses.refresh
      @sigwinch_mutex.synchronize { @sigwinch_happened = false }
      Redwood::log "new screen size is #{Ncurses.rows} x #{Ncurses.cols}"
 -- 
 1.6.3.3
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090815/a67dfe70/attachment.bin>
 
 From cworth@cworth.org  Sat Aug 15 00:05:32 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Fri, 14 Aug 2009 21:05:32 -0700
 Subject: [sup-talk] Introduction, thanks, and a tiny patch
 Message-ID: <1250307036-sup-8890@yoom>
 
 Hi. My name's Carl, and I've uh, been collecting email for 12 years.
 
 First off, I want to thank William and all contributors for sup! I
 just started using it this morning, and I'm amazed by it. I've long
 been frustrated by wrong-headed email systems, and also long been
 dreaming of one done right, (entirely label-and-search-based and
 focused on threads as the primary unit, bonus points if the UI is 100%
 keyboard-driven and integrates with emacs). What a dream come true to
 find sup!
 
 In my first use of sup, I was surprised by two things immediately:
 
    1. Most text is white-on-white (invisible) if the default terminal
       background color is white. I would suggest that the default
       background color be changed from "default" to "black" to avoid
       this trap.
 
    2. All of the mail I imported from various maildir folders was
       labelled as "unread", (in spite of the fact that a large
       majority of it had the 'S' tag for "seen" in the maildir
       filename). I tracked this down to my maildir filenames
       containing ',' characters to the left of the ':' like so:
 
 1250158845.M979457P4354V000000000000FE01I001B8B56_0.yoom,S=46114:2,S
 
 I've attached a patch to fix this second issue, (a single-character
 change).
 
 As for my involvement with sup, here are a couple of things I'd like
 to help with:
 
    1. I love the NewUserGuide, but I've needed a ReferenceManual for
       various issues already, (configuring colors, configuring SMTP,
       understanding the sources.yaml file well enough to be able to
       re-process mail that was mis-labelled the first time,
       etc.).
 
       The wiki has been useful for much of this already, but I'd like
       to have some of this information more cleanly organized, and
       perhaps distributed as plain-text in alongside the user
       guide. So I'd like to try pulling some existing information
       together, organizing things, and also identifying missing
       sections.
 
       One potential issue is that I don't see any explicit license
       terms on the wiki. Can I assume that any text on the wiki is
       suitable for putting into a document to be contributed to and
       distributed with sup?
 
    2. I really like the ideas William has posted on his blog about
       separating the interface from the guts of sup, (to make the new
       STS). I'd be happy to help with that as well if possible.
 
 -Carl
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-maildir-Allow-in-the-unique-name-portion-of-a-maildi.patch
 Type: application/octet-stream
 Size: 1097 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090814/bb1094e7/attachment.obj>
 -------------- 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/20090814/bb1094e7/attachment.bin>
 
 From igor.brkic@fer.hr  Sat Aug 15 06:18:33 2009
 From: igor.brkic@fer.hr (Igor Brkic)
 Date: Sat, 15 Aug 2009 12:18:33 +0200
 Subject: [sup-talk] Introduction, thanks, and a small patch
 In-Reply-To: <20090815041446.GA1249@yoom.home.cworth.org>
 References: <20090815041446.GA1249@yoom.home.cworth.org>
 Message-ID: <1250331013-sup-3083@xps>
 
 Excerpts from Carl Worth's message of Sub Kol 15 06:14:46 +0200 2009:
 > PS. I'm sending this message from mutt since sup crashed when I tried
 > to send the message (see exception output below). I think this is one
 
 Hi Carl!
 
 I had same problem with sup. Sup actually manages to send message before
 crashing and then it crashes when indexing sent messages.
 
 Solution that worked for me is to comment out line "Time.parse time, 0"
 in mbox.rb file. This is not good solution, more like a hack, but for
 some reason it works for me. Try it out.
 
 I tried to find out why this is happening, but I'm not so familiar with 
 sup internals (and not so good in ruby too) and didn't come to any conclusion.
 
 Igor
 
 From marco-oweber@gmx.de  Sat Aug 15 07:03:00 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Sat, 15 Aug 2009 13:03:00 +0200
 Subject: [sup-talk] Introduction, thanks, and a small patch
 In-Reply-To: <20090815041446.GA1249@yoom.home.cworth.org>
 References: <20090815041446.GA1249@yoom.home.cworth.org>
 Message-ID: <1250334013-sup-3733@nixos>
 
 >    1. Most text is white-on-white (invisible) if the default terminal
 >       background color is white. I would suggest that the default
 >       background color be changed from "default" to "black" to avoid
 >       this trap.
 
 The bg colour is set to black somewhere but for some reason it doesn't
 work here. I've switched my terminal bg colour to light green so that I
 can still read all text. It's a little bit annoying though. So if you
 can tell me how to make sup background black I'd be happy.
 
 I haven't taken the time yet to investigate the issue.
 
 Sincerly
 Marc Weber
 
 From cworth@cworth.org  Sat Aug 15 10:35:02 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Sat, 15 Aug 2009 07:35:02 -0700
 Subject: [sup-talk] Introduction, thanks, and a small patch
 In-Reply-To: <1250331013-sup-3083@xps>
 References: <20090815041446.GA1249@yoom.home.cworth.org>
 	<1250331013-sup-3083@xps>
 Message-ID: <1250346449-sup-6703@yoom>
 
 Excerpts from Igor Brkic's message of Sat Aug 15 03:18:33 -0700 2009:
 > Hi Carl!
 
 Hi Igor!
 
 > I had same problem with sup. Sup actually manages to send message before
 > crashing and then it crashes when indexing sent messages.
 
 Ah, yes. I did notice afterwards that my original message did make it
 to the list. So sorry for all the noise, (though my first send of the
 patch did have some debug junk in it, so I suppose it's good I sent a
 cleaner version).
 
 > Solution that worked for me is to comment out line "Time.parse time, 0"
 > in mbox.rb file. This is not good solution, more like a hack, but for
 > some reason it works for me. Try it out.
 
 Thanks. I gave this a try, but it didn't work for me. I'm also not
 much for debugging ruby so I haven't made much progress here yet. (Is
 there anything like gdb for ruby? If I could just march up the stack
 and more easily find where m.date should be initialized to non-nil
 then that might help).
 
 But thanks for describing the bug more accurately for mo. At least
 knowing that the crash is happening while indexing ~/.sup/sent.mb I
 was able to just move that out of the way for now, so I can at least
 run sup again.
 
 And actually, this brings up another point for that missing reference
 manual. How can I configure sup to deliver sent messages to a maildir
 instead of an mbox? (I'd prefer that anyway, and it just might
 workaround this bug.)
 
 Thanks for the warm welcome,
 
 -Carl
 -------------- 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/20090815/849f4ac4/attachment.bin>
 
 From cworth@cworth.org  Sat Aug 15 10:41:51 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Sat, 15 Aug 2009 07:41:51 -0700
 Subject: [sup-talk] Introduction, thanks, and a small patch
 In-Reply-To: <1250334013-sup-3733@nixos>
 References: <20090815041446.GA1249@yoom.home.cworth.org>
 	<1250334013-sup-3733@nixos>
 Message-ID: <1250346921-sup-8888@yoom>
 
 Excerpts from Marc Weber's message of Sat Aug 15 04:03:00 -0700 2009:
 > The bg colour is set to black somewhere but for some reason it doesn't
 > work here. I've switched my terminal bg colour to light green so that I
 > can still read all text. It's a little bit annoying though. So if you
 > can tell me how to make sup background black I'd be happy.
 > 
 > I haven't taken the time yet to investigate the issue.
 
 I did my color configuration according to the following page:
 
 http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
 
 That provides this very useful command which reads all the default
 color settings and puts them into a configuration file that you can
 easily edit:
 
 ruby -rubygems -rsup -e 'print Redwood::Colormap::DEFAULT_COLORS.to_yaml' > ~/.sup/colors.yaml
 
 You know, I don't think it would be a crazy idea for sup to
 automatically dump that there on its first run. Or perhaps better,
 sup-config could do it, (and could even ask if the user would prefer a
 black-on-white or a white-on-black default color scheme).
 
 -Carl
 -------------- 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/20090815/e3d7b777/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Sun Aug 16 15:35:30 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 12:35:30 -0700
 Subject: [sup-talk] [PATCH 1/2] move all GDBM data into Xapian
 Message-ID: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 
 Keeping everything in Xapian means much better consistency in case of a crash.
 Thread killing is now supported.
 ---
  lib/sup/xapian_index.rb |  177 +++++++++++++++++++++++++++++------------------
  1 files changed, 110 insertions(+), 67 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 861c2a3..825e7a3 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -1,5 +1,4 @@
  require 'xapian'
 -require 'gdbm'
  require 'set'
  
  module Redwood
 @@ -23,12 +22,6 @@ class XapianIndex < BaseIndex
    end
  
    def load_index
 -    @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)
 @@ -48,19 +41,19 @@ class XapianIndex < BaseIndex
    end
  
    def contains_id? id
 -    synchronize { @entries.member? id }
 +    synchronize { find_docid(id) && true }
    end
  
    def source_for_id id
 -    synchronize { @entries[id][:source_id] }
 +    synchronize { get_entry(id)[:source_id] }
    end
  
    def delete id
 -    synchronize { @xapian.delete_document @docids[id] }
 +    synchronize { @xapian.delete_document mkterm(:msgid, id) }
    end
  
    def build_message id
 -    entry = synchronize { @entries[id] }
 +    entry = synchronize { get_entry id }
      return unless entry
  
      source = SourceManager[entry[:source_id]]
 @@ -88,7 +81,7 @@ class XapianIndex < BaseIndex
    end
  
    def sync_message m, opts={}
 -    entry = synchronize { @entries[m.id] }
 +    entry = synchronize { get_entry m.id }
      snippet = m.snippet
      entry ||= {}
      labels = m.labels
 @@ -113,9 +106,7 @@ class XapianIndex < BaseIndex
      m.labels.each { |l| LabelManager << l }
  
      synchronize do
 -      index_message m, opts
 -      union_threads([m.id] + m.refs + m.replytos)
 -      @entries[m.id] = d
 +      index_message m, d, opts
      end
      true
    end
 @@ -147,8 +138,26 @@ class XapianIndex < BaseIndex
    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 } }
 +    return unless doc = find_doc(m.id)
 +    queue = doc.value(THREAD_VALUENO).split(',')
 +    msgids = [m.id]
 +    seen_threads = Set.new
 +    seen_messages = Set.new [m.id]
 +    while not queue.empty?
 +      thread_id = queue.pop
 +      next if seen_threads.member? thread_id
 +      return false if thread_killed? thread_id 
 +      seen_threads << thread_id
 +      docs = term_docids(mkterm(:thread, thread_id)).map { |x| @xapian.document x }
 +      docs.each do |doc|
 +        msgid = doc.value MSGID_VALUENO
 +        next if seen_messages.member? msgid
 +        msgids << msgid
 +        seen_messages << msgid
 +        queue.concat doc.value(THREAD_VALUENO).split(',')
 +      end
 +    end
 +    msgids.each { |id| yield id, lambda { build_message id } }
      true
    end
  
 @@ -297,11 +306,16 @@ class XapianIndex < BaseIndex
      'label' => 'L',
      'source_id' => 'I',
      'attachment_extension' => 'O',
 +    'msgid' => 'Q',
 +    'thread' => 'H',
 +    'ref' => 'R',
    }
  
    PREFIX = NORMAL_PREFIX.merge BOOLEAN_PREFIX
  
 -  DATE_VALUENO = 0
 +  MSGID_VALUENO = 0
 +  THREAD_VALUENO = 1
 +  DATE_VALUENO = 2
  
    MAX_TERM_LENGTH = 245
  
 @@ -317,14 +331,48 @@ class XapianIndex < BaseIndex
    def assign_docid m, truncated_date
      t = (truncated_date.to_i - MIDDLE_DATE.to_i).to_f
      docid = (DOCID_SCALE - DOCID_SCALE/(Math::E**(-(t/TIME_SCALE)) + 1)).to_i
 +    while docid > 0 and docid_exists? docid
 +      docid -= 1
 +    end
 +    docid > 0 ? docid : nil
 +  end
 +
 +  # XXX is there a better way?
 +  def docid_exists? docid
      begin
 -      while @assigned_docids.member? [docid].pack("N")
 -        docid -= 1
 -      end
 -    rescue
 +      @xapian.doclength docid
 +      true
 +    rescue RuntimeError #Xapian::DocNotFoundError
 +      raise unless $!.message =~ /DocNotFoundError/
 +      false
      end
 -    @assigned_docids[[docid].pack("N")] = ''
 -    docid
 +  end
 +
 +  def term_docids term
 +    @xapian.postlist(term).map { |x| x.docid }
 +  end
 +
 +  def find_docid id
 +    term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first
 +  end
 +
 +  def find_doc id
 +    return unless docid = find_docid(id)
 +    @xapian.document docid
 +  end
 +
 +  def get_id docid
 +    return unless doc = @xapian.document(docid)
 +    doc.value MSGID_VALUENO
 +  end
 +
 +  def get_entry id
 +    return unless doc = find_doc(id)
 +    Marshal.load doc.data
 +  end
 +
 +  def thread_killed? thread_id
 +    not run_query(Q.new(Q::OP_AND, mkterm(:thread, thread_id), mkterm(:label, :Killed)), 0, 1).empty?
    end
  
    def synchronize &b
 @@ -340,7 +388,7 @@ class XapianIndex < BaseIndex
  
    def run_query_ids xapian_query, offset, limit
      matchset = run_query xapian_query, offset, limit
 -    matchset.matches.map { |r| r.document.data }
 +    matchset.matches.map { |r| r.document.value MSGID_VALUENO }
    end
  
    Q = Xapian::Query
 @@ -371,7 +419,7 @@ class XapianIndex < BaseIndex
      end
    end
  
 -  def index_message m, opts
 +  def index_message m, entry, opts
      terms = []
      text = []
  
 @@ -394,6 +442,7 @@ class XapianIndex < BaseIndex
      terms << mkterm(:date,m.date) if m.date
      m.labels.each { |t| terms << mkterm(:label,t) }
      terms << mkterm(:type, 'mail')
 +    terms << mkterm(:msgid, m.id)
      terms << mkterm(:source_id, m.source.id)
      m.attachments.each do |a|
        a =~ /\.(\w+)$/ or next
 @@ -401,6 +450,23 @@ class XapianIndex < BaseIndex
        terms << t
      end
  
 +    ## Thread membership
 +    children = term_docids(mkterm(:ref, m.id)).map { |docid| @xapian.document docid }
 +    parent_ids = m.refs + m.replytos
 +    parents = parent_ids.map { |id| find_doc id }.compact
 +    thread_members = SavingHash.new { [] }
 +    (children + parents).each do |doc2|
 +      thread_ids = doc2.value(THREAD_VALUENO).split ','
 +      thread_ids.each { |thread_id| thread_members[thread_id] << doc2 }
 +    end
 +
 +    thread_ids = thread_members.empty? ? [m.id] : thread_members.keys
 +
 +    thread_ids.each { |thread_id| terms << mkterm(:thread, thread_id) }
 +    parent_ids.each do |ref|
 +      terms << mkterm(:ref, ref)
 +    end
 +
      # Full text search content
      text << [subject_text, PREFIX['subject']]
      text << [subject_text, PREFIX['body']]
 @@ -424,17 +490,29 @@ class XapianIndex < BaseIndex
        Xapian.sortable_serialise 0
      end
  
 -    doc = Xapian::Document.new
 -    docid = @docids[m.id] || assign_docid(m, truncated_date)
 +    docid = nil
 +    unless doc = find_doc(m.id)
 +      doc = Xapian::Document.new
 +      if not docid = assign_docid(m, truncated_date)
 +        # Could be triggered by spam
 +        Redwood::log "warning: docid underflow, dropping #{m.id.inspect}"
 +        return
 +      end
 +    else
 +      doc.clear_terms
 +      doc.clear_values
 +      docid = doc.docid
 +    end
  
      @term_generator.document = doc
      text.each { |text,prefix| @term_generator.index_text text, 1, prefix }
      terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH }
 +    doc.add_value MSGID_VALUENO, m.id
 +    doc.add_value THREAD_VALUENO, (thread_ids * ',')
      doc.add_value DATE_VALUENO, date_value
 -    doc.data = m.id
 +    doc.data = Marshal.dump entry
  
      @xapian.replace_document docid, doc
 -    @docids[m.id] = docid
    end
  
    # Construct a Xapian term
 @@ -457,48 +535,13 @@ class XapianIndex < BaseIndex
        PREFIX['source_id'] + args[0].to_s.downcase
      when :attachment_extension
        PREFIX['attachment_extension'] + args[0].to_s.downcase
 +    when :msgid, :ref, :thread
 +      PREFIX[type.to_s] + args[0][0...(MAX_TERM_LENGTH-1)]
      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.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 16 15:35:31 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 12:35:31 -0700
 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
 In-Reply-To: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |   13 ++++++++++++-
  1 files changed, 12 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 825e7a3..c4989e4 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -8,6 +8,7 @@ module Redwood
  # for searching due to precomputing thread membership.
  class XapianIndex < BaseIndex
    STEM_LANGUAGE = "english"
 +  INDEX_VERSION = '1'
  
    ## dates are converted to integers for xapian, and are used for document ids,
    ## so we must ensure they're reasonably valid. this typically only affect
 @@ -22,7 +23,17 @@ class XapianIndex < BaseIndex
    end
  
    def load_index
 -    @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
 +    path = File.join(@dir, 'xapian')
 +    if File.exists? path
 +      @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_OPEN)
 +      db_version = @xapian.get_metadata 'version'
 +      if db_version != INDEX_VERSION
 +        fail "Index version #{db_version.inspect} is different than Sup version #{INDEX_VERSION.inspect}"
 +      end
 +    else
 +      @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE)
 +      @xapian.set_metadata 'version', INDEX_VERSION
 +    end
      @term_generator = Xapian::TermGenerator.new()
      @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
      @enquire = Xapian::Enquire.new @xapian
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 16 15:35:59 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 12:35:59 -0700
 Subject: [sup-talk] [PATCH] skip system buffers when rolling
 Message-ID: <1250451359-16110-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/buffer.rb |   16 +++++++++++-----
  1 files changed, 11 insertions(+), 5 deletions(-)
 
 diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
 index b3a256f..3fd2fe4 100644
 --- a/lib/sup/buffer.rb
 +++ b/lib/sup/buffer.rb
 @@ -237,14 +237,20 @@ EOS
    ## have to change this. but it's not clear that we will ever actually
    ## do that.
    def roll_buffers
 -    @buffers.last.force_to_top = false
 -    raise_to_front @buffers.first
 +    bufs = rollable_buffers
 +    bufs.last.force_to_top = false
 +    raise_to_front bufs.first
    end
  
    def roll_buffers_backwards
 -    return unless @buffers.length > 1
 -    @buffers.last.force_to_top = false
 -    raise_to_front @buffers[@buffers.length - 2]
 +    bufs = rollable_buffers
 +    return unless bufs.length > 1
 +    bufs.last.force_to_top = false
 +    raise_to_front bufs[bufs.length - 2]
 +  end
 +
 +  def rollable_buffers
 +    @buffers.select { |b| !b.system? || @buffers.last == b }
    end
  
    def handle_input c
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 16 15:36:08 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 12:36:08 -0700
 Subject: [sup-talk] [PATCH] add 'I' keybinding to raise Inbox buffer
 Message-ID: <1250451368-16150-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index a9f0b95..d1eb163 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -78,6 +78,7 @@ global_keymap = Keymap.new do |k|
    k.add :compose, "Compose new message", 'm', 'c'
    k.add :nothing, "Do nothing", :ctrl_g
    k.add :recall_draft, "Edit most recent draft message", 'R'
 +  k.add :show_inbox, "Show the Inbox buffer", 'I'
  end
  
  ## the following magic enables wide characters when used with a ruby
 @@ -286,6 +287,8 @@ begin
          b, new = BufferManager.spawn_unless_exists("All drafts") { LabelSearchResultsMode.new [:draft] }
          b.mode.load_threads :num => b.content_height if new
        end
 +    when :show_inbox
 +      BufferManager.raise_to_front ibuf
      when :nothing, InputSequenceAborted
      when :redraw
        bm.completely_redraw_screen
 -- 
 1.6.4
 
 
 From dato@net.com.org.es  Sun Aug 16 16:01:16 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Sun, 16 Aug 2009 21:01:16 +0100
 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
 In-Reply-To: <1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <20090816200116.GA17272@chistera.yi.org>
 
 + Rich Lane (Sun, 16 Aug 2009 12:35:31 -0700):
 
 > + fail "Index version #{db_version.inspect} is different than Sup
 > version #{INDEX_VERSION.inspect}"
 
 The second part of the sentence seems to refer to Sup's version itself,
 rather than what it really means (the index version expected by the
 running version of Sup).
 
 Maybe the following wording could work better?
 
   | This Sup version expects a v#{INDEX_VERSION.inspect} index, whereas
   | v#{db_version.inspect} is in the filesystem.
 
 (And, perhaps, suggesting what to do next would be grea too.)
 
 HTH,
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 16 16:28:56 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 16:28:56 -0400
 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
 In-Reply-To: <20090816200116.GA17272@chistera.yi.org>
 References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 	<20090816200116.GA17272@chistera.yi.org>
 Message-ID: <1250453934-sup-9651@zyrg.net>
 
 ---
 How's this wording?
 
 I've been thinking about a label log that would store every label
 modification along with the timestamp, etc. This would make the awkward
 downgrade-dump-upgrade step unnecessary. We could also flush it to disk
 more often than the full index.
 
  lib/sup/xapian_index.rb |   14 +++++++++++++-
  1 files changed, 13 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 825e7a3..18b5050 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -8,6 +8,7 @@ module Redwood
  # for searching due to precomputing thread membership.
  class XapianIndex < BaseIndex
    STEM_LANGUAGE = "english"
 +  INDEX_VERSION = '1'
  
    ## dates are converted to integers for xapian, and are used for document ids,
    ## so we must ensure they're reasonably valid. this typically only affect
 @@ -22,7 +23,18 @@ class XapianIndex < BaseIndex
    end
  
    def load_index
 -    @xapian = Xapian::WritableDatabase.new(File.join(@dir, "xapian"), Xapian::DB_CREATE_OR_OPEN)
 +    path = File.join(@dir, 'xapian')
 +    if File.exists? path
 +      @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_OPEN)
 +      db_version = @xapian.get_metadata 'version'
 +      db_version = '0' if db_version.empty?
 +      if db_version != INDEX_VERSION
 +        fail "This Sup version expects a v#{INDEX_VERSION} index, but you have an existing v#{db_version} index. Please downgrade to your previous version and dump your labels before upgrading to this version (then run sup-sync --restore)."
 +      end
 +    else
 +      @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE)
 +      @xapian.set_metadata 'version', INDEX_VERSION
 +    end
      @term_generator = Xapian::TermGenerator.new()
      @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
      @enquire = Xapian::Enquire.new @xapian
 -- 
 1.6.4
 
 From wmorgan-sup@masanjin.net  Sun Aug 16 17:22:56 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 16 Aug 2009 14:22:56 -0700
 Subject: [sup-talk] Introduction, thanks, and a small patch
 In-Reply-To: <1250331013-sup-3083@xps>
 References: <20090815041446.GA1249@yoom.home.cworth.org>
 	<1250331013-sup-3083@xps>
 Message-ID: <1250456575-sup-4326@masanjin.net>
 
 Reformatted excerpts from Igor Brkic's message of 2009-08-15:
 > Solution that worked for me is to comment out line "Time.parse time,
 > 0" in mbox.rb file. This is not good solution, more like a hack, but
 > for some reason it works for me. Try it out.
 
 I've think I've fixed this in master. Thanks for your log; that was
 helpful. The problem was that Sup was producing the date component of
 the From_ lines in the sent mail mbox using the current locale, and
 later on wouldn't necessarily recognize that as a date. (Particularly
 for people with "funny locales".)
 
 You will have to manually edit your ~/.sup/sent.mbox file and change all
 the From_ line dates that are not in UTC to UTC. If there are just a
 couple, you should be able to copy and paste from the Date: header a few
 lines below.
 
 Removing the Time.parse line you mention will work, but it has the side
 effect of potentially splitting mbox files in mid-message. E.g. if you
 ever have a line of text like "From xxx yyy\n", Sup will consider that
 a message delimiter. This is fallout from the great mbox From_ line
 misdesign of 1972.
 
 Please let me know if it works for you.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Aug 16 17:38:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 16 Aug 2009 14:38:31 -0700
 Subject: [sup-talk] Introduction, thanks, and a small patch
 In-Reply-To: <20090815041446.GA1249@yoom.home.cworth.org>
 References: <20090815041446.GA1249@yoom.home.cworth.org>
 Message-ID: <1250457809-sup-6784@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-14:
 > Hi. My name's Carl, and I've uh, been collecting email for 12 years.
 
 Hi Carl! Welcome.
 
 > 1. Most text is white-on-white (invisible) if the default terminal
 >    background color is white. I would suggest that the default
 >    background color be changed from "default" to "black" to avoid
 >    this trap.
 
 Complaining about the colors already? You're fitting right in around
 here.
 
 We recently changed it from black to default in order to make it work
 for people with transparent terminals. Since there's clearly not a
 setting that works for everyone, I think the best solution is your
 suggestion in a later email: provide a few reasonable color schemes
 directly in sup-sync.
 
 > I've attached a patch to fix this second issue, (a single-character
 > change).
 
 Great, thanks. The patch looks good but I think you left a debugging
 puts call in there. If you want to resubmit,  I will apply this.
 
 > I love the NewUserGuide, but I've needed a ReferenceManual for various
 > issues already, (configuring colors, configuring SMTP, understanding
 > the sources.yaml file well enough to be able to re-process mail that
 > was mis-labelled the first time, etc.).
 
 Agree. This would be very valuable and is currently a sore spot, IMO.
 
 > One potential issue is that I don't see any explicit license terms on
 > the wiki. Can I assume that any text on the wiki is suitable for
 > putting into a document to be contributed to and distributed with sup?
 
 I think it's fair to assume that anyone contributing to a wiki for an
 open-source product knows what they're getting into. So, yes.
 
 Of course, if anyone objects to their wiki content being distributed as
 part of Sup (which is currently distributed under GPL v2), please speak
 now!
 
 > I really like the ideas William has posted on his blog about
 > separating the interface from the guts of sup, (to make the new STS).
 > I'd be happy to help with that as well if possible.
 
 Although it's been over a year of vaporware promises, this is slowly
 happening. I have a protocol defined and a simple server written. Recent
 work on replacing Ferret with Xapian has actually been helpful in terms
 of moving us away from Ferretisms. Expect something "soon".
 
 > NoMethodError from thread: main
 > undefined method `to_indexable_s' for nil:NilClass
 
 This should now be fixed in git master; see my previous email in this
 thread. (You will have to manually edit your sent.mbox a bit.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Aug 16 17:43:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 16 Aug 2009 14:43:03 -0700
 Subject: [sup-talk] Stack overflow in regexp matcher
 In-Reply-To: <92457f310908120145n453d6639mf22fe68b62054392@mail.gmail.com>
 References: <92457f310908030116k146a901aleee95a09db907d97@mail.gmail.com>
 	<1250021966-sup-933@masanjin.net>
 	<92457f310908120145n453d6639mf22fe68b62054392@mail.gmail.com>
 Message-ID: <1250458792-sup-9177@masanjin.net>
 
 Reformatted excerpts from Mark Drayton's message of 2009-08-12:
 > The line it's choking on is 284058 bytes long and contains ~6400
 > addresses. (gotta love mail from "internal communications").
 
 Wow!
 
 > If I halve the number of addresses it works, so perhaps this isn't
 > worth fixing at all. If you do want to tackle it I'm happy to help
 > off-list.
 
 Well... it's clearly a weird case, but it would be nice to do something
 besides barf. I suppose we could detect very long lines, emit a warning,
 and just parse the first few kb. What do you think?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Aug 16 17:44:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 16 Aug 2009 14:44:49 -0700
 Subject: [sup-talk] some internal api refactors
 In-Reply-To: <1250054282-sup-9053@pion.club.cc.cmu.edu>
 References: <1250021119-sup-4253@masanjin.net>
 	<1250054282-sup-9053@pion.club.cc.cmu.edu>
 Message-ID: <1250459019-sup-6390@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-11:
 > It's worth noting that update_message_state needs to handle modified
 > refs and snippets as well as labels. Maybe add a comment about this in
 > BaseIndex?
 
 Different snippet, definitely. Good point. Modified refs: I'm tempted to
 replace this with another API call, since we don't really care about the
 refs; we just want the index to thread the messages together. Thoughts?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Aug 16 18:00:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 16 Aug 2009 15:00:50 -0700
 Subject: [sup-talk] [PATCH] Restore keypad mode after we force ncurses
 	to refresh the whole screen.
 In-Reply-To: <1250291137-sup-2796@localdomain>
 References: <1250022259-sup-8328@masanjin.net>
 	<1250028581-15826-2-git-send-email-benoit.pierre@gmail.com>
 	<1250281039-sup-2788@masanjin.net>
 	<1250289386-sup-7331@localdomain> <1250291137-sup-2796@localdomain>
 Message-ID: <1250460036-sup-9343@masanjin.net>
 
 Reformatted excerpts from Beno?t PIERRE's message of 2009-08-14:
 > This also happen to fix a regression after a call to run-mailcap,
 > since for some reason a screen resize event is triggered when we get
 > control back...
 
 Applied to ncurses-fixes, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From kevinr@free-dissociation.com  Sun Aug 16 17:47:09 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Sun, 16 Aug 2009 17:47:09 -0400
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 Message-ID: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com>
 
 From: Kevin Riggle <kevinr at black-opal.mit.edu>
 
 I want to do some unrelated processing on each message I receive, but I
 don't want to block the message being added to the index.  This patch
 adds a hook which runs /after/ the message is added to the index.
 ---
  lib/sup/poll.rb |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
 index 8a9d218..e4b7e02 100644
 --- a/lib/sup/poll.rb
 +++ b/lib/sup/poll.rb
 @@ -11,6 +11,12 @@ Variables:
    message: the new message
  EOS
  
 +  HookManager.register "after-add-message", <<EOS
 +Executes after a message is added to the index.
 +Variables:
 +  message: the new message
 +EOS
 +
    HookManager.register "before-poll", <<EOS
  Executes immediately before a poll for new messages commences.
  No variables.
 @@ -156,6 +162,7 @@ EOS
          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
 +        HookManager.run "after-add-message", :message => m_new
        end
      rescue SourceError => e
        Redwood::log "problem getting messages from #{source}: #{e.message}"
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 16 18:49:24 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 18:49:24 -0400
 Subject: [sup-talk] some internal api refactors
 In-Reply-To: <1250459019-sup-6390@masanjin.net>
 References: <1250021119-sup-4253@masanjin.net>
 	<1250054282-sup-9053@pion.club.cc.cmu.edu>
 	<1250459019-sup-6390@masanjin.net>
 Message-ID: <1250461358-sup-7209@zyrg.net>
 
 Excerpts from William Morgan's message of Sun Aug 16 17:44:49 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-08-11:
 > > It's worth noting that update_message_state needs to handle modified
 > > refs and snippets as well as labels. Maybe add a comment about this in
 > > BaseIndex?
 > 
 > Different snippet, definitely. Good point. Modified refs: I'm tempted to
 > replace this with another API call, since we don't really care about the
 > refs; we just want the index to thread the messages together. Thoughts?
 
 The ThreadSet still needs the ref to do the UI-level threading, right?
 Making it another API call is good as long as that's still taken care of.
 
 From igor.brkic@fer.hr  Sun Aug 16 19:18:22 2009
 From: igor.brkic@fer.hr (Igor Brkic)
 Date: Mon, 17 Aug 2009 01:18:22 +0200
 Subject: [sup-talk] Introduction, thanks, and a small patch
 In-Reply-To: <1250456575-sup-4326@masanjin.net>
 References: <20090815041446.GA1249@yoom.home.cworth.org>
 	<1250331013-sup-3083@xps> <1250456575-sup-4326@masanjin.net>
 Message-ID: <1250464611-sup-5505@xps>
 
 Excerpts from William Morgan's message of Sun Aug 16 23:22:56 +0200 2009:
 > I've think I've fixed this in master. Thanks for your log; that was
 > helpful. The problem was that Sup was producing the date component of
 > the From_ lines in the sent mail mbox using the current locale, and
 > later on wouldn't necessarily recognize that as a date. (Particularly
 > for people with "funny locales".)
 > 
 > ...
 > 
 > Please let me know if it works for you.
 
 I've made changes and for now it works like a charm. Thanks!
 
 Igor
 
 From rlane@club.cc.cmu.edu  Mon Aug 17 02:38:43 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 23:38:43 -0700
 Subject: [sup-talk] [PATCH] index log
 Message-ID: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu>
 
 Add a YAML logfile that records changes to the index and modify sup-dump to use
 this rather than the normal database. The log is index format/version agnostic
 so that users can switch between incompatible Sup versions without running
 sup-dump first.
 
 This should also make automated backups easier.
 ---
  bin/sup-dump            |   19 +++++++++++++------
  lib/sup/ferret_index.rb |    7 +++++++
  lib/sup/index.rb        |   22 ++++++++++++++++++++++
  lib/sup/xapian_index.rb |    7 ++++++-
  lib/sup/yaml_log.rb     |   25 +++++++++++++++++++++++++
  5 files changed, 73 insertions(+), 7 deletions(-)
  create mode 100644 lib/sup/yaml_log.rb
 
 diff --git a/bin/sup-dump b/bin/sup-dump
 index ba36b21..531a30a 100755
 --- a/bin/sup-dump
 +++ b/bin/sup-dump
 @@ -2,7 +2,8 @@
  
  require 'rubygems'
  require 'trollop'
 -require "sup"
 +require 'sup' # Redwood::VERSION, Redwood::BASE_DIR
 +require "sup/yaml_log"
  
  $opts = Trollop::options do
    version "sup-dump (sup #{Redwood::VERSION})"
 @@ -21,10 +22,16 @@ No options.
  EOS
  end
  
 -index = Redwood::Index.new
 -Redwood::SourceManager.new
 -index.load
 +labels = {}
  
 -index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m|
 -  puts "#{m.id} (#{m.labels * ' '})"
 +Redwood::log "processing index log"
 +index_log = YamlLogReader.new File.join(Redwood::BASE_DIR, 'index_log.yaml')
 +index_log.each do |h| 
 +  case h['type']
 +  when 'add_message', 'update_message_state'
 +    labels[h['id']] = h['labels']
 +  end
  end
 +
 +Redwood::log "dumping labels"
 +labels.each { |msgid,labels| puts "#{msgid} (#{labels * ' '})" }
 diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
 index 98ea9b5..2cb9759 100644
 --- a/lib/sup/ferret_index.rb
 +++ b/lib/sup/ferret_index.rb
 @@ -57,6 +57,7 @@ EOS
  
    def sync_message m, opts={}
      entry = @index[m.id]
 +    existed = !entry.nil?
  
      raise "no source info for message #{m.id}" unless m.source && m.source_info
  
 @@ -131,6 +132,12 @@ EOS
      }
  
      @index_mutex.synchronize do
 +      if existed
 +        @log.update_message_state m.id, m.labels
 +      else
 +        @log.add_message m.id, m.labels
 +      end
 +
        @index.delete m.id
        @index.add_document d
      end
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 54ec843..7360cf5 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -1,6 +1,7 @@
  ## Index interface, subclassed by Ferret indexer.
  
  require 'fileutils'
 +require 'sup/yaml_log'
  
  begin
    require 'chronic'
 @@ -65,6 +66,7 @@ class BaseIndex
  
    def load
      SourceManager.load_sources
 +    @log = IndexLogWriter.new File.join(@dir, 'index_log.yaml')
      load_index
    end
  
 @@ -176,6 +178,26 @@ class BaseIndex
    def parse_query s
      unimplemented
    end
 +
 +  private
 +
 +  class IndexLogWriter < YamlLogWriter
 +    def update_message_state id, labels
 +      write_entry 'update_message_state', 'id' => id, 'labels' => labels.map { |x| x.to_s }
 +    end
 +
 +    def add_message id, labels
 +      write_entry 'add_message', 'id' => id, 'labels' => labels.map { |x| x.to_s }
 +    end
 +
 +    def remove_message id
 +      write_entry 'remove_message', 'id' => id
 +    end
 +
 +    def write_entry type, hash
 +      self << hash.merge('type' => type, 'time' => Time.now)
 +    end
 +  end
  end
  
  index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 18b5050..c4dbc5f 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -61,7 +61,10 @@ class XapianIndex < BaseIndex
    end
  
    def delete id
 -    synchronize { @xapian.delete_document mkterm(:msgid, id) }
 +    synchronize do
 +      @log.remove_message id
 +      @xapian.delete_document mkterm(:msgid, id)
 +    end
    end
  
    def build_message id
 @@ -510,10 +513,12 @@ class XapianIndex < BaseIndex
          Redwood::log "warning: docid underflow, dropping #{m.id.inspect}"
          return
        end
 +      @log.add_message m.id, m.labels
      else
        doc.clear_terms
        doc.clear_values
        docid = doc.docid
 +      @log.update_message_state m.id, m.labels
      end
  
      @term_generator.document = doc
 diff --git a/lib/sup/yaml_log.rb b/lib/sup/yaml_log.rb
 new file mode 100644
 index 0000000..325cca9
 --- /dev/null
 +++ b/lib/sup/yaml_log.rb
 @@ -0,0 +1,25 @@
 +class YamlLogReader
 +  include Enumerable
 +
 +  def initialize filename
 +    @io = File.open(filename, 'r+')
 +  end
 +
 +  def each &b
 +    @io.rewind
 +    YAML.each_document @io, &b
 +  end
 +end
 +
 +class YamlLogWriter
 +  def initialize filename
 +    @io = File.open(filename, 'a')
 +  end
 +
 +  def <<(o)
 +    YAML.dump o, @io
 +
 +    ## This only flushes to the OS. We may want to fsync occasionally too.
 +    @io.flush
 +  end
 +end
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Mon Aug 17 02:39:11 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 23:39:11 -0700
 Subject: [sup-talk] [PATCH 1/5] console mode
 Message-ID: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup                       |    4 +++
  lib/sup.rb                    |    1 +
  lib/sup/modes/console-mode.rb |   42 +++++++++++++++++++++++++++++++++++++++++
  3 files changed, 47 insertions(+), 0 deletions(-)
  create mode 100644 lib/sup/modes/console-mode.rb
 
 diff --git a/bin/sup b/bin/sup
 index a9f0b95..1dc322a 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -78,6 +78,7 @@ global_keymap = Keymap.new do |k|
    k.add :compose, "Compose new message", 'm', 'c'
    k.add :nothing, "Do nothing", :ctrl_g
    k.add :recall_draft, "Edit most recent draft message", 'R'
 +  k.add :show_console, "Show the Console buffer", '~'
  end
  
  ## the following magic enables wide characters when used with a ruby
 @@ -286,6 +287,9 @@ begin
          b, new = BufferManager.spawn_unless_exists("All drafts") { LabelSearchResultsMode.new [:draft] }
          b.mode.load_threads :num => b.content_height if new
        end
 +    when :show_console
 +      b, new = bm.spawn_unless_exists("Console", :system => true) { ConsoleMode.new }
 +      b.mode.run
      when :nothing, InputSequenceAborted
      when :redraw
        bm.completely_redraw_screen
 diff --git a/lib/sup.rb b/lib/sup.rb
 index cfa93fc..9e0c33a 100644
 --- a/lib/sup.rb
 +++ b/lib/sup.rb
 @@ -295,6 +295,7 @@ require "sup/modes/buffer-list-mode"
  require "sup/modes/poll-mode"
  require "sup/modes/file-browser-mode"
  require "sup/modes/completion-mode"
 +require "sup/modes/console-mode"
  require "sup/sent"
  
  $:.each do |base|
 diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
 new file mode 100644
 index 0000000..d06d37b
 --- /dev/null
 +++ b/lib/sup/modes/console-mode.rb
 @@ -0,0 +1,42 @@
 +require 'pp'
 +
 +module Redwood
 +
 +class Console
 +  def initialize mode
 +    @mode = mode
 +  end
 +end
 +
 +class ConsoleMode < LogMode
 +  def initialize
 +    super
 +    @binding = Console.new(self).instance_eval { binding }
 +  end
 +
 +  def execute cmd
 +    begin
 +      self << ">> #{cmd}\n"
 +      ret = eval cmd, @binding
 +      self << "=> #{ret.pretty_inspect}\n"
 +    rescue Exception
 +      self << "#{$!.class}: #{$!.message}\n"
 +      clean_backtrace = []
 +      $!.backtrace.each { |l| break if l =~ /console-mode/; clean_backtrace << l }
 +      clean_backtrace.each { |l| self << "#{l}\n" }
 +    end
 +  end
 +
 +  def prompt
 +    BufferManager.ask :console, "eval: "
 +  end
 +
 +  def run
 +    while true
 +      cmd = prompt or return
 +      execute cmd
 +    end
 +  end
 +end
 +
 +end
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Mon Aug 17 02:39:13 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 23:39:13 -0700
 Subject: [sup-talk] [PATCH 3/5] console: index internals accessor
 In-Reply-To: <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/modes/console-mode.rb |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
 index a91bbbf..c794a4c 100644
 --- a/lib/sup/modes/console-mode.rb
 +++ b/lib/sup/modes/console-mode.rb
 @@ -18,6 +18,9 @@ class Console
    def remove_labels(query, *labels)
      query(query).each { |m| m.labels -= labels; m.save Index }
    end
 +
 +  def xapian; Index.instance.instance_variable_get :@xapian; end
 +  def ferret; Index.instance.instance_variable_get :@index; end
  end
  
  class ConsoleMode < LogMode
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Mon Aug 17 02:39:12 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 23:39:12 -0700
 Subject: [sup-talk] [PATCH 2/5] console: add/remove labels
 In-Reply-To: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/modes/console-mode.rb |   12 ++++++++++++
  1 files changed, 12 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
 index d06d37b..a91bbbf 100644
 --- a/lib/sup/modes/console-mode.rb
 +++ b/lib/sup/modes/console-mode.rb
 @@ -6,6 +6,18 @@ class Console
    def initialize mode
      @mode = mode
    end
 +
 +  def query(query)
 +    Enumerable::Enumerator.new(Index, :each_message, Index.parse_query(query))
 +  end
 +
 +  def add_labels(query, *labels)
 +    query(query).each { |m| m.labels += labels; m.save Index }
 +  end
 +
 +  def remove_labels(query, *labels)
 +    query(query).each { |m| m.labels -= labels; m.save Index }
 +  end
  end
  
  class ConsoleMode < LogMode
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Mon Aug 17 02:39:14 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 23:39:14 -0700
 Subject: [sup-talk] [PATCH 4/5] console: reload
 In-Reply-To: <1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250491155-19281-4-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/modes/console-mode.rb |   30 ++++++++++++++++++++++++++++++
  1 files changed, 30 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
 index c794a4c..c344fa6 100644
 --- a/lib/sup/modes/console-mode.rb
 +++ b/lib/sup/modes/console-mode.rb
 @@ -21,6 +21,36 @@ class Console
  
    def xapian; Index.instance.instance_variable_get :@xapian; end
    def ferret; Index.instance.instance_variable_get :@index; end
 +
 +  ## files that won't cause problems when reloaded
 +  ## TODO expand this list / convert to blacklist
 +  RELOAD_WHITELIST = %w(sup/xapian_index.rb sup/modes/console-mode.rb)
 +
 +  def reload
 +    old_verbose = $VERBOSE
 +    $VERBOSE = nil
 +    old_features = $".dup
 +    begin
 +      fs = $".grep(/^sup\//)
 +      fs.reject! { |f| not RELOAD_WHITELIST.member? f }
 +      fs.each { |f| $".delete f }
 +      fs.each do |f|
 +        @mode << "reloading #{f}\n"
 +        begin
 +          require f
 +        rescue LoadError => e
 +          raise unless e.message =~ /no such file to load/
 +        end
 +      end
 +    rescue Exception
 +      $".clear
 +      $".concat old_features
 +      raise
 +    ensure
 +      $VERBOSE = old_verbose
 +    end
 +    true
 +  end
  end
  
  class ConsoleMode < LogMode
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Mon Aug 17 02:39:15 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 23:39:15 -0700
 Subject: [sup-talk] [PATCH 5/5] console: clear_hooks
 In-Reply-To: <1250491155-19281-4-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250491155-19281-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1250491155-19281-3-git-send-email-rlane@club.cc.cmu.edu>
 	<1250491155-19281-4-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250491155-19281-5-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/hook.rb               |    2 ++
  lib/sup/modes/console-mode.rb |    5 +++++
  2 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
 index 33a97b2..099158d 100644
 --- a/lib/sup/hook.rb
 +++ b/lib/sup/hook.rb
 @@ -130,6 +130,8 @@ EOS
  
    def enabled? name; !hook_for(name).nil? end
  
 +  def clear; @hooks.clear; end
 +
  private
  
    def hook_for name
 diff --git a/lib/sup/modes/console-mode.rb b/lib/sup/modes/console-mode.rb
 index c344fa6..372a466 100644
 --- a/lib/sup/modes/console-mode.rb
 +++ b/lib/sup/modes/console-mode.rb
 @@ -51,6 +51,11 @@ class Console
      end
      true
    end
 +
 +  def clear_hooks
 +    HookManager.clear
 +    nil
 +  end
  end
  
  class ConsoleMode < LogMode
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Mon Aug 17 02:39:32 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 16 Aug 2009 23:39:32 -0700
 Subject: [sup-talk] [PATCH] cache results of Person.from_address
 Message-ID: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
 
 The regexes in this function are very expensive, so caching improves
 performance significantly for queries and slightly for indexing.
 ---
  lib/sup/cache.rb  |   46 ++++++++++++++++++++++++++++++++++++++++++++++
  lib/sup/person.rb |    7 ++++++-
  2 files changed, 52 insertions(+), 1 deletions(-)
  create mode 100644 lib/sup/cache.rb
 
 diff --git a/lib/sup/cache.rb b/lib/sup/cache.rb
 new file mode 100644
 index 0000000..0836dbd
 --- /dev/null
 +++ b/lib/sup/cache.rb
 @@ -0,0 +1,46 @@
 +class Cache
 +  def initialize n=128, i=3
 +    @n = n
 +    @i = i
 +    @values = {}
 +    @marks = {}
 +    @delete_stack = []
 +  end
 +
 +  def [](k)
 +    if @values.member? k
 +      @marks[k] = @i
 +      @values[k]
 +    else
 +      nil
 +    end
 +  end
 +
 +  def []=(k,v)
 +    if @values.size < @n
 +      @values[k] = v
 +      @marks[k] = @i
 +    else
 +      if @delete_stack.empty?
 +        sweep
 +      else
 +        k2 = @delete_stack.pop
 +        @values.delete k2
 +        @marks.delete k2
 +        self[k] = v
 +      end
 +    end
 +  end
 +
 +  def sweep
 +    @marks.each do |k,v|
 +      v -= 1
 +      if v == 0
 +        @delete_stack.push k
 +        @marks.delete k
 +      else
 +        @marks[k] = v
 +      end
 +    end
 +  end
 +end
 diff --git a/lib/sup/person.rb b/lib/sup/person.rb
 index c4f40a5..046eedc 100644
 --- a/lib/sup/person.rb
 +++ b/lib/sup/person.rb
 @@ -1,3 +1,5 @@
 +require 'sup/cache'
 +
  module Redwood
  
  class Person 
 @@ -73,8 +75,11 @@ class Person
      end.downcase
    end
  
 +  ## This method is expensive, so memoize it.
 +  @from_address_cache = Cache.new
    def self.from_address s
      return nil if s.nil?
 +    @from_address_cache[s].tap { |x| return x if x }
  
      ## try and parse an email address and name
      name, email = case s
 @@ -102,7 +107,7 @@ class Person
          [nil, s]
        end
  
 -    Person.new name, email
 +    @from_address_cache[s] = Person.new name, email
    end
  
    def self.from_address_list ss
 -- 
 1.6.4
 
 
 From taruti@taruti.net  Mon Aug 17 03:22:35 2009
 From: taruti@taruti.net (Taru Karttunen)
 Date: Mon, 17 Aug 2009 10:22:35 +0300
 Subject: [sup-talk] Sup crashing
 In-Reply-To: 1250281208-sup-4199 <1250281208-sup-4199@masanjin.net>
 References: <1250148617-sup-6053@oz.taruti.net>
 	<1250281208-sup-4199@masanjin.net>
 Message-ID: <1250493725-sup-5683@oz.taruti.net>
 
 Excerpts from William Morgan's message of Fri Aug 14 23:20:28 +0300 2009:
 > 
 > Weird. Does sup-sync --optimize fix anything?
 
 Made things work again. Thanks.
 
 - Taru Karttunen
 
 From garoth@gmail.com  Mon Aug 17 09:07:25 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 17 Aug 2009 09:07:25 -0400
 Subject: [sup-talk] [PATCH] cache results of Person.from_address
 In-Reply-To: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250514421-sup-7564@Longbow>
 
 Just want to say thanks again for your seemingly unending amount of good
 work to improve Sup.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From wmorgan-sup@masanjin.net  Mon Aug 17 10:01:10 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 17 Aug 2009 07:01:10 -0700
 Subject: [sup-talk] Sup crashing
 In-Reply-To: <1250493725-sup-5683@oz.taruti.net>
 References: <1250148617-sup-6053@oz.taruti.net>
 	<1250281208-sup-4199@masanjin.net>
 	<1250493725-sup-5683@oz.taruti.net>
 Message-ID: <1250517574-sup-940@masanjin.net>
 
 Reformatted excerpts from Taru Karttunen's message of 2009-08-17:
 > Made things work again. Thanks.
 
 Good.  Let me know if it happens again. I'm not sure what would cause it
 to get in that state.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From dato@net.com.org.es  Mon Aug 17 12:08:57 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Mon, 17 Aug 2009 17:08:57 +0100
 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
 In-Reply-To: <1250453934-sup-9651@zyrg.net>
 References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 	<20090816200116.GA17272@chistera.yi.org>
 	<1250453934-sup-9651@zyrg.net>
 Message-ID: <20090817160857.GA2496@chistera.yi.org>
 
 + Rich Lane (Sun, 16 Aug 2009 16:28:56 -0400):
 
 > How's this wording?
 
 > + fail "This Sup version expects a v#{INDEX_VERSION} index, but you
 > have an existing v#{db_version} index. Please downgrade to your
 > previous version and dump your labels before upgrading to this version
 > (then run sup-sync --restore)."
 
 Sounds much better, thanks!
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From wmorgan-sup@masanjin.net  Mon Aug 17 15:39:57 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 17 Aug 2009 12:39:57 -0700
 Subject: [sup-talk] some internal api refactors
 In-Reply-To: <1250461358-sup-7209@zyrg.net>
 References: <1250021119-sup-4253@masanjin.net>
 	<1250054282-sup-9053@pion.club.cc.cmu.edu>
 	<1250459019-sup-6390@masanjin.net> <1250461358-sup-7209@zyrg.net>
 Message-ID: <1250537445-sup-4504@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-16:
 > The ThreadSet still needs the ref to do the UI-level threading, right?
 > Making it another API call is good as long as that's still taken care
 > of.
 
 I'm thinking about moving in the direction where the index is also
 responsible for threading (so maybe "index" is not the right term
 anymore), so the ThreadSet would just be a static representation of the
 thread structure of a set of messages as returned by the index. We'll
 see how it develops.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 17 15:50:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 17 Aug 2009 12:50:52 -0700
 Subject: [sup-talk] logging and internal API changes in next
 Message-ID: <1250538107-sup-7121@masanjin.net>
 
 Dear Suppers,
 
 I've merged the aforementioned internal API changes, and a pretty big
 rewrite of the logging system (branch "logging"), into next. It works
 for me, but please report any problems you see.
 
 All logging messages are now categorized by level (debug, info, warn,
 error) and will only be output when the global logging level is <= the
 message level. The global logging level is determined by the environment
 variable SUP_LOG_LEVEL; when unset, the default is "info". You'll notice
 that the majority of the messages you saw before are now "debug"
 messages, so the log buffer is much quieter.
 
 This change also applies to the various sup-* scripts.
 
 If you use this code and then switch to a branch without these changes,
 you may encounter errors because labels are now represented on disk as
 Sets instead of arrays. The solution is to edit your sources.yaml file
 and manually change the Sets back to arrays; it should be obvious how to
 do this. I don't anticipate this affecting too many people. If it does,
 we can transform labels to arrays before storing to make this easier,
 but hopefully it's just a temporary issue.
 
 I would like to merge these changes down to master sooner rather than
 later, because they're so far-reaching.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Mon Aug 17 15:54:45 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 17 Aug 2009 15:54:45 -0400
 Subject: [sup-talk] ncurses hack
 Message-ID: <1250538875-sup-2195@javelin>
 
 Today, I decided to throw in the towel and patch my copy of ncurses
 to have the appropriate fix for international characters + tabs.  Does
 anyone know of a list of instructions for carrying this out?
 
 Cheers,
 Edward
 
 From garoth@gmail.com  Mon Aug 17 16:31:22 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 17 Aug 2009 16:31:22 -0400
 Subject: [sup-talk] logging and internal API changes in next
 In-Reply-To: <1250538107-sup-7121@masanjin.net>
 References: <1250538107-sup-7121@masanjin.net>
 Message-ID: <1250541071-sup-7690@Longbow>
 
 Excerpts from William Morgan's message of Mon Aug 17 15:50:52 -0400 2009:
 > Dear Suppers,
 > 
 > I've merged the aforementioned internal API changes, and a pretty big
 > rewrite of the logging system (branch "logging"), into next. It works
 > for me, but please report any problems you see.
 > 
 > All logging messages are now categorized by level (debug, info, warn,
 > error) and will only be output when the global logging level is <= the
 > message level. The global logging level is determined by the environment
 > variable SUP_LOG_LEVEL; when unset, the default is "info". You'll notice
 > that the majority of the messages you saw before are now "debug"
 > messages, so the log buffer is much quieter.
 > 
 > This change also applies to the various sup-* scripts.
 > 
 > If you use this code and then switch to a branch without these changes,
 > you may encounter errors because labels are now represented on disk as
 > Sets instead of arrays. The solution is to edit your sources.yaml file
 > and manually change the Sets back to arrays; it should be obvious how to
 > do this. I don't anticipate this affecting too many people. If it does,
 > we can transform labels to arrays before storing to make this easier,
 > but hopefully it's just a temporary issue.
 > 
 > I would like to merge these changes down to master sooner rather than
 > later, because they're so far-reaching.
 
 Looking forward to it, thanks.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From wmorgan-sup@masanjin.net  Mon Aug 17 22:43:18 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 17 Aug 2009 19:43:18 -0700
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250538875-sup-2195@javelin>
 References: <1250538875-sup-2195@javelin>
 Message-ID: <1250563136-sup-432@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-08-17:
 > Today, I decided to throw in the towel and patch my copy of ncurses to
 > have the appropriate fix for international characters + tabs.  Does
 > anyone know of a list of instructions for carrying this out?
 
 Try http://sup.rubyforge.org/wiki/wiki.pl?UTF8. If you're running Sup
 git, I've made a nice branch for this:
 
   $ git branch --track ncursesw origin/ncursesw
   $ git checkout ncursesw
   $ cd ncurses-0.9.1/
   $ ./run-this-for-sup.sh
 
 Which will generate an ncurses.so file in lib/. You can then switch back
 to master or next and it should pick it up.
 
 This should fix many wide-character issues but it won't fix all of them,
 because there's still no way of determining the display width of a
 unicode character (e.g. Chinese characters take two columns to display).
 So the display still ends up funny.
 
 Ruby 1.9 has better encoding support but I don't know if it fixes this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ef_dva@yahoo.com  Tue Aug 18 03:42:48 2009
 From: ef_dva@yahoo.com (Dusan)
 Date: Tue, 18 Aug 2009 09:42:48 +0200
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250563136-sup-432@masanjin.net>
 References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net>
 Message-ID: <1250580593-sup-1346@archpc>
 
 Excerpts from William Morgan's message of Tue Aug 18 04:43:18 +0200 2009:
 > Reformatted excerpts from Edward Z. Yang's message of 2009-08-17:
 > > Today, I decided to throw in the towel and patch my copy of ncurses to
 > > have the appropriate fix for international characters + tabs.  Does
 > > anyone know of a list of instructions for carrying this out?
 > 
 > Try http://sup.rubyforge.org/wiki/wiki.pl?UTF8. If you're running Sup
 > git, I've made a nice branch for this:
 > 
 >   $ git branch --track ncursesw origin/ncursesw
 >   $ git checkout ncursesw
 >   $ cd ncurses-0.9.1/
 >   $ ./run-this-for-sup.sh
 > 
 > Which will generate an ncurses.so file in lib/. You can then switch back
 > to master or next and it should pick it up.
 > 
 > This should fix many wide-character issues but it won't fix all of them,
 > because there's still no way of determining the display width of a
 > unicode character (e.g. Chinese characters take two columns to display).
 > So the display still ends up funny.
 > 
 > Ruby 1.9 has better encoding support but I don't know if it fixes this.
 
 I am new sup user and love it very much.
 
 Not being able to fix search/save and other edits is huge show-stopper.
 I do what I read somewhere:
 
 -start search, get garbage results
 -kill that buffer with 'x'
 -start another search but instead of typing search term again first
 repeat: press up, delete search garbage, press up, delete search
 garbage, repeat until there is nothing to delete
 -type another search term and search now works 100%
 
 This works for searches but edits like save still fail (or save X((%^1X file
 so if you can find it you can rename it).
 
 Looks like fixable bug to simulate what I did for searches? Repeat in
 code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong.
 
 Using sup and not being able to properly search or save is too wrong.
 
 If there is any config/version I should report to get this fixed just
 let me know. Without waiting for new ruby of course -- I do have proper
 results when I repeat deleting ritual.
 
 Thanks
 
 From bwalton@artsci.utoronto.ca  Tue Aug 18 12:58:57 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 18 Aug 2009 12:58:57 -0400
 Subject: [sup-talk] xapian rpms
 Message-ID: <1250614640-sup-8983@ntdws12.chass.utoronto.ca>
 
 
 Hi All,
 
 I've built a set of rpms for xapian (1.0.14) for rhel5.  If you're
 interested in them, I'll share.  I have both 32 and 64 bit versions.
 The xapian site rpm collection doesn't offer the ruby bindings.
 
 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/20090818/aa04491f/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Tue Aug 18 13:33:33 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 18 Aug 2009 10:33:33 -0700
 Subject: [sup-talk] [PATCH] maildir: Allow ',
 	' in the unique-name portion of a maildir filename.
 In-Reply-To: <20090815042943.GA2414@yoom.home.cworth.org>
 References: <20090815042943.GA2414@yoom.home.cworth.org>
 Message-ID: <1250616640-sup-2613@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-14:
 > A unique name can be anything that doesn't contain a colon (or slash)
 > and doesn't start with a dot.
 
 I've applied this patch directly to master. (The one I complained about
 was attached to your original email; I just noticed this one was
 different now.)
 
 > Argh! What's worse than Forgotten Attachment Syndrome (FAS),
 > (especially on my first post to a list)?
 
 Since Sup should now work for you, you'll be happy to know that it warns
 you if you use the word "attachment" without attaching anything. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Tue Aug 18 13:35:35 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 18 Aug 2009 13:35:35 -0400
 Subject: [sup-talk] crash when sup-syncing to xapian
 Message-ID: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 
 
 I just tried to import my index to xapian and it crashed part way
 through the import.  I then discovered that I couldn't use ferret
 either.  There is something wonky with label handling, as per attached
 exception log.  I haven't had a chance to look at the code yet, but
 I'll poke at it tonight.
 
 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 --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: sup-exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/28bccae3/attachment.txt>
 
 From wmorgan-sup@masanjin.net  Tue Aug 18 13:36:27 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 18 Aug 2009 10:36:27 -0700
 Subject: [sup-talk] [PATCH] skip system buffers when rolling
 In-Reply-To: <1250451359-16110-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250451359-16110-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250616971-sup-7888@masanjin.net>
 
 Nice idea. Branch buffer-rolling, merged into next.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Aug 18 13:38:58 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 18 Aug 2009 10:38:58 -0700
 Subject: [sup-talk] [PATCH] add 'I' keybinding to raise Inbox buffer
 In-Reply-To: <1250451368-16150-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250451368-16150-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250617129-sup-4194@masanjin.net>
 
 Applied to master, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Tue Aug 18 13:49:05 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 18 Aug 2009 10:49:05 -0700
 Subject: [sup-talk] [PATCH] maildir: Allow ',
 	' in the unique-name portion of a maildir filename.
 In-Reply-To: <1250616640-sup-2613@masanjin.net>
 References: <20090815042943.GA2414@yoom.home.cworth.org>
 	<1250616640-sup-2613@masanjin.net>
 Message-ID: <1250617174-sup-2755@yoom>
 
 Excerpts from William Morgan's message of Tue Aug 18 10:33:33 -0700 2009:
 > I've applied this patch directly to master. (The one I complained about
 > was attached to your original email; I just noticed this one was
 > different now.)
 
 Thanks for catching this.
 
 > > Argh! What's worse than Forgotten Attachment Syndrome (FAS),
 > > (especially on my first post to a list)?
 > 
 > Since Sup should now work for you, you'll be happy to know that it warns
 > you if you use the word "attachment" without attaching anything. :)
 
 If it's just the word "attachment" I don't think it will affect me at
 all. The wording I generally use is something like:
 
 	I've attached a test case to demonstrate the bug.
 
 But in general this should be a nice feature, (except for a mail like
 this one that will cause a false warning from the check). ;-)
 
 Thanks again for all your work on sup,
 
 -Carl
 -------------- 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/20090818/26c6e1c6/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Tue Aug 18 13:54:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 18 Aug 2009 10:54:20 -0700
 Subject: [sup-talk] [PATCH] maildir: Allow ',
 	' in the unique-name portion of a maildir filename.
 In-Reply-To: <1250617174-sup-2755@yoom>
 References: <20090815042943.GA2414@yoom.home.cworth.org>
 	<1250616640-sup-2613@masanjin.net> <1250617174-sup-2755@yoom>
 Message-ID: <1250617985-sup-2416@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-18:
 > If it's just the word "attachment" I don't think it will affect me at
 > all.
 
 Don't worry, Sup uses sophisticated natural language technology to
 induce message semantics.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Aug 18 13:56:15 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 18 Aug 2009 10:56:15 -0700
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 In-Reply-To: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com>
 References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com>
 Message-ID: <1250618123-sup-8797@masanjin.net>
 
 Reformatted excerpts from Kevin Riggle's message of 2009-08-16:
 > I want to do some unrelated processing on each message I receive, but
 > I don't want to block the message being added to the index.  This
 > patch adds a hook which runs /after/ the message is added to the
 > index.
 
 Won't this block subsequent emails from being added to the index, when
 Sup gets multiple new emails during a poll?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From benoit.pierre@gmail.com  Tue Aug 18 14:20:41 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Tue, 18 Aug 2009 20:20:41 +0200
 Subject: [sup-talk] crash when sup-syncing to xapian
 In-Reply-To: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 Message-ID: <1250619511-sup-2827@localdomain>
 
 Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
 > 
 > I just tried to import my index to xapian and it crashed part way
 > through the import.  I then discovered that I couldn't use ferret
 > either.  There is something wonky with label handling, as per attached
 > exception log.  I haven't had a chance to look at the code yet, but
 > I'll poke at it tonight.
 
 I think I just ran into the same problem! For now I fixed it with
 the following small patch:
 
 diff --git a/lib/sup/label.rb b/lib/sup/label.rb
 index 67474c2..59c0c0f 100644
 --- a/lib/sup/label.rb
 +++ b/lib/sup/label.rb
 @@ -61,6 +61,7 @@ class LabelManager
    end
 
    def << t
 +    t = t.to_sym if t.is_a? String
      raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol
      unless @labels.member?(t) || RESERVED_LABELS.member?(t)
        @labels[t] = true
 
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 289 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/4a4ab3f7/attachment.bin>
 
 From benoit.pierre@gmail.com  Tue Aug 18 14:24:45 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Tue, 18 Aug 2009 20:24:45 +0200
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250580593-sup-1346@archpc>
 References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net>
 	<1250580593-sup-1346@archpc>
 Message-ID: <1250619721-sup-91@localdomain>
 
 Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
 >
 > [...]
 > 
 > Not being able to fix search/save and other edits is huge show-stopper.
 > I do what I read somewhere:
 > 
 > -start search, get garbage results
 > -kill that buffer with 'x'
 > -start another search but instead of typing search term again first
 > repeat: press up, delete search garbage, press up, delete search
 > garbage, repeat until there is nothing to delete
 > -type another search term and search now works 100%
 > 
 > This works for searches but edits like save still fail (or save X((%^1X file
 > so if you can find it you can rename it).
 > 
 > Looks like fixable bug to simulate what I did for searches? Repeat in
 > code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong.
 > 
 > Using sup and not being able to properly search or save is too wrong.
 > 
 > If there is any config/version I should report to get this fixed just
 > let me know. Without waiting for new ruby of course -- I do have proper
 > results when I repeat deleting ritual.
 
 Hi, can you try the following patch and tell me if it fix the problem?
 
 diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
 index b8dec59..ccc8533 100644
 --- a/lib/sup/textfield.rb
 +++ b/lib/sup/textfield.rb
 @@ -36,8 +36,9 @@ class TextField
      @field = Ncurses::Form.new_field 1, @width - question.length, @y,
 @x + question.length, 256, 0
      @form = Ncurses::Form.new_form [@field]
      @value = default
 +    @value ||= ''
      Ncurses::Form.post_form @form
 -    set_cursed_value default if default
 +    set_cursed_value @value
    end
 
    def position_cursor
 
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 
 From alex@chmrr.net  Tue Aug 18 14:30:00 2009
 From: alex@chmrr.net (Alex Vandiver)
 Date: Tue, 18 Aug 2009 14:30:00 -0400
 Subject: [sup-talk] [PATCH] Fix a thread merging bug introduced by
 	refactoring in 59f8fc2
 Message-ID: <1250620200-24319-1-git-send-email-alex@chmrr.net>
 
 
 Signed-off-by: Alex Vandiver <alex at chmrr.net>
 ---
  lib/sup/thread.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb
 index d395c35..3ff4e7f 100644
 --- a/lib/sup/thread.rb
 +++ b/lib/sup/thread.rb
 @@ -357,7 +357,7 @@ class ThreadSet
      return if threads.size < 2
  
      containers = threads.map do |t|
 -      c = @messages.member?(c) ? @messages[t.first.id] : nil
 +      c = @messages.member?(t.first.id) ? @messages[t.first.id] : nil
        raise "not in threadset: #{t.first.id}" unless c && c.message
        c
      end
 -- 
 1.6.3.3
 
 
 From wmorgan-sup@masanjin.net  Tue Aug 18 14:37:38 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 18 Aug 2009 11:37:38 -0700
 Subject: [sup-talk] [PATCH 1/5] console mode
 In-Reply-To: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491155-19281-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250620017-sup-3445@masanjin.net>
 
 Cool idea. Branch console-mode, merged into next.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Tue Aug 18 14:42:13 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 18 Aug 2009 14:42:13 -0400
 Subject: [sup-talk] crash when sup-syncing to xapian
 In-Reply-To: <1250619511-sup-2827@localdomain>
 References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 	<1250619511-sup-2827@localdomain>
 Message-ID: <1250620771-sup-1373@zyrg.net>
 
 Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009:
 > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
 > > 
 > > I just tried to import my index to xapian and it crashed part way
 > > through the import.  I then discovered that I couldn't use ferret
 > > either.  There is something wonky with label handling, as per attached
 > > exception log.  I haven't had a chance to look at the code yet, but
 > > I'll poke at it tonight.
 > 
 > I think I just ran into the same problem! For now I fixed it with
 > the following small patch:
 
 That's odd because the Xapian code passes the labels straight through
 from the message to LabelManager. Try instrumenting Message#labels= to
 raise an exception if any member of the set is not a Symbol.
 
 From ef_dva@yahoo.com  Tue Aug 18 14:46:52 2009
 From: ef_dva@yahoo.com (Dusan)
 Date: Tue, 18 Aug 2009 20:46:52 +0200
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250619721-sup-91@localdomain>
 References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net>
 	<1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain>
 Message-ID: <1250620908-sup-7463@archpc>
 
 Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
 > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
 > >
 > > [...]
 > > 
 > > Not being able to fix search/save and other edits is huge show-stopper.
 > > I do what I read somewhere:
 > > 
 > > -start search, get garbage results
 > > -kill that buffer with 'x'
 > > -start another search but instead of typing search term again first
 > > repeat: press up, delete search garbage, press up, delete search
 > > garbage, repeat until there is nothing to delete
 > > -type another search term and search now works 100%
 > > 
 > > This works for searches but edits like save still fail (or save X((%^1X file
 > > so if you can find it you can rename it).
 > > 
 > > Looks like fixable bug to simulate what I did for searches? Repeat in
 > > code ten times 'up arrow', '50 x delete char'? Sorry if I am wrong.
 > > 
 > > Using sup and not being able to properly search or save is too wrong.
 > > 
 > > If there is any config/version I should report to get this fixed just
 > > let me know. Without waiting for new ruby of course -- I do have proper
 > > results when I repeat deleting ritual.
 > 
 > Hi, can you try the following patch and tell me if it fix the problem?
 > 
 > diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
 > index b8dec59..ccc8533 100644
 > --- a/lib/sup/textfield.rb
 > +++ b/lib/sup/textfield.rb
 > @@ -36,8 +36,9 @@ class TextField
 >      @field = Ncurses::Form.new_field 1, @width - question.length, @y,
 > @x + question.length, 256, 0
 >      @form = Ncurses::Form.new_form [@field]
 >      @value = default
 > +    @value ||= ''
 >      Ncurses::Form.post_form @form
 > -    set_cursed_value default if default
 > +    set_cursed_value @value
 >    end
 > 
 >    def position_cursor
 
 I will, just give me day or two. I am using gem version, not svn or git.
 I did some stuff with them but never with ruby. Can you give me two
 lines help what to install and where? Latest svn?
 
 Sorry I am not _that_ helpful but ruby is new thing to me. I should be
 able to test this soon enough with some help.
 
 Thanks,
 Dusan
 
 From benoit.pierre@gmail.com  Tue Aug 18 14:59:20 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Tue, 18 Aug 2009 20:59:20 +0200
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250620908-sup-7463@archpc>
 References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net>
 	<1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain>
 	<1250620908-sup-7463@archpc>
 Message-ID: <1250621614-sup-5683@localdomain>
 
 Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009:
 > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
 > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
 >
 > [...]
 > 
 > I will, just give me day or two. I am using gem version, not svn or git.
 > I did some stuff with them but never with ruby. Can you give me two
 > lines help what to install and where? Latest svn?
 
 You can probably directly patch the sources in the gem. For example on
 Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx.
 
 Use 'gem environment' to get the installation directory.
 
 Another option is to follow the wiki to get the latest git version:
 http://sup.rubyforge.org/wiki/wiki.pl?Contributing
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/302eaeb0/attachment.bin>
 
 From ef_dva@yahoo.com  Tue Aug 18 15:04:16 2009
 From: ef_dva@yahoo.com (Dusan)
 Date: Tue, 18 Aug 2009 21:04:16 +0200
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250621614-sup-5683@localdomain>
 References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net>
 	<1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain>
 	<1250620908-sup-7463@archpc> <1250621614-sup-5683@localdomain>
 Message-ID: <1250622060-sup-324@archpc>
 
 Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:59:20 +0200 2009:
 > Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009:
 > > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
 > > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
 > >
 > > [...]
 > > 
 > > I will, just give me day or two. I am using gem version, not svn or git.
 > > I did some stuff with them but never with ruby. Can you give me two
 > > lines help what to install and where? Latest svn?
 > 
 > You can probably directly patch the sources in the gem. For example on
 > Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx.
 > 
 > Use 'gem environment' to get the installation directory.
 > 
 > Another option is to follow the wiki to get the latest git version:
 > http://sup.rubyforge.org/wiki/wiki.pl?Contributing
 
 Everything but git, thanks :)
 Of course, ruby is interpreter, I keep forgetting that.
 I am using ArchLinux and should be fairly skilled to do some changing. Reporting
 back tomorrow.
 
 From benoit.pierre@gmail.com  Tue Aug 18 15:17:03 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Tue, 18 Aug 2009 21:17:03 +0200
 Subject: [sup-talk] crash when sup-syncing to xapian
 In-Reply-To: <1250620771-sup-1373@zyrg.net>
 References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 	<1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net>
 Message-ID: <1250622911-sup-2815@localdomain>
 
 Excerpts from Rich Lane's message of Tue Aug 18 20:42:13 +0200 2009:
 > Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009:
 > > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
 > > > 
 > > > I just tried to import my index to xapian and it crashed part way
 > > > through the import.  I then discovered that I couldn't use ferret
 > > > either.  There is something wonky with label handling, as per attached
 > > > exception log.  I haven't had a chance to look at the code yet, but
 > > > I'll poke at it tonight.
 > > 
 > > I think I just ran into the same problem! For now I fixed it with
 > > the following small patch:
 > 
 > That's odd because the Xapian code passes the labels straight through
 > from the message to LabelManager. Try instrumenting Message#labels= to
 > raise an exception if any member of the set is not a Symbol.
 
 I applied the following patch:
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 965c10e..9156c02 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -1,4 +1,5 @@
  require 'time'
 +require 'pp'
 
  module Redwood
 
 @@ -183,6 +184,7 @@ class Message
    def labels= l
      raise ArgumentError, "not a set" unless l.is_a?(Set)
      return if @labels == l
 +    warn "labels=#{l.pretty_inspect}"
      @labels = l
      @dirty = true
    end
 
 And get this in the logs:
 
 [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread, "aquarius", "music"}>
 [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread, "metalblade", "music"}>
 
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/721494a9/attachment.bin>
 
 From ef_dva@yahoo.com  Tue Aug 18 15:24:44 2009
 From: ef_dva@yahoo.com (Dusan)
 Date: Tue, 18 Aug 2009 21:24:44 +0200
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250621614-sup-5683@localdomain>
 References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net>
 	<1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain>
 	<1250620908-sup-7463@archpc> <1250621614-sup-5683@localdomain>
 Message-ID: <1250623031-sup-6731@archpc>
 
 Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:59:20 +0200 2009:
 > Excerpts from Dusan's message of Tue Aug 18 20:46:52 +0200 2009:
 > > Excerpts from Beno?t PIERRE's message of Tue Aug 18 20:24:45 +0200 2009:
 > > > Excerpts from Dusan's message of Tue Aug 18 09:42:48 +0200 2009:
 > >
 > > [...]
 > > 
 > > I will, just give me day or two. I am using gem version, not svn or git.
 > > I did some stuff with them but never with ruby. Can you give me two
 > > lines help what to install and where? Latest svn?
 > 
 > You can probably directly patch the sources in the gem. For example on
 > Ubuntu, the sources should be somewhere in /var/lib/gems/1.8/gems/sup-xxx.
 > 
 > Use 'gem environment' to get the installation directory.
 > 
 > Another option is to follow the wiki to get the latest git version:
 > http://sup.rubyforge.org/wiki/wiki.pl?Contributing
 
 Bah, I could not wait till tomorrow and it's not _that_ late...
 
 This fix WORKS :) Every time so far. Please include this into release
 asap, this is what prevents a lot of people from using sup.
 
 I patched source with vim, diff is too automatic :)
 
 Here is func that works:
 
   activate window, y, x, width, question, default=nil, &block
     @w, @y, @x, @width = window, y, x, width
     @question = question
     @completion_block = block
     @field = Ncurses::Form.new_field 1, @width - question.length, @y, @x
 + question.length, 256, 0
     @form = Ncurses::Form.new_form [@field]
     @value = default
     @value ||= ''
     Ncurses::Form.post_form @form
     # set_cursed_value default if default
     set_cursed_value @value
   end 
 
 Probably @value=default can go too, not sure since I don't know ruby?
 
 Thanks a lot!
 
 From bachjh@googlemail.com  Tue Aug 18 15:31:35 2009
 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=)
 Date: Tue, 18 Aug 2009 21:31:35 +0200
 Subject: [sup-talk] ncurses hack
 In-Reply-To: <1250619721-sup-91@localdomain>
 References: <1250538875-sup-2195@javelin> <1250563136-sup-432@masanjin.net>
 	<1250580593-sup-1346@archpc> <1250619721-sup-91@localdomain>
 Message-ID: <91de50e10908181231h2f8f4cbdr6ab546aa4a3466ca@mail.gmail.com>
 
 2009/8/18 Beno?t PIERRE <benoit.pierre at gmail.com>:
 > Hi, can you try the following patch and tell me if it fix the problem?
 >
 > diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
 > index b8dec59..ccc8533 100644
 > --- a/lib/sup/textfield.rb
 > +++ b/lib/sup/textfield.rb
 > @@ -36,8 +36,9 @@ class TextField
 > ? ? @field = Ncurses::Form.new_field 1, @width - question.length, @y,
 > @x + question.length, 256, 0
 > ? ? @form = Ncurses::Form.new_form [@field]
 > ? ? @value = default
 > + ? ?@value ||= ''
 > ? ? Ncurses::Form.post_form @form
 > - ? ?set_cursed_value default if default
 > + ? ?set_cursed_value @value
 > ? end
 >
 > ? def position_cursor
 
 Thanks a lot. I don't know what this does exactly, but the first added
 line of that patch was sufficient to get searches with utf-8 running
 well from startup, without the need to go for a dummy search each time
 i restarted sup.
 
 The full patch (including the replacement at line 41) broke searching
 altogether, on hitting '\' it throws:
 
 --- TypeError from thread: main
 can't convert nil into String
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:159:in
 `set_field_buffer'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:159:in
 `set_cursed_value'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/textfield.rb:42:in `activate'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:537:in `ask'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:26:in `synchronize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:26:in `sync'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/buffer.rb:536:in `ask'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:268
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 
 
 - J?rg-Hendrik
 
 From rlane@club.cc.cmu.edu  Tue Aug 18 15:52:12 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 18 Aug 2009 15:52:12 -0400
 Subject: [sup-talk] crash when sup-syncing to xapian
 In-Reply-To: <1250622911-sup-2815@localdomain>
 References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 	<1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net>
 	<1250622911-sup-2815@localdomain>
 Message-ID: <1250624577-sup-4801@zyrg.net>
 
 Excerpts from Beno?t PIERRE's message of Tue Aug 18 15:17:03 -0400 2009:
 > Excerpts from Rich Lane's message of Tue Aug 18 20:42:13 +0200 2009:
 > > Excerpts from Beno?t PIERRE's message of Tue Aug 18 14:20:41 -0400 2009:
 > > > Excerpts from Ben Walton's message of Tue Aug 18 19:35:35 +0200 2009:
 > > > > 
 > > > > I just tried to import my index to xapian and it crashed part way
 > > > > through the import.  I then discovered that I couldn't use ferret
 > > > > either.  There is something wonky with label handling, as per attached
 > > > > exception log.  I haven't had a chance to look at the code yet, but
 > > > > I'll poke at it tonight.
 > > > 
 > > > I think I just ran into the same problem! For now I fixed it with
 > > > the following small patch:
 > > 
 > > That's odd because the Xapian code passes the labels straight through
 > > from the message to LabelManager. Try instrumenting Message#labels= to
 > > raise an exception if any member of the set is not a Symbol.
 > 
 > I applied the following patch:
 > 
 > diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 > index 965c10e..9156c02 100644
 > --- a/lib/sup/message.rb
 > +++ b/lib/sup/message.rb
 > @@ -1,4 +1,5 @@
 >  require 'time'
 > +require 'pp'
 > 
 >  module Redwood
 > 
 > @@ -183,6 +184,7 @@ class Message
 >    def labels= l
 >      raise ArgumentError, "not a set" unless l.is_a?(Set)
 >      return if @labels == l
 > +    warn "labels=#{l.pretty_inspect}"
 >      @labels = l
 >      @dirty = true
 >    end
 > 
 > And get this in the logs:
 > 
 > [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread,
 > "aquarius", "music"}>
 > [Tue Aug 18 21:12:39 +0200 2009] WARNING: labels=#<Set: {:inbox, :unread,
 > "metalblade", "music"}>
 > 
 
 It'd be nice to get a backtrace including the offending caller. I'd just
 replace the warn with a fail.
 
 From benoit.pierre@gmail.com  Tue Aug 18 16:14:49 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Tue, 18 Aug 2009 22:14:49 +0200
 Subject: [sup-talk] crash when sup-syncing to xapian
 In-Reply-To: <1250624577-sup-4801@zyrg.net>
 References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 	<1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net>
 	<1250622911-sup-2815@localdomain> <1250624577-sup-4801@zyrg.net>
 Message-ID: <1250626302-sup-2408@localdomain>
 
 Excerpts from Rich Lane's message of Tue Aug 18 21:52:12 +0200 2009:
 > Excerpts from Beno?t PIERRE's message of Tue Aug 18 15:17:03 -0400 2009:
 >
 > [...]
 > 
 > It'd be nice to get a backtrace including the offending caller. I'd just
 > replace the warn with a fail.
 
 The problem comes from my ~/.sup/sources.yaml file, the labels for a source
 are not symbols:
 
     hash: 
       relapse: true
       music: true
 
 After converting them to symbols it works:
 
     hash: 
       :relapse: true
       :music: true
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/94c721f9/attachment.bin>
 
 From cworth@cworth.org  Tue Aug 18 17:02:05 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 18 Aug 2009 14:02:05 -0700
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 Message-ID: <1250629282-sup-8521@yoom>
 
 I'm now a few days into using sup, and it's clearly helped me to be
 more productive at processing mail, (inbox is down to 0 from *lots* of
 messages), so thanks!
 
 However, I still don't feel like I'm experiencing the zen of sup
 yet. So I'm interested in hearing from others:
 
     What is your typical workflow with sup? That is:
 
     What different modes of task do you find yourself doing with sup?
     Precisely what keystrokes do you use for those tasks?
     Where, if anywhere, does sup get in your way rather than help?
 
 What follows is my (rather long) answer to those questions, and more
 or less a todo list of things I'd like to help improve in sup.
 
 My desired workflow
 ===================
 I think there's a basic two-level approach I take to processing new
 email. Fortunately, these two modes correspond well with sup's
 inbox-mode and thread-view-mode. Here's what I'd like to do:
 
 Identify "unimportant" threads (no need to read)
 ------------------------------------------------
 This is a quick scan of the thread titles in my inbox. The goal here
 is to identify as quickly as possible threads that I will never need
 to read at all, (so that they can be immediately removed from my
 inbox). Ideally, I will make a decision in one or two seconds, and
 issue a single character command to indicate the decision.
 
 Dealing with remaining "important" threads
 ------------------------------------------
 After having eliminated as many threads as possible during the scan of
 the inbox, I now switch to a mode where I'm actually looking at mail
 messages. The goal here is to identify whether I need to do anything,
 and how much time that will take. There are three possible outcomes:
 
     * No action needed
 
     * Quick action, (less than two minutes)
 
     * Longer action required (to assign to some project)
 
 (Any similarity to a method proposed by David Allen in Getting Things
 Done is not accidental, and he deserves credit as such.)   
 
 Regardless of the three results, I will be quickly archiving the
 thread so that it's gone from my inbox. That will be either immediate
 archiving, archiving after a quick action (such as a reply), or
 archiving after tagging the thread with a label for the appropriate
 project.
 
 How sup could support my workflow better
 ========================================
 So sup obviously fits in quite well with the above model---which is
 why I immediately fell in love with it. So first of all I have to
 again say thank you. And I apologize that I will go into more detail
 on the things I'd like to change in sup as opposed to the things that
 already work so well. This isn't a criticism of the tool, just an
 expression of my desire to improve it.
 
 I'll phrase the list below as feature requests. Some of these things
 may already exist in sup, and I just missed them. In such cases, I'll
 be glad to hear pointers to the things I missed. Otherwise, I plan to
 work on developing patches for these, and I'll be glad for any help.
 
 I'll give each feature a name in [square-brackets] for easy reference in followup messages.
 
 inbox-mode
 -----------
 * [black-on-white-color-scheme]
 
   We've talked in another thread about adding support for a
   black-text-on-white-background color scheme to sup-config. Before I
   can write a patch for that, does somebody have an example
   black-on-white color scheme that works well? I've been trying to
   come up with one but I've been unable to find how to change some
   colors, specifically:
 
   + [change-color-of-thread-selector]
 
     The selector for the current thread in thread-mode appears as
     black-foreground-on-cyan right now. I haven't been able to find
     the setting to make that a more easy-to-read background color, and
     this is the only line in the view that isn't bold when unread,
     (which is not ideal since it's the only line I'm trying to read
     and process).
 
   + [change-color-of-tag-markers]
 
     The tag markers are yellow, which is hard to see on white. I also
     couldn't find the setting to change this.
 
 * [import-read-messages-as-archived-from-initial-sup-config-based-sync]
   
   When I very first started using sup, (running sup-config which setup
   sources and ran sup-sync) I was surprised to find my inbox with
   thousands of unread messages in it. Now that I'm using sup more I
   love that sup treats inbox and unread as separate labels, (far too
   many email programs fail to separate those notions). But for that
   initial import, I think it would have been much more useful to have
   only given the inbox tag to unread messages.
 
 * [sort-priority-labels-before-date]
  
   The default sorting for the inbox is reverse-chronological which is
   a reasonable-enough default, (and works fine for me when I keep my
   inbox small). But when I get behind and my inbox gets large, (say
   after a few days away from email), I do have some tags that I would
   like to be sorted to the top, regardless of date. How about support
   for a configurable list of "priority" tags that would provide a
   primary sort before the date-based sort?
 
 * [save-all-state-changes-immediately]
 
   The 'a' and 'd' commands do almost exactly what I expect, (by
   immediately making the current thread disappear and advancing the
   selector to the next thread). That's perfect for fast
   processing. One thing missing here is that they don't actually save
   this state, (requiring me to hit '$' at some point). Perhaps that
   safety feature was more important before undo was implemented, but
   now that it exists, would immediate state saving make sense?
 
   The two bad side effects I've experienced due to lack of immediate
   saving are: 1. Seeing confusingly inconsistent results after
   processing a bunch of my inbox and then doing a search based on
   label:unread or label:inbox (Why am I seeing all these messages
   again?). 2. Losing a bunch of processing state due to crashes. (The
   crashes have been due to the mbox-processing bug which has since
   been fixed, but being immune to state loss for any future crashes
   would be beneficial.)
 
 search-results-mode
 -------------------
 * [provide-commands-to-refine-the-current-search]
 
   I mentioned above wanting to sort priority labels before
   date. Similarly, when processing a very large email I sometimes want
   to process related messages together, (to reduce mental context
   switches). So I want variants of both "\, F: Search all messages"
   and "L: list labels" search commands that refine the current search
   rather than doing a new global search. That is, the new commands
   would simply append new search terms to the current search rather
   than starting a new search.
 
 * [allow-for-inbox-mode-magic-elsewhere]
 
   Another way to reword this one would be to "eliminate any magic of
   inbox mode". My question is, "What makes inbox-mode different than
   search-results-mode and how can I get the behavior of inbox-mode in
   my searches?".
 
   Without commands to refine the current search as described above,
   I've been trying to achieve results like "inbox refined to
   label:foo" with a search as follows:
 
 	label:inbox -label:killed label:foo
 
   This gives me the set of threads that I want, but now my standard
   processing commands no longer work. For example, the 'a' key still
   removes the inbox label, but it doesn't make the tag then disappear
   immediately.
 
   One approach to fix this would be that when adding the commands to
   refine the inbox search, the new search results would also be in
   inbox-mode with all necessary magic.
 
   A more general fix would be to process the current thread after any
   changes, (such as the addition or removal of a label), and removing
   it from the current search results if it no longer meets those
   criteria.
 
 * [fix-handling-of-kill-thread-outside-inbox]
 
   The handling of the "&: kill thread" command when applied outside of
   the inbox, (such as in search-results-mode), is currently very
   confusing. What it currently seems to do is to add the killed label
   and make the thread disappear from the current view. But then,
   running "@: Refresh view" will make it reappear, (whereupon one can
   make it disappear again with &, ad infinitum). The removal of the
   thread from the current view seems to be magic associated with the
   kill-thread command, (leading to inconsistent behavior). I would
   again suggest to instead implement the general fix described above,
   (always reprocessing a thread after label changes to see if it still
   meets the current search). That way, trying to kill a thread without
   -label:killed in the current search would simply add the "killed"
   label and the user would learn to add the necessary search terms,
   (or to do searches based on refining the searches of existing views
   to inherit this term).
 
 thread-view-mode
 ----------------
 * [override-arrow-keys-to-jump-to-next-actionable-line]
 
   In thread-view-mode the up and down arrows currently advance a
   selector by one line at a time, (inherited from line-cursor-mode),
   all the way into message bodies. As far as I can tell, this is not a
   useful behavior. I propose that the down arrow key should instead
   advance the selector to the next line which would cause a context
   change for the various operations that can be performed based on the
   selector, (or scroll to the next page if there are no such lines on
   the current or next page).
 
 * [be-less-overzealous-in-moving-text-to-the-left-column]
 
   I tend to use sup in a very wide terminal, (200+ columns). And I'm
   glad to see that the inbox-mode takes advantage of this by showing a
   preview of the message body (that's a nice touch!) where many
   console-based clients just cut things off at 80 columns.
 
   However, in thread-view-mode, sup always pushes the current message
   all the way over to the left-hand column. This does mean that the
   "current" message is visible, but I have a tendency to read much
   more than the current message, (even before advancing), and
   subsequent messages are often scrolled such that the first several
   columns of text are scrolled off to the left. Meanwhile, I have
   acres of terminal real-estate to the right that sup isn't using.
 
   I would propose that messages only be scrolled to the left if
   necessary to avoid the 80th column of the message body not being
   visible, (assuming the terminal is at least 80 columns wide).
 
 compose-mode
 ------------
 * [repeated-postponing-shouldnt-make-additional-drafts]
 
   I find that while composing a message I often want to go look at
   some other messages for reference. This is currently quite awkward
   with sup. It would be easier if sup could be run multiple times. It
   would also be easier if sup could somehow fire off an editor as an
   external process, while still allowing for sup to be operated.
 
   As it stands, instead, I have to save and quit from my editor,
   postpone the message within sup, and then later come back to edit it
   again, and find where I was in the editor. It's an expensive context
   switch with a lot of keystrokes and lost state, (such as where point
   was inside emacs, my kill ring, etc.). I'm currently finding myself
   sometimes just drafting messages in emacs sessions unrelated to sup,
   and then doing "M-x insert-file" once sup has launched emacs for
   me. (This does relate a bit to the point I made in a previous thread
   where I would love to find a way to keep all the mail-composition
   tasks very separate from sup, but not lose things like replied-to
   bits.)
 
   Anyway, the current misfeature I'm hitting is that if I do postpone
   a draft, then return to edit it more, then postpone it again,
   etc. eventually when I send the message I'll have several
   partially-composed drafts in various states that I need to go and
   manually clean up. It seems like most email programs avoid this
   problem by removing the draft as soon as its selected for editing
   again, and I propose that sup do the same.
 
 Anyway, I've probably run into several other little things that I
 didn't capture in this email, but I'll hopefully remember them
 later. If anyone has feedback on any of the above, (and actually read
 this far!), then I'll appreciate getting it.
 
 Otherwise, like I said, I hope to start trying to implement some of
 these ideas, and when I do, I'll of course come back with separate new
 threads for each.
 
 -Carl
 
 -------------- 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/20090818/43f15a25/attachment.bin>
 
 From pioto@pioto.org  Tue Aug 18 13:30:34 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Tue, 18 Aug 2009 13:30:34 -0400
 Subject: [sup-talk] Crash w/ current 'next'
 Message-ID: <aeb4682e1581f7534cb1c81bd143dbc6@pioto.org>
 
 Hi,
 
 I just built from the current next branch, and now whenever I load sup, it
 gives me the attached crash.
 
 I'm guessing this is related to the Set thing William mentioned, but I have
 just gone from an older 'next' to a newer one, which I thought was supposed
 to not have this problem.
 
 Any suggestions?
 
 -- 
 Mike Kelly
 -------------- next part --------------
 --- ArgumentError from thread: poll after loading inbox
 expecting a symbol
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/label.rb:64:in `<<'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:149:in `each_message_from'
 /usr/local/lib/ruby/1.8/set.rb:195:in `each'
 /usr/local/lib/ruby/1.8/set.rb:195:in `each_key'
 /usr/local/lib/ruby/1.8/set.rb:195:in `each'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:149:in `each_message_from'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in `each_message_from'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:93:in `do_poll'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `each'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `do_poll'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `synchronize'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `do_poll'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:48:in `poll'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:666:in `call'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:666:in `__unprotected_load_threads'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `call'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup:190
 /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup:19:in `load'
 /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup:19
 
 From cworth@cworth.org  Tue Aug 18 17:46:41 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 18 Aug 2009 14:46:41 -0700
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250629282-sup-8521@yoom>
 References: <1250629282-sup-8521@yoom>
 Message-ID: <1250631221-sup-8993@yoom>
 
 Excerpts from Carl Worth's message of Tue Aug 18 14:02:05 -0700 2009:
 > Anyway, I've probably run into several other little things that I
 > didn't capture in this email, but I'll hopefully remember them
 > later.
 
 And of course, here are a few:
 
 inbox-mode
 ----------
  * [dont-perturb-selected-thread-when-new-mail-arrives]
 
    I think I just saw the following race condition:
 
 	1. I have the top-most thread selected and I identify it as spam
 	2. I start moving to press the d key to delete it
 	3. Before I get their, new mail arrives and becomes selected
 	4. I delete mail I really care about
 
    I propose that new mail arriving should not cause the selector to
    move from the thread currently selected.
 
 label-list-mode
 ---------------
  * [allow-for-limiting-to-interesting-labels]
 
    In the workflow I described earlier, I process all mail mercilessly
    and get it archived and out of my inbox as quickly as possible. But
    some of those threads I identified as needing some significant time
    to deal with, so I labelled them to assign them to a particular
    "project".
 
    So, later, I'd like to look at my list of projects, choose one, and
    then choose the first task to be done.
 
    The label-list-mode is *almost* the perfect thing for this. The
    only problem is that it displays several labels, (with *lots* of
    messages each) that are not interesting to me at all in this
    sense. For example, killed and unread, for example, as well as
    several other labels that I use in ways other than my "project"
    labels.
 
    What I'd like here is a feature much like 'u' which toggles to
    display of only labels with unread messages, but insteads toggles
    to display only the labels that I've somehow marked as my "project"
    labels. (I'm not sure exactly how to name this feature for general
    use. The "project" sense is something personal to my usage. Maybe,
    "todo" or something?)
 
 inbox-mode/search-result-mode
 -----------------------------
 * [display-number-of-unread-messages]
 
   In my ruthless scan while processing new messages, I want to be able
   to make split-second, yet accurate, decisions on whether I need to
   read messages, (and if so, how much time it will take). The current
   thread display shows a total number of messages within a thread, but
   that leads to me making an inaccurate estimate of how "expensive" it
   would be to read a thread. I'd much rather see the number of unread
   messages in the thread. Perhaps best would be to diplay both numbers
   such as: (1/64) with the 1 in bold to indicate that a thread with 64
   total messages has 1 unread message.
 
 -Carl
 -------------- 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/20090818/5f65c5b3/attachment.bin>
 
 From garoth@gmail.com  Tue Aug 18 18:07:28 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 18 Aug 2009 18:07:28 -0400
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250629282-sup-8521@yoom>
 References: <1250629282-sup-8521@yoom>
 Message-ID: <1250632714-sup-9910@Longbow>
 
 Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009:
 > * [sort-priority-labels-before-date]
 >  
 >   The default sorting for the inbox is reverse-chronological which is
 >   a reasonable-enough default, (and works fine for me when I keep my
 >   inbox small). But when I get behind and my inbox gets large, (say
 >   after a few days away from email), I do have some tags that I would
 >   like to be sorted to the top, regardless of date. How about support
 >   for a configurable list of "priority" tags that would provide a
 >   primary sort before the date-based sort?
 
 Yeah, I'd really really like this also. This has been discussed, and in
 general, it'd be lovely to be able to sort by hook or something. I think
 grouping by labels first and then by time would be a good default.
 
 > * [save-all-state-changes-immediately]
 > 
 >   The 'a' and 'd' commands do almost exactly what I expect, (by
 >   immediately making the current thread disappear and advancing the
 >   selector to the next thread). That's perfect for fast
 >   processing. One thing missing here is that they don't actually save
 >   this state, (requiring me to hit '$' at some point). Perhaps that
 >   safety feature was more important before undo was implemented, but
 >   now that it exists, would immediate state saving make sense?
 > 
 >   The two bad side effects I've experienced due to lack of immediate
 >   saving are: 1. Seeing confusingly inconsistent results after
 >   processing a bunch of my inbox and then doing a search based on
 >   label:unread or label:inbox (Why am I seeing all these messages
 >   again?). 2. Losing a bunch of processing state due to crashes. (The
 >   crashes have been due to the mbox-processing bug which has since
 >   been fixed, but being immune to state loss for any future crashes
 >   would be beneficial.)
 
 I assume here that part of the problem is the time it takes to write
 changes. If I read all my morning e-mails and then press $, it usually
 takes a few seconds for this to finish. If it's just one e-mail, there
 is still usually a noticeable-ish delay.
 
 However, perhaps Xapian will improve this speed also, and if this is the
 case, I'd love an "autosave" option at least in the config.
 > * [repeated-postponing-shouldnt-make-additional-drafts]
 > 
 >   I find that while composing a message I often want to go look at
 >   some other messages for reference. This is currently quite awkward
 >   with sup. It would be easier if sup could be run multiple times. It
 >   would also be easier if sup could somehow fire off an editor as an
 >   external process, while still allowing for sup to be operated.
 > 
 >   As it stands, instead, I have to save and quit from my editor,
 >   postpone the message within sup, and then later come back to edit it
 >   again, and find where I was in the editor. It's an expensive context
 >   switch with a lot of keystrokes and lost state, (such as where point
 >   was inside emacs, my kill ring, etc.). I'm currently finding myself
 >   sometimes just drafting messages in emacs sessions unrelated to sup,
 >   and then doing "M-x insert-file" once sup has launched emacs for
 >   me. (This does relate a bit to the point I made in a previous thread
 >   where I would love to find a way to keep all the mail-composition
 >   tasks very separate from sup, but not lose things like replied-to
 >   bits.)
 > 
 >   Anyway, the current misfeature I'm hitting is that if I do postpone
 >   a draft, then return to edit it more, then postpone it again,
 >   etc. eventually when I send the message I'll have several
 >   partially-composed drafts in various states that I need to go and
 >   manually clean up. It seems like most email programs avoid this
 >   problem by removing the draft as soon as its selected for editing
 >   again, and I propose that sup do the same.
 
 I think I agree there, and vaguely recall someone attempting to
 implement being able to switch buffers even when an external editor is
 in effect.
 
 Anyway, impressive post there. You seem to really abuse your e-mail
 client and know what you're on about. Good stuff.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From cworth@cworth.org  Tue Aug 18 18:16:08 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 18 Aug 2009 15:16:08 -0700
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250632714-sup-9910@Longbow>
 References: <1250629282-sup-8521@yoom> <1250632714-sup-9910@Longbow>
 Message-ID: <1250633501-sup-3981@yoom>
 
 Excerpts from Andrei Thorp's message of Tue Aug 18 15:07:28 -0700 2009:
 > Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009:
 > >   Anyway, the current misfeature I'm hitting is that if I do postpone
 > >   a draft, then return to edit it more, then postpone it again,
 > >   etc. eventually when I send the message I'll have several
 > >   partially-composed drafts in various states that I need to go and
 > >   manually clean up. It seems like most email programs avoid this
 > >   problem by removing the draft as soon as its selected for editing
 > >   again, and I propose that sup do the same.
 > 
 > I think I agree there, and vaguely recall someone attempting to
 > implement being able to switch buffers even when an external editor is
 > in effect.
 
 That would be nice. In the meantime, I have realized that I don't need
 to actually postpone my messages to do what I want---I can just exit
 the editor and then switch buffers from compose-mode/reply-mode. So
 that at least avoids the multiple-drafts issue, (but still leaves the
 I-lose-my-state-when-I-quit-the-editor issue).
 
 > Anyway, impressive post there. You seem to really abuse your e-mail
 > client and know what you're on about. Good stuff.
 
 Thanks. I have had a lot of ideas cooking for years about what my
 dream email-system would look like. I think the impressive bit is that
 of the half-dozen programs I've used in the last decade, sup is the
 first one to get me to write up a post like that. (All other programs
 were so far away from what I wanted as to make it infeasible to fix
 them incrementally.)
 
 -Carl
 -------------- 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/20090818/6e240f41/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Tue Aug 18 19:02:01 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 18 Aug 2009 19:02:01 -0400
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250629282-sup-8521@yoom>
 References: <1250629282-sup-8521@yoom>
 Message-ID: <1250634897-sup-4631@zyrg.net>
 
 provide-commands-to-refine-the-current-search:
 
 '|' exists for search-results-mode (and it should be implemented for
 label-results-mode if it doesn't exist there).
 
 
 sort-priority-labels-before-date:
 
 This isn't entirely easy for large numbers of messages. We've optimized
 the index (especially Xapian) for reverse chronological order. You could
 either do the sorting entirely in the UI, but just on the subset of
 results currently loaded, or you could create a new mode that merges and
 prioritizes the results of multiple queries.
 
 
 allow-for-limiting-to-interesting-labels:
 
 I have a hack for this. I reopen Redwood::Mode in the startup hook, then
 add a keybinding to spawn a SearchResultsMode for a set of interesting
 labels. Same for starred messages. A better solution would be good.
 
 
 save-all-state-changes-immediately,
 allow-for-inbox-mode-magic-elsewhere,
 fix-handling-of-kill-thread-outside-inbox:
 
 These are related - saving label changes immediately means we can use
 the index to decide which threads are relevant. The new index api
 methods unblock this, and now that they're in next I plan to implement
 this soon.
 
 
 be-less-overzealous-in-moving-text-to-the-left-column,
 dont-perturb-selected-thread-when-new-mail-arrives:
 
 +1 to these.
 
 From kevinr@free-dissociation.com  Tue Aug 18 19:36:15 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Tue, 18 Aug 2009 19:36:15 -0400
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 In-Reply-To: <1250618123-sup-8797@masanjin.net>
 References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com>
 	<1250618123-sup-8797@masanjin.net>
 Message-ID: <1250638381-sup-2952@black-opal.mit.edu>
 
 Excerpts from William Morgan's message of Tue Aug 18 13:56:15 -0400 2009:
 > Reformatted excerpts from Kevin Riggle's message of 2009-08-16:
 > > I want to do some unrelated processing on each message I receive, but
 > > I don't want to block the message being added to the index.  This
 > > patch adds a hook which runs /after/ the message is added to the
 > > index.
 > 
 > Won't this block subsequent emails from being added to the index, when
 > Sup gets multiple new emails during a poll?
 
 I don't /think/ so, unless I misunderstand the way hooks work.  I assumed
 the hook would execute and then execution of the loop would resume, and
 I don't think I throw anything in the hook which should cause that either.
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 http://free-dissociation.com
 
 From bwalton@artsci.utoronto.ca  Tue Aug 18 20:03:49 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 18 Aug 2009 20:03:49 -0400
 Subject: [sup-talk] crash when sup-syncing to xapian
 In-Reply-To: <1250626302-sup-2408@localdomain>
 References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 	<1250619511-sup-2827@localdomain> <1250620771-sup-1373@zyrg.net>
 	<1250622911-sup-2815@localdomain> <1250624577-sup-4801@zyrg.net>
 	<1250626302-sup-2408@localdomain>
 Message-ID: <1250640188-sup-7551@ntdws12.chass.utoronto.ca>
 
 Excerpts from Beno?t PIERRE's message of Tue Aug 18 16:14:49 -0400 2009:
 
 > After converting them to symbols it works:
 > 
 >     hash: 
 >       :relapse: true
 >       :music: true
 
 I have labels setup to import as an array (of strings)...is this not
 the way it's supposed to be?
 
 -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/20090818/9e8e3a03/attachment.bin>
 
 From cworth@cworth.org  Tue Aug 18 20:49:03 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 18 Aug 2009 17:49:03 -0700
 Subject: [sup-talk] Exception trying to run git source
 Message-ID: <1250642676-sup-2244@yoom>
 
 Until now I've been running sup 0.8.1 from a Debian package. But in an
 effort to get to where I can actually start implementing some of the
 features I want, (and to get to where I can actually send a message
 without triggering sent.mbox crashes), I'm trying to move to running
 sup from a git checkout. But whenever I try, I get the following
 exception:
 
     --- NoMethodError from thread: main
     undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160 @source=nil, @fn="sup://sent">
     ./lib/sup/util.rb:519:in `send'
     ./lib/sup/util.rb:519:in `method_missing'
     bin/sup:171
 
 I bisected this down to the following commit:
 
     commit 5057149d9c3b57c6b5c4d0964a0aae9d490aaa38
     Author: Ben Walton <bwalton at artsci.utoronto.ca>
     Date:   Wed May 6 22:44:24 2009 -0400
     
         SentManager: rework handling to allow for user specified source
 
 That looks like an awfully nice commit since I'd like my sent messages
 to go into a maildir anyway. So I tried configuring this by adding a
 line to my ~/.sup/config.yaml as follows:
 
     :sent_source: maildir:/home/cworth/mail/sent
 
 That didn't actually help too much, it just changed the stack trace
 slightly:
 
     --- NoMethodError from thread: main
     undefined method `source_uri' for #<Redwood::SentManager:0xb73ce404>
     ./lib/sup/util.rb:519:in `send'
     ./lib/sup/util.rb:519:in `method_missing'
     bin/sup:171
 
 So what am I actually missing here?
 
 -Carl
 -------------- 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/20090818/a004f5e4/attachment.bin>
 
 From cworth@cworth.org  Tue Aug 18 21:58:55 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 18 Aug 2009 18:58:55 -0700
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250634897-sup-4631@zyrg.net>
 References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net>
 Message-ID: <1250646478-sup-4064@yoom>
 
 Excerpts from Rich Lane's message of Tue Aug 18 16:02:01 -0700 2009:
 > provide-commands-to-refine-the-current-search:
 > 
 > '|' exists for search-results-mode (and it should be implemented for
 > label-results-mode if it doesn't exist there).
 
 Ah, thanks for pointing this out. I totally missed it somehow.
 
 This doesn't exist for inbox-mode, which is where I think I would like
 it the most. And conceptually, the inbox is just a search, right? It
 seems to me that inbox-mode should be at most a very slight tweak of
 search-results-mode. I'll go digging in the code to see how far away
 that would be.
 
 For what it's worth, | doesn't exist for search-results mode.
 
 And also, the shortcuts to refine the search by adding a label would
 be nice too, (so one wouldn't need to type "label:"). So now I at
 least know what already exists.
 
 > sort-priority-labels-before-date:
 > 
 > This isn't entirely easy for large numbers of messages. We've optimized
 > the index (especially Xapian) for reverse chronological order. You could
 > either do the sorting entirely in the UI, but just on the subset of
 > results currently loaded, or you could create a new mode that merges and
 > prioritizes the results of multiple queries.
 
 I think the former would be fine. The UI encourages only a small number of
 results to be loaded already, so just sorting there should work find I
 thin.
 
 > allow-for-limiting-to-interesting-labels:
 > 
 > I have a hack for this. I reopen Redwood::Mode in the startup hook, then
 > add a keybinding to spawn a SearchResultsMode for a set of interesting
 > labels. Same for starred messages. A better solution would be good.
 
 While waiting for a better solution, would you mind sharing your code
 for this? I'm quite new to ruby, so even if what you described should
 be trivial for me to replicate, it's not yet. :-)
 
 Maybe a page on the wiki?
 
 > save-all-state-changes-immediately,
 > allow-for-inbox-mode-magic-elsewhere,
 > fix-handling-of-kill-thread-outside-inbox:
 > 
 > These are related - saving label changes immediately means we can use
 > the index to decide which threads are relevant. The new index api
 > methods unblock this, and now that they're in next I plan to implement
 > this soon.
 
 Excellent. It did seem that things were moving this direction, and I'm
 glad to hear that they are.
 
 > be-less-overzealous-in-moving-text-to-the-left-column,
 > dont-perturb-selected-thread-when-new-mail-arrives:
 > 
 > +1 to these.
 
 Great. And those don't sound too complicated, so maybe I'll try
 cutting my teeth on those first.
 
 Meanwhile, I thought of another race condition. If new mail arrives
 for the current thread when in thread-view-mode, does it get added to
 the view? It might seem nice for it to show up, but it might also lead
 to it getting accidentally archived away if I "knew" that there were
 only 4 messages, say, when I entered the thread view, then I hit ".a"
 and archived away 5 messages.
 
 It seems a silly thing, but it's the kind of thing that makes me start
 distrusting ".a" and instead using "x", double-checking, then "a"
 which is obviously less efficient. (Oh, and there's another place
 where the current selector needs to not be perturbed. After I hit "x"
 from thread-view-mode I find that a different thread can be selected
 than the one I was just viewing if new mail arrived.)
 
 -Carl
 -------------- 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/20090818/ab65d341/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Tue Aug 18 22:47:40 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 18 Aug 2009 22:47:40 -0400
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250642676-sup-2244@yoom>
 References: <1250642676-sup-2244@yoom>
 Message-ID: <1250649988-sup-9079@ntdws12.chass.utoronto.ca>
 
 Excerpts from Carl Worth's message of Tue Aug 18 20:49:03 -0400 2009:
 > 
 >     --- NoMethodError from thread: main
 >     undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
 > @source=nil, @fn="sup://sent">
 >     ./lib/sup/util.rb:519:in `send'
 >     ./lib/sup/util.rb:519:in `method_missing'
 >     bin/sup:171
 
 Hmm...I think that's likely an easy fix.  I'll look tomorrow morning.
 
 -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/20090818/2ef0d45e/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Tue Aug 18 23:02:57 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 18 Aug 2009 23:02:57 -0400
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250646478-sup-4064@yoom>
 References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net>
 	<1250646478-sup-4064@yoom>
 Message-ID: <1250649270-sup-2166@zyrg.net>
 
 Excerpts from Carl Worth's message of Tue Aug 18 21:58:55 -0400 2009:
 > > allow-for-limiting-to-interesting-labels:
 > > 
 > > I have a hack for this. I reopen Redwood::Mode in the startup hook, then
 > > add a keybinding to spawn a SearchResultsMode for a set of interesting
 > > labels. Same for starred messages. A better solution would be good.
 > 
 > While waiting for a better solution, would you mind sharing your code
 > for this? I'm quite new to ruby, so even if what you described should
 > be trivial for me to replicate, it's not yet. :-)
 > 
 > Maybe a page on the wiki?
 
 Sure, I added an example to the end of the Hooks page.
 
 > Meanwhile, I thought of another race condition. If new mail arrives
 > for the current thread when in thread-view-mode, does it get added to
 > the view? It might seem nice for it to show up, but it might also lead
 > to it getting accidentally archived away if I "knew" that there were
 > only 4 messages, say, when I entered the thread view, then I hit ".a"
 > and archived away 5 messages.
 > 
 > It seems a silly thing, but it's the kind of thing that makes me start
 > distrusting ".a" and instead using "x", double-checking, then "a"
 > which is obviously less efficient. (Oh, and there's another place
 > where the current selector needs to not be perturbed. After I hit "x"
 > from thread-view-mode I find that a different thread can be selected
 > than the one I was just viewing if new mail arrived.)
 
 I'm glad to know there are other people annoyed by UI race conditions :).
 Even after a quick look at the code I'm not sure what ThreadViewMode
 will do when a thread is added to. It might actually archive/read/etc
 new messages but not display them.
 
 I'd like a keybinding to reload/redisplay the thread and a status bar
 note if there are new messages. Any label changes should only affect
 messages that have been displayed. What do you think?
 
 From garoth@gmail.com  Wed Aug 19 10:03:49 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Wed, 19 Aug 2009 10:03:49 -0400
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250649270-sup-2166@zyrg.net>
 References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net>
 	<1250646478-sup-4064@yoom> <1250649270-sup-2166@zyrg.net>
 Message-ID: <1250690604-sup-4154@Longbow>
 
 Excerpts from Rich Lane's message of Tue Aug 18 23:02:57 -0400 2009:
 > I'm glad to know there are other people annoyed by UI race conditions :).
 > Even after a quick look at the code I'm not sure what ThreadViewMode
 > will do when a thread is added to. It might actually archive/read/etc
 > new messages but not display them.
 > 
 > I'd like a keybinding to reload/redisplay the thread and a status bar
 > note if there are new messages. Any label changes should only affect
 > messages that have been displayed. What do you think?
 
 Ooh, I like it. I guess gmail does this.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From bwalton@artsci.utoronto.ca  Wed Aug 19 11:59:12 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 19 Aug 2009 11:59:12 -0400
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250642676-sup-2244@yoom>
 References: <1250642676-sup-2244@yoom>
 Message-ID: <1250697503-sup-1083@ntdws12.chass.utoronto.ca>
 
 Excerpts from Carl Worth's message of Tue Aug 18 20:49:03 -0400 2009:
 > line to my ~/.sup/config.yaml as follows:
 > 
 >     :sent_source: maildir:/home/cworth/mail/sent
 
 Here is my configuration:
 
 maildir:///u/bwalton/Maildir/.sent-mail/
 
 I think you just need to fix the URI.  I'm looking into the code
 though to see why it bombed out on you.
 
 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/20090819/f9f554ee/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Wed Aug 19 12:19:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 19 Aug 2009 09:19:44 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250642676-sup-2244@yoom>
 References: <1250642676-sup-2244@yoom>
 Message-ID: <1250698636-sup-6732@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-18:
 >     --- NoMethodError from thread: main
 >     undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
 > @source=nil, @fn="sup://sent">
 
 Very curious. SentManager most definitely has a source_uri method. If
 you look at lib/sup/sent.rb, does it include the line "attr_reader
 :source, :source_uri"? If so, is there a line in the log that says
 "SentManager initialized with source uri: xxx"?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Wed Aug 19 12:33:10 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 09:33:10 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250698636-sup-6732@masanjin.net>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 Message-ID: <1250699408-sup-9579@yoom>
 
 Excerpts from William Morgan's message of Wed Aug 19 09:19:44 -0700 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-18:
 > >     --- NoMethodError from thread: main
 > >     undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
 > > @source=nil, @fn="sup://sent">
 > 
 > Very curious. SentManager most definitely has a source_uri method. If
 > you look at lib/sup/sent.rb, does it include the line "attr_reader
 > :source, :source_uri"?
 
 Yes, that is there.
 
 >                         If so, is there a line in the log that says
 > "SentManager initialized with source uri: xxx"?
 
 No, I don't think so. At least, that is, if I'm looking at the right
 place. Is the "log" anything other than the output on stdout/err when
 I run sup? Do I need to turn on any additional verbosity somehow?
 
 Below you can see the entire output I get when running sup from git
 master.
 
 -Carl (wishing he had any skills for debugging ruby...)
 
 0:~/src/sup:(master)$ ruby -I lib -w bin/sup
 ./lib/sup/util.rb:8: warning: method redefined; discarding old
 gen_lock_id
 ./lib/sup/util.rb:19: warning: method redefined; discarding old
 dump_lock_id
 [Wed Aug 19 09:22:55 -0700 2009] using character set encoding "UTF-8"
 ./lib/sup/message-chunks.rb:36: warning: method redefined; discarding
 old make_tmpname
 ./lib/sup/imap.rb:117: warning: ambiguous first argument; put
 parentheses or even spaces
 /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:13:
 warning: useless use of > in void context
 /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:19:
 warning: useless use of > in void context
 /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:25:
 warning: useless use of < in void context
 [Wed Aug 19 09:22:55 -0700 2009] using index Redwood::FerretIndex
 Warning: $KCODE is NONE.
 [Wed Aug 19 09:22:55 -0700 2009] dynamically loading setlocale() from
 libc.so.6
 [Wed Aug 19 09:22:55 -0700 2009] setting locale...
 [Wed Aug 19 09:22:55 -0700 2009] locking /home/cworth/.sup/lock...
 [Wed Aug 19 09:22:55 -0700 2009] crypto: detected gpg binary in
 /usr/bin/gpg
 [Wed Aug 19 09:22:55 -0700 2009] loading index...
 [Wed Aug 19 09:22:55 -0700 2009] loaded index of 557361 messages
 ./lib/sup/index.rb:53: warning: instance variable @lock_update_thread
 not initialized
 bin/sup:126: warning: global variable `$cursing' not initialized
 [Wed Aug 19 09:22:55 -0700 2009] stopped cursing
 [Wed Aug 19 09:22:55 -0700 2009] oh crap, an exception
 [Wed Aug 19 09:22:55 -0700 2009] unlocking /home/cworth/.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
 ----------------------------------------------------------------
 --- NoMethodError from thread: main
 undefined method `source_uri' for #<Redwood::SentManager:0xb75441a8
 @source=nil, @fn="sup://sent">
 ./lib/sup/util.rb:519:in `send'
 ./lib/sup/util.rb:519:in `method_missing'
 bin/sup:171
 -------------- 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/20090819/9feb1415/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Wed Aug 19 12:34:09 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 19 Aug 2009 12:34:09 -0400
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250698636-sup-6732@masanjin.net>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 Message-ID: <1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Wed Aug 19 12:19:44 -0400 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-18:
 > >     --- NoMethodError from thread: main
 > >     undefined method `source_uri' for #<Redwood::SentManager:0xb74f1160
 > > @source=nil, @fn="sup://sent">
 > 
 > Very curious. SentManager most definitely has a source_uri method. If
 > you look at lib/sup/sent.rb, does it include the line "attr_reader
 > :source, :source_uri"? If so, is there a line in the log that says
 > "SentManager initialized with source uri: xxx"?
 
 Also, is bin/sup part of your git checkout (meaning it lines up with
 the rest of your lib/, etc)?  Are you running from the next branch?
 I'm looking at bin/sup here (5f393122), and the line numbers don't
 "add up."  Line 152 is where I see the call into
 SentManager.source_uri, not 171.
 
 -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/20090819/4c299b1e/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 19 13:53:54 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 10:53:54 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 Message-ID: <1250704257-sup-3308@yoom>
 
 Excerpts from Ben Walton's message of Wed Aug 19 09:34:09 -0700 2009:
 > Also, is bin/sup part of your git checkout (meaning it lines up with
 > the rest of your lib/, etc)?
 
 Yes.
 
 >                              Are you running from the next branch?
 > I'm looking at bin/sup here (5f393122), and the line numbers don't
 > "add up."  Line 152 is where I see the call into
 > SentManager.source_uri, not 171.
 
 No, I was running from master, (so line 171 does make sense there).
 
 I tried running from next and got a different failure (see below).  I
 suspected I might have something just broken in my configuration, so I
 moved ~/.sup away for the run below, (which didn't seem to change
 anything).
 
 This new failure seems to be occurring earlier, so I bisected,
 (labelling the previous source_uri exception as "good" and the new
 no-SentManager-instance as "bad"), and that pointed at the following
 commit:
 
 9dd4f50b9f62ab5642241359bf6f7c291ccfa738 is first bad commit
 commit 9dd4f50b9f62ab5642241359bf6f7c291ccfa738
 Author: William Morgan <wmorgan-sup at masanjin.net>
 Date:   Wed Aug 12 13:14:34 2009 -0400
 
     rewrite Singleton to not require i_am_the_instance
     
     The flip side is that you have to use .init instead of .new.
 
 I'm really wondering why I'm getting what appear to be unique crashes
 compared to others. Is it my ruby version:
 
 $ ruby --version
 ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
 
 Any ideas?
 
 -Carl
 
 0:~/src/sup:(next)$ ruby -I lib -w ./bin/sup
 ./lib/sup/util.rb:9: warning: method redefined; discarding old gen_lock_id
 ./lib/sup/util.rb:20: warning: method redefined; discarding old dump_lock_id
 ./lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname
 ./lib/sup/imap.rb:118: warning: ambiguous first argument; put parentheses or even spaces
 /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:13: warning: useless use of > in void context
 /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:19: warning: useless use of > in void context
 /usr/lib/ruby/1.8/chronic/repeaters/repeater_month_name.rb:25: warning: useless use of < in void context
 [Wed Aug 19 10:26:50 -0700 2009] WARNING: Warning: $KCODE is NONE.
 ./lib/sup/index.rb:54: warning: instance variable @lock_update_thread not initialized
 ./bin/sup:127: warning: global variable `$cursing' not initialized
 ./bin/sup:329: warning: global variable `$die' not initialized
 [Wed Aug 19 10:26:50 -0700 2009] ERROR: oh crap, an exception
 ----------------------------------------------------------------
 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
 ----------------------------------------------------------------
 --- RuntimeError from thread: main
 no Redwood::SentManager instance defined in method call to i_am_the_instance!
 ./lib/sup/util.rb:512:in `method_missing'
 /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize'
 ./lib/sup/util.rb:524:in `new'
 ./lib/sup/util.rb:524:in `init'
 ./lib/sup.rb:110:in `start'
 ./bin/sup:138
 
 From bwalton@artsci.utoronto.ca  Wed Aug 19 14:08:19 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 19 Aug 2009 14:08:19 -0400
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250704257-sup-3308@yoom>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 	<1250704257-sup-3308@yoom>
 Message-ID: <1250705105-sup-7923@ntdws12.chass.utoronto.ca>
 
 Excerpts from Carl Worth's message of Wed Aug 19 13:53:54 -0400 2009:
 > $ ruby --version
 > ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
 
 I'm running the (now fossilized):
 $ ruby --version
 ruby 1.8.5 (2006-08-25) [i386-linux]
 
 (as shipped with rhel5).
 
 > Any ideas?
 
 Not right now, but I'll think about it.
 
 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/20090819/cd6d7c32/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Wed Aug 19 14:39:56 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 19 Aug 2009 11:39:56 -0700
 Subject: [sup-talk] crash when sup-syncing to xapian
 In-Reply-To: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 References: <1250616603-sup-5612@ntdws12.chass.utoronto.ca>
 Message-ID: <1250707129-sup-7698@masanjin.net>
 
 Reformatted excerpts from Ben Walton's message of 2009-08-18:
 > There is something wonky with label handling, as per attached
 > exception log.
 
 This should be fixed in next. It was a result of some of the API
 refactoring I've been doing recently. Everyone's source.yaml should now
 automagically revert to the format from the good ol' days.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Aug 19 14:52:26 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 19 Aug 2009 11:52:26 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250704257-sup-3308@yoom>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 	<1250704257-sup-3308@yoom>
 Message-ID: <1250707794-sup-6173@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
 
 Fine.
 
 > no Redwood::SentManager instance defined in method call to i_am_the_instance!
 > ./lib/sup/util.rb:512:in `method_missing'
 > /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize'
 > ./lib/sup/util.rb:524:in `new'
 > ./lib/sup/util.rb:524:in `init'
 > ./lib/sup.rb:110:in `start'
 > ./bin/sup:138
 
 Do you get this error in next head, and in the "first bad commit" you
 reported? Neither of those should have any calls to i_am_the_instance!
 anywhere in the code.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Aug 19 14:52:56 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 19 Aug 2009 11:52:56 -0700
 Subject: [sup-talk] Crash w/ current 'next'
 In-Reply-To: <aeb4682e1581f7534cb1c81bd143dbc6@pioto.org>
 References: <aeb4682e1581f7534cb1c81bd143dbc6@pioto.org>
 Message-ID: <1250707961-sup-5229@masanjin.net>
 
 Reformatted excerpts from Mike Kelly's message of 2009-08-18:
 > I just built from the current next branch, and now whenever I load
 > sup, it gives me the attached crash.
 
 Should be fixed. Sorry about that.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Aug 19 14:55:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 19 Aug 2009 11:55:03 -0700
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 In-Reply-To: <1250638381-sup-2952@black-opal.mit.edu>
 References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com>
 	<1250618123-sup-8797@masanjin.net>
 	<1250638381-sup-2952@black-opal.mit.edu>
 Message-ID: <1250707991-sup-5429@masanjin.net>
 
 Reformatted excerpts from Kevin Riggle's message of 2009-08-18:
 > I don't /think/ so, unless I misunderstand the way hooks work.  I
 > assumed the hook would execute and then execution of the loop would
 > resume, and I don't think I throw anything in the hook which should
 > cause that either.
 
 What I'm saying is that this hook will execute *after* each message is
 added to the index, so if Sup found several new messages, all except the
 first one will wait on this hook to execute before being added to the
 index. Or do you mean block in some sense besides "wait for completion"?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Wed Aug 19 15:40:15 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 12:40:15 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250707794-sup-6173@masanjin.net>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 	<1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net>
 Message-ID: <1250710221-sup-925@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Wed Aug 19 11:52:26 -0700 2009:
 > > no Redwood::SentManager instance defined in method call to i_am_the_instance!
 > > ./lib/sup/util.rb:512:in `method_missing'
 > > /usr/lib/ruby/1.8/sup/sent.rb:10:in `initialize'
 > > ./lib/sup/util.rb:524:in `new'
 > > ./lib/sup/util.rb:524:in `init'
 > > ./lib/sup.rb:110:in `start'
 > > ./bin/sup:138
 > 
 > Do you get this error in next head, and in the "first bad commit" you
 > reported?
 
 Yes.
 
 > Neither of those should have any calls to i_am_the_instance!
 > anywhere in the code.
 
 Thanks. That confirms that I'm not running the code I think I am, and
 the above stack trace makes that obvious, (see
 /usr/lib/ruby/1.8/sup/sent.rb). So I was running some unholy mixture
 of the installed Debian sup and the from-git sup and it worked no
 better than one would expect.
 
 My previously reported crashes didn't happen to fail in a way that
 made /usr/lib show up in the stack trace, but both crashes are fixed
 by just moving /usr/lib/ruby/1.8/sup out of the way.
 
 So I'm glad to have things working now, but I'm still curious to know
 why ruby goes digging into /usr/lib/ruby/1.8 to find sup/sent.rb when
 there's a ./lib/sub/sent.rb present and I've passed a "-I ./lib"
 option to ruby, (and plainly, ruby is interpreting other files from
 ./lib).
 
 And I'd be glad if someone could recommend a ruby-esque way to debug a
 situation like this. I mean, I could obviously have just run ruby
 under strace and looked for the paths of various *.rb files getting
 loaded, but surely there's some more ruby-specific way to list files
 that are being used?
 
 -Carl
 
 PS. I'm intrigued by the following mention:
 
 	You?ve got the same sort of command-line debugger available.
 	[http://www.ruby-lang.org/en/documentation/ruby-from-other-languages/to-ruby-from-c-and-c-/]
 
 so that's clearly something I'm going to have to learn to use.
 
 
 -------------- 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/20090819/b7de0a71/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Wed Aug 19 16:02:26 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 19 Aug 2009 13:02:26 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250710221-sup-925@yoom.home.cworth.org>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 	<1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net>
 	<1250710221-sup-925@yoom.home.cworth.org>
 Message-ID: <1250712045-sup-3506@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > Thanks. That confirms that I'm not running the code I think I am,
 
 Good, that explains a lot.
 
 > So I'm glad to have things working now, but I'm still curious to know
 > why ruby goes digging into /usr/lib/ruby/1.8 to find sup/sent.rb when
 > there's a ./lib/sub/sent.rb present and I've passed a "-I ./lib"
 > option to ruby, (and plainly, ruby is interpreting other files from
 > ./lib).
 
 I find it surprising too. I haven't seen taht behavior before. FWIW, Sup
 does try and detect if bin/sup and lib/sup have mismatched versions, and
 that didn't fire... I wonder if it's just sent.rb that's been loaded.
 Did you somehow delete sent.rb from your git directory, or something
 like that?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From benoit.pierre@gmail.com  Wed Aug 19 16:56:55 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Wed, 19 Aug 2009 22:56:55 +0200
 Subject: [sup-talk] [PATCH] fix garbaged text in textfield when using
 	ncursesw
 Message-ID: <1250715278-sup-1941@localdomain>
 
 Apparently, field_buffer content is not initialized to blanks when using
 the wide-character version of ncurses. Forcing a call to
 set_field_buffer fix the problem.
 ---
  lib/sup/textfield.rb |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb
 index b8dec59..76803bf 100644
 --- a/lib/sup/textfield.rb
 +++ b/lib/sup/textfield.rb
 @@ -35,9 +35,9 @@ class TextField
      @completion_block = block
      @field = Ncurses::Form.new_field 1, @width - question.length, @y, @x + question.length, 256, 0
      @form = Ncurses::Form.new_form [@field]
 -    @value = default
 +    @value = default || ''
      Ncurses::Form.post_form @form
 -    set_cursed_value default if default
 +    set_cursed_value @value
    end
  
    def position_cursor
 -- 
 1.6.3.3
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/95de5c6f/attachment.bin>
 
 From dato@net.com.org.es  Wed Aug 19 17:22:09 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Wed, 19 Aug 2009 22:22:09 +0100
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
  variable with the attachment charset
 In-Reply-To: <20090730155656.GA20442@chistera.yi.org>
 References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 	<20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry>
 	<20090730155656.GA20442@chistera.yi.org>
 Message-ID: <20090819212209.GA10883@chistera.yi.org>
 
 Ping?
 
 + Adeodato Sim? (Thu, 30 Jul 2009 17:56:56 +0200):
 
 > + William Morgan (Mon, 27 Jul 2009 09:51:17 -0700):
 
 > > Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
 > > > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
 > > > > +                          :charset => encoded_content.charset,
 
 > > > Hm, so apparently encoded_content doesn't always have a charset
 > > > member...
 
 > > In which case that value of that variable is nil, right? Is that a
 > > problem? The patch still seems useful.
 
 > Yes, I took a closer look and you're right the result of
 > encoded_content.charset is nil in that case. I also saw (I think) where
 > the traceback I was seeing is coming from: apparently it's not possible
 > to pass to HookContext a local that is nil, since then "super" will get
 > called in HookContext::method_missing() as far as I can see.
 
 > So, perhaps, to fix this patch, one could do:
 
 >     :charset => encoded_content.charset || ''
 
 > But then, I think it would be better to fix HookContext to allow for
 > @__locals to contain nil. I'm not very familiar with that class, but it
 > seems easy enough to fix, see upcoming patch (also found in
 > ~dato/sup/sup-dato:fixes at Gitorious, if you prefer that). With it,
 > this improvement to mime-decode seems to work without any further
 > trouble.
 
 > Cheers,
 
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From cworth@cworth.org  Wed Aug 19 17:37:15 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 14:37:15 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250712045-sup-3506@masanjin.net>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 	<1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net>
 	<1250710221-sup-925@yoom.home.cworth.org>
 	<1250712045-sup-3506@masanjin.net>
 Message-ID: <1250717434-sup-4489@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Wed Aug 19 13:02:26 -0700 2009:
 > I find it surprising too. I haven't seen taht behavior before. FWIW, Sup
 > does try and detect if bin/sup and lib/sup have mismatched versions, and
 > that didn't fire... I wonder if it's just sent.rb that's been loaded.
 > Did you somehow delete sent.rb from your git directory, or something
 > like that?
 
 Nope. The git checkout is entirely intact, and it was quite a large
 number of modules getting misloaded.
 
 I ran an strace on the ruby process[*] and was able to plainly see
 that modules were being correctly loaded from ./lib until after
 /usr/lib/ruby/1.8/chronic.rb was loaded. After that, ruby would look
 for modules in /usr/lib/ruby/1.8 before ./lib. And sure enough, the
 first line of my chronic.rb has:
 
 $:.unshift File.dirname(__FILE__)     # For use/testing when no gem is installed
 
 I'll go ahead and find the right place to file that bug, but at least
 the mystery is solved now.
 
 -Carl
 
 [*] http://cworth.org/~cworth/tmp/ruby-sup.strace
 -------------- 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/20090819/5e1ba854/attachment.bin>
 
 From wirtwolff@gmail.com  Wed Aug 19 16:41:54 2009
 From: wirtwolff@gmail.com (Wirt Wolff)
 Date: Wed, 19 Aug 2009 14:41:54 -0600
 Subject: [sup-talk] In next: thread-view-mode labelling No method join for
 	Set
 Message-ID: <1250714501-sup-3033@chigamba>
 
 Lots of great improvements in next. Love the utf8.
 
 When I try to 'l'abel in thread view mode, however, sup crashes with
 
 --- NoMethodError from thread: main
 undefined method `join' for #<Set: {:list, :xm}>
 ./lib/sup/buffer.rb:506:in `ask_for_labels'
 ./lib/sup/util.rb:520:in `send'
 ./lib/sup/util.rb:520:in `method_missing'
 ./lib/sup/modes/thread-view-mode.rb:253:in `edit_labels'
 ./lib/sup/mode.rb:50:in `send'
 ./lib/sup/mode.rb:50:in `handle_input'
 ./lib/sup/buffer.rb:260:in `handle_input'
 
 ----------------------------------------
 
 Most recent commit is
     Merge branch 'various-api-refactors' into next
 commit 3de96fb9b308afe600c7ccfcee75913f039ef4f6
 
 run with % ruby -Ilib bin/sup
 
 ----------------------------------------
 
 Advice how to fix?
 
 thanks,
 
 -- 
 wmw
 
 From cworth@cworth.org  Wed Aug 19 19:21:08 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 16:21:08 -0700
 Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
 In-Reply-To: <1250649270-sup-2166@zyrg.net>
 References: <1250629282-sup-8521@yoom> <1250634897-sup-4631@zyrg.net>
 	<1250646478-sup-4064@yoom> <1250649270-sup-2166@zyrg.net>
 Message-ID: <1250723746-sup-4632@yoom.home.cworth.org>
 
 Excerpts from Rich Lane's message of Tue Aug 18 20:02:57 -0700 2009:
 > Excerpts from Carl Worth's message of Tue Aug 18 21:58:55 -0400 2009:
 > > Maybe a page on the wiki?
 > 
 > Sure, I added an example to the end of the Hooks page.
 
 Excellent. That looks very helpful.
 
 And looking closer at the hooks wiki page, I see that it shows me how
 to label incoming mail with ruby code, (which I've been wanting to
 switch to instead of using maildrop to deliver mail to different
 maildirs, and sup adding labels based on the source).
 
 The hooks page also shows me how to display the number of unread
 messages in a thread like I wanted, (though I'll still propose that
 for sup itself rather than relying on a user hook for this).
 
 So thanks for the encouragement to take a closer look at this page.
 
 > I'm glad to know there are other people annoyed by UI race conditions :).
 > Even after a quick look at the code I'm not sure what ThreadViewMode
 > will do when a thread is added to. It might actually archive/read/etc
 > new messages but not display them.
 
 That was definitely my fear.
 
 > I'd like a keybinding to reload/redisplay the thread and a status bar
 > note if there are new messages. Any label changes should only affect
 > messages that have been displayed. What do you think?
 
 Only affecting messages that have been displayed is the critical
 piece, yes. Adding a status bar notice would be a nice addition.
 
 -Carl
 -------------- 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/20090819/62013666/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 19 20:31:12 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 17:31:12 -0700
 Subject: [sup-talk] In next: thread-view-mode labelling No method join
 	for Set
 In-Reply-To: <1250714501-sup-3033@chigamba>
 References: <1250714501-sup-3033@chigamba>
 Message-ID: <1250727630-sup-3112@yoom.home.cworth.org>
 
 Excerpts from Wirt Wolff's message of Wed Aug 19 13:41:54 -0700 2009:
 > Lots of great improvements in next. Love the utf8.
 
 Agreed. These are very nice.
 
 > When I try to 'l'abel in thread view mode, however, sup crashes with
 > 
 > --- NoMethodError from thread: main
 > undefined method `join' for #<Set: {:list, :xm}>
 > ./lib/sup/buffer.rb:506:in `ask_for_labels'
 
 I'm getting that too. It bisected down to the following which is not
 so surprising:
 
     commit 7aea418a8a62b7070eee764475fcfc0bdd8d58dd
     Author: William Morgan <wmorgan-sup at masanjin.net>
     Date:   Tue Aug 11 16:00:52 2009 -0400
 
         maintain labels as Sets rather than arrays
 
 I've attached a patch that at least makes the crashes I was able ro
 reproduce go away. But I have no idea if I got them all of course[*].
 And please let me know if I'm doing anything wrong. I'm new to ruby as
 well as sup here, so go easy on me, please! :-)
 
 -Carl
 
 [*] Totally off-topic: This is one of the things about "dynamically
 typed" languages that I've never been able to wrap my brain around. I
 really like that with static typing I can trust the compiler to help
 me be very thorough if I make a type change like this, (and catch all
 the cases before shipping any code). Instead, here, there's a hard
 task of exercising every possible code path (at run time) before we
 know if there are any type errors still lingering. I've seen some
 proponents of dynamically-typed languages argue that unit testing
 should provide the same coverage that a statically-typed compiler
 would, but I haven't seen that in practice.
 
 You all definitely have a lot more experience with ruby than I do, so
 I'm honestly interested in learning form your experience. What do you
 do to deal with cases like this?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Convert-a-couple-of-arrays-to-sets-for-labels.patch
 Type: application/octet-stream
 Size: 1685 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090819/c4120e6d/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/20090819/c4120e6d/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Wed Aug 19 22:57:25 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 19 Aug 2009 22:57:25 -0400
 Subject: [sup-talk] In next: thread-view-mode labelling No method join
 	for Set
 In-Reply-To: <1250727630-sup-3112@yoom.home.cworth.org>
 References: <1250714501-sup-3033@chigamba>
 	<1250727630-sup-3112@yoom.home.cworth.org>
 Message-ID: <1250734085-sup-2162@ntdws12.chass.utoronto.ca>
 
 Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009:
 
 > [*] Totally off-topic: This is one of the things about "dynamically
 > typed" languages that I've never been able to wrap my brain around. I
 > really like that with static typing I can trust the compiler to help
 > me be very thorough if I make a type change like this, (and catch all
 > the cases before shipping any code). Instead, here, there's a hard
 > task of exercising every possible code path (at run time) before we
 > know if there are any type errors still lingering. I've seen some
 > proponents of dynamically-typed languages argue that unit testing
 > should provide the same coverage that a statically-typed compiler
 > would, but I haven't seen that in practice.
 
 The term you'll see bandied about in ruby circles/books/etc is 'duck
 typing' which coming from strongly typed languages is definitely
 something that takes some getting used to.  Basically, instead of
 caring about the type of the object, you case about what the object
 does.  If it walks like a duck and quacks like a duck, treat it like a
 duck.
 
 A very simple example is a function that expects to append data to
 another object.  You could pass it a string (which uses << to append)
 or an array (which uses << to push elements on the end).  If you
 originally passed a string, but found performance (memory ->
 realloc()) issues, you could swap the string object for an array
 object and do array.join when everything is collected into array
 elements.
 
 Then, you'll see many examples where there is code like:
 
 raise SomeException, "blah" unless someobject.respond_to?(:somemethod)
 
 Your code doesn't care _what kind_ of object it gets as long as it
 knows _how_ to talk to it.
 
 Personally, I really like this.  Ruby isn't perfect by any stretch,
 but of all the languages I've used, it's hands down the most fun to
 write.
 
 -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/20090819/a644ea46/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 00:03:08 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 21:03:08 -0700
 Subject: [sup-talk] In next: thread-view-mode labelling No method join
 	for Set
 In-Reply-To: <1250734085-sup-2162@ntdws12.chass.utoronto.ca>
 References: <1250714501-sup-3033@chigamba>
 	<1250727630-sup-3112@yoom.home.cworth.org>
 	<1250734085-sup-2162@ntdws12.chass.utoronto.ca>
 Message-ID: <1250740488-sup-1624@yoom.home.cworth.org>
 
 Excerpts from Ben Walton's message of Wed Aug 19 19:57:25 -0700 2009:
 > Excerpts from Carl Worth's message of Wed Aug 19 20:31:12 -0400 2009:
 > 
 > > [*] Totally off-topic: This is one of the things about "dynamically
 > > typed" languages that I've never been able to wrap my brain around. I
 > > really like that with static typing I can trust the compiler to help
 > > me be very thorough if I make a type change like this, (and catch all
 > > the cases before shipping any code).
 ...
 > The term you'll see bandied about in ruby circles/books/etc is 'duck
 > typing' which coming from strongly typed languages is definitely
 > something that takes some getting used to.  Basically, instead of
 > caring about the type of the object, you case about what the object
 > does.  If it walks like a duck and quacks like a duck, treat it like a
 > duck.
 
 Yes, I understand that just fine. But two points:
 
 1. That's not actually helping in the current case where we're trying
    to do simple things like '+' and the distinction between Set and
    Array is causing problems. (See the patch where we're having to add
    .to_a and Set.new to coerce things.) So, here, at least things are
    falling down. So somehow something in ruby isn't living up to the
    concept here.
 
 > Then, you'll see many examples where there is code like:
 > 
 > raise SomeException, "blah" unless someobject.respond_to?(:somemethod)
 >
 > Your code doesn't care _what kind_ of object it gets as long as it
 > knows _how_ to talk to it.
 
 2. Even with the "duck typing" I'd still like to express this
    constraint in a way that is decidable statically. I've definitely
    failed as a programmer if a user sees a runtime exception like
    that. Sytems with sophisticated runtimes are very interesting to
    me. It's just discouraging to me that so many such systems fail to
    actually help me avoid problems like this before the user is
    running my code.
 
 > Personally, I really like this.  Ruby isn't perfect by any stretch,
 > but of all the languages I've used, it's hands down the most fun to
 > write.
 
 That could still be the case for me here. I haven't tried much with it
 yet, so I don't have any strong opinion there yet. :-)
 
 -Carl
 -------------- 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/20090819/aae17dcd/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 01:25:39 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 22:25:39 -0700
 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
 Message-ID: <1250745799-sup-6607@yoom.home.cworth.org>
 
 The idea here is that if someone is looking at the log and not seeing
 the information of interest, then the log itself should tell them
 how to get more information, (by suggesting to set SUP_LOG_LEVEL
 to the next lower level).
 ---
 
 I'm probably still off as far as standard ruby idioms, (and I'm
 probably committing some sup layer violations as well). But hopefully
 you get the idea. I went to the log looking for details, couldn't find
 them, and had to resort to searching the mailing list for the exact
 name of the SUP_LOG_LEVEL variable.
 
  bin/sup           |    3 +++
  lib/sup/logger.rb |    2 ++
  2 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 3d5b6c1..afe2233 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -169,6 +169,9 @@ begin
    lmode.on_kill { Logger.clear! }
    Logger.add_sink lmode
    Logger.force_message "Welcome to Sup! Log level is set to #{Logger.level}."
 +  if Logger.LEVELS.index(Logger.level) > 0
 +    Logger.force_message "For more verbose logging, restart with SUP_LOG_LEVEL=#{Logger.LEVELS[Logger.LEVELS.index(Logger.level)-1]}."
 +  end
  
    debug "initializing inbox buffer"
    imode = InboxMode.new
 diff --git a/lib/sup/logger.rb b/lib/sup/logger.rb
 index ccaeae0..8567174 100644
 --- a/lib/sup/logger.rb
 +++ b/lib/sup/logger.rb
 @@ -12,6 +12,8 @@ class Logger
  
    LEVELS = %w(debug info warn error) # in order!
  
 +  def LEVELS; LEVELS end
 +
    def initialize level=nil
      level ||= ENV["SUP_LOG_LEVEL"] || "info"
      @level = LEVELS.index(level) or raise ArgumentError, "invalid log level #{level.inspect}: should be one of #{LEVELS * ', '}"
 -- 
 1.6.3.3
 -------------- 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/20090819/8eb1635a/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 02:31:25 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 19 Aug 2009 23:31:25 -0700
 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the left
 	column
 Message-ID: <1250749447-sup-1744@yoom.home.cworth.org>
 
 Specifically, scroll as little as possible to get the current message
 to just fit on the right side.
 ---
 
 This seems to work quite nicely and I think is ready to be comitted as
 is. It's still not perfect in a few ways though, which I think we can
 leave for subsequent commits:
 
 1. I *think* that with this change the loose_alignment mode is
    unnecessary. But I confess that I didn't totally understand the
    calculation it is making, so I tried to just preserve its behavior
    rather than ripping it out.
 
 2. In deep threads of short messages, (so that lots of nesting is
    visible in one screenful), it's easier than it was before for
    messages other than the current message to be scrolled off to the
    right, (though the current message is always made to fit if
    possible). I can imagine someone finding the current patch
    unacceptable based on this.
 
    The fix for this would be to consider the total width of all
    visible messages when making the calculation made here, rather than
    just the width of the current message. I'm not sure how readily
    available that number is.
 
 3. It's still easy to get stuff scrolled off to the left, (which was a
    symptom of the original bug I'm trying to fix), when doing
    something like (E: Expand all messages). This command should
    recompute a left column, so perhaps we should abstract the
    left-column calculation out to some shared place.
 
 Anyway, all feedback is quite welcome,
 
 -Carl (happy to finally be running code from git and contributing patches)
 
  lib/sup/modes/thread-view-mode.rb |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index dfe30ff..678b841 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -423,6 +423,9 @@ EOS
          0
        end
  
 +    ## scroll as little as possible to make the message fit
 +    ideal_left = (-(buffer.content_width - l.width - left - 1)).clamp(0, ideal_left)
 +
      jump_to_col [ideal_left, 0].max
  
      ## either way, move the cursor to the first line
 -- 
 1.6.3.3
 
 
 -------------- 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/20090819/16ea9c2d/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 13:07:16 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 20 Aug 2009 10:07:16 -0700
 Subject: [sup-talk] On making kill-thread easier
 Message-ID: <1250785604-sup-5488@yoom.home.cworth.org>
 
 I wrote a long post that started out talking about workflows, but then
 went on into just a dump of feature requests. I'd like to get back to
 talking about workflows again a bit.
 
 I find that when processing my mail in inbox-mode I do a first pass
 with one of two different actions on each thread:
 
 	1. 'a' to archive the thread without reading
 or:
 	2. <down-arrow> to leave the thread in my inbox for reading on
 	   a later pass.
 
 But this misses out on the killer-feature that was one of the things
 that made me most interested in sup: kill-thread.
 
 So I can currently decide to kill a thread instead of archiving it,
 but this requires extra effort on my part, (deciding that I need to do
 something more than just archiving it, and then using a different
 key---currently with a keybinding that requires two keys).
 
 What I find is that I end up using kill-thread much less frequently
 than I should. Basically what ends up happening is that when a thread
 comes up several times (and I keep just archiving it) before I finally
 make the mental effort to kill it instead of just archiving it. And I
 keep trying to train myself to not be afraid to use kill-thread more
 frequently.
 
 But then thought occurs to me, "Shouldn't sup just see that I'm not
 ever reading this thread when it reappears?".
 
 So I think what I actually want is a single keybinding that either
 archives or kills a thread based on whether I've actually read any of
 it or not. Does anybody else agree that that would be useful? Perhaps
 even as the default?
 
 I think a first pass that only does kill-thread if the entire thread
 is unread will likely be enough. I can imagine a more clever version
 that kills a thread even if it's partially read but no new messages
 have been read since the last time this thread was labelled as
 inbox. But that's perhaps more complexity than appropriate[*] and an
 explicit kill-thread command will work just fine here.
 
 -Carl
 
 [*] By the way, my concern with complexity has nothing to do with the
 state management in the code---that shouldn't be bad. It's more a
 matter of making the user-interface easy to explain and understand. If
 a tool violates that, then it can lose a user's trust, (which can be
 quite fatal for a mail client).
 -------------- 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/20090820/aefd9813/attachment.bin>
 
 From garoth@gmail.com  Thu Aug 20 14:19:19 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Thu, 20 Aug 2009 14:19:19 -0400
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250785604-sup-5488@yoom.home.cworth.org>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 Message-ID: <1250792255-sup-4740@Longbow>
 
 Excerpts from Carl Worth's message of Thu Aug 20 13:07:16 -0400 2009:
 > I wrote a long post that started out talking about workflows, but then
 > went on into just a dump of feature requests. I'd like to get back to
 > talking about workflows again a bit.
 > 
 > I find that when processing my mail in inbox-mode I do a first pass
 > with one of two different actions on each thread:
 > 
 >     1. 'a' to archive the thread without reading
 > or:
 >     2. <down-arrow> to leave the thread in my inbox for reading on
 >        a later pass.
 > 
 > But this misses out on the killer-feature that was one of the things
 > that made me most interested in sup: kill-thread.
 > 
 > So I can currently decide to kill a thread instead of archiving it,
 > but this requires extra effort on my part, (deciding that I need to do
 > something more than just archiving it, and then using a different
 > key---currently with a keybinding that requires two keys).
 > 
 > What I find is that I end up using kill-thread much less frequently
 > than I should. Basically what ends up happening is that when a thread
 > comes up several times (and I keep just archiving it) before I finally
 > make the mental effort to kill it instead of just archiving it. And I
 > keep trying to train myself to not be afraid to use kill-thread more
 > frequently.
 > 
 > But then thought occurs to me, "Shouldn't sup just see that I'm not
 > ever reading this thread when it reappears?".
 > 
 > So I think what I actually want is a single keybinding that either
 > archives or kills a thread based on whether I've actually read any of
 > it or not. Does anybody else agree that that would be useful? Perhaps
 > even as the default?
 > 
 > I think a first pass that only does kill-thread if the entire thread
 > is unread will likely be enough. I can imagine a more clever version
 > that kills a thread even if it's partially read but no new messages
 > have been read since the last time this thread was labelled as
 > inbox. But that's perhaps more complexity than appropriate[*] and an
 > explicit kill-thread command will work just fine here.
 > 
 > -Carl
 > 
 > [*] By the way, my concern with complexity has nothing to do with the
 > state management in the code---that shouldn't be bad. It's more a
 > matter of making the user-interface easy to explain and understand. If
 > a tool violates that, then it can lose a user's trust, (which can be
 > quite fatal for a mail client).
 
 Seems like making it the default is a bit cavalier. It's not good to
 assume what the user wants, I think. Maybe a separate key if we want to
 spare it, but I think the better solution is "learn to kill threads
 already and use an explicit command for it."
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From chris@chris-wilson.co.uk  Thu Aug 20 16:01:10 2009
 From: chris@chris-wilson.co.uk (Chris Wilson)
 Date: Thu, 20 Aug 2009 21:01:10 +0100
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250785604-sup-5488@yoom.home.cworth.org>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 Message-ID: <1250797598-sup-5105@tiger.alporthouse.com>
 
 Hi everybody! I've just started using sup after Carl told me he'd found
 a fantastic new mail client. And, as usual, he was right.
 
 Excerpts from Carl Worth's message of Thu Aug 20 18:07:16 +0100 2009:
 > But then thought occurs to me, "Shouldn't sup just see that I'm not
 > ever reading this thread when it reappears?".
 
 I have a very similar inbox pattern to Carl, a quick pass to remove
 uninteresting material before acting upon the rest. To this end, I use
 '&' far less frequently than I should, because it's an awkward key
 combination to use in conjunction with scrolling + archiving, and so I
 am irritated by repeatedly archiving a thread which I have never read.
 The behaviour I would like here is exactly: "Shouldn't sup just see that
 I'm not ever reading this thread when it reappears?".
 
 I'd be happy to have sup automatically kill a thread that I have
 archived twice without reading.
 -ickle
 
 From garoth@gmail.com  Thu Aug 20 16:36:15 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Thu, 20 Aug 2009 16:36:15 -0400
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250797598-sup-5105@tiger.alporthouse.com>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 Message-ID: <1250800492-sup-136@Longbow>
 
 Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
 > Hi everybody! I've just started using sup after Carl told me he'd found
 > a fantastic new mail client. And, as usual, he was right.
 
 If you're half as verbose as he is, I'll never have time to read it all!
 ;)
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From bwalton@artsci.utoronto.ca  Thu Aug 20 16:43:08 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 20 Aug 2009 16:43:08 -0400
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250797598-sup-5105@tiger.alporthouse.com>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 Message-ID: <1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 
 Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
 
 > I have a very similar inbox pattern to Carl, a quick pass to remove
 > uninteresting material before acting upon the rest. To this end, I use
 > '&' far less frequently than I should, because it's an awkward key
 > combination to use in conjunction with scrolling + archiving, and so I
 > am irritated by repeatedly archiving a thread which I have never read.
 > The behaviour I would like here is exactly: "Shouldn't sup just see that
 > I'm not ever reading this thread when it reappears?".
 
 I have a similar pattern where there are lots of list messages that I
 don't care about (based on subject).  I skim the inbox using 't' to
 tag all messages I don't care about.  When I've tagged a bunch of
 items, after the scan, I simply to '=' followed by either 'A'
 (archive, mark read) or '&'.  It saves lots of shift key use and
 allows me to quickly tackle a lot of mail.
 
 > I'd be happy to have sup automatically kill a thread that I have
 > archived twice without reading.
 
 I think this kind of heuristic is a) hard to get right b) not required
 if you do batch operations as described above.  Part b) is subject to
 personal opinion, of course! :)
 
 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/20090820/1dbd06f5/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 17:07:28 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 20 Aug 2009 14:07:28 -0700
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250800492-sup-136@Longbow>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800492-sup-136@Longbow>
 Message-ID: <1250802401-sup-2516@yoom.home.cworth.org>
 
 Excerpts from Andrei Thorp's message of Thu Aug 20 13:36:15 -0700 2009:
 > Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
 > > Hi everybody! I've just started using sup after Carl told me he'd found
 > > a fantastic new mail client. And, as usual, he was right.
 > 
 > If you're half as verbose as he is, I'll never have time to read it all!
 > ;)
 
 Yeah, sorry about that. I will try to be terse when I can. :-)
 
 Welcome, Chris!
 
 -Carl
 -------------- 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/20090820/481671be/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 17:11:49 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 20 Aug 2009 14:11:49 -0700
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 Message-ID: <1250802452-sup-4348@yoom.home.cworth.org>
 
 Excerpts from Ben Walton's message of Thu Aug 20 13:43:08 -0700 2009:
 > Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
 > I have a similar pattern where there are lots of list messages that I
 > don't care about (based on subject).  I skim the inbox using 't' to
 > tag all messages I don't care about.  When I've tagged a bunch of
 > items, after the scan, I simply to '=' followed by either 'A'
 > (archive, mark read) or '&'.  It saves lots of shift key use and
 > allows me to quickly tackle a lot of mail.
 
 Thanks, Ben!
 
 This is just the kind of workflow report I've been hoping to read.
 
 I wonder, though, what happens when you want to archive some and kill
 others. Do you end up making two passes? Executing the '=' operation
 partway through and then start tagging again? A quick, non-tag 'A' or
 '&' for the exceptional thread? Or maybe just let a few slip by the
 "wrong" direction.
 
 > > I'd be happy to have sup automatically kill a thread that I have
 > > archived twice without reading.
 > 
 > I think this kind of heuristic is a) hard to get right b) not required
 > if you do batch operations as described above.  Part b) is subject to
 > personal opinion, of course! :)
 
 I plan to try a single keybinding for archive-or-kill-if-unread for a
 while and see how I like it, (I'll obviously share it when I code it
 up).. Of course, the failure mode is hiding messages from me, so it
 might be hard for me to know if it fails. :-)
 
 -Carl
 -------------- 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/20090820/cec04ef5/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Thu Aug 20 18:56:52 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 20 Aug 2009 18:56:52 -0400
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250802452-sup-4348@yoom.home.cworth.org>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 	<1250802452-sup-4348@yoom.home.cworth.org>
 Message-ID: <1250808931-sup-3198@ntdws12.chass.utoronto.ca>
 
 Excerpts from Carl Worth's message of Thu Aug 20 17:11:49 -0400 2009:
 > I wonder, though, what happens when you want to archive some and kill
 > others. Do you end up making two passes? Executing the '=' operation
 > partway through and then start tagging again? A quick, non-tag 'A' or
 > '&' for the exceptional thread? Or maybe just let a few slip by the
 > "wrong" direction.
 
 I typically do a big pass to 'A' or '&' large numbers of things.  That
 knocks the list to a point where I can either do another smaller pass
 where I'll apply labels and skim things.  My last pass is for things I
 actually read, many of which get archived right away too.  I don't
 completely practice 'inbox 0' but I do follow many of its tenets.
 
 My own personal habits are such that an archived thread has to really
 bug me before I kill it, so much of the first (morning) pass is for
 'A.'  Part of this is because while I don't want to necessarily follow
 a thread, there is potential for interesting things to pop in late in
 the game (many of these are on the git ml)...so, after I see a lot of
 activity on it, I may scan the thread or possibly read it.
 
 Bike shedding gets killed quickly! :)
 
 > I plan to try a single keybinding for archive-or-kill-if-unread for a
 > while and see how I like it, (I'll obviously share it when I code it
 > up).. Of course, the failure mode is hiding messages from me, so it
 > might be hard for me to know if it fails. :-)
 
 If you get into adding code, consider writing it such that there is an
 available Hook that overrides the default behaviour.  This may get you
 the best of all outcomes.  It'd be useful for you and more likely to
 be useful for others.
 
 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/20090820/0226132d/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 20:09:30 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 20 Aug 2009 17:09:30 -0700
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250808931-sup-3198@ntdws12.chass.utoronto.ca>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 	<1250802452-sup-4348@yoom.home.cworth.org>
 	<1250808931-sup-3198@ntdws12.chass.utoronto.ca>
 Message-ID: <1250812689-sup-2614@yoom.home.cworth.org>
 
 Excerpts from Ben Walton's message of Thu Aug 20 15:56:52 -0700 2009:
 > My own personal habits are such that an archived thread has to really
 > bug me before I kill it, so much of the first (morning) pass is for
 > 'A.'  Part of this is because while I don't want to necessarily follow
 > a thread, there is potential for interesting things to pop in late in
 > the game (many of these are on the git ml)...so, after I see a lot of
 > activity on it, I may scan the thread or possibly read it.
 
 Thanks. Those are good points. I've definitely seen some interesting
 stuff on the git mailing list where threads start off looking
 worthless, but then Linus comes in with some gem of insight and things
 take off again.
 
 See Joey's post on thread patterns for some examples here:
 
 	http://joey.kitenet.net/blog/entry/thread_patterns/
 
 > Bike shedding gets killed quickly! :)
 
 Yes! Bike shedding without kill-thread available is a lot more painful.
 
 I guess part of what I'm getting at with the idea of merging "archive"
 and "kill-thread" is that I think the distinction between these two
 commands forces the user to get a little too chummy with details of
 the mail store.
 
 I wrote a long post about sup and mail in general here:
 
 	http://cworth.org/sup/a-mail-client-for-geeks/ [*]
 
 and one of the ideas I start talking about there is that I'd like my
 mail client to present me with "Here's what you should find most
 interesting right now", and I can implicitly give the system feedback
 by either reading it or not. So "archive" vs. "kill" feels like manual
 tuning of what would ideally be an automated process.
 
 Of course, getting that process automated and working well is likely
 an open research topic. I'd love for the system to take tags into
 account, authors of messages, my history of reading (or not) posts by
 given authors, etc. Obviously, sup's not going to acquire that kind of
 functionality instantly, but it likely makes a good basis already for
 someone who wants to explore that kind of thing.
 
 So, ideas of mine like "sort certain tags before sorting by date", and
 "merge archive and thread into a single key" I think are both just
 baby steps toward the Big Idea I'd love to see someone tackle. Anyone
 looking for a good M.S. thesis around here? (So much research has been
 dedicated to spam, but has there been as much to sorting out the ham?
 I should ask my C.S-professor-friend---he'd be up on the current state
 of the literature here.)
 
 -Carl
 
 [*] See, I'm keeping some of my verbosity off the list at least. ;-)
 -------------- 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/20090820/3ed0cc42/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Thu Aug 20 20:16:23 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 20 Aug 2009 20:16:23 -0400
 Subject: [sup-talk] In next: thread-view-mode labelling No method join
 	for Set
 In-Reply-To: <1250740488-sup-1624@yoom.home.cworth.org>
 References: <1250714501-sup-3033@chigamba>
 	<1250727630-sup-3112@yoom.home.cworth.org>
 	<1250734085-sup-2162@ntdws12.chass.utoronto.ca>
 	<1250740488-sup-1624@yoom.home.cworth.org>
 Message-ID: <1250813245-sup-6519@ntdws12.chass.utoronto.ca>
 
 Excerpts from Carl Worth's message of Thu Aug 20 00:03:08 -0400 2009:
 
 > 1. That's not actually helping in the current case where we're trying
 >    to do simple things like '+' and the distinction between Set and
 >    Array is causing problems. (See the patch where we're having to add
 >    .to_a and Set.new to coerce things.) So, here, at least things are
 >    falling down. So somehow something in ruby isn't living up to the
 >    concept here.
 
 You're correct.  The difference between fixing this in Ruby vs fixing
 this in a strongly typed language though is that you could implement
 Set#join such that the code expecting an array wouldn't know the
 difference _or_ you could have that code use kind_of?(Array) to ensure
 it was getting the type of argument it was expecting.  Both are
 technically correct.
 
 In a strongly typed language, you'd have to modify the acceptable
 arguments (function definition) and ensure everything that called the
 function passed something acceptable or provide an overloaded version
 (if you're working with a language that supports it).
 
 Those are correct solutions too.
 
 > > Your code doesn't care _what kind_ of object it gets as long as it
 > > knows _how_ to talk to it.
 > 
 > 2. Even with the "duck typing" I'd still like to express this
 >    constraint in a way that is decidable statically. I've definitely
 >    failed as a programmer if a user sees a runtime exception like
 >    that. Sytems with sophisticated runtimes are very interesting to
 >    me. It's just discouraging to me that so many such systems fail to
 >    actually help me avoid problems like this before the user is
 >    running my code.
 
 Bugs are bugs! :)  Static typing only goes so far to prevent some of
 this stuff...just look what you can make a C compiler do with funky
 casts.  I take your point 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/20090820/575e53e4/attachment.bin>
 
 From cworth@cworth.org  Thu Aug 20 21:36:28 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 20 Aug 2009 18:36:28 -0700
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 Message-ID: <1250817987-sup-7256@yoom.home.cworth.org>
 
 Excerpts from Ben Walton's message of Thu Aug 20 13:43:08 -0700 2009:
 > Excerpts from Chris Wilson's message of Thu Aug 20 16:01:10 -0400 2009:
 >
 > > I'd be happy to have sup automatically kill a thread that I have
 > > archived twice without reading.
 > 
 > I think this kind of heuristic is a) hard to get right b) not required
 > if you do batch operations as described above.  Part b) is subject to
 > personal opinion, of course! :)
 
 [Here's one last thought from me in this thread before I come back
 next time with actual code and maybe some experience in using it.]
 
 Since, by nature of being a heuristic, this kind of thing can't be
 perfect, and since the cost of a false positive is high, (an important
 message being killed and never seen), here's another idea:
 
 First, leave killing to the user as an explicit action.
 
 Second, use the heuristics not for killing messages, but merely for
 prioritizing them in the inbox. But since the inbox might often be
 small, it's not adequate to move the "uninteresting" messages to the
 bottom. Instead threads that the heuristic identifies as "likely
 uninteresting" could have a delay attached to them before they are
 presented again in the inbox, (not too unlike throttling proposed for
 mailing-list servers to keep flamewars in check).
 
 This way instead of pestering the user with the bikeshedding until the
 user finally kills the thread in frustration, the bikeshedding could
 get delayed until the next morning's sweep where a day's worth of
 bikeshedding would be easy to identify and easy to kill.
 
 So maybe something like "Once I archive a thread twice without
 reading, don't show it to me again until tomorrow" or so. That might
 be interesting to try out.
 
 -Carl
 -------------- 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/20090820/aefb8350/attachment.bin>
 
 From kevinr@free-dissociation.com  Thu Aug 20 21:57:42 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Thu, 20 Aug 2009 21:57:42 -0400
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 In-Reply-To: <1250707991-sup-5429@masanjin.net>
 References: <1250707991-sup-5429@masanjin.net>
 Message-ID: <1250819862-4858-1-git-send-email-kevinr@free-dissociation.com>
 
 This time the loop stores messages in an array as they're added to the
 index, and passes that array to the hook.
 
 I want to do some unrelated processing on each message I receive, but I
 don't want to block the message being added to the index.  This patch
 adds a hook which runs /after/ the message is added to the index.
 ---
  lib/sup/poll.rb |   10 ++++++++++
  1 files changed, 10 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
 index 8a9d218..fb3aacf 100644
 --- a/lib/sup/poll.rb
 +++ b/lib/sup/poll.rb
 @@ -11,6 +11,12 @@ Variables:
    message: the new message
  EOS
  
 +  HookManager.register "after-add-message", <<EOS
 +Executes after all messages are added to the index.
 +Variables:
 +  messages: an array of the new messages added
 +EOS
 +
    HookManager.register "before-poll", <<EOS
  Executes immediately before a poll for new messages commences.
  No variables.
 @@ -138,6 +144,7 @@ EOS
      begin
        return if source.done? || source.has_errors?
  
 +      messages = []
        source.each do |offset, default_labels|
          if source.has_errors?
            Redwood::log "error loading messages from #{source}: #{source.error.message}"
 @@ -145,6 +152,7 @@ EOS
          end
  
          m_new = Message.build_from_source source, offset
 +        messages.push(m_new)
          m_old = Index.build_message m_new.id
  
          m_new.labels += default_labels + (source.archived? ? [] : [:inbox])
 @@ -157,6 +165,8 @@ EOS
          Index.sync_message m_ret, opts
          UpdateManager.relay self, :added, m_ret unless m_old
        end
 +      HookManager.run "after-add-message", :messages => messages
 +
      rescue SourceError => e
        Redwood::log "problem getting messages from #{source}: #{e.message}"
        Redwood::report_broken_sources :force_to_top => true
 -- 
 1.6.0.4
 
 
 From kevinr@free-dissociation.com  Thu Aug 20 22:07:17 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Thu, 20 Aug 2009 22:07:17 -0400
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 In-Reply-To: <1250707991-sup-5429@masanjin.net>
 References: <1250459229-4500-1-git-send-email-kevinr@free-dissociation.com>
 	<1250618123-sup-8797@masanjin.net>
 	<1250638381-sup-2952@black-opal.mit.edu>
 	<1250707991-sup-5429@masanjin.net>
 Message-ID: <1250820245-sup-2250@black-opal.mit.edu>
 
 Excerpts from William Morgan's message of Wed Aug 19 14:55:03 -0400 2009:
 > Reformatted excerpts from Kevin Riggle's message of 2009-08-18:
 > > I don't /think/ so, unless I misunderstand the way hooks work.  I
 > > assumed the hook would execute and then execution of the loop would
 > > resume, and I don't think I throw anything in the hook which should
 > > cause that either.
 > 
 > What I'm saying is that this hook will execute *after* each message is
 > added to the index, so if Sup found several new messages, all except the
 > first one will wait on this hook to execute before being added to the
 > index. Or do you mean block in some sense besides "wait for completion"?
 
 Oh, duh.  I take your point -- I've sent a new patch.
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 http://free-dissociation.com
 
 From cworth@cworth.org  Thu Aug 20 22:09:15 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 20 Aug 2009 19:09:15 -0700
 Subject: [sup-talk] 'next' crash: wrong id called on nil (thread.rb:264:in
 	`thread_for')
 Message-ID: <1250820431-sup-8159@yoom.home.cworth.org>
 
 I'm running sup next, (3de96fb9b308afe600c7ccfcee75913f039ef4f6 + 3
 patches that I've posted to this list, but which I hope are not
 relevant here), and I got the following crash.
 
 My best recollection is that I had just sent a reply, and then hit
 ".a".
 
 Anything here look like an obvious fix for someone?
 
 -Carl
 
 --- RuntimeError from thread: main
 wrong id called on nil
 ./lib/sup.rb:17:in `id'
 ./lib/sup/thread.rb:264:in `thread_for'
 ./lib/sup/modes/thread-index-mode.rb:702:in `thread_containing'
 ./lib/sup/modes/thread-index-mode.rb:702:in `synchronize'
 ./lib/sup/modes/thread-index-mode.rb:702:in `thread_containing'
 ./lib/sup/modes/thread-index-mode.rb:173:in `handle_simple_update'
 ./lib/sup/modes/thread-index-mode.rb:180:in `handle_archived_update'
 ./lib/sup/update.rb:26:in `send'
 ./lib/sup/update.rb:26:in `relay'
 ./lib/sup/update.rb:26:in `each'
 ./lib/sup/update.rb:26:in `relay'
 ./lib/sup/util.rb:520:in `send'
 ./lib/sup/util.rb:520:in `method_missing'
 ./lib/sup/modes/thread-view-mode.rb:481:in `archive_and_then'
 ./lib/sup/modes/thread-view-mode.rb:515:in `dispatch'
 ./lib/sup/modes/thread-view-mode.rb:525:in `call'
 ./lib/sup/modes/thread-view-mode.rb:525:in `dispatch'
 ./lib/sup/modes/thread-view-mode.rb:479:in `archive_and_then'
 ./lib/sup/modes/thread-view-mode.rb:461:in `archive_and_kill'
 ./lib/sup/mode.rb:50:in `send'
 ./lib/sup/mode.rb:50:in `handle_input'
 ./lib/sup/buffer.rb:260:in `handle_input'
 ./bin/sup:237
 
 -------------- 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/20090820/c9929115/attachment.bin>
 
 From chris@chris-wilson.co.uk  Fri Aug 21 11:16:26 2009
 From: chris@chris-wilson.co.uk (Chris Wilson)
 Date: Fri, 21 Aug 2009 16:16:26 +0100
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 Message-ID: <1250867140-sup-2558@tiger.alporthouse.com>
 
 Excerpts from Ben Walton's message of Thu Aug 20 21:43:08 +0100 2009:
 > I skim the inbox using 't' to
 > tag all messages I don't care about.  When I've tagged a bunch of
 > items, after the scan, I simply to '=' followed by either 'A'
 > (archive, mark read) or '&'.
 
 This works very nicely, thanks. Though I miss the subtly of why you
 use 'A' rather than 'a'. Could you explain the difference this makes?
 -ickle
 
 From ezyang@MIT.EDU  Fri Aug 21 11:19:35 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 21 Aug 2009 11:19:35 -0400
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250867140-sup-2558@tiger.alporthouse.com>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 	<1250867140-sup-2558@tiger.alporthouse.com>
 Message-ID: <1250867926-sup-4258@javelin>
 
 Excerpts from Chris Wilson's message of Fri Aug 21 11:16:26 -0400 2009:
 > This works very nicely, thanks. Though I miss the subtly of why you
 > use 'A' rather than 'a'. Could you explain the difference this makes?
 > -ickle
 
 A -> mark as read and archive
 a -> just archive
 
 This means you can have unread messages that are archived.  I use this
 to great effect with my mailing list messages (which I have filters
 to archive but not to mark read).
 
 Cheers,
 Edward
 
 From bwalton@artsci.utoronto.ca  Fri Aug 21 11:20:23 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 21 Aug 2009 11:20:23 -0400
 Subject: [sup-talk] On making kill-thread easier
 In-Reply-To: <1250867140-sup-2558@tiger.alporthouse.com>
 References: <1250785604-sup-5488@yoom.home.cworth.org>
 	<1250797598-sup-5105@tiger.alporthouse.com>
 	<1250800965-sup-4218@ntdws12.chass.utoronto.ca>
 	<1250867140-sup-2558@tiger.alporthouse.com>
 Message-ID: <1250867933-sup-5786@ntdws12.chass.utoronto.ca>
 
 Excerpts from Chris Wilson's message of Fri Aug 21 11:16:26 -0400 2009:
 
 > This works very nicely, thanks. Though I miss the subtly of why you
 > use 'A' rather than 'a'. Could you explain the difference this makes?
 
 'A' marks the mail as read in addition to archiving it.  This makes
 'U' (unread view) mode better for my use.
 
 -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/20090821/9b947b49/attachment.bin>
 
 From guillaume.quintard@gmail.com  Fri Aug 21 12:00:29 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Fri, 21 Aug 2009 18:00:29 +0200
 Subject: [sup-talk] Crashing ssh + sup, bad combo
 Message-ID: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 
 Sooooo, here's what happened: I was running sup through ssh, minding
 my own business, when suddenly, my local machine crashed. I reboot,
 reconnect, sup is somehow still running, I kill it (with a good ol'
 kill, because the lock file was empty so sup could ask for a seppuku),
 and no I have this:
 [Fri Aug 21 17:54:54 +0200 2009] ERROR: oh crap, an exception
 ----------------------------------------------------------------
 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
 ----------------------------------------------------------------
 --- RuntimeError from thread: load threads for thread-index-mode
 wrong id called on nil
 ./lib/sup.rb:17:in `id'
 ./lib/sup/xapian_index.rb:155:in `each_message_in_thread_for'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 ./lib/sup/xapian_index.rb:336:in `synchronize'
 ./lib/sup/xapian_index.rb:155:in `each_message_in_thread_for'
 ./lib/sup/thread.rb:341:in `load_thread_for_message'
 ./lib/sup/thread.rb:333:in `load_n_threads'
 ./lib/sup/xapian_index.rb:149:in `each_id_by_date'
 ./lib/sup/xapian_index.rb:142:in `each_id'
 ./lib/sup/xapian_index.rb:142:in `each'
 ./lib/sup/xapian_index.rb:142:in `each_id'
 ./lib/sup/xapian_index.rb:149:in `each_id_by_date'
 ./lib/sup/thread.rb:328:in `load_n_threads'
 ./lib/sup/modes/thread-index-mode.rb:623:in `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 ./lib/sup/modes/thread-index-mode.rb:607:in `load_n_threads_background'
 ./lib/sup.rb:77:in `reporting_thread'
 ./lib/sup.rb:75:in `initialize'
 ./lib/sup.rb:75:in `new'
 ./lib/sup.rb:75:in `reporting_thread'
 ./lib/sup/modes/thread-index-mode.rb:606:in `load_n_threads_background'
 ./lib/sup/modes/thread-index-mode.rb:676:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 bin/sup:192
 
 me no likey :-(
 
 -- 
 Guillaume
 
 From marka@pobox.com  Fri Aug 21 14:57:10 2009
 From: marka@pobox.com (Mark Alexander)
 Date: Fri, 21 Aug 2009 14:57:10 -0400
 Subject: [sup-talk] Crashing ssh + sup, bad combo
 In-Reply-To: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 Message-ID: <a412e2a70908211157vcd73cc6r4b401fd38f50902@mail.gmail.com>
 
 This isn't directly related, and you may already know about this, and
 apologies if that's the case... but I highly recommend running screen
 on the machine where you're running sup.  That way you don't lose any
 work when your ssh connection drops for any reason.
 
 From guillaume.quintard@gmail.com  Fri Aug 21 15:29:22 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Fri, 21 Aug 2009 21:29:22 +0200
 Subject: [sup-talk] Crashing ssh + sup, bad combo
 In-Reply-To: <a412e2a70908211157vcd73cc6r4b401fd38f50902@mail.gmail.com>
 References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 	<a412e2a70908211157vcd73cc6r4b401fd38f50902@mail.gmail.com>
 Message-ID: <1e5fdab70908211229w2f11d11h4db7500a340b923b@mail.gmail.com>
 
 On Fri, Aug 21, 2009 at 8:57 PM, Mark Alexander<marka at pobox.com> wrote:
 > This isn't directly related, and you may already know about this, and
 > apologies if that's the case... but I highly recommend running screen
 > on the machine where you're running sup. ?That way you don't lose any
 > work when your ssh connection drops for any reason.
 >
 
 Yup, I know, but screen isn't yet natural to me, and I tend to forgot
 to use it :-)
 
 
 -- 
 Guillaume
 
 From rlane@club.cc.cmu.edu  Fri Aug 21 16:57:55 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 21 Aug 2009 16:57:55 -0400
 Subject: [sup-talk] Crashing ssh + sup, bad combo
 In-Reply-To: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 Message-ID: <1250887753-sup-7844@zyrg.net>
 
 Excerpts from Guillaume Quintard's message of Fri Aug 21 12:00:29 -0400 2009:
 > Sooooo, here's what happened: I was running sup through ssh, minding
 > my own business, when suddenly, my local machine crashed. I reboot,
 > reconnect, sup is somehow still running, I kill it (with a good ol'
 > kill, because the lock file was empty so sup could ask for a seppuku),
 > and no I have this:
 
 I'm guessing this is an inconsistency between your xapian and entries.db
 databases. A sup-sync -a might fix it.
 
 I posted a patch a few days ago that moves all index data into Xapian to
 prevent this sort of issue. William, could you take a look at / merge that
 patch?
 
 From lcontzen@gmail.com  Sat Aug 22 05:45:18 2009
 From: lcontzen@gmail.com (Contzen Laurent)
 Date: Sat, 22 Aug 2009 11:45:18 +0200
 Subject: [sup-talk] Sup crashed at launch
 Message-ID: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com>
 
 Hello,
 
 I've heard about sup and it sounded great so I decided to give it a
 try following http://www.brainyautomation.com/blog/post/Reading-Gmail-with-Sup.aspx
 .
 
 I installed everything, configured ssmtp and got it working, etc. I
 then launched sup for a first time to let it create my ~/.sup and exit
 whithout any troubles. I then configured my .sup/sources.yaml as shown
 in the webpage mentionned above and then launched sup. It crashed with
 that output :
 
 [Sat Aug 22 11:41:56 +0200 2009] using character set encoding "utf8"
 [Sat Aug 22 11:41:56 +0200 2009] dynamically loading setlocale() from libc.so.6
 [Sat Aug 22 11:41:56 +0200 2009] setting locale...
 [Sat Aug 22 11:41:56 +0200 2009] locking /home/laurent/.sup/lock...
 [Sat Aug 22 11:41:56 +0200 2009] crypto: detected gpg binary in /usr/bin/gpg
 [Sat Aug 22 11:41:56 +0200 2009] stopped cursing
 [Sat Aug 22 11:41:56 +0200 2009] oh crap, an exception
 [Sat Aug 22 11:41:56 +0200 2009] unlocking /home/laurent/.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
 ----------------------------------------------------------------
 --- ArgumentError from thread: main
 username and password must be specified
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/imap.rb:60:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:30:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:30:in `yaml_properties'
 /usr/lib/ruby/1.8/yaml.rb:133:in `call'
 /usr/lib/ruby/1.8/yaml.rb:133:in `transfer'
 /usr/lib/ruby/1.8/yaml.rb:133:in `node_import'
 /usr/lib/ruby/1.8/yaml.rb:133:in `load'
 /usr/lib/ruby/1.8/yaml.rb:133:in `load'
 /usr/lib/ruby/1.8/yaml.rb:144:in `load_file'
 /usr/lib/ruby/1.8/yaml.rb:143:in `open'
 /usr/lib/ruby/1.8/yaml.rb:143:in `load_file'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:98:in `load_yaml_obj'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:473:in `load_sources'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:121:in `load'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:162
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 
 The ouput asked to send this mail so I decided to try to help you by doing it.
 
 Don't hesitate to ask for details, ...
 
 Laurent
 
 From ulrik.sverdrup@gmail.com  Fri Aug 21 19:04:15 2009
 From: ulrik.sverdrup@gmail.com (Ulrik Sverdrup)
 Date: Sat, 22 Aug 2009 01:04:15 +0200
 Subject: [sup-talk] Bug: Log printing with encoding problems
 Message-ID: <a1b6cb1b0908211604p4c0e94bk87134933f45e6f73@mail.gmail.com>
 
 My locale is sv_SE.UTF-8, log is truncated since the date string is
 longer than expected.
 
 The date should print "l?r" (from L?rdag = Saturday)
 
 Sat Aug 22 00:55:52 +0200 2009: using character set encoding "UTF-8"
 Sat Aug 22 00:55:52 +0200 2009: dynamically loading setlocale() from libc.so.6
 Sat Aug 22 00:55:52 +0200 2009: setting locale...
 lM-CM-6r aug 22 00:55:52 +0200 2009: locking /home/ulrik/.sup/lo
 lM-CM-6r aug 22 00:55:52 +0200 2009: crypto: detected gpg binary in /usr/bi
 lM-CM-6r aug 22 00:55:52 +0200 2009: loading ind
 lM-CM-6r aug 22 00:55:52 +0200 2009: loaded index of 0 mes
 lM-CM-6r aug 22 00:55:52 +0200 2009: starting c
 
 
 Regards,
 ulrik
 
 From ulrik.sverdrup@gmail.com  Fri Aug 21 19:08:30 2009
 From: ulrik.sverdrup@gmail.com (Ulrik Sverdrup)
 Date: Sat, 22 Aug 2009 01:08:30 +0200
 Subject: [sup-talk] Bug: Quits on unbound(?) keys
 Message-ID: <a1b6cb1b0908211608u40e3ab67h9ff7373a4a686062@mail.gmail.com>
 
 Sup seems to crash if you press a key not bound(?)
 
 Sup version: 0.8.1 (debian unstable)
 
 start sup-mail.
 press 'c'
 
 sup will crash with following message:
 uby: symbol lookup error:
 /usr/lib/ruby/1.8/powerpc-linux/ncurses_bin.so: undefined symbol:
 funcall
 
 
 Regards,
 ulrik
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 09:46:27 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 06:46:27 -0700
 Subject: [sup-talk] [PATCH] index log
 In-Reply-To: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250948551-sup-2052@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-16:
 > Add a YAML logfile that records changes to the index and modify
 > sup-dump to use this rather than the normal database.
 
 I like this. I'm going to wait to apply it until the api refactoring
 stuff is merged down to master though. Should be soon.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 10:10:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 07:10:04 -0700
 Subject: [sup-talk] [PATCH] cache results of Person.from_address
 In-Reply-To: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250949615-sup-1773@masanjin.net>
 
 This looks good. Two minor questions before I apply:
 
 Reformatted excerpts from Rich Lane's message of 2009-08-16:
 > The regexes in this function are very expensive, so caching improves
 > performance significantly for queries and slightly for indexing.
 
 When you say this affects query performance, is it just the contact-list
 query, or is there some other mechanism by which this is slowing down
 regular queries?
 
 Also in this method:
 
 > +  def []=(k,v)
 > +    if @values.size < @n
 > +      @values[k] = v
 > +      @marks[k] = @i
 > +    else
 > +      if @delete_stack.empty?
 > +        sweep
 > +      else
 > +        k2 = @delete_stack.pop
 > +        @values.delete k2
 > +        @marks.delete k2
 > +        self[k] = v
 > +      end
 > +    end
 > +  end
 
 Wouldn't it be better to do this?
 
        else
          if @delete_stack.empty?
            sweep
          end
 
          unless @delete_stack.empty?
            k2 = @delete_stack.pop
            @values.delete k2
            @marks.delete k2
            self[k] = v
          end
 
 So we check the delete stack even after calling sweep, and we allow for
 the value to be nil.
 
 Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 10:10:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 07:10:20 -0700
 Subject: [sup-talk] [PATCH] cache results of Person.from_address
 In-Reply-To: <1250514421-sup-7564@Longbow>
 References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250514421-sup-7564@Longbow>
 Message-ID: <1250950211-sup-1042@masanjin.net>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-08-17:
 > Just want to say thanks again for your seemingly unending amount of
 > good work to improve Sup.
 
 Agreed!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 10:35:37 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 07:35:37 -0700
 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
 In-Reply-To: <1250453934-sup-9651@zyrg.net>
 References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 	<20090816200116.GA17272@chistera.yi.org>
 	<1250453934-sup-9651@zyrg.net>
 Message-ID: <1250951723-sup-3859@masanjin.net>
 
 Branch xapian-updates, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 10:50:58 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 07:50:58 -0700
 Subject: [sup-talk] [PATCH] Fix a thread merging bug introduced by
 	refactoring in 59f8fc2
 In-Reply-To: <1250620200-24319-1-git-send-email-alex@chmrr.net>
 References: <1250620200-24319-1-git-send-email-alex@chmrr.net>
 Message-ID: <1250952651-sup-2682@masanjin.net>
 
 Applied to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 11:01:30 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 08:01:30 -0700
 Subject: [sup-talk] [PATCH] fix garbaged text in textfield when using
 	ncursesw
 In-Reply-To: <1250715278-sup-1941@localdomain>
 References: <1250715278-sup-1941@localdomain>
 Message-ID: <1250952979-sup-9364@masanjin.net>
 
 Reformatted excerpts from Beno?t PIERRE's message of 2009-08-19:
 > Apparently, field_buffer content is not initialized to blanks when
 > using the wide-character version of ncurses. Forcing a call to
 > set_field_buffer fix the problem.
 
 Awesome. Applied to master. I hope this clears up the problems that
 people have been having with newer ncurses ruby libraries and utf8. If
 you've been seeing garbage characters when searching, please let us know
 if this fixes it.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From carlos_franke@gmx.de  Sat Aug 22 10:49:17 2009
 From: carlos_franke@gmx.de (Carlos Franke)
 Date: Sat, 22 Aug 2009 16:49:17 +0200
 Subject: [sup-talk] sup crash
 Message-ID: <20090822164917.0a84a749@gmx.de>
 
 Hi!
 
 sup 0.8.1 crashed being started after sup-config and sup-sync. Mail
 source: Local IMAP server (Courier) that works with other clients.
 sup's output asked me to send you the appended file. Have fun with it!
 
 Carlos
 -------------- next part --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090822/fc801d3c/attachment.txt>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090822/fc801d3c/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 12:26:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 09:26:36 -0700
 Subject: [sup-talk] Sup crashed at launch
 In-Reply-To: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com>
 References: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com>
 Message-ID: <1250958276-sup-9140@masanjin.net>
 
 Reformatted excerpts from Contzen Laurent's message of 2009-08-22:
 > username and password must be specified
 
 Sounds like your sources.yaml file doesn't have a username and password
 for that entry, or isn't have the correct format. You may want to delete
 it and run sup-add (or sup-config) instead to generate it automatically.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 12:31:47 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 09:31:47 -0700
 Subject: [sup-talk] sup crash
 In-Reply-To: <20090822164917.0a84a749@gmx.de>
 References: <20090822164917.0a84a749@gmx.de>
 Message-ID: <1250958467-sup-381@masanjin.net>
 
 Reformatted excerpts from Carlos Franke's message of 2009-08-22:
 > invalid source 1
 
 Sup is saying it has messages in its index that claim they're from
 source 1, but your sources.yaml doesn't have such a source. Did you
 remove something from sources.yaml?
 
 The easiest way to fix this is to delete your ~/.sup/ferret/ directory
 and run sup-sync --all --all-sources to rebuild the index, but you'll
 lose all messages state. If that's not acceptable, you can re-add source
 1, or you can delete all such messages from the index with some effort
 and devel/console.sh.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 12:34:40 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 09:34:40 -0700
 Subject: [sup-talk] Sup crashed at launch
 In-Reply-To: <1250958276-sup-9140@masanjin.net>
 References: <49454bf60908220245w52764765rdbd111dfd446896f@mail.gmail.com>
 	<1250958276-sup-9140@masanjin.net>
 Message-ID: <1250958837-sup-947@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-08-22:
 > Sounds like your sources.yaml file doesn't have a username and password
 > for that entry, or isn't have the correct format.
 
 In particular, that webpage doesn't preserve spacing for its example
 sources.yaml, and yaml is space-sensitive.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 14:15:15 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 11:15:15 -0700
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
 	variable with the attachment charset
 In-Reply-To: <20090819212209.GA10883@chistera.yi.org>
 References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 	<20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry>
 	<20090730155656.GA20442@chistera.yi.org>
 	<20090819212209.GA10883@chistera.yi.org>
 Message-ID: <1250964880-sup-7106@masanjin.net>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-08-19:
 > Ping?
 
 Sorry, working on a fix for the hook variables issue. Bug me again in a
 few days if I haven't gotten to this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Sat Aug 22 14:28:15 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 22 Aug 2009 11:28:15 -0700
 Subject: [sup-talk] [PATCH] add Message#load_from_index! shortcut
 Message-ID: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
 
 Message#parse_header is slow, taking up to 2/3 of the time spent loading
 threads in thread-index-mode. This patch adds a shortcut method that the index
 can use to efficiently initialize a message.
 ---
  lib/sup/message.rb      |   25 +++++++++++++++++++++++++
  lib/sup/xapian_index.rb |   30 +++++++++++-------------------
  2 files changed, 36 insertions(+), 19 deletions(-)
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 965c10e..56e66de 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -127,6 +127,31 @@ class Message
      @list_unsubscribe = header["list-unsubscribe"]
    end
  
 +  ## Expected index entry format:
 +  ## :message_id, :subject => String
 +  ## :date => Time
 +  ## :refs, :replytos => Array of String
 +  ## :from => Person
 +  ## :to, :cc, :bcc => Array of Person
 +  def load_from_index! entry
 +    @id = entry[:message_id]
 +    @from = entry[:from]
 +    @date = entry[:date]
 +    @subj = entry[:subject]
 +    @to = entry[:to]
 +    @cc = entry[:cc]
 +    @bcc = entry[:bcc]
 +    @refs = (@refs + entry[:refs]).uniq
 +    @replytos = entry[:replytos]
 +
 +    @replyto = nil
 +    @list_address = nil
 +    @recipient_email = nil
 +    @source_marked_read = false
 +    @list_subscribe = nil
 +    @list_unsubscribe = nil
 +  end
 +
    def add_ref ref
      @refs << ref
      @dirty = true
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 85f6ef0..c260728 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -71,25 +71,17 @@ class XapianIndex < BaseIndex
      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
 +    m = Message.new :source => source, :source_info => entry[:source_info],
 +                    :labels => entry[:labels], :snippet => entry[:snippet]
 +
 +    mk_person = lambda { |x| Person.new(*x.reverse!) }
 +    entry[:from] = mk_person[entry[:from]]
 +    entry[:to].map!(&mk_person)
 +    entry[:cc].map!(&mk_person)
 +    entry[:bcc].map!(&mk_person)
 +
 +    m.load_from_index! entry
 +    m
    end
  
    def add_message m; sync_message m end
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Sat Aug 22 14:28:39 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 22 Aug 2009 14:28:39 -0400
 Subject: [sup-talk] [PATCH] cache results of Person.from_address
 In-Reply-To: <1250949615-sup-1773@masanjin.net>
 References: <1250491172-19317-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250949615-sup-1773@masanjin.net>
 Message-ID: <1250964897-sup-2990@zyrg.net>
 
 Excerpts from William Morgan's message of Sat Aug 22 10:10:04 -0400 2009:
 > This looks good. Two minor questions before I apply:
 > 
 > Reformatted excerpts from Rich Lane's message of 2009-08-16:
 > > The regexes in this function are very expensive, so caching improves
 > > performance significantly for queries and slightly for indexing.
 > 
 > When you say this affects query performance, is it just the contact-list
 > query, or is there some other mechanism by which this is slowing down
 > regular queries?
 
 Actually, your question prompted me to wonder why we're calling
 Person.from_address on this path at all. With a little support from
 Message we can completely avoid Message#parse_header. I've just sent in
 a patch that does this. Please apply that rather than the from_address
 cache.
 
 The performance improvement from the new patch is slightly better than
 that of the cache. Depending on the benchmark I see the time taken by
 ThreadIndexMode#load_n_threads decrease by 1/2 to 2/3.
 
 From rlane@club.cc.cmu.edu  Sat Aug 22 14:54:23 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 22 Aug 2009 11:54:23 -0700
 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a
 	Person
 In-Reply-To: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu>
 
 Another 10% query performance boost.
 ---
  lib/sup/xapian_index.rb |   10 +++++++++-
  1 files changed, 9 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index c260728..3a23951 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -74,7 +74,7 @@ class XapianIndex < BaseIndex
      m = Message.new :source => source, :source_info => entry[:source_info],
                      :labels => entry[:labels], :snippet => entry[:snippet]
  
 -    mk_person = lambda { |x| Person.new(*x.reverse!) }
 +    mk_person = lambda { |x| QuickPerson.new(*x) }
      entry[:from] = mk_person[entry[:from]]
      entry[:to].map!(&mk_person)
      entry[:cc].map!(&mk_person)
 @@ -84,6 +84,14 @@ class XapianIndex < BaseIndex
      m
    end
  
 +  class QuickPerson < Person
 +    def initialize email, name
 +      raise ArgumentError, "email can't be nil" unless email
 +      @email = email
 +      @name = name
 +    end
 +  end
 +
    def add_message m; sync_message m end
    def update_message m; sync_message m end
    def update_message_state m; sync_message m end
 -- 
 1.6.4
 
 
 From ingmar@exherbo.org  Sat Aug 22 15:12:30 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Sat, 22 Aug 2009 21:12:30 +0200
 Subject: [sup-talk] Bug: Quits on unbound(?) keys
 In-Reply-To: <a1b6cb1b0908211608u40e3ab67h9ff7373a4a686062@mail.gmail.com>
 References: <a1b6cb1b0908211608u40e3ab67h9ff7373a4a686062@mail.gmail.com>
 Message-ID: <1250968143-sup-3847@cannonball>
 
 Excerpts from Ulrik Sverdrup's message of Sat Aug 22 01:08:30 +0200 2009:
 > sup will crash with following message:
 > ruby: symbol lookup error:
 > /usr/lib/ruby/1.8/powerpc-linux/ncurses_bin.so: undefined symbol:
 > funcall
 
 I bet you're using ncurses-ruby-1.2.2? What you're seeing is an
 ncurses-ruby bug:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532431
 Update to 1.2.3 or 1.2.4 & you'll be find. If that's not an option,
 downgrade to a 1.1 release.
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From dato@net.com.org.es  Sat Aug 22 15:16:17 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Sat, 22 Aug 2009 20:16:17 +0100
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
  variable with the attachment charset
 In-Reply-To: <1250964880-sup-7106@masanjin.net>
 References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 	<20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry>
 	<20090730155656.GA20442@chistera.yi.org>
 	<20090819212209.GA10883@chistera.yi.org>
 	<1250964880-sup-7106@masanjin.net>
 Message-ID: <20090822191617.GA26897@chistera.yi.org>
 
 + William Morgan (Sat, 22 Aug 2009 11:15:15 -0700):
 
 > Reformatted excerpts from Adeodato Sim?'s message of 2009-08-19:
 > > Ping?
 
 > Sorry, working on a fix for the hook variables issue. Bug me again in a
 > few days if I haven't gotten to this.
 
 Only in case it needs saying: you mean a fix other than the patch I sent
 for that as well? (Perhaps my proposed fix was not completed, I just
 want to make sure the patch got noticed.)
 
 Thanks,
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 16:23:17 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 13:23:17 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250717434-sup-4489@yoom.home.cworth.org>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 	<1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net>
 	<1250710221-sup-925@yoom.home.cworth.org>
 	<1250712045-sup-3506@masanjin.net>
 	<1250717434-sup-4489@yoom.home.cworth.org>
 Message-ID: <1250964942-sup-8625@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > I ran an strace on the ruby process[*] and was able to plainly see
 > that modules were being correctly loaded from ./lib until after
 > /usr/lib/ruby/1.8/chronic.rb was loaded. After that, ruby would look
 > for modules in /usr/lib/ruby/1.8 before ./lib. And sure enough, the
 > first line of my chronic.rb has:
 > 
 > $:.unshift File.dirname(__FILE__)     # For use/testing when no gem is installed
 
 I'd call that a bug in chronic. It shouldn't be screwing with the load
 path. Nice debug work.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Aug 22 16:25:22 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 22 Aug 2009 13:25:22 -0700
 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
 In-Reply-To: <1250745799-sup-6607@yoom.home.cworth.org>
 References: <1250745799-sup-6607@yoom.home.cworth.org>
 Message-ID: <1250972634-sup-6871@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > I'm probably still off as far as standard ruby idioms, (and I'm
 > probably committing some sup layer violations as well).
 
 It all looks good except you can use Logger::LEVELS to access the
 constants. Then there's no need to write a LEVELS method. If you fix
 that I will apply. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From chris@chris-wilson.co.uk  Sun Aug 23 08:44:29 2009
 From: chris@chris-wilson.co.uk (Chris Wilson)
 Date: Sun, 23 Aug 2009 13:44:29 +0100
 Subject: [sup-talk] How to edit attachments in reply?
 Message-ID: <1251031062-sup-4617@tiger.alporthouse.com>
 
 Just a simple plea to make my life easier... Given an email with a
 couple of attached patches, what is the easiest way to reply including
 inline comments on the attached patches? At the moment I'm saving the
 attachments to /tmp and then manually including them whilst replying.
 Can anyone give me any clues on how to automatically include the
 attachments in a reply?
 
 Thanks.
 -Chris
 
 From wmorgan-sup@masanjin.net  Sun Aug 23 13:34:10 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 23 Aug 2009 10:34:10 -0700
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
 	variable with the attachment charset
 In-Reply-To: <20090822191617.GA26897@chistera.yi.org>
 References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 	<20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry>
 	<20090730155656.GA20442@chistera.yi.org>
 	<20090819212209.GA10883@chistera.yi.org>
 	<1250964880-sup-7106@masanjin.net>
 	<20090822191617.GA26897@chistera.yi.org>
 Message-ID: <1251048347-sup-5075@masanjin.net>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-08-22:
 > Only in case it needs saying: you mean a fix other than the patch I
 > sent for that as well? (Perhaps my proposed fix was not completed, I
 > just want to make sure the patch got noticed.)
 
 Hm, I don't remember seeing it and can't find it now. Can you resend,
 please?
 
 I do see a previous patch that did miss from you, about a crypto+mime
 fix. Is that still something that should be applied? It looks good to
 me.
 
 Anyways, I just merged my hook changes into next, on the branch
 hook-local-vars. Take a look and tell me what you think. This should
 also fix Edward Z. Yang's problems with hook locals not being useable in
 statements like "x = x.foo()".
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Aug 23 13:55:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 23 Aug 2009 10:55:59 -0700
 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the
 	left column
 In-Reply-To: <1250749447-sup-1744@yoom.home.cworth.org>
 References: <1250749447-sup-1744@yoom.home.cworth.org>
 Message-ID: <1251050007-sup-9740@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > Specifically, scroll as little as possible to get the current message
 > to just fit on the right side.
 
 Is this the same as setting loose_alignment to true, and the
 IDEAL_*_CONTENTs to 0?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Sun Aug 23 14:36:59 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 23 Aug 2009 11:36:59 -0700
 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that dont
 	already exist
 Message-ID: <1251052619-9915-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup-sync |    5 +++++
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/bin/sup-sync b/bin/sup-sync
 index 2aa00c3..003a72d 100755
 --- a/bin/sup-sync
 +++ b/bin/sup-sync
 @@ -174,7 +174,12 @@ begin
        ## decide what to do based on message labels and the operation we're performing
        dothis, new_labels = case
        when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels != restored_state[m.id])
 +        num_restored += 1
          [:update_message_state, restored_state[m.id]]
 +      when (op == :restore) && restored_state[m.id] && !old_m
 +        num_restored += 1
 +        m.labels = restored_state[m.id]
 +        :add_message
        when op == :discard
          if old_m && (old_m.labels != m.labels)
            [:update_message_state, m.labels]
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 23 14:46:10 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 23 Aug 2009 11:46:10 -0700
 Subject: [sup-talk] [PATCH 1/2] preemptively load messages when scrolling
 Message-ID: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/modes/line-cursor-mode.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/modes/line-cursor-mode.rb b/lib/sup/modes/line-cursor-mode.rb
 index 246f2b5..0b1fd1d 100644
 --- a/lib/sup/modes/line-cursor-mode.rb
 +++ b/lib/sup/modes/line-cursor-mode.rb
 @@ -77,7 +77,7 @@ protected
    end
  
    def cursor_down
 -    call_load_more_callbacks buffer.content_height if @curpos == lines - 1
 +    call_load_more_callbacks buffer.content_height if @curpos >= lines - [buffer.content_height/2,1].max
      return false unless @curpos < lines - 1
  
      if @curpos >= botline - 1
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 23 14:46:11 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 23 Aug 2009 11:46:11 -0700
 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
 In-Reply-To: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup                            |    1 +
  lib/sup/modes/thread-index-mode.rb |    4 ++--
  2 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 3d5b6c1..f3c6771 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -58,6 +58,7 @@ if $opts[:list_hooks]
  end
  
  Thread.abort_on_exception = true # make debugging possible
 +Thread.current.priority = 1 # keep ui responsive
  
  module Redwood
  
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index fb6b2ce..177431b 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -76,8 +76,7 @@ EOS
      @last_load_more_size = nil
      to_load_more do |size|
        next if @last_load_more_size == 0
 -      load_threads :num => 1, :background => false
 -      load_threads :num => (size - 1),
 +      load_threads :num => size,
                     :when_done => lambda { |num| @last_load_more_size = num }
      end
    end
 @@ -627,6 +626,7 @@ EOS
          BufferManager.draw_screen
          last_update = Time.now
        end
 +      ::Thread.pass
        break if @interrupt_search
      end
      @ts.threads.each { |th| th.labels.each { |l| LabelManager << l } }
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 23 14:49:02 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 23 Aug 2009 11:49:02 -0700
 Subject: [sup-talk] [PATCH] reply all keybindings
 Message-ID: <1251053342-11859-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/modes/reply-mode.rb        |    6 ++++--
  lib/sup/modes/thread-index-mode.rb |    7 +++++--
  lib/sup/modes/thread-view-mode.rb  |    7 +++++--
  3 files changed, 14 insertions(+), 6 deletions(-)
 
 diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb
 index 700dfc1..3d39a8a 100644
 --- a/lib/sup/modes/reply-mode.rb
 +++ b/lib/sup/modes/reply-mode.rb
 @@ -40,7 +40,7 @@ Return value:
    The reply mode you desire, or nil to use the default behavior.
  EOS
  
 -  def initialize message
 +  def initialize message, type_arg=nil
      @m = message
  
      ## it's important to put this early because it forces a read of
 @@ -138,7 +138,9 @@ EOS
      hook_reply = HookManager.run "reply-to", :modes => types
  
      @type_selector.set_to(
 -      if types.include? hook_reply
 +      if types.include? type_arg
 +        type_arg
 +      elsif types.include? hook_reply
          hook_reply
        elsif @m.is_list_message?
          :list
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index fb6b2ce..d1b7fdb 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -40,6 +40,7 @@ EOS
      k.add :save, "Save changes now", '$'
      k.add :jump_to_next_new, "Jump to next new thread", :tab
      k.add :reply, "Reply to latest message in a thread", 'r'
 +    k.add :reply_all, "Reply to all participants of the latest message in a thread", 'G'
      k.add :forward, "Forward latest message in a thread", 'f'
      k.add :toggle_tagged, "Tag/untag selected thread", 't'
      k.add :toggle_tagged_all, "Tag/untag all threads", 'T'
 @@ -584,15 +585,17 @@ EOS
      end
    end
  
 -  def reply
 +  def reply type_arg=nil
      t = cursor_thread or return
      m = t.latest_message
      return if m.nil? # probably won't happen
      m.load_from_source!
 -    mode = ReplyMode.new m
 +    mode = ReplyMode.new m, type_arg
      BufferManager.spawn "Reply to #{m.subj}", mode
    end
  
 +  def reply_all; reply :all; end
 +
    def forward
      t = cursor_thread or return
      m = t.latest_message
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index bac4792..98145cc 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -53,6 +53,7 @@ EOS
      k.add :toggle_new, "Toggle unread/read status of message", 'N'
  #    k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N'
      k.add :reply, "Reply to a message", 'r'
 +    k.add :reply_all, "Reply to all participants of this message", 'G'
      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'
 @@ -161,12 +162,14 @@ EOS
      update
    end
  
 -  def reply
 +  def reply type_arg=nil
      m = @message_lines[curpos] or return
 -    mode = ReplyMode.new m
 +    mode = ReplyMode.new m, type_arg
      BufferManager.spawn "Reply to #{m.subj}", mode
    end
  
 +  def reply_all; reply :all; end
 +
    def subscribe_to_list
      m = @message_lines[curpos] or return
      if m.list_subscribe && m.list_subscribe =~ /<mailto:(.*?)\?(subject=(.*?))>/
 -- 
 1.6.4
 
 
 From nicolas.pouillard@gmail.com  Mon Aug 24 08:20:20 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 24 Aug 2009 14:20:20 +0200
 Subject: [sup-talk] [PATCH] index log
 In-Reply-To: <1250948551-sup-2052@masanjin.net>
 References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250948551-sup-2052@masanjin.net>
 Message-ID: <1251116226-sup-1373@peray>
 
 Excerpts from William Morgan's message of Sat Aug 22 15:46:27 +0200 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-08-16:
 > > Add a YAML logfile that records changes to the index and modify
 > > sup-dump to use this rather than the normal database.
 > 
 > I like this. I'm going to wait to apply it until the api refactoring
 > stuff is merged down to master though. Should be soon.
 
 I'm wondering if a simpler format would not be better, I've patch
 in my sup copy do feed a file called ~/.sup/labels-mapping.log with
 lines like those:
 
 000e0cd20f80143822047118693d at google.com (unread inbox -> )
 20090813213654.GA30223 at community.haskell.org (unread inbox patch -> patch)
 1250148617-sup-6053 at oz.taruti.net (unread inbox sup -> sup)
 1250281208-sup-4199 at masanjin.net (unread inbox sup -> sup)
 
 Their are in the style of sup-dump output and there are pretty easy to manage
 by any tools.
 
 Not to say that I don't like YAML, I am a pretty big fan of it; but here it
 seems overkill.
 
 Best regards,
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From nicolas.pouillard@gmail.com  Mon Aug 24 08:41:03 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 24 Aug 2009 14:41:03 +0200
 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
 In-Reply-To: <1250951723-sup-3859@masanjin.net>
 References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 	<20090816200116.GA17272@chistera.yi.org>
 	<1250453934-sup-9651@zyrg.net> <1250951723-sup-3859@masanjin.net>
 Message-ID: <1251117610-sup-9144@peray>
 
 Excerpts from William Morgan's message of Sat Aug 22 16:35:37 +0200 2009:
 > Branch xapian-updates, merged into next. Thanks!
 
 What is the updating procedure please ?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 14:13:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 11:13:43 -0700
 Subject: [sup-talk] In next: thread-view-mode labelling No method join
 	for Set
 In-Reply-To: <1250727630-sup-3112@yoom.home.cworth.org>
 References: <1250714501-sup-3033@chigamba>
 	<1250727630-sup-3112@yoom.home.cworth.org>
 Message-ID: <1251137007-sup-3974@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > I've attached a patch that at least makes the crashes I was able ro
 > reproduce go away.
 
 Applied, thanks!
 
 > [*] Totally off-topic: This is one of the things about "dynamically
 > typed" languages that I've never been able to wrap my brain around. I
 > really like that with static typing I can trust the compiler to help
 > me be very thorough if I make a type change like this, (and catch all
 > the cases before shipping any code). Instead, here, there's a hard
 > task of exercising every possible code path (at run time) before we
 > know if there are any type errors still lingering. I've seen some
 > proponents of dynamically-typed languages argue that unit testing
 > should provide the same coverage that a statically-typed compiler
 > would, but I haven't seen that in practice.
 
 You're right, this is a classic example of the type of bug that would be
 caught with static typing. Unit tests are the canonical answer. I'd
 argue that unit tests provide better error checking than static typing,
 since they allow you to capture the exact set of errors you're
 interested in, rather than the set of type mismatches that a
 type-checker can detect. (IMO the two sets rarely have more than a very
 small overlap.)
 
 Unit tests are only useful, of course, if you write them. Sup doesn't
 have very many. I've made an explicit choice to spend my oh-so-limited
 Sup time adding new features rather than ensuring a rock-solid platform.
 The occasional bug like this is the price we all pay. But it's a matter
 of tradeoffs---I do believe that if I were using a statically-typed
 language, development would be significantly slower, and Sup would be
 nowhere near the point it is now. I have no proof of this statement, of
 course.
 
 And if anyone wants to retrofit some unit tests, I'm more than happy to
 accept them!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From lists@larsko.org  Mon Aug 24 16:54:35 2009
 From: lists@larsko.org (Lars Kotthoff)
 Date: Mon, 24 Aug 2009 21:54:35 +0100
 Subject: [sup-talk] Encrypted password in configuration file
 Message-ID: <20090824215435.182e0007@ronin.larsko.net>
 
 Hi list,
 
  is it possible to store the account password encrypted in the configuration
 file?
 
 Thanks,
 
 Lars
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 18:38:42 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 15:38:42 -0700
 Subject: [sup-talk] Bug: Quits on unbound(?) keys
 In-Reply-To: <1250968143-sup-3847@cannonball>
 References: <a1b6cb1b0908211608u40e3ab67h9ff7373a4a686062@mail.gmail.com>
 	<1250968143-sup-3847@cannonball>
 Message-ID: <1251153498-sup-1707@masanjin.net>
 
 Reformatted excerpts from Ingmar Vanhassel's message of 2009-08-22:
 > I bet you're using ncurses-ruby-1.2.2? What you're seeing is an
 > ncurses-ruby bug:
 > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=532431
 
 Wow, Sup is really giving the ncurses-ruby maintainer a workout. Nice!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 18:44:58 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 15:44:58 -0700
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 In-Reply-To: <1250819862-4858-1-git-send-email-kevinr@free-dissociation.com>
 References: <1250707991-sup-5429@masanjin.net>
 	<1250819862-4858-1-git-send-email-kevinr@free-dissociation.com>
 Message-ID: <1251153881-sup-1538@masanjin.net>
 
 Reformatted excerpts from Kevin Riggle's message of 2009-08-20:
 > I want to do some unrelated processing on each message I receive, but
 > I don't want to block the message being added to the index.  This
 > patch adds a hook which runs /after/ the message is added to the
 > index.
 
 Branch after-add-message-hook, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 18:45:37 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 15:45:37 -0700
 Subject: [sup-talk] 'next' crash: wrong id called on nil
 	(thread.rb:264:in `thread_for')
 In-Reply-To: <1250820431-sup-8159@yoom.home.cworth.org>
 References: <1250820431-sup-8159@yoom.home.cworth.org>
 Message-ID: <1251153912-sup-5105@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-20:
 > --- RuntimeError from thread: main
 > wrong id called on nil
 
 I think this should be fixed in recent nexts. Can you confirm?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 18:46:12 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 15:46:12 -0700
 Subject: [sup-talk] Crashing ssh + sup, bad combo
 In-Reply-To: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 References: <1e5fdab70908210900y5b51722agf33487b3d4dafcf4@mail.gmail.com>
 Message-ID: <1251153959-sup-7992@masanjin.net>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-08-21:
 > --- RuntimeError from thread: load threads for thread-index-mode
 > wrong id called on nil
 
 Let me know if this is still a problem.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 18:48:05 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 15:48:05 -0700
 Subject: [sup-talk] Bug: Log printing with encoding problems
 In-Reply-To: <a1b6cb1b0908211604p4c0e94bk87134933f45e6f73@mail.gmail.com>
 References: <a1b6cb1b0908211604p4c0e94bk87134933f45e6f73@mail.gmail.com>
 Message-ID: <1251154017-sup-4599@masanjin.net>
 
 Reformatted excerpts from Ulrik Sverdrup's message of 2009-08-21:
 > My locale is sv_SE.UTF-8, log is truncated since the date string is
 > longer than expected.
 
 Are you running with the ncursesw-enabled ncurses.so? If so, this should
 work, assuming your terminal is otherwise capable of displaying utf8.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 19:23:32 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 16:23:32 -0700
 Subject: [sup-talk] [PATCH] add Message#load_from_index! shortcut
 In-Reply-To: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251156117-sup-2313@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-22:
 > Message#parse_header is slow, taking up to 2/3 of the time spent
 > loading threads in thread-index-mode. This patch adds a shortcut
 > method that the index can use to efficiently initialize a message.
 
 Yes, great catch. I've applied this to xapian-updates branch and
 remerged into next.
 
 BTW can you base your patches off master instead of next? It will save
 me a couple keystrokes.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 19:24:19 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 16:24:19 -0700
 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a
 	Person
 In-Reply-To: <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251156216-sup-5563@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-22:
 > -    mk_person = lambda { |x| Person.new(*x.reverse!) }
 > +    mk_person = lambda { |x| QuickPerson.new(*x) }
 
 What about lambda { |x| Person.new x[1], x[0] }. Surely that must be
 even faster?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 24 19:29:40 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 24 Aug 2009 16:29:40 -0700
 Subject: [sup-talk] How to edit attachments in reply?
 In-Reply-To: <1251031062-sup-4617@tiger.alporthouse.com>
 References: <1251031062-sup-4617@tiger.alporthouse.com>
 Message-ID: <1251156446-sup-143@masanjin.net>
 
 Reformatted excerpts from Chris Wilson's message of 2009-08-23:
 > Can anyone give me any clues on how to automatically include the
 > attachments in a reply?
 
 There's no way to do this currently. The best option might be to add a
 hook that sets the reply body at the beginning of reply-mode. Then you
 could add the attachments (if the mime type were appropriate) and do
 whatever other transformations you wanted on the message.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Mon Aug 24 21:03:29 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 24 Aug 2009 21:03:29 -0400
 Subject: [sup-talk] [PATCH 2/2] xapian index format versioning
 In-Reply-To: <1251117610-sup-9144@peray>
 References: <1250451331-16070-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250451331-16070-2-git-send-email-rlane@club.cc.cmu.edu>
 	<20090816200116.GA17272@chistera.yi.org>
 	<1250453934-sup-9651@zyrg.net>
 	<1250951723-sup-3859@masanjin.net> <1251117610-sup-9144@peray>
 Message-ID: <1251161843-sup-2990@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Mon Aug 24 08:41:03 -0400 2009:
 > Excerpts from William Morgan's message of Sat Aug 22 16:35:37 +0200 2009:
 > > Branch xapian-updates, merged into next. Thanks!
 > 
 > What is the updating procedure please ?
 > 
 
 sup-dump and sup-sync. Sorry for the inconvenience, but I don't
 currently have plans to break compatibility again so you should be safe
 for a while.
 
 From nicolas.pouillard@gmail.com  Tue Aug 25 03:44:11 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 25 Aug 2009 09:44:11 +0200
 Subject: [sup-talk] In next: thread-view-mode labelling No method join
 	for Set
 In-Reply-To: <1251137007-sup-3974@masanjin.net>
 References: <1250714501-sup-3033@chigamba>
 	<1250727630-sup-3112@yoom.home.cworth.org>
 	<1251137007-sup-3974@masanjin.net>
 Message-ID: <1251185965-sup-6316@peray>
 
 Excerpts from William Morgan's message of Mon Aug 24 20:13:43 +0200 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > > I've attached a patch that at least makes the crashes I was able ro
 > > reproduce go away.
 > 
 > Applied, thanks!
 > 
 > > [*] Totally off-topic: This is one of the things about "dynamically
 > > typed" languages that I've never been able to wrap my brain around. I
 > > really like that with static typing I can trust the compiler to help
 > > me be very thorough if I make a type change like this, (and catch all
 > > the cases before shipping any code). Instead, here, there's a hard
 > > task of exercising every possible code path (at run time) before we
 > > know if there are any type errors still lingering. I've seen some
 > > proponents of dynamically-typed languages argue that unit testing
 > > should provide the same coverage that a statically-typed compiler
 > > would, but I haven't seen that in practice.
 
 [...]
 
 > I do believe that if I were using a statically-typed
 > language, development would be significantly slower, and Sup would be
 > nowhere near the point it is now. I have no proof of this statement, of
 > course.
 
 I don't really want to start troll on this subject... However it depends
 on what kind of statically-typed language to talk about, if you mean Java
 or C++ then I agree with you, the development would be much sloooower.
 Although if we take a language like Haskell (or OCaml, or Scala...) the
 development become really competitive.
 
 Best regards,
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From israel.herraiz@gmail.com  Tue Aug 25 05:29:01 2009
 From: israel.herraiz@gmail.com (Israel Herraiz)
 Date: Tue, 25 Aug 2009 11:29:01 +0200
 Subject: [sup-talk] [PATCH] Add UTF-8 encoding string for ArchLinux systems
 Message-ID: <1251192382-sup-2350@elly>
 
 Hi,
 
 in ArchLinux, UTF-8 encoding is identified by "utf8" instead of
 "UTF-8".
 
 Cheers,
 Israel
 
 ---
  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 068ce6b..f99e1c1 100644
 --- a/lib/sup/util.rb
 +++ b/lib/sup/util.rb
 @@ -177,7 +177,7 @@ class String
    ## nasty multibyte hack for ruby 1.8. if it's utf-8, split into chars using
    ## the utf8 regex and count those. otherwise, use the byte length.
    def display_length
 -    if $encoding == "UTF-8"
 +    if $encoding == "UTF-8" || $encoding == "utf8"
        scan(/./u).size
      else
        size
 -- 
 1.6.4
 
 
 
 From israel.herraiz@gmail.com  Tue Aug 25 05:31:55 2009
 From: israel.herraiz@gmail.com (Israel Herraiz)
 Date: Tue, 25 Aug 2009 11:31:55 +0200
 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post
 	is not present
 Message-ID: <1251192579-sup-1849@elly>
 
 Hi,
 
 I am subscribed to some lists that do not fill the list-post header,
 but have a list-id header. I am not sure how standard-compliant is
 that, but it would nice if Sup could identify those messages as list
 messages.
 
 Cheers,
 Israel
 
 ---
  lib/sup/message.rb |   11 +++++++++--
  1 files changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index 56e66de..67f928c 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -34,7 +34,7 @@ class Message
  
    attr_reader :id, :date, :from, :subj, :refs, :replytos, :to, :source,
                :cc, :bcc, :labels, :attachments, :list_address, :recipient_email, :replyto,
 -              :source_info, :list_subscribe, :list_unsubscribe
 +              :source_info, :list_subscribe, :list_unsubscribe, :list_id
  
    bool_reader :dirty, :source_marked_read, :snippet_contains_encrypted_content
  
 @@ -120,6 +120,13 @@ class Message
        else
          nil
        end
 +     
 +    @list_id =
 +      if header["list-id"]
 +        @list_id = header["list-id"].gsub(/^<|>$/, "")
 +      else
 +        nil
 +      end
  
      @recipient_email = header["envelope-to"] || header["x-original-to"] || header["delivered-to"]
      @source_marked_read = header["status"] == "RO"
 @@ -162,7 +169,7 @@ class Message
    end
  
    def snippet; @snippet || (chunks && @snippet); end
 -  def is_list_message?; !@list_address.nil?; end
 +  def is_list_message?; !@list_address.nil? || !@list_id.nil?; end
    def is_draft?; @source.is_a? DraftLoader; end
    def draft_filename
      raise "not a draft" unless is_draft?
 -- 
 1.6.4
 
 
 From wmorgan-sup@masanjin.net  Tue Aug 25 10:16:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 25 Aug 2009 07:16:44 -0700
 Subject: [sup-talk] lots of branches merged down to  master
 Message-ID: <1251209432-sup-766@masanjin.net>
 
 Just FYI, I've merged the following branches down to master:
 buffer-rolling, run-mailcap-fixes, locking-refactor, logging,
 various-api-tweaks, and ncurses-fixes. If you're running master, you
 should see some fun improvements.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Tue Aug 25 21:50:48 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 25 Aug 2009 21:50:48 -0400
 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a
 	Person
 In-Reply-To: <1251156216-sup-5563@masanjin.net>
 References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1251156216-sup-5563@masanjin.net>
 Message-ID: <1251250991-sup-3593@zyrg.net>
 
 Excerpts from William Morgan's message of Mon Aug 24 19:24:19 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-08-22:
 > > -    mk_person = lambda { |x| Person.new(*x.reverse!) }
 > > +    mk_person = lambda { |x| QuickPerson.new(*x) }
 > 
 > What about lambda { |x| Person.new x[1], x[0] }. Surely that must be
 > even faster?
 
 The slow part is the processing in Person#initialize, which QuickPerson
 overrides. You might also be able to avoid that by moving the
 initialize() code into Person.from_address.
 
 From cworth@cworth.org  Wed Aug 26 16:26:34 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 13:26:34 -0700
 Subject: [sup-talk] 'next' crash: wrong id called on nil
 	(thread.rb:264:in `thread_for')
 In-Reply-To: <1251153912-sup-5105@masanjin.net>
 References: <1250820431-sup-8159@yoom.home.cworth.org>
 	<1251153912-sup-5105@masanjin.net>
 Message-ID: <1251318332-sup-4953@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Mon Aug 24 15:45:37 -0700 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-20:
 > > --- RuntimeError from thread: main
 > > wrong id called on nil
 > 
 > I think this should be fixed in recent nexts. Can you confirm?
 
 I don't think I'll be able to, (since I don't have a good recipe for
 reproducing the bug). But I'll certainly start running rom newer next
 and I'll let you know if I run into any further problems.
 
 Thanks for everything,
 
 -Carl
 -------------- 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/20090826/e9ada9c1/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 17:15:36 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 14:15:36 -0700
 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
 In-Reply-To: <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu>
 References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251318620-sup-3031@yoom.home.cworth.org>
 
 My message here really has nothing to do with Rich's patches
 specifically, (so sorry about that), but his patches happened to
 provide the perfect context for an issue I wanted to bring up. As is
 typical of git-formatted patches, Rich's emails have subject lines
 from his commit messages:
 
     [sup-talk] [PATCH 1/2] preemptively load messages when scrolling
     [sup-talk] [PATCH 2/2] ui responsiveness tweaks
 
 As far as the git commits go, this subject line is one of the most
 essential pieces of metadata to accompany the patch. Yet by default
 sup doesn't display it at all, (requiring keypresses to display the
 header and find the subject line). I think what I would like is for
 sup to display the subject line everytime it changes significantly in
 a thread, (specifically not regarding things like an initial "Re: "
 getting added as significant).
 
 I think I'd be willing to spend an entire line's worth of screen real
 estate for this information---it's quite useful when people do
 meaningful subject changes for sub-threads.
 
 -Carl
 
 Excerpts from Rich Lane's message of Sun Aug 23 11:46:11 -0700 2009:
 > ---
 >  bin/sup                            |    1 +
 >  lib/sup/modes/thread-index-mode.rb |    4 ++--
 >  2 files changed, 3 insertions(+), 2 deletions(-)
 > 
 > diff --git a/bin/sup b/bin/sup
 > index 3d5b6c1..f3c6771 100755
 > --- a/bin/sup
 > +++ b/bin/sup
 > @@ -58,6 +58,7 @@ if $opts[:list_hooks]
 >  end
 >  
 >  Thread.abort_on_exception = true # make debugging possible
 > +Thread.current.priority = 1 # keep ui responsive
 >  
 >  module Redwood
 >  
 > diff --git a/lib/sup/modes/thread-index-mode.rb
 > b/lib/sup/modes/thread-index-mode.rb
 > index fb6b2ce..177431b 100644
 > --- a/lib/sup/modes/thread-index-mode.rb
 > +++ b/lib/sup/modes/thread-index-mode.rb
 > @@ -76,8 +76,7 @@ EOS
 >      @last_load_more_size = nil
 >      to_load_more do |size|
 >        next if @last_load_more_size == 0
 > -      load_threads :num => 1, :background => false
 > -      load_threads :num => (size - 1),
 > +      load_threads :num => size,
 >                     :when_done => lambda { |num| @last_load_more_size = num }
 >      end
 >    end
 > @@ -627,6 +626,7 @@ EOS
 >          BufferManager.draw_screen
 >          last_update = Time.now
 >        end
 > +      ::Thread.pass
 >        break if @interrupt_search
 >      end
 >      @ts.threads.each { |th| th.labels.each { |l| LabelManager << l } }
 -------------- 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/20090826/5b3011d5/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 17:26:18 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 14:26:18 -0700
 Subject: [sup-talk] Exception trying to run git source
 In-Reply-To: <1250964942-sup-8625@masanjin.net>
 References: <1250642676-sup-2244@yoom> <1250698636-sup-6732@masanjin.net>
 	<1250699596-sup-8133@ntdws12.chass.utoronto.ca>
 	<1250704257-sup-3308@yoom> <1250707794-sup-6173@masanjin.net>
 	<1250710221-sup-925@yoom.home.cworth.org>
 	<1250712045-sup-3506@masanjin.net>
 	<1250717434-sup-4489@yoom.home.cworth.org>
 	<1250964942-sup-8625@masanjin.net>
 Message-ID: <1251321606-sup-7393@yoom.home.cworth.org>
 
 Reformatted excerpts from William Morgan's message of Sat Aug 22 13:23:17 -0700 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > > $:.unshift File.dirname(__FILE__)     # For use/testing when no gem is installed
 > 
 > I'd call that a bug in chronic. It shouldn't be screwing with the load
 > path.
 
 That's what I thought too. I filed a Debian bug against the
 libchronic-ruby package here:
 
     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542491
 
 But I reall only did that because I didn't find any contact
 information for how to submit an upstream bug against chronic
 (http://chronic.rubyforge.net didn't have any details that I could
 find).
 
 So if someone knows a better place to file the bug, I'd be glad to do
 that.
 
 > Nice debug work.
 
 Thanks.
 
 -Carl
 -------------- 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/20090826/41bd963c/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 17:35:25 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 14:35:25 -0700
 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
 In-Reply-To: <1250972634-sup-6871@masanjin.net>
 References: <1250745799-sup-6607@yoom.home.cworth.org>
 	<1250972634-sup-6871@masanjin.net>
 Message-ID: <1251322427-sup-9184@yoom.home.cworth.org>
 
 The idea here is that if someone is looking at the log and not seeing
 the information of interest, then the log itself should tell them
 how to get more information, (by suggesting to set SUP_LOG_LEVEL
 to the next lower level).
 ---
 
 Excerpts from William Morgan's message of Sat Aug 22 13:25:22 -0700 2009:
 > It all looks good except you can use Logger::LEVELS to access the
 > constants. Then there's no need to write a LEVELS method. If you fix
 > that I will apply. Thanks!
 
 Thanks. I had the distinct feeling I was doing something wrong
 there. Here's a corrected version.
 
 -Carl
 
  bin/sup |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 3d5b6c1..cdf1ff2 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -169,6 +169,9 @@ begin
    lmode.on_kill { Logger.clear! }
    Logger.add_sink lmode
    Logger.force_message "Welcome to Sup! Log level is set to #{Logger.level}."
 +  if Logger::LEVELS.index(Logger.level) > 0
 +    Logger.force_message "For more verbose logging, restart with SUP_LOG_LEVEL=#{Logger::LEVELS[Logger::LEVELS.index(Logger.level)-1]}."
 +  end
  
    debug "initializing inbox buffer"
    imode = InboxMode.new
 -- 
 1.6.3.3
 
 -------------- 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/20090826/3686da0d/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 17:53:32 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 14:53:32 -0700
 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the
 	left column
 In-Reply-To: <1251050007-sup-9740@masanjin.net>
 References: <1250749447-sup-1744@yoom.home.cworth.org>
 	<1251050007-sup-9740@masanjin.net>
 Message-ID: <1251323127-sup-5162@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Sun Aug 23 10:55:59 -0700 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-19:
 > > Specifically, scroll as little as possible to get the current message
 > > to just fit on the right side.
 > 
 > Is this the same as setting loose_alignment to true, and the
 > IDEAL_*_CONTENTs to 0?
 
 I don't think so.
 
 Doing that, (at least as in the below patch, for example), always puts
 the current message flush left. And that can result in later messages
 in the threads, (not descendants of the current thread though), being
 cut off on the left. (And all this with dozens of empty columns on the
 right of my terminal.) That's precisely the behavior I was getting
 before my patch and which I'm trying to change.
 
 What I want instead is for the message to appear in its "natural"
 position (according to the threading), unless that would cause the
 message to be cut off on the right. In which case, we jump to the
 minimum column such that:
 
 	1. We don't cut any of the current message off on the left
 
 	2. We display all of the message on the right, (if possible
 	   without violating point 1).
 
 I believe that what I've coded achieves that. The two open questions I
 still have are:
 
 	A. Is there some simpler way to achieve the result I want with
 	   some of the existing code?
 
 	B. If not, is some of the existing code rendered obsolete with
 	   my code in place?
 
 As for (B), for example, with my code in place I don't think there's
 any need for a notion of "ideal context". The ideal context is the
 natural position of the thread.
 
 And I still haven't figured out what loose_alignment means and which
 actions will cause loose vs. non-loose layout.
 
 -Carl
 
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index dfe30ff..b7bbc7c 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -401,9 +401,9 @@ EOS
      end
    end
  
 -  IDEAL_TOP_CONTEXT = 3 # try and give 3 rows of top context
 -  IDEAL_LEFT_CONTEXT = 4 # try and give 4 columns of left context
 -  def jump_to_message m, loose_alignment=false
 +  IDEAL_TOP_CONTEXT = 0 # don't bother trying to give any rows of top context
 +  IDEAL_LEFT_CONTEXT = 0 # don't bother trying to give any columns of left context
 +  def jump_to_message m, loose_alignment=true
      l = @layout[m]
      left = l.depth * INDENT_SPACES
      right = left + l.width
 -------------- 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/20090826/8c5c013c/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 18:24:36 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 15:24:36 -0700
 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar
 Message-ID: <1251323747-sup-1595@yoom.home.cworth.org>
 
 [Argh! I ended up getting really verbose again with this one. Thanks
 to anyone patient enough to wade through all of this. There is a patch
 here for one issue at least. See below.]
 
 I spent about 4 days away from email which gave me my first case of a
 large inbox after switching to sup. And there are definitely a few
 things I'd like to convince sup to do to make it easier for me to deal
 with this.
 
 Most important, with a large inbox, my mail falls into different
 "classes", some of which are more important than others, and I'd like
 to deal with the most important things first. I also often want to
 deal with a single "class" of mail as a whole to avoid mental context
 switches.
 
 Fortunately, I've got sup labels capturing these classes quite
 well. I've got some future ideas for having a prioritized (partial
 order) list of labels so that inbox-mode will present messages
 according to that priority. But for now, it would be good enough to be
 able to easily filter my inbox down to just a single class of messages
 at a time.
 
 To this end, I started using the patch below, which adds a
 refine_search keybinding to inbox-mode much like the same function in
 search-result-mode. This is useful already and might be considered for
 inclusion as is, (another feature I'd like for both modes is "restrict
 to label" which would act like refine-search but save me from having
 to type "label:" much like the 'L' command avoids having to type
 "label:" compared to the 'F' command).
 
 Beyond this patch as is, though, I'd like to talk a bit about how to
 better achieve what I want. There's obviously some code duplication in
 this patch which is not ideal. It would be better if InboxMode could
 be a derived class from SearchResultsMode. Not only would this reduce
 code-duplication, but there are features currently in InboxMode that I
 think belong in all searches.
 
 For example, if I use the refine_search command below to get a view of
 my inbox restricted to a particular label, it no longer acts like my
 inbox does. One of the most noticeable cases is the archive
 command[*].  In both inbox-mode and search-result-mode this command
 removes the "inbox" label from a thread, but in inbox-mode the thread
 is immediately removed from the results, while in search-results-mode
 the thread remains in the results.
 
 One annoying side effect of this is that when I'm reading and
 archiving many threads in some class, then I happen to reply to one
 thread, that thread gets bumped to the top of my search so when I
 navigate to the "next" thread I start cycling through threads that I
 just got finished reading and archiving. To fix this I end up having
 to notice I'm seeing repeated messages, remember why, then save my
 current changes and refresh the search. And I have to do this after
 every reply.
 
 [Note: Even if archiving messages made them immediately disappear from
 my search results, there could still be problems with "next" causing
 me to re-cycle through messages I had already read but decided to
 leave in my inbox. I think this is just another general race-condition
 bug. I think the fix would be for the transition from
 search-results-mode to thread-view-mode to somehow snapshot the
 current search results so that future modifications due to newly
 arriving messages don't modify the meaning of "next thread" within
 thread-view-mode.]
 
 So what I want is for anytime a message is changed such that it no
 longer meets the current search criteria, it is immediately removed
 from the search results. I think that means simply implementing the
 is_relevant? method for SearcResultsMode where there is currently just
 the following comment:
 
   ## a proper is_relevant? method requires some way of asking ferret
   ## if an in-memory object satisfies a query. i'm not sure how to do
   ## that yet. in the worst case i can make an in-memory index, add
   ## the message, and search against it to see if i have > 0 results,
   ## but that seems pretty insane.
 
 That single-message index and search sounds exactly like what I want,
 and not insane at all. Has someone attempted this and found a
 performance issue? (In which case, I would think we just need to fix
 that performance bug.) Or is it simply a matter of nobody having tried
 to code this up yet? (In which case, I'll try, and I'll be glad for
 any pointers that anyone can give me on how to go about creating an
 in-memory index and searching on it.)
 
 Thanks,
 
 -Carl
 
 [*] I'll ignore for now the fact that 'a' is a toggle of the inbox
 label in SearchResultsMode and a one-way removal of the label in
 InboxMode. I haven't found any need to ever put a thread _back_ into
 the inbox, (except perhaps in the case of accidental archiving, and
 there an immediate undo works fine). So I would imagine the use is
 rare enough to not need a single-character command. The command I
 would find natural for putting a thread back into the inbox would be
 to simply add the inbox label to the thread. Oddly this is currently
 not allowed as "inbox" is a reserved label. I don't
 
 
 >From d37eca31aaddee80f05357d6a4ed896f39bbad16 Mon Sep 17 00:00:00 2001
 From: Carl Worth <cworth at cworth.org>
 Date: Wed, 26 Aug 2009 10:17:20 -0700
 Subject: [PATCH] Add a refine_search command to InboxMode
 
 This is just a copy of SearchResultsMode's refine_search command.
 A much cleaner, but more involved, approach would be to rework
 InboxMode to derive from SearchResultsMode in the first place.
 ---
  lib/sup/modes/inbox-mode.rb |    7 +++++++
  1 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/inbox-mode.rb b/lib/sup/modes/inbox-mode.rb
 index ba095da..c8072cd 100644
 --- a/lib/sup/modes/inbox-mode.rb
 +++ b/lib/sup/modes/inbox-mode.rb
 @@ -7,6 +7,7 @@ class InboxMode < ThreadIndexMode
      ## overwrite toggle_archived with archive
      k.add :archive, "Archive thread (remove from inbox)", 'a'
      k.add :read_and_archive, "Archive thread (remove from inbox) and mark read", 'A'
 +    k.add :refine_search, "Refine search", '|'
    end
  
    def initialize
 @@ -17,6 +18,12 @@ class InboxMode < ThreadIndexMode
  
    def is_relevant? m; (m.labels & [:spam, :deleted, :killed, :inbox]) == Set.new([:inbox]) end
  
 +  def refine_search
 +    text = BufferManager.ask :search, "refine query: ", "label:inbox -label:spam -label:deleted -label:killed "
 +    return unless text && text !~ /^\s*$/
 +    SearchResultsMode.spawn_from_query text
 +  end
 +
    ## label-list-mode wants to be able to raise us if the user selects
    ## the "inbox" label, so we need to keep our singletonness around
    def self.instance; @@instance; end
 -- 
 1.6.3.3
 
 -------------- 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/20090826/0ec68a3f/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 18:40:34 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 15:40:34 -0700
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode
 	to archive/delete current thread
 Message-ID: <1251325542-sup-3105@yoom.home.cworth.org>
 
 These behave identically to the existing ",a" and ",d" commands, (that
 is they archive or delete the current thread and then view the next).
 ---
 
 I appreciate that within thread-view-mode, sup already supports
 explicitly selecting one of three different actions for what do after
 the user is done with a thread. And the choice is determined by one of
 three different prefix characters. For example:
 
     . -> return to previous buffer (likely something like
          inbox-mode/search-result-mode)
     , -> advance to next thread (into thread-view-mode)
     ] -> advance to previous thread (into thread-view-mode)
 
 I'm lazy enough to want a single-character command for efficient
 processing of mail in thread-view-mode, (just like I already have
 while in inbox-mode and search-results-mode). And for two of the
 different actions, (archive and delete), the obvious/consistent
 keybinding is available. So this patch assigns those, ('a' as a
 shortcut for ',a' and 'd' as a shortcut for ',d').
 
 If I seem too lazy here, and it doesn't seem sane to add these
 keybindingd by default, just let me know. In that case I'll consign
 myself to just using a hook to setup these keybindings for myself
 personally.
 
 The perhaps-not-as-obvious piece is what the exit action should be for
 these shortcut commands. For my own use, I've found it best to advance
 to the next thread. (This supports a workflow where there's one pass
 through the inbox to archive as much as possible without reading, and
 then another pass through thread-view-mode for everything that's
 left.)
 
 One thing this patch doesn't provide is shortcuts for the other three
 exit actions, (',s' for mark-as-spam-then-next, ',N' for
 mark-as-unread-then-next, and ',n' for simply advancing to the next
 thread without changing the current thread).
 
 Of those, the only one I really care about personally is ',n'. It's
 obviously not a simple matter of just making 'n' a shortcut for ',n'
 since the 'n' keybinding is already used. But actually, I think I
 would like the 'n' keybinding to advance to the next thread once I'm
 viewing the last open message in the current thread. This would make
 for very efficient sessions of just reading mail, where I'd only need
 to keep hitting 'n', (and I could hit 'a' whenever bored with any
 particular thread). So perhaps I'll look into coding that up next.
 
  lib/sup/modes/thread-view-mode.rb |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 678b841..0706757 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -64,6 +64,9 @@ EOS
      k.add :unsubscribe_from_list, "Subscribe to/unsubscribe from mailing list", ")"
      k.add :pipe_message, "Pipe message or attachment to a shell command", '|'
  
 +    k.add :archive_and_next, "Archive this thread, kill buffer, and view next", 'a'
 +    k.add :delete_and_next, "Delete this thread, kill buffer, and view next", 'd'
 +
      k.add_multi "(a)rchive/(d)elete/mark as (s)pam/mark as u(N)read:", '.' do |kk|
        kk.add :archive_and_kill, "Archive this thread and kill buffer", 'a'
        kk.add :delete_and_kill, "Delete this thread and kill buffer", 'd'
 -- 
 1.6.3.3
 -------------- 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/20090826/ac261bb3/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 18:47:54 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 15:47:54 -0700
 Subject: [sup-talk] Should '/' trigger the loading of more messages?
 Message-ID: <1251326494-sup-2328@yoom.home.cworth.org>
 
 It seems to me that the "search in current buffer" command should
 automatically trigger the loading of additional messages when no
 results are found so that it can continue searching.
 
 What just happened to me is that I *knew* my inbox contained a message
 with a particular string in the subject, but I couldn't find it with
 '/'. The problem was that enough new threads had arrived that the
 message of interest wasn't loaded yet.
 
 The fact that the various ThreadIndexModes don't load all relevant
 threads is just an optimization, but I don't think it should change
 the semantics of a search operation. (My thread *is* still in my inbox
 even if it hasn't been loaded.)
 
 Of course, for the feature I want to work well there needs to be an
 easy way to interrupt the searching and loading if it's going on too
 long, (say, I mistyped the search string and I know it's likely to
 load a million messages without ever finding the string I typed).
 
 Does sup already have a notion like emacs' "C-g" which is used to
 cancel or interrupt any ongoing command?
 
 -Carl
 -------------- 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/20090826/5445e913/attachment.bin>
 
 From cworth@cworth.org  Wed Aug 26 18:52:38 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 26 Aug 2009 15:52:38 -0700
 Subject: [sup-talk] On making inbox-mode and search-results-mode more
 	similar
 In-Reply-To: <1251323747-sup-1595@yoom.home.cworth.org>
 References: <1251323747-sup-1595@yoom.home.cworth.org>
 Message-ID: <1251327030-sup-7342@yoom.home.cworth.org>
 
 Excerpts from Carl Worth's message of Wed Aug 26 15:24:36 -0700 2009:
 > +    text = BufferManager.ask :search, "refine query: ", "label:inbox
 > -label:spam -label:deleted -label:killed "
 
 Is that even the right syntax for searching for threads with the inbox
 label but excluding threades with the spam, deleted, or killed labels?
 
 I took a guess at the syntax and I thought I saw it working, but it
 doesn't appear to be now. Can someone tell me the actual syntax? (Or
 better, is there a writeup somewhere of the general search syntax
 accepted by sup?)
 
 -Carl
 -------------- 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/20090826/c0c5ef5d/attachment.bin>
 
 From ingmar@exherbo.org  Wed Aug 26 22:37:57 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Thu, 27 Aug 2009 04:37:57 +0200
 Subject: [sup-talk] Should '/' trigger the loading of more messages?
 In-Reply-To: <1251326494-sup-2328@yoom.home.cworth.org>
 References: <1251326494-sup-2328@yoom.home.cworth.org>
 Message-ID: <1251340454-sup-3773@cannonball>
 
 Excerpts from Carl Worth's message of Thu Aug 27 00:47:54 +0200 2009:
 > It seems to me that the "search in current buffer" command should
 > automatically trigger the loading of additional messages when no
 > results are found so that it can continue searching.
 
 I'd expect a "search in current buffer" to do exactly that, no more no
 less.
 
 > What just happened to me is that I *knew* my inbox contained a message
 > with a particular string in the subject, but I couldn't find it with
 > '/'. The problem was that enough new threads had arrived that the
 > message of interest wasn't loaded yet.
 
 If you know it's in your inbox, why not search with '\', for
 'label:inbox foo'?
 
 > The fact that the various ThreadIndexModes don't load all relevant
 > threads is just an optimization, but I don't think it should change
 > the semantics of a search operation. (My thread *is* still in my inbox
 > even if it hasn't been loaded.)
 > 
 > Of course, for the feature I want to work well there needs to be an
 > easy way to interrupt the searching and loading if it's going on too
 > long, (say, I mistyped the search string and I know it's likely to
 > load a million messages without ever finding the string I typed).
 > 
 > Does sup already have a notion like emacs' "C-g" which is used to
 > cancel or interrupt any ongoing command?
 
 Try C-g. :-)
 (Documented as ^G on the help page)
 
 > -Carl
 -- 
 Exherbo KDE, X.org maintainer
 
 From ingmar@exherbo.org  Wed Aug 26 22:54:36 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Thu, 27 Aug 2009 04:54:36 +0200
 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks
 In-Reply-To: <1251318620-sup-3031@yoom.home.cworth.org>
 References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1251318620-sup-3031@yoom.home.cworth.org>
 Message-ID: <1251341498-sup-428@cannonball>
 
 Excerpts from Carl Worth's message of Wed Aug 26 23:15:36 +0200 2009:
 > My message here really has nothing to do with Rich's patches
 > specifically, (so sorry about that), but his patches happened to
 > provide the perfect context for an issue I wanted to bring up. As is
 > typical of git-formatted patches, Rich's emails have subject lines
 > from his commit messages:
 > 
 >     [sup-talk] [PATCH 1/2] preemptively load messages when scrolling
 >     [sup-talk] [PATCH 2/2] ui responsiveness tweaks
 > 
 > As far as the git commits go, this subject line is one of the most
 > essential pieces of metadata to accompany the patch. Yet by default
 > sup doesn't display it at all, (requiring keypresses to display the
 > header and find the subject line). I think what I would like is for
 > sup to display the subject line everytime it changes significantly in
 > a thread, (specifically not regarding things like an initial "Re: "
 > getting added as significant).
 > 
 > I think I'd be willing to spend an entire line's worth of screen real
 > estate for this information---it's quite useful when people do
 > meaningful subject changes for sub-threads.
 
 Yeah, I completely agree. That would make sup even better for me.
 
 Maybe this could be implemented as a 3-way toggle, toggling between
   - don't show subjects (current default?)
   - only show interesting subject changes
   - always show subject
 in a threadview.
 
 -Ingmar
 -- 
 Exherbo KDE, X.org maintainer
 
 From rlane@club.cc.cmu.edu  Thu Aug 27 02:50:29 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 27 Aug 2009 02:50:29 -0400
 Subject: [sup-talk] On making inbox-mode and search-results-mode more
 	similar
 In-Reply-To: <1251323747-sup-1595@yoom.home.cworth.org>
 References: <1251323747-sup-1595@yoom.home.cworth.org>
 Message-ID: <1251341286-sup-9400@zyrg.net>
 
 Excerpts from Carl Worth's message of Wed Aug 26 18:24:36 -0400 2009:
 > So what I want is for anytime a message is changed such that it no
 > longer meets the current search criteria, it is immediately removed
 > from the search results. I think that means simply implementing the
 > is_relevant? method for SearcResultsMode where there is currently just
 > the following comment:
 > 
 >   ## a proper is_relevant? method requires some way of asking ferret
 >   ## if an in-memory object satisfies a query. i'm not sure how to do
 >   ## that yet. in the worst case i can make an in-memory index, add
 >   ## the message, and search against it to see if i have > 0 results,
 >   ## but that seems pretty insane.
 > 
 > That single-message index and search sounds exactly like what I want,
 > and not insane at all. Has someone attempted this and found a
 > performance issue? (In which case, I would think we just need to fix
 > that performance bug.) Or is it simply a matter of nobody having tried
 > to code this up yet? (In which case, I'll try, and I'll be glad for
 > any pointers that anyone can give me on how to go about creating an
 > in-memory index and searching on it.)
 
 We had a thread a while back about applying label changes immediately
 and I think the consensus was that that's a good idea. Doing this could
 simplify a great deal of thread-index-mode code because a fast
 is_relevant? could be implemented using existing index operations
 without the special cases for archiving/etc and without creating an
 inmemory database. I have a patch I plan to mail out soon that makes
 changing labels with Xapian much quicker, so that should help. It'd be
 great if you decide to tackle this.
 
 From marcus-sup@bar-coded.net  Thu Aug 27 05:05:13 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 27 Aug 2009 10:05:13 +0100
 Subject: [sup-talk] Should '/' trigger the loading of more messages?
 In-Reply-To: <1251340454-sup-3773@cannonball>
 References: <1251326494-sup-2328@yoom.home.cworth.org>
 	<1251340454-sup-3773@cannonball>
 Message-ID: <1251363903-sup-2197@bar-coded.net>
 
 On 27.8.2009, Ingmar Vanhassel wrote:
 > > What just happened to me is that I *knew* my inbox contained a message
 > > with a particular string in the subject, but I couldn't find it with
 > > '/'. The problem was that enough new threads had arrived that the
 > > message of interest wasn't loaded yet.
 > 
 > If you know it's in your inbox, why not search with '\', for
 > 'label:inbox foo'?
 
 ... coupled with '!!' to load all threads in the search (ctrl-g works
 to stop search) this would do what you want.
 
 HTH
 
 Marcus
 
 From cworth@cworth.org  Thu Aug 27 08:17:12 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 27 Aug 2009 05:17:12 -0700
 Subject: [sup-talk] Should '/' trigger the loading of more messages?
 In-Reply-To: <1251340454-sup-3773@cannonball>
 References: <1251326494-sup-2328@yoom.home.cworth.org>
 	<1251340454-sup-3773@cannonball>
 Message-ID: <1251375048-sup-403@yoom.home.cworth.org>
 
 Excerpts from Ingmar Vanhassel's message of Wed Aug 26 19:37:57 -0700 2009:
 > Excerpts from Carl Worth's message of Thu Aug 27 00:47:54 +0200 2009:
 > > It seems to me that the "search in current buffer" command should
 > > automatically trigger the loading of additional messages when no
 > > results are found so that it can continue searching.
 > 
 > I'd expect a "search in current buffer" to do exactly that, no more no
 > less.
 
 You obviously know well what the current buffer is doing,
 (incrementally loading threads only as you page down to them). But I
 don't think it's reasonable to expect all users to understand things
 that well in order to use sup correctly.
 
 Imagine the near future where we get the thread-loading performance
 bugs all worked out, (see nearby threads making good progress). If a
 user starts sup and sees a screenful of threads instantly, hits page
 down a couple of times and sees another couple of screensful
 instantly, then wouldn't it be reasonable for such a user to expect
 that all of that instantly-appearing content does exist in the current
 buffer?
 
 > If you know it's in your inbox, why not search with '\', for
 > 'label:inbox foo'?
 
 I'm searching locally, because I already performed a global search and
 don't want to repeat the terms of it. Or else why does sup have a
 local search command independent of the global search?
 
 > Try C-g. :-)
 > (Documented as ^G on the help page)
 
 Ah, thanks. Now this one was just me being stupid. (I think I was
 already using this in sup naturally.)
 
 -Carl
 -------------- 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/20090827/cb5aaa58/attachment.bin>
 
 From guillaume.quintard@gmail.com  Thu Aug 27 08:18:53 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Thu, 27 Aug 2009 14:18:53 +0200
 Subject: [sup-talk] Nobody told me
 Message-ID: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com>
 
 Playing the dumb newbie here, but when did that happened?
 
 ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects
 a v1 index, but you have an existing v0 index. Please downgrade to
 your previous version and dump your labels before upgrading to this
 version (then run sup-sync --restore). (RuntimeError)
         from ./lib/sup/index.rb:67:in `load'
         from bin/sup-sync:117
 
 -- 
 Guillaume
 
 From ezyang@MIT.EDU  Thu Aug 27 11:36:28 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 27 Aug 2009 11:36:28 -0400
 Subject: [sup-talk] Ignore killed messages in U screen
 Message-ID: <1251387376-sup-7180@javelin>
 
 >From e01820e5914c4fb8deb5836473aa37553e5a6234 Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <ezyang at mit.edu>
 Date: Wed, 26 Aug 2009 10:45:26 -0400
 Subject: [PATCH] Do not display killed messages in unread screen.
 
 Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
 ---
  bin/sup |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index bbb6c17..645a9a1 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -263,7 +263,7 @@ begin
        next unless query && query !~ /^\s*$/
        SearchResultsMode.spawn_from_query query
      when :search_unread
 -      SearchResultsMode.spawn_from_query "is:unread"
 +      SearchResultsMode.spawn_from_query "is:unread !label:killed"
      when :list_labels
        labels = LabelManager.all_labels.map { |l| LabelManager.string_for l }
        user_label = bm.ask_with_completions :label, "Show threads with label (enter for listing): ", labels
 -- 
 1.6.4
 
 From bwalton@artsci.utoronto.ca  Thu Aug 27 11:50:08 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 27 Aug 2009 11:50:08 -0400
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1251387376-sup-7180@javelin>
 References: <1251387376-sup-7180@javelin>
 Message-ID: <1251388133-sup-2253@ntdws12.chass.utoronto.ca>
 
 Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
 > Subject: [PATCH] Do not display killed messages in unread screen.
 
 +1 for this.
 -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/20090827/95eba3ab/attachment.bin>
 
 From ezyang@MIT.EDU  Thu Aug 27 11:56:32 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 27 Aug 2009 11:56:32 -0400
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1251387376-sup-7180@javelin>
 References: <1251387376-sup-7180@javelin>
 Message-ID: <1251388546-sup-7744@javelin>
 
 Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009:
 > -      SearchResultsMode.spawn_from_query "is:unread"
 > +      SearchResultsMode.spawn_from_query "is:unread !label:killed"
 
 I might have one legitimate objection to this patch, which is
 that searches should ignore killed tags unless explicitly told
 not to.
 
 Cheers,
 Edward
 
 From joe@joeshaw.org  Thu Aug 27 15:44:02 2009
 From: joe@joeshaw.org (Joe Shaw)
 Date: Thu, 27 Aug 2009 15:44:02 -0400
 Subject: [sup-talk] sent and draft sources
 Message-ID: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 
 Hi,
 
 I'd like to use existing maildir folders I have for Sup's sent and
 draft folders, but I couldn't find a way how.  Is this possible?  I am
 surprised this is not a FAQ. :)
 
 Apologies for the total noob question.  I'm liking what I see in Sup so far.
 
 Thanks,
 Joe
 
 From bwalton@artsci.utoronto.ca  Thu Aug 27 15:49:17 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 27 Aug 2009 15:49:17 -0400
 Subject: [sup-talk] sent and draft sources
 In-Reply-To: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 References: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 Message-ID: <1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 
 Excerpts from Joe Shaw's message of Thu Aug 27 15:44:02 -0400 2009:
 > I'd like to use existing maildir folders I have for Sup's sent and
 > draft folders, but I couldn't find a way how.  Is this possible?  I am
 > surprised this is not a FAQ. :)
 
 For sent, yes.  For drafts, not yet.  Using sup-config you can select
 the sent source, or you could edit config.yaml by hand.  The line in
 my config is this:
 
 :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/
 
 I defined a source with that URI and then set the value in
 config.yaml.  My outbound mail is then stored in that Maildir folder.
 Only some sources work for mail storage.  These are mbox, Maildir and
 IMAP.  I'd advise against having anything else write to the same mbox
 (eg: don't have new mail delivered to the same source) if you go with
 an mbox URI.
 
 I'm not sure whether the official release includes this functionality
 yet or not as I run from git:next.  I _think_ 0.8.1 included it, but
 would have to actually check.
 
 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/20090827/f78fafa2/attachment.bin>
 
 From joe@joeshaw.org  Thu Aug 27 15:58:29 2009
 From: joe@joeshaw.org (Joe Shaw)
 Date: Thu, 27 Aug 2009 15:58:29 -0400
 Subject: [sup-talk] sent and draft sources
 In-Reply-To: <1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 References: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 	<1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 Message-ID: <f8203010908271258m32cbaacfked4ec80969ce3034@mail.gmail.com>
 
 Hi,
 
 Thanks for the info.
 
 On Thu, Aug 27, 2009 at 3:49 PM, Ben Walton<bwalton at artsci.utoronto.ca> wrote:
 > I'm not sure whether the official release includes this functionality
 > yet or not as I run from git:next. ?I _think_ 0.8.1 included it, but
 > would have to actually check.
 
 It doesn't appear to.  At least, setting sup-config didn't give me any
 option to, and setting it in my config.yaml didn't seem to work
 either.
 
 How safe is building and running from git master?  Is there a general
 philosophy about its stability?  I'm a hacker, but I'm not strong in
 Ruby and I am not sure yet that I want to hack on my mailer. ;)
 
 Joe
 
 From sean.escriva@gmail.com  Thu Aug 27 16:03:17 2009
 From: sean.escriva@gmail.com (Sean Escriva)
 Date: Thu, 27 Aug 2009 13:03:17 -0700
 Subject: [sup-talk] sup crashed: NoMethodError
 Message-ID: <20090827200317.GA3065@gmail.com>
 
 I broke my sup!
 
 I wanted to play with the git version so I did: 
 
     git pull, rake gem, gem install pkg/sup-999.gem
 
 well that broke it all, and I don't know how to fix it.
 
 so far I have tried a gem cleanup, gem uninstall sup, gem install -r
 sup, all to no avail. It still always crashes with the following:
 
 --- NoMethodError from thread: main
 undefined method `[]' for false:FalseClass
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 Any tips on how to fix/figure out what I did wrong are greatly
 appreciated!
 
 -sme
 
 From dato@net.com.org.es  Thu Aug 27 16:00:53 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Thu, 27 Aug 2009 21:00:53 +0100
 Subject: [sup-talk] sent and draft sources
 In-Reply-To: <1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 References: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 	<1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 Message-ID: <20090827200053.GA17416@chistera.yi.org>
 
 + Ben Walton (Thu, 27 Aug 2009 15:49:17 -0400):
 
 > For sent, yes.  For drafts, not yet.  Using sup-config you can select
 > the sent source, or you could edit config.yaml by hand.  The line in
 > my config is this:
 
 > :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/
 
 I tried that, but then all messages got tagged "sent", even old ones and
 threads in which I didn't participate.
 
 > I'd advise against having anything else write to the same mbox
 > (eg: don't have new mail delivered to the same source) if you go with
 > an mbox URI.
 
 Why? Would sup not lock the mbox properly?
 
 Thanks,
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From bwalton@artsci.utoronto.ca  Thu Aug 27 19:39:20 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 27 Aug 2009 19:39:20 -0400
 Subject: [sup-talk] sent and draft sources
 In-Reply-To: <20090827200053.GA17416@chistera.yi.org>
 References: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 	<1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 	<20090827200053.GA17416@chistera.yi.org>
 Message-ID: <1251416206-sup-4808@ntdws12.chass.utoronto.ca>
 
 Excerpts from Adeodato Sim?'s message of Thu Aug 27 16:00:53 -0400 2009:
 > > I'd advise against having anything else write to the same mbox
 > > (eg: don't have new mail delivered to the same source) if you go with
 > > an mbox URI.
 > 
 > Why? Would sup not lock the mbox properly?
 
 No, it wouldn't.  I've got a half-baked LockManager branch sitting
 around, but I haven't touched it for some time now.  I don't use any
 mbox here myself so it's not a personal itch.
 
 As it stands, the LockManager code has the basic ability to do
 locking using three lock types.  I haven't worked out the nicest way
 to stack them (ala dovecot) though in a way that will play nicely with
 threads _and_ allow for non-block-wrapped calling.
 
 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/20090827/28664d43/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Thu Aug 27 20:43:56 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 27 Aug 2009 20:43:56 -0400
 Subject: [sup-talk] sent and draft sources
 In-Reply-To: <20090827200053.GA17416@chistera.yi.org>
 References: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 	<1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 	<20090827200053.GA17416@chistera.yi.org>
 Message-ID: <1251420193-sup-4823@ntdws12.chass.utoronto.ca>
 
 Excerpts from Adeodato Sim?'s message of Thu Aug 27 16:00:53 -0400 2009:
 
 > > :sent_source: maildir:///u/bwalton/Maildir/.sent-mail/
 > 
 > I tried that, but then all messages got tagged "sent", even old ones and
 > threads in which I didn't participate.
 
 This is interesting.  It might have happened to me too, but since all
 of the mail in that folder was historically sent, I either didn't
 notice (since it was already archived) or this is a new issue.
 
 -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/20090827/312b5433/attachment.bin>
 
 From jim@gonzul.net  Thu Aug 27 22:37:48 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Fri, 28 Aug 2009 14:37:48 +1200
 Subject: [sup-talk] Encrypted password in configuration file
 In-Reply-To: <20090824215435.182e0007@ronin.larsko.net>
 References: <20090824215435.182e0007@ronin.larsko.net>
 Message-ID: <f4cc59760908271937t764e61aeh7f105c7195fec1ce@mail.gmail.com>
 
 On Tue, Aug 25, 2009 at 8:54 AM, Lars Kotthoff<lists at larsko.org> wrote:
 > Hi list,
 >
 > ?is it possible to store the account password encrypted in the configuration
 > file?
 
 It's possible, but slightly pointless.
 
 Have a read of Eric Raymond's discussions about Fetchmail, which has
 the same configuration data :-
 http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s09.html
 
 "Another lesson is about security by obscurity. Some fetchmail users
 asked me to change the software to store passwords encrypted in the rc
 file, so snoopers wouldn't be able to casually see them.
 
 I didn't do it, because this doesn't actually add protection. Anyone
 who's acquired permissions to read your rc file will be able to run
 fetchmail as you anyway?and if it's your password they're after,
 they'd be able to rip the necessary decoder out of the fetchmail code
 itself to get it.
 
 All .fetchmailrc password encryption would have done is give a false
 sense of security to people who don't think very hard. The general
 rule here is:
 
     17. A security system is only as secure as its secret. Beware of
 pseudo-secrets."
 
 -jim
 
 From jim@gonzul.net  Fri Aug 28 03:07:02 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Fri, 28 Aug 2009 19:07:02 +1200
 Subject: [sup-talk] Encrypted password in configuration file
 In-Reply-To: <20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu>
 References: <20090824215435.182e0007@ronin.larsko.net>
 	<f4cc59760908271937t764e61aeh7f105c7195fec1ce@mail.gmail.com> 
 	<20090828012502.15484x8musndy5mo@webmail.seas.upenn.edu>
 Message-ID: <f4cc59760908280007i3b226f0egd063126476e6ea3d@mail.gmail.com>
 
 On Fri, Aug 28, 2009 at 5:25 PM, <wagnerdm at seas.upenn.edu> wrote:
 > I can imagine all kinds of situations with "benevolent" attackers. ?For
 > example, what about a girlfriend that pokes around your hard drive looking
 > for lolcats when she's bored? ?One glance at .fetchmailrc would show it's
 > not a lolcat; but that same glance could show a password that you don't
 > really want her to know.
 
 It took over 7 years before I would even tell my wife my login
 password; I've since changed it and won't share it. And I trust her
 implicitly with my machine -- there is nothing on there that I'm not
 happy for her to see :-)
 
 So, how does the putative bored girlfriend poke around your hard-drive
 in the first place, in this scenario? If you are letting her use your
 account and poke around your machine in the first place, how does her
 seeing a password cause a problem?
 
 If you don't want someone to know something, don't put them is a
 situation where they might find it. You shouldn't expect a program to
 employ a pointless encryption/obscuration scheme just because you
 don't look after your other data. You are increasing the complexity of
 the code, increasing the complexity of the testing environment,
 increasing the opportunity for bugs to occur (possibly causing data
 loss?), and protecting against nothing.
 
 Now, there is an approach used by mutt that sup doesn't seem to use,
 which is to prompt the user at the beginning of a session for the
 various source passwords; this way they are only held in memory (and
 swap files, probably). That may be a way out of the situation; as a
 mail client is inherently an interactive program, there's no harm in
 prompting for things missing from the config, I think.
 
 -jim
 
 From jim@gonzul.net  Fri Aug 28 05:28:28 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Fri, 28 Aug 2009 21:28:28 +1200
 Subject: [sup-talk] Encrypted password in configuration file
 In-Reply-To: <20090828082349.61bfc91b@ronin.larsko.net>
 References: <20090824215435.182e0007@ronin.larsko.net>
 	<f4cc59760908271937t764e61aeh7f105c7195fec1ce@mail.gmail.com> 
 	<20090828082349.61bfc91b@ronin.larsko.net>
 Message-ID: <f4cc59760908280228i47bbd52dy87a5695e3a2361c0@mail.gmail.com>
 
 On Fri, Aug 28, 2009 at 7:23 PM, Lars Kotthoff<lars at larsko.org> wrote:
 >> It's possible, but slightly pointless.
 >
 > Not if the user supplies the passphrase, e.g. it could be encrypted with the
 > user's GPG key and ask for the passphrase at startup.
 
 Why not just ask for the IMAP password itself? There's no functional
 difference between that secret, and the secret that unlocks the secret
 ... indeed, if sup were to accidentally expose the passphrase you
 provided, would you rather lose your GPG key or your IMAP key?
 
 If you are really determined to allow others to read your private
 files, why not just encrypt the whole .sup directory with a separate
 tool (TrueCrypt, loopback, rot13, encfs, ecryptfs, or whatever else
 your distribution provides).
 
 That way, you are also protecting the ferret index collection, and the
 default sent box, which all contain data of the same level of
 sensitivity as your mailbox. Given your concern, I assume that you
 will be remembering to terminate sup and dismount the .sup directory
 every time you walk away from the keyboard.
 
 (Many schemes these days encrypt the whole of $HOME, which makes the
 whole screensaver/away from the keyboard thing even more difficult).
 
 Security must be appropriate to be actual security. Otherwise it's
 just an expensive fa?ade.
 
 -jim
 
 From stan@stanheckman.com  Wed Aug 26 15:59:46 2009
 From: stan@stanheckman.com (Stan Heckman)
 Date: Wed, 26 Aug 2009 19:59:46 +0000
 Subject: [sup-talk] an error occurred in Sup
 Message-ID: <1251316321-sup-8091@clover.schedar.com>
 
 While setting up sup I received the error below.
 I attach the exception-log requested.
 
 I had told sup-config about my existing maildirs. This produced a large inbox.
 I attempted to archive all but 15 recent messages from this inbox by loading
 all messages with "!!" and archiving them all by holding down the "a" key for
 several seconds.
 
 After several minutes of archiving, I received the error below.
 
 
 [Wed Aug 26 19:38:08 +0000 2009] stopped cursing
 [Wed Aug 26 19:38:08 +0000 2009] oh crap, an exception
 [Wed Aug 26 19:38:08 +0000 2009] unlocking /home/stan/.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
 ----------------------------------------------------------------
 --- NoMethodError from thread: periodic poll
 undefined method `+' for nil:NilClass
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:141:in `end_offset'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/source.rb:87:in `done?'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
 /usr/lib/ruby/1.8/sup/poll.rb:89:in `do_poll'
 /usr/lib/ruby/1.8/sup/poll.rb:86:in `each'
 /usr/lib/ruby/1.8/sup/poll.rb:86:in `do_poll'
 /usr/lib/ruby/1.8/sup/poll.rb:85:in `synchronize'
 /usr/lib/ruby/1.8/sup/poll.rb:85:in `do_poll'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 /usr/lib/ruby/1.8/sup/modes/poll-mode.rb:17:in `poll'
 /usr/lib/ruby/1.8/sup/poll.rb:53:in `poll'
 /usr/lib/ruby/1.8/sup/poll.rb:70:in `start'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
 /usr/lib/ruby/1.8/sup/poll.rb:67:in `start'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 /home/stan/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup:213
 /home/stan/.gem/ruby/1.8/bin/sup:19:in `load'
 /home/stan/.gem/ruby/1.8/bin/sup:19
 -------------- next part --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090826/6de40820/attachment.txt>
 
 From lars@larsko.org  Fri Aug 28 03:23:49 2009
 From: lars@larsko.org (Lars Kotthoff)
 Date: Fri, 28 Aug 2009 08:23:49 +0100
 Subject: [sup-talk] Encrypted password in configuration file
 In-Reply-To: <f4cc59760908271937t764e61aeh7f105c7195fec1ce@mail.gmail.com>
 References: <20090824215435.182e0007@ronin.larsko.net>
 	<f4cc59760908271937t764e61aeh7f105c7195fec1ce@mail.gmail.com>
 Message-ID: <20090828082349.61bfc91b@ronin.larsko.net>
 
 > It's possible, but slightly pointless.
 
 Not if the user supplies the passphrase, e.g. it could be encrypted with the
 user's GPG key and ask for the passphrase at startup.
 
 Lars
 
 From wmorgan-sup@masanjin.net  Fri Aug 28 16:29:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 28 Aug 2009 13:29:03 -0700
 Subject: [sup-talk] Encrypted password in configuration file
 In-Reply-To: <20090824215435.182e0007@ronin.larsko.net>
 References: <20090824215435.182e0007@ronin.larsko.net>
 Message-ID: <1251491240-sup-1148@masanjin.net>
 
 Reformatted excerpts from Lars Kotthoff's message of 2009-08-24:
 > is it possible to store the account password encrypted in the
 > configuration file?
 
 Despite generally agreeing with Jim's argument, I'm happy to accept a
 patch to do this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Aug 28 16:31:26 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 28 Aug 2009 13:31:26 -0700
 Subject: [sup-talk] sent and draft sources
 In-Reply-To: <f8203010908271258m32cbaacfked4ec80969ce3034@mail.gmail.com>
 References: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 	<1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 	<f8203010908271258m32cbaacfked4ec80969ce3034@mail.gmail.com>
 Message-ID: <1251491386-sup-7354@masanjin.net>
 
 Reformatted excerpts from Joe Shaw's message of 2009-08-27:
 > How safe is building and running from git master?
 
 Pretty safe. I merge all changes into next first, which is where people
 see breakage, and only merge them into master when they've baked long
 enough.
 
 > Is there a general philosophy about its stability?
 
 "Stability is good". :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Aug 28 16:35:06 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 28 Aug 2009 13:35:06 -0700
 Subject: [sup-talk] sent and draft sources
 In-Reply-To: <20090827200053.GA17416@chistera.yi.org>
 References: <f8203010908271244p1d296d9dw3d2d989b6d48a2ee@mail.gmail.com>
 	<1251402318-sup-4655@ntdws12.chass.utoronto.ca>
 	<20090827200053.GA17416@chistera.yi.org>
 Message-ID: <1251491567-sup-2126@masanjin.net>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-08-27:
 > Why? Would sup not lock the mbox properly?
 
 Sup doesn't lock the sent mbox currently. It wouldn't be too hard to
 add. I'm still waiting for Ben to provide a nice refactoring patch for
 me. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Aug 28 16:37:12 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 28 Aug 2009 13:37:12 -0700
 Subject: [sup-talk] Nobody told me
 In-Reply-To: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com>
 References: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com>
 Message-ID: <1251491725-sup-284@masanjin.net>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-08-27:
 > Playing the dumb newbie here, but when did that happened?
 
 If anyone else has this problem (and anyone who's running next with the 
 Xapian index will): after the dump and before sup-sync, I believe you
 need to remove your ~/.sup/xapian directory and ~/.sup/*.db. Life on the
 bleeding edge!
 
 > ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects
 > a v1 index, but you have an existing v0 index. Please downgrade to
 > your previous version and dump your labels before upgrading to this
 > version (then run sup-sync --restore). (RuntimeError)
 >         from ./lib/sup/index.rb:67:in `load'
 >         from bin/sup-sync:117
 > 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Aug 28 16:38:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 28 Aug 2009 13:38:59 -0700
 Subject: [sup-talk] an error occurred in Sup
 In-Reply-To: <1251316321-sup-8091@clover.schedar.com>
 References: <1251316321-sup-8091@clover.schedar.com>
 Message-ID: <1251491856-sup-4902@masanjin.net>
 
 Reformatted excerpts from Stan Heckman's message of 2009-08-26:
 > I had told sup-config about my existing maildirs. This produced a
 > large inbox.  I attempted to archive all but 15 recent messages from
 > this inbox by loading all messages with "!!" and archiving them all by
 > holding down the "a" key for several seconds.
 
 Definitely the slow an painful way to do this, and also the way to
 trigger one of the display threading heisenbugs.
 
 I recommend instead using sup-tweak-labels, or starting over and using
 --archive when you sup-add the source (and then just adding the inbox
 label back to the first 15).
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Aug 28 16:41:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 28 Aug 2009 13:41:41 -0700
 Subject: [sup-talk] sup crashed: NoMethodError
 In-Reply-To: <20090827200317.GA3065@gmail.com>
 References: <20090827200317.GA3065@gmail.com>
 Message-ID: <1251492008-sup-6128@masanjin.net>
 
 Reformatted excerpts from Sean Escriva's message of 2009-08-27:
 > so far I have tried a gem cleanup, gem uninstall sup, gem install -r
 > sup, all to no avail. It still always crashes with the following:
 > 
 > --- NoMethodError from thread: main
 > undefined method `[]' for false:FalseClass
 > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start'
 > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161
 > /usr/bin/sup:19:in `load'
 > /usr/bin/sup:19
 > 
 > Any tips on how to fix/figure out what I did wrong are greatly
 > appreciated!
 
 Hm, is your ~/.sup/config.yaml file empty for some reason? If so, delete
 it and retry, and I will add some code to catch this case.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Fri Aug 28 17:01:04 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Fri, 28 Aug 2009 23:01:04 +0200
 Subject: [sup-talk] Nobody told me
 In-Reply-To: <1251491725-sup-284@masanjin.net>
 References: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com>
 	<1251491725-sup-284@masanjin.net>
 Message-ID: <1e5fdab70908281401k7f0b59ectb38ce7dfe7280569@mail.gmail.com>
 
 On Fri, Aug 28, 2009 at 10:37 PM, William
 Morgan<wmorgan-sup at masanjin.net> wrote:
 
 arg, when I try to restore, I get this:
 ./lib/sup/crypto.rb:157:in ``': Cannot allocate memory - /usr/bin/gpg
 --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify
 /tmp/31666-0-redwood.signature /tmp/31666-0-redwood.payload 2>
 /dev/null (Errno::ENOMEM)
 	from ./lib/sup/crypto.rb:157:in `run_gpg'
 	from ./lib/sup/crypto.rb:92:in `verify'
 	from ./lib/sup/util.rb:520:in `send'
 	from ./lib/sup/util.rb:520:in `method_missing'
 	from ./lib/sup/message.rb:385:in `multipart_signed_to_chunks'
 	from ./lib/sup/message.rb:421:in `message_to_chunks'
 	from ./lib/sup/message.rb:236:in `load_from_source!'
 	from ./lib/sup/message.rb:332:in `build_from_source'
 	from ./lib/sup/poll.rb:153:in `each_message_from'
 	from ./lib/sup/source.rb:104:in `each'
 	from ./lib/sup/util.rb:560:in `send'
 	from ./lib/sup/util.rb:560:in `__pass'
 	from ./lib/sup/util.rb:547:in `method_missing'
 	from ./lib/sup/poll.rb:147:in `each_message_from'
 	from ./lib/sup/util.rb:520:in `send'
 	from ./lib/sup/util.rb:520:in `method_missing'
 	from bin/sup-sync:146
 	from bin/sup-sync:141:in `each'
 	from bin/sup-sync:141
 
 is it leaking, or is my huge mbox just too big for it?
 
 cheers
 
 -- 
 Guillaume
 
 From sean.escriva@gmail.com  Fri Aug 28 18:50:41 2009
 From: sean.escriva@gmail.com (Sean Escriva)
 Date: Fri, 28 Aug 2009 15:50:41 -0700
 Subject: [sup-talk] sup crashed: NoMethodError
 In-Reply-To: <1251492008-sup-6128@masanjin.net>
 References: <20090827200317.GA3065@gmail.com>
 	<1251492008-sup-6128@masanjin.net>
 Message-ID: <20090828225041.GA22963@gmail.com>
 
 On Fri, Aug 28, 2009 at 01:41:41PM -0700, William Morgan wrote:
 > Reformatted excerpts from Sean Escriva's message of 2009-08-27:
 > > so far I have tried a gem cleanup, gem uninstall sup, gem install -r
 > > sup, all to no avail. It still always crashes with the following:
 > > 
 > > --- NoMethodError from thread: main
 > > undefined method `[]' for false:FalseClass
 > > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:107:in `start'
 > > /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:161
 > > /usr/bin/sup:19:in `load'
 > > /usr/bin/sup:19
 > > 
 > > Any tips on how to fix/figure out what I did wrong are greatly
 > > appreciated!
 > 
 > Hm, is your ~/.sup/config.yaml file empty for some reason? If so, delete
 > it and retry, and I will add some code to catch this case.
 
 That may have been it. I just clobbered my whole setup and started
 over, now it's working Although now I'm using the gem and not the git
 next branch. I don't want to loose my 8K+ message index again.
 
 was my install process wrong for switching to the git -next branch?
 
 -sme
 
 ps: i'll consider switching fully to sup as soon as I figure out how to manage
 multiple email accounts :)
 
 From pioto@pioto.org  Fri Aug 28 18:48:59 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Fri, 28 Aug 2009 18:48:59 -0400
 Subject: [sup-talk] Encrypted password in configuration file
 In-Reply-To: <20090824215435.182e0007@ronin.larsko.net>
 References: <20090824215435.182e0007@ronin.larsko.net>
 Message-ID: <20090828184859.59b7f825@aether.home.pioto.org>
 
 On Mon, 24 Aug 2009 21:54:35 +0100
 Lars Kotthoff <lists at larsko.org> wrote:
 >  is it possible to store the account password encrypted in the
 > configuration file?
 
 Along the lines of what Jim said, doing any sort of two-way encryption
 on the password is a wasted effort. There are other sort of
 authentication mechanisms which are probably more appropriate
 (certificate-based, Kerberos/GSSAPI, ...).
 
 -- 
 Mike Kelly
 
 From nicolas.pouillard@gmail.com  Sat Aug 29 05:18:52 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 29 Aug 2009 11:18:52 +0200
 Subject: [sup-talk] Crash while syncing
 Message-ID: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 
 Hello,
 
 While doing a from scratch sup-sync to benefit for the new version of
 the xapian index, sup-sync
 crashed like this:
 
 /usr/lib/ruby/site_ruby/1.8/xapian.rb:240:in `doclength':
 DocNotFoundError: Document 3318104838 not found (RuntimeError)
         from /usr/lib/ruby/site_ruby/1.8/xapian.rb:240:in `postlist'
         from /usr/lib/ruby/site_ruby/1.8/xapian.rb:60:in `_safelyIterate'
         from /usr/lib/ruby/site_ruby/1.8/xapian.rb:238:in `postlist'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:365:in
 `term_docids'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:369:in
 `find_docid'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:373:in
 `find_doc'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in
 `index_message'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in
 `map'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:469:in
 `index_message'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:118:in
 `sync_message'
         from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:392:in
 `synchronize'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:117:in
 `sync_message'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:87:in
 `add_message'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:202
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:152:in
 `each_message_from'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in
 `method_missing'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in
 `each_message_from'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in
 `method_missing'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:146
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141:in `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141
         from /usr/bin/sup-sync:19:in `load'
         from /usr/bin/sup-sync:19
 
 The last status message was:
 
 ## read 9996m (about 30%) @ 11.1m/s. 0:15:03 elapsed, about 0:35:00 remaining
 
 And it was processing a 500MB mbox.
 
 I would like to know what are my options from here?
 
 Best regards,
 
 -- 
 Nicolas Pouillard aka Ertai
 
 From nicolas.pouillard@gmail.com  Sat Aug 29 08:03:04 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 29 Aug 2009 14:03:04 +0200
 Subject: [sup-talk] Crash while syncing
 In-Reply-To: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 References: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 Message-ID: <cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
 
 On Sat, Aug 29, 2009 at 11:18 AM, Nicolas
 Pouillard<nicolas.pouillard at gmail.com> wrote:
 > Hello,
 >
 > While doing a from scratch sup-sync to benefit for the new version of
 > the xapian index, sup-sync
 > crashed like this:
 >
 
 I've lauched sup-sync on another bunch of mboxes and got this crash at the end:
 
 Deleting missing messages from the index...
 /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:17:in `id': wrong id
 called on nil (RuntimeError)
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:237
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:150:in
 `each_message'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
 `each_id'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
 `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
 `each_id'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:149:in
 `each_message'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:235
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233:in `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233
         from /usr/bin/sup-sync:19:in `load'
         from /usr/bin/sup-sync:19
 
 
 -- 
 Nicolas Pouillard aka Ertai
 
 From rlane@club.cc.cmu.edu  Sat Aug 29 12:25:33 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 29 Aug 2009 12:25:33 -0400
 Subject: [sup-talk] Crash while syncing
 In-Reply-To: <cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
 References: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 	<cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
 Message-ID: <1251563082-sup-3525@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Sat Aug 29 08:03:04 -0400 2009:
 > On Sat, Aug 29, 2009 at 11:18 AM, Nicolas
 > Pouillard<nicolas.pouillard at gmail.com> wrote:
 > > Hello,
 > >
 > > While doing a from scratch sup-sync to benefit for the new version of
 > > the xapian index, sup-sync
 > > crashed like this:
 > >
 > 
 > I've lauched sup-sync on another bunch of mboxes and got this crash at the end:
 > 
 > Deleting missing messages from the index...
 > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:17:in `id': wrong id
 > called on nil (RuntimeError)
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:237
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:150:in
 > `each_message'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
 > `each_id'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
 > `each'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:141:in
 > `each_id'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:149:in
 > `each_message'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:235
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233:in `each'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:233
 >         from /usr/bin/sup-sync:19:in `load'
 >         from /usr/bin/sup-sync:19
 > 
 
 Are you using the Flint or Chert Xapian backend?
 
 From nicolas.pouillard@gmail.com  Sat Aug 29 12:45:29 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 29 Aug 2009 18:45:29 +0200
 Subject: [sup-talk] Crash while syncing
 In-Reply-To: <1251563082-sup-3525@zyrg.net>
 References: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 	<cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
 	<1251563082-sup-3525@zyrg.net>
 Message-ID: <cd67f63a0908290945j2007c75cyc56ab6c1dcfdbbb1@mail.gmail.com>
 
 On Sat, Aug 29, 2009 at 6:25 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote:
 > Excerpts from Nicolas Pouillard's message of Sat Aug 29 08:03:04 -0400 2009:
 >> On Sat, Aug 29, 2009 at 11:18 AM, Nicolas Pouillard<nicolas.pouillard at gmail.com> wrote:
 >> > Hello,
 >> >
 >> > While doing a from scratch sup-sync to benefit for the new version of
 >> > the xapian index, sup-sync
 >> > crashed like this:
 >> >
 
 [...]
 
 > Are you using the Flint or Chert Xapian backend?
 
 The Chert one.
 
 -- 
 Nicolas Pouillard aka Ertai
 
 From rlane@club.cc.cmu.edu  Sat Aug 29 12:59:59 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 29 Aug 2009 12:59:59 -0400
 Subject: [sup-talk] Crash while syncing
 In-Reply-To: <cd67f63a0908290945j2007c75cyc56ab6c1dcfdbbb1@mail.gmail.com>
 References: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 	<cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
 	<1251563082-sup-3525@zyrg.net>
 	<cd67f63a0908290945j2007c75cyc56ab6c1dcfdbbb1@mail.gmail.com>
 Message-ID: <1251564961-sup-5855@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Sat Aug 29 12:45:29 -0400 2009:
 > > Are you using the Flint or Chert Xapian backend?
 > 
 > The Chert one.
 
 Could you try it with Flint? I've seen this (nondeterministic) bug when
 using Chert.
 
 From nicolas.pouillard@gmail.com  Sat Aug 29 13:05:33 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 29 Aug 2009 19:05:33 +0200
 Subject: [sup-talk] Crash while syncing
 In-Reply-To: <1251564961-sup-5855@zyrg.net>
 References: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 	<cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
 	<1251563082-sup-3525@zyrg.net>
 	<cd67f63a0908290945j2007c75cyc56ab6c1dcfdbbb1@mail.gmail.com>
 	<1251564961-sup-5855@zyrg.net>
 Message-ID: <cd67f63a0908291005m5a53b2cei71bfa48e4bc1d658@mail.gmail.com>
 
 On Sat, Aug 29, 2009 at 6:59 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote:
 > Excerpts from Nicolas Pouillard's message of Sat Aug 29 12:45:29 -0400 2009:
 >> > Are you using the Flint or Chert Xapian backend?
 >>
 >> The Chert one.
 >
 > Could you try it with Flint? I've seen this (nondeterministic) bug when
 > using Chert.
 
 I was currently running it again with no problems so far.
 
 Are the nondeterministic bugs only during sync?
 
 Chert is supposed to faster?
 
 Thanks for your help,
 
 -- 
 Nicolas Pouillard
 
 From bwalton@artsci.utoronto.ca  Sat Aug 29 14:35:03 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 29 Aug 2009 14:35:03 -0400
 Subject: [sup-talk] exception while importing to xapian
 Message-ID: <1251570765-sup-4265@ntdws12.chass.utoronto.ca>
 
 
 I just tried again to switch to xapian and I got the following:
 
 $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore ~/.sup/dumpfile 
 Loading state dump from /cquest/roger/staff0/systems/bwalton/.sup/dumpfile...
 Read 72360 entries from dump file.
 Scanning maildir:///u/bwalton/Maildir/...
 [Sat Aug 29 14:29:11 -0400 2009] hook: read 'before-add-message' from
 /cquest/roger/staff0/systems/bwalton/.sup/hooks/before-add-message.rb
 ./lib/sup/xapian_index.rb:365:in `find_docid': undefined method `tap'
 for []:Array (NoMethodError)
         from ./lib/sup/xapian_index.rb:369:in `find_doc'
         from ./lib/sup/xapian_index.rb:379:in `get_entry'
         from ./lib/sup/xapian_index.rb:68:in `build_message'
         from /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize'
         from ./lib/sup/xapian_index.rb:388:in `synchronize'
         from ./lib/sup/xapian_index.rb:68:in `build_message'
         from bin/sup-sync:149
         from ./lib/sup/poll.rb:160:in `each_message_from'
          ... 8 levels...
         from ./lib/sup/util.rb:520:in `method_missing'
         from bin/sup-sync:146
         from bin/sup-sync:141:in `each'
         from bin/sup-sync:141
 
 This happened with 806a067 (the current tip of next).  Exception log
 attached.
 
 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 --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: sup-exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090829/c6d25c82/attachment.txt>
 -------------- 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/20090829/c6d25c82/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Sat Aug 29 20:22:15 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 29 Aug 2009 20:22:15 -0400
 Subject: [sup-talk] Crash while syncing
 In-Reply-To: <cd67f63a0908291005m5a53b2cei71bfa48e4bc1d658@mail.gmail.com>
 References: <cd67f63a0908290218g30a737a9pd46d902cdf5399bb@mail.gmail.com>
 	<cd67f63a0908290503g37ab5575ibb6162d06f7528af@mail.gmail.com>
 	<1251563082-sup-3525@zyrg.net>
 	<cd67f63a0908290945j2007c75cyc56ab6c1dcfdbbb1@mail.gmail.com>
 	<1251564961-sup-5855@zyrg.net>
 	<cd67f63a0908291005m5a53b2cei71bfa48e4bc1d658@mail.gmail.com>
 Message-ID: <1251565999-sup-7892@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Sat Aug 29 13:05:33 -0400 2009:
 > Are the nondeterministic bugs only during sync?
 
 I've only seen it during sup-sync, but I'd guess if you ran sup long
 enough you'd see it there too (after changing labels / polling).
 
 > Chert is supposed to faster?
 
 Yes, and more space efficient.
 
 From bburky@bburky.com  Sun Aug 30 16:14:56 2009
 From: bburky@bburky.com (Blake Burkhart)
 Date: Sun, 30 Aug 2009 15:14:56 -0500
 Subject: [sup-talk] exception while importing to xapian
 In-Reply-To: <1251570765-sup-4265@ntdws12.chass.utoronto.ca>
 References: <1251570765-sup-4265@ntdws12.chass.utoronto.ca>
 Message-ID: <1251662840-sup-4363@Backspace.local>
 
 Excerpts from Ben Walton's message of Sat Aug 29 13:35:03 -0500 2009:
 > 
 > I just tried again to switch to xapian and I got the following:
 > 
 > $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore
 > ~/.sup/dumpfile 
 > Loading state dump from /cquest/roger/staff0/systems/bwalton/.sup/dumpfile...
 > Read 72360 entries from dump file.
 > Scanning maildir:///u/bwalton/Maildir/...
 > [Sat Aug 29 14:29:11 -0400 2009] hook: read 'before-add-message' from
 > /cquest/roger/staff0/systems/bwalton/.sup/hooks/before-add-message.rb
 > ./lib/sup/xapian_index.rb:365:in `find_docid': undefined method `tap'
 > for []:Array (NoMethodError)
 >
 >  [...]
 > 
 
 I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6.
 Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and
 later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and
 backported from there.
 
 Is it necessary to use this method? Is there an alternate way to do this?
 
 -- Blake Burkhart
 
 From bwalton@artsci.utoronto.ca  Sun Aug 30 16:21:30 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 30 Aug 2009 16:21:30 -0400
 Subject: [sup-talk] exception while importing to xapian
 In-Reply-To: <1251662840-sup-4363@Backspace.local>
 References: <1251570765-sup-4265@ntdws12.chass.utoronto.ca>
 	<1251662840-sup-4363@Backspace.local>
 Message-ID: <1251663644-sup-5538@ntdws12.chass.utoronto.ca>
 
 Excerpts from Blake Burkhart's message of Sun Aug 30 16:14:56 -0400 2009:
 
 > I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6.
 > Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and
 > later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and
 > backported from there.
 
 Actually, I'm on 1.8.5 (the version shipped with rhel5).  Sup may
 finally force me to update it 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/20090830/fa051bea/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Sun Aug 30 16:28:55 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 30 Aug 2009 13:28:55 -0700
 Subject: [sup-talk] [PATCH] remove use of Object#tap
 Message-ID: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |    4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index c260728..1395601 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -362,7 +362,9 @@ class XapianIndex < BaseIndex
    end
  
    def find_docid id
 -    term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first
 +    docids = term_docids(mkterm(:msgid,id))
 +    fail unless docids.size <= 1
 +    docids.first
    end
  
    def find_doc id
 -- 
 1.6.0.4
 
 
 From bburky@bburky.com  Sun Aug 30 16:45:48 2009
 From: bburky@bburky.com (Blake Burkhart)
 Date: Sun, 30 Aug 2009 15:45:48 -0500
 Subject: [sup-talk] [PATCH] remove use of Object#tap
 In-Reply-To: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251664798-sup-8169@Backspace.local>
 
 Excerpts from Rich Lane's message of Sun Aug 30 15:28:55 -0500 2009:
 > ---
 >  lib/sup/xapian_index.rb |    4 +++-
 >  1 files changed, 3 insertions(+), 1 deletions(-)
 > 
 > diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 > index c260728..1395601 100644
 > --- a/lib/sup/xapian_index.rb
 > +++ b/lib/sup/xapian_index.rb
 > @@ -362,7 +362,9 @@ class XapianIndex < BaseIndex
 >    end
 >  
 >    def find_docid id
 > -    term_docids(mkterm(:msgid,id)).tap { |x| fail unless x.size <= 1 }.first
 > +    docids = term_docids(mkterm(:msgid,id))
 > +    fail unless docids.size <= 1
 > +    docids.first
 >    end
 >  
 >    def find_doc id
 
 After applying this on next in hopes it lets me run sup on ruby 1.8.6, it
 doesn't work.
 
 It crashed with this log:
 $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore ~/dumpfile
 Loading state dump from /Users/blake/dumpfile...
 Read 6790 entries from dump file.
 Scanning maildir:/Users/blake/Mail/bburky/INBOX...
 [Sun Aug 30 15:38:57 -0500 2009] hook: read 'before-add-message' from /Users/blake/.sup/hooks/before-add-message.rb
 [Sun Aug 30 15:38:57 -0500 2009] hook[before-add-message]: Marking message 1234774373-sup-1128 at zo as suptalk, subject is 'Re: [sup-talk] (no subject)'
 ./lib/sup/label.rb:64:in `<<': expecting a symbol (ArgumentError)
 	from ./lib/sup/util.rb:520:in `send'
 	from ./lib/sup/util.rb:520:in `method_missing'
 	from ./lib/sup/xapian_index.rb:114:in `sync_message'
 	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each'
 	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each_key'
 	from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:189:in `each'
 	from ./lib/sup/xapian_index.rb:114:in `sync_message'
 	from ./lib/sup/xapian_index.rb:87:in `add_message'
 	 ... 10 levels...
 	from ./lib/sup/util.rb:520:in `method_missing'
 	from bin/sup-sync:146
 	from bin/sup-sync:141:in `each'
 	from bin/sup-sync:141
 
 However, I'm having other odd problems too with labels anyway. On the ferret
 version of sup, I'm not able to apply labels with the 'l' command. However, I
 have a hook for applying a label from the List-ID that does still work. So
 this patch may or may not work, I think I'm possibly having problems of my
 own.
 
 Actually, I haven't tried to restore from a dumpfile for ferret. I'll do that
 later and see if it works.
 
 -- Blake Burkhart
 
 From rlane@club.cc.cmu.edu  Sun Aug 30 16:47:59 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 30 Aug 2009 16:47:59 -0400
 Subject: [sup-talk] exception while importing to xapian
 In-Reply-To: <1251662840-sup-4363@Backspace.local>
 References: <1251570765-sup-4265@ntdws12.chass.utoronto.ca>
 	<1251662840-sup-4363@Backspace.local>
 Message-ID: <1251664201-sup-9803@zyrg.net>
 
 Excerpts from Blake Burkhart's message of Sun Aug 30 16:14:56 -0400 2009:
 > I am getting this same error myself. I'm running Mac OS 10.5 with ruby 1.8.6.
 > Are you also using ruby 1.8.6? I think the tap method is in ruby 1.8.7 and
 > later. Actually a quick google shows it may even be ruby 1.9 only, or 1.9 and
 > backported from there.
 > 
 > Is it necessary to use this method? Is there an alternate way to do this?
 
 Yeah, this was just a 1.8.7-ism. I've sent a patch to fix it.
 
 From bburky@bburky.com  Sun Aug 30 17:50:09 2009
 From: bburky@bburky.com (Blake Burkhart)
 Date: Sun, 30 Aug 2009 16:50:09 -0500
 Subject: [sup-talk] [PATCH] remove use of Object#tap
 In-Reply-To: <1251664798-sup-8169@Backspace.local>
 References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1251664798-sup-8169@Backspace.local>
 Message-ID: <1251668806-sup-7253@Backspace.local>
 
 Excerpts from Blake Burkhart's message of Sun Aug 30 15:45:48 -0500 2009:
 > After applying this on next in hopes it lets me run sup on ruby 1.8.6, it
 > doesn't work.
 > 
 > It crashed with this log:
 > $ SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore
 > ~/dumpfile
 > Loading state dump from /Users/blake/dumpfile...
 > Read 6790 entries from dump file.
 > Scanning maildir:/Users/blake/Mail/bburky/INBOX...
 > [Sun Aug 30 15:38:57 -0500 2009] hook: read 'before-add-message' from
 > /Users/blake/.sup/hooks/before-add-message.rb
 > [Sun Aug 30 15:38:57 -0500 2009] hook[before-add-message]: Marking message
 > 1234774373-sup-1128 at zo as suptalk, subject is 'Re: [sup-talk] (no subject)'
 > ./lib/sup/label.rb:64:in `<<': expecting a symbol (ArgumentError)
 >     from ./lib/sup/util.rb:520:in `send'
 >     from ./lib/sup/util.rb:520:in `method_missing'
 >     from ./lib/sup/xapian_index.rb:114:in `sync_message'
 >     from
 > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1
 > 89:in `each'
 >     from
 > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1
 > 89:in `each_key'
 >     from
 > /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:1
 > 89:in `each'
 >     from ./lib/sup/xapian_index.rb:114:in `sync_message'
 >     from ./lib/sup/xapian_index.rb:87:in `add_message'
 >      ... 10 levels...
 >     from ./lib/sup/util.rb:520:in `method_missing'
 >     from bin/sup-sync:146
 >     from bin/sup-sync:141:in `each'
 >     from bin/sup-sync:141
 > 
 > However, I'm having other odd problems too with labels anyway. On the ferret
 > version of sup, I'm not able to apply labels with the 'l' command. However, I
 > have a hook for applying a label from the List-ID that does still work. So
 > this patch may or may not work, I think I'm possibly having problems of my
 > own.
 I got it to work. Mostly a least. What does a sup-dump file actually store? I
 lost all read/unread statuses and all labels (including the spam label thing,
 I assume it's just a normal label).
 
 To get it to work, I removed my before-add-message hook. It has worked for a
 long time, through different versions of sup, etc. However, It doesn't seem to
 be working with xapian.
 
 I don't actually know where this code came from, possibly this list, or maybe
 else where. I may have even modified it, I don't really remember. The hook is
 this:
 
 listIdMatch = message.raw_header.match(/List-Id:.*?<(.*?)>\s*$/i)
 
 if(listIdMatch)
   listIdLabel = listIdMatch[1].split(/\./).first.sub(/[^0-9A-Za-z]/, "")
   message.add_label listIdLabel
   log "Marking message #{message.id} as #{listIdLabel}, subject is '#{message.subj}'"
 end
 
 > Actually, I haven't tried to restore from a dumpfile for ferret. I'll do that
 > later and see if it works.
 
 I did try a restore from dumpfile with ferret. It worked except it didn't
 remember the labels the same way xapian didn't. However, the hook did work,
 and created labels on all mailing list messages.
 
 I think this isn't a xapian problem, because ferret is acting the same.
 
 If I want to recreate the sup files from scratch, what do I need to have? My
 config.yaml, sources.yaml, sent.mbox and a dumpfile? Is that all?
 
 From bwalton@artsci.utoronto.ca  Sun Aug 30 19:55:56 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 30 Aug 2009 19:55:56 -0400
 Subject: [sup-talk] [PATCH] remove use of Object#tap
 In-Reply-To: <1251668806-sup-7253@Backspace.local>
 References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1251664798-sup-8169@Backspace.local>
 	<1251668806-sup-7253@Backspace.local>
 Message-ID: <1251676342-sup-7038@ntdws12.chass.utoronto.ca>
 
 Excerpts from Blake Burkhart's message of Sun Aug 30 17:50:09 -0400 2009:
 
 > I got it to work. Mostly a least. What does a sup-dump file actually store? I
 > lost all read/unread statuses and all labels (including the spam label thing,
 > I assume it's just a normal label).
 
 I also lost labels on my first attempt at switching to xapian.  I gave
 up for a few days as there were other issues with labels at the time.
 Losing labels during the switch would be a deal breaker, but I assume
 this isn't intended (as that would be madness, madness, I say)...is
 there a step I'm missing in the following (assuming HEAD of next)?
 
 4. cp ~/.sup/sources.yaml{,.bak}
 5. ruby -Ilib bin/sup-dump > dumpfile
 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources
    --restore dumpfile
 7. SUP_INDEX=xapian ruby -Ilib bin/sup -o
 
 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/20090830/1955cef2/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Sun Aug 30 20:50:34 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 30 Aug 2009 17:50:34 -0700
 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that dont
 	already exist
 Message-ID: <1251679834-5313-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup-sync |    5 +++++
  1 files changed, 5 insertions(+), 0 deletions(-)
 
 diff --git a/bin/sup-sync b/bin/sup-sync
 index 2aa00c3..003a72d 100755
 --- a/bin/sup-sync
 +++ b/bin/sup-sync
 @@ -174,7 +174,12 @@ begin
        ## decide what to do based on message labels and the operation we're performing
        dothis, new_labels = case
        when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels != restored_state[m.id])
 +        num_restored += 1
          [:update_message_state, restored_state[m.id]]
 +      when (op == :restore) && restored_state[m.id] && !old_m
 +        num_restored += 1
 +        m.labels = restored_state[m.id]
 +        :add_message
        when op == :discard
          if old_m && (old_m.labels != m.labels)
            [:update_message_state, m.labels]
 -- 
 1.6.4
 
 
 From rlane@club.cc.cmu.edu  Sun Aug 30 20:50:46 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 30 Aug 2009 20:50:46 -0400
 Subject: [sup-talk] [PATCH] remove use of Object#tap
 In-Reply-To: <1251676342-sup-7038@ntdws12.chass.utoronto.ca>
 References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1251664798-sup-8169@Backspace.local>
 	<1251668806-sup-7253@Backspace.local>
 	<1251676342-sup-7038@ntdws12.chass.utoronto.ca>
 Message-ID: <1251677009-sup-2661@zyrg.net>
 
 Excerpts from Ben Walton's message of Sun Aug 30 19:55:56 -0400 2009:
 > Excerpts from Blake Burkhart's message of Sun Aug 30 17:50:09 -0400 2009:
 > 
 > > I got it to work. Mostly a least. What does a sup-dump file actually store? I
 > > lost all read/unread statuses and all labels (including the spam label thing,
 > > I assume it's just a normal label).
 > 
 > I also lost labels on my first attempt at switching to xapian.  I gave
 > up for a few days as there were other issues with labels at the time.
 > Losing labels during the switch would be a deal breaker, but I assume
 > this isn't intended (as that would be madness, madness, I say)...is
 > there a step I'm missing in the following (assuming HEAD of next)?
 > 
 > 4. cp ~/.sup/sources.yaml{,.bak}
 > 5. ruby -Ilib bin/sup-dump > dumpfile
 > 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources
 >    --restore dumpfile
 > 7. SUP_INDEX=xapian ruby -Ilib bin/sup -o
 > 
 > Thanks
 > -Ben
 > 
 
 This is an issue that was introduced in 906ab35e. I've just resent a
 patch for it.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: restore-state-fix
 Type: application/octet-stream
 Size: 3534 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090830/5be2a745/attachment.obj>
 
 From bburky@bburky.com  Sun Aug 30 21:48:50 2009
 From: bburky@bburky.com (Blake Burkhart)
 Date: Sun, 30 Aug 2009 20:48:50 -0500
 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that
 	dont already exist
 In-Reply-To: <1251679834-5313-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1251679834-5313-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251683226-sup-7685@Backspace.local>
 
 Excerpts from Rich Lane's message of Sun Aug 30 19:50:34 -0500 2009:
 > ---
 >  bin/sup-sync |    5 +++++
 >  1 files changed, 5 insertions(+), 0 deletions(-)
 > 
 > diff --git a/bin/sup-sync b/bin/sup-sync
 > index 2aa00c3..003a72d 100755
 > --- a/bin/sup-sync
 > +++ b/bin/sup-sync
 > @@ -174,7 +174,12 @@ begin
 >        ## decide what to do based on message labels and the operation we're
 > performing
 >        dothis, new_labels = case
 >        when (op == :restore) && restored_state[m.id] && old_m && (old_m.labels
 > != restored_state[m.id])
 > +        num_restored += 1
 >          [:update_message_state, restored_state[m.id]]
 > +      when (op == :restore) && restored_state[m.id] && !old_m
 > +        num_restored += 1
 > +        m.labels = restored_state[m.id]
 > +        :add_message
 >        when op == :discard
 >          if old_m && (old_m.labels != m.labels)
 >            [:update_message_state, m.labels]
 
 Yay, thank you. Everything works now I think. I now have xapian working correctly I think.
 
 From rlane@club.cc.cmu.edu  Mon Aug 31 00:16:03 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 31 Aug 2009 00:16:03 -0400
 Subject: [sup-talk] [PATCH] index log
 In-Reply-To: <1251116226-sup-1373@peray>
 References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250948551-sup-2052@masanjin.net> <1251116226-sup-1373@peray>
 Message-ID: <1251691269-sup-246@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Mon Aug 24 08:20:20 -0400 2009:
 > Excerpts from William Morgan's message of Sat Aug 22 15:46:27 +0200 2009:
 > > Reformatted excerpts from Rich Lane's message of 2009-08-16:
 > > > Add a YAML logfile that records changes to the index and modify
 > > > sup-dump to use this rather than the normal database.
 > > 
 > > I like this. I'm going to wait to apply it until the api refactoring
 > > stuff is merged down to master though. Should be soon.
 > 
 > I'm wondering if a simpler format would not be better, I've patch
 > in my sup copy do feed a file called ~/.sup/labels-mapping.log with
 > lines like those:
 > 
 > 000e0cd20f80143822047118693d at google.com (unread inbox -> )
 > 20090813213654.GA30223 at community.haskell.org (unread inbox patch -> patch)
 > 1250148617-sup-6053 at oz.taruti.net (unread inbox sup -> sup)
 > 1250281208-sup-4199 at masanjin.net (unread inbox sup -> sup)
 > 
 > Their are in the style of sup-dump output and there are pretty easy to manage
 > by any tools.
 > 
 > Not to say that I don't like YAML, I am a pretty big fan of it; but here it
 > seems overkill.
 > 
 > Best regards,
 > 
 
 I agree that YAML is overkill for what we're currently storing in the
 log. The intention was to make this as foolproof for future expansion as
 possible, but after some time thinking about it I haven't come up with
 more fields to add (not that there still couldn't be, but I think it's
 unlikely). I'll submit a simpler patch.
 
 What do people think about replacing the current undo system with one
 based on the label log? This would only be possible once we have
 immediate label changes. I think it would simplify a lot of code.
 
 From bwalton@artsci.utoronto.ca  Mon Aug 31 07:42:21 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 31 Aug 2009 07:42:21 -0400
 Subject: [sup-talk] [PATCH] index log
 In-Reply-To: <1251691269-sup-246@zyrg.net>
 References: <1250491123-19240-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1250948551-sup-2052@masanjin.net> <1251116226-sup-1373@peray>
 	<1251691269-sup-246@zyrg.net>
 Message-ID: <1251718898-sup-2772@ntdws12.chass.utoronto.ca>
 
 Excerpts from Rich Lane's message of Mon Aug 31 00:16:03 -0400 2009:
 
 > What do people think about replacing the current undo system with one
 > based on the label log? This would only be possible once we have
 > immediate label changes. I think it would simplify a lot of code.
 
 +1 for this.  I find that more often than not, undo doesn't work as
 expected anyway.  It's been suggested that this is a threading bug,
 which is quite likely...
 
 -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/20090831/8111b611/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Mon Aug 31 22:41:06 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 31 Aug 2009 19:41:06 -0700
 Subject: [sup-talk] [PATCH] sup-sync: restore state on messages that
 	dont already exist
 In-Reply-To: <1251052619-9915-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1251052619-9915-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251772852-sup-5207@masanjin.net>
 
 Applied, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 31 22:51:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 31 Aug 2009 19:51:20 -0700
 Subject: [sup-talk] [PATCH] reply all keybindings
 In-Reply-To: <1251053342-11859-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1251053342-11859-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251773465-sup-3081@masanjin.net>
 
 Branch reply-all-keybindings, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 31 22:57:54 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 31 Aug 2009 19:57:54 -0700
 Subject: [sup-talk] [PATCH] Add UTF-8 encoding string for ArchLinux
 	systems
 In-Reply-To: <1251192382-sup-2350@elly>
 References: <1251192382-sup-2350@elly>
 Message-ID: <1251773862-sup-2194@masanjin.net>
 
 Reformatted excerpts from Israel Herraiz's message of 2009-08-25:
 > in ArchLinux, UTF-8 encoding is identified by "utf8" instead of
 > "UTF-8".
 
 Applied to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 31 22:58:47 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 31 Aug 2009 19:58:47 -0700
 Subject: [sup-talk] [PATCH] Identify list messages by list-id if
 	list-post is not present
 In-Reply-To: <1251192579-sup-1849@elly>
 References: <1251192579-sup-1849@elly>
 Message-ID: <1251773879-sup-5227@masanjin.net>
 
 Reformatted excerpts from Israel Herraiz's message of 2009-08-25:
 > I am subscribed to some lists that do not fill the list-post header,
 > but have a list-id header. I am not sure how standard-compliant is
 > that, but it would nice if Sup could identify those messages as list
 > messages.
 
 Does this patch work for you?
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index ed27d3d..472b9dc 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -114,12 +114,11 @@ class Message
      @replytos = (header["in-reply-to"] || "").scan(/<(.+?)>/).map { |x| sanitize_me
  
      @replyto = Person.from_address header["reply-to"]
 -    @list_address =
 -      if header["list-post"]
 -        @list_address = Person.from_address header["list-post"].gsub(/^<mailto:|>$/
 -      else
 -        nil
 -      end
 +    @list_address = if header["list-post"]
 +      Person.from_address header["list-post"].gsub(/^<mailto:|>$/, "")
 +    elsif header["list-id"]
 +      Person.from_address header["list-id"].gsub(/^<:|>$/, "")
 +    end
  
      @recipient_email = header["envelope-to"] || header["x-original-to"] || header["
      @source_marked_read = header["status"] == "RO"
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 31 23:06:05 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 31 Aug 2009 20:06:05 -0700
 Subject: [sup-talk] [PATCH] Make SUP_LOG_LEVEL self-documenting.
 In-Reply-To: <1251322427-sup-9184@yoom.home.cworth.org>
 References: <1250745799-sup-6607@yoom.home.cworth.org>
 	<1250972634-sup-6871@masanjin.net>
 	<1251322427-sup-9184@yoom.home.cworth.org>
 Message-ID: <1251774349-sup-4067@masanjin.net>
 
 Applied, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Aug 31 23:17:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 31 Aug 2009 20:17:36 -0700
 Subject: [sup-talk] [PATCH] remove use of Object#tap
 In-Reply-To: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1251664135-1383-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1251774958-sup-5853@masanjin.net>
 
 Applied. Sup does define a #returning function which is equivalent to
 #tap, FWIW.
 -- 
 William <wmorgan-sup at masanjin.net>