sup

community/pipermail-archives/sup-talk/2009-09.txt (322874B) - raw

 From ingmar@exherbo.org  Tue Sep  1 04:07:27 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Tue, 01 Sep 2009 10:07:27 +0200
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248713376-sup-5163@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> <1248713376-sup-5163@cannonball>
 Message-ID: <1251792282-sup-2057@cannonball>
 
 Excerpts from Ingmar Vanhassel's message of Mon Jul 27 18:56:28 +0200 2009:
 > Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 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? ('@')
 > 
 > It's true in both cases. Even after a sync, 'U' still produces read
 > messages (among unread), and a search for label:foo has threads without
 > that label. If you quit sup & restart it things work as expected for a
 > while.
 
 I can still reproduce this for a more specific case, with xapian 1.0.15.
 
 Searching for is:unread (hit U), works as expected. When I filter
 that with threads having a second label (hit |, label:foo), then it
 shows threads with label:foo, but it loses the is:unread constraint.
 
 Same for immediately doing is:unread label:foo, which gives me unread
 threads, but not always with the foo label.
 -- 
 Exherbo KDE, X.org maintainer
 
 From israel.herraiz@gmail.com  Tue Sep  1 04:51:28 2009
 From: israel.herraiz@gmail.com (Israel Herraiz)
 Date: Tue, 01 Sep 2009 10:51:28 +0200
 Subject: [sup-talk] [PATCH] Identify list messages by list-id if
 	list-post is not present
 In-Reply-To: <1251773879-sup-5227@masanjin.net>
 References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net>
 Message-ID: <1251794935-sup-3802@elly>
 
 Excerpts from William Morgan's message of Tue Sep 01 04:58:47 +0200 2009:
 > Does this patch work for you?
 
 Yes, although list-id is not an address (it does not contain the "@"
 symbol for instance). But I am happy with that patch :-).
 
 Cheers,
 Israel
 
 From wmorgan-sup@masanjin.net  Tue Sep  1 16:59:56 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 01 Sep 2009 13:59:56 -0700
 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a
 	Person
 In-Reply-To: <1251250991-sup-3593@zyrg.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> <1251250991-sup-3593@zyrg.net>
 Message-ID: <1251838745-sup-376@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-25:
 > 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.
 
 Yeah, I think that's a better approach. There's no need for the
 constructor to do all that work. I'll work on this when I get a chance,
 or feel free to beat me to it.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Tue Sep  1 23:59:57 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 01 Sep 2009 23:59:57 -0400
 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: <1251863327-sup-8206@zyrg.net>
 
 Just making sure these patches don't drop off your radar. I know
 searching is supposed to make scrolling obsolete, but some Mutt users
 asked for this. They'll see the light eventually.
 
 From wmorgan-sup@masanjin.net  Wed Sep  2 09:50:13 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 02 Sep 2009 06:50:13 -0700
 Subject: [sup-talk] Nobody told me
 In-Reply-To: <1e5fdab70908281401k7f0b59ectb38ce7dfe7280569@mail.gmail.com>
 References: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com>
 	<1251491725-sup-284@masanjin.net>
 	<1e5fdab70908281401k7f0b59ectb38ce7dfe7280569@mail.gmail.com>
 Message-ID: <1251899343-sup-1025@masanjin.net>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-08-28:
 > 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)
 
 If anyone else has been having memory usage problems on the next branch
 recently (probably when sup-syncing a large mbox file), they should be
 fixed now. I've unmerged the after-add hook, which was the culprit.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep  2 09:53:17 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 02 Sep 2009 06:53:17 -0700
 Subject: [sup-talk] [PATCH] Add an after-add-message hook
 In-Reply-To: <1251153881-sup-1538@masanjin.net>
 References: <1250707991-sup-5429@masanjin.net>
 	<1250819862-4858-1-git-send-email-kevinr@free-dissociation.com>
 	<1251153881-sup-1538@masanjin.net>
 Message-ID: <1251899447-sup-1658@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-08-24:
 > Branch after-add-message-hook, merged into next. Thanks!
 
 I've had to unmerge this, because keeping all the messages around led to
 memory problems with large mailboxes.
 
 What about just using the before-add hook and either backgrounding the
 process (if it's a separate process) or doing the processing in a Thread
 (if it's Ruby code)?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marco-oweber@gmx.de  Thu Sep  3 10:24:32 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Thu, 03 Sep 2009 16:24:32 +0200
 Subject: [sup-talk] Trouble loading dump into Xapian index
 Message-ID: <1251987692-sup-9940@nixos>
 
 I've used this sh script to get a new SUP_BASE using xapian only:
 However somehow i couldn't import the tags? What have I done wrong?
 dump2: The dump file created from the xapian index.
 
   set -x
   OLD=~/.sup-old/
   NEW=~/.sup-new-test
   DUMP=/tmp/dump-file-new
   DUMP2=/tmp/dump-file-new2
   SYNC_LOG=/tmp/sup-sync-log
   GIT_REPO=~/managed_repos/sup_mainline
 
   rm -fr $NEW
 
   export SUP_BASE=$OLD
   sup-dump > $DUMP
 
   # from now on operate on the new base only
   export SUP_BASE=$NEW
   cp -r $OLD $NEW
   rm -fr $NEW/ferret
   mv $NEW/{hooks,hooks-disabled}
 
   # echo loading stuff..
   export SUP_INDEX=xapian
   cd $GIT_REPO 
   echo "syncing.. this will take long. use tail -f $SYNC_LOG to watch progress"
   ruby -Ilib bin/sup-sync --all --all-sources --restore $DUMP &> $SYNC_LOG
 
   echo "writing dump"
   ruby -Ilib bin/sup-dump > $DUMP2
 
 
 dump: (first line after sorting)
 000001c9fe57$346bf530$9d43df90$@com.au (unread openeeg)
 
 dump2: (first line after sorting)
 000001c9fe57$346bf530$9d43df90$@com.au (inbox unread)
 
 Marc Weber
 
 From amit.kucheria@gmail.com  Thu Sep  3 10:26:40 2009
 From: amit.kucheria@gmail.com (Amit Kucheria)
 Date: Thu, 3 Sep 2009 17:26:40 +0300
 Subject: [sup-talk] Dynamic list of maildir folders as sources
 Message-ID: <20090903142640.GB4465@matterhorn.verdurent.com>
 
 Hi,
 
 I've been watching sup for a while and finally decided to take the plunge
 today.  Apologies for the long-winded explanation before the real question,
 but I guess if something in my workflow could be optimised, someone might be
 able to point it out here.
 
 I'll be running sup on a bunch of maildir folders downloaded via offlineimap.
 
 All my mail comes as IMAP from 3 gmail accounts. When I subscribe to a new
 mailing list, I simply create a new filter in gmail to add a new tag to email
 from that list and skip the inbox. This shows up as a new maildir folder on my
 local machine.
 
 Mutt finds this new folder using the following folder-hook hack I have in my
 .muttrc:
 
 folder-hook +foo.* mailboxes `find ~/Mail/foo -type d
 -name cur -type d -printf '%h\n' | sort | tr '\012' ' '`
 
 , where foo is one of my mailboxes. So I have ~/Mail/bar and ~/Mail/foobar for
 my other accounts. Each of these have several maildir folder in them.
 
 I've run sup-config and it seems to expect that I list every maildir folder
 I've got. Is there a way to generate this dynamically?
 
 Regards,
 Amit
 p.s. sup-sync has been at it on my lkml folder with ~40K mail messages for
 30mins now.
 -- 
 ------------------------------------------------------------
 Amit Kucheria
 ------------------------------------------------------------
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 11:25:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 08:25:50 -0700
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1251987692-sup-9940@nixos>
 References: <1251987692-sup-9940@nixos>
 Message-ID: <1251991420-sup-3869@masanjin.net>
 
 Reformatted excerpts from Marc Weber's message of 2009-09-03:
 > I've used this sh script to get a new SUP_BASE using xapian only:
 > However somehow i couldn't import the tags? What have I done wrong?
 
 This *might* be related to a patch that Rich sent that I thought I had
 applied, but apparently did not. Can you try once more with the latest
 master? If it still doesn't work we'll take it from there. (Also, check
 that the number of messages sup-sync reports it has restored state on is
 the number of messages you'd expect, e.g. roughly the number of lines in
 the dumpfile.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 11:37:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 08:37:50 -0700
 Subject: [sup-talk] Dynamic list of maildir folders as sources
 In-Reply-To: <20090903142640.GB4465@matterhorn.verdurent.com>
 References: <20090903142640.GB4465@matterhorn.verdurent.com>
 Message-ID: <1251991617-sup-9735@masanjin.net>
 
 Reformatted excerpts from Amit Kucheria's message of 2009-09-03:
 > I've been watching sup for a while and finally decided to take the
 > plunge today.
 
 Welcome!
 
 > I've run sup-config and it seems to expect that I list every maildir
 > folder I've got. Is there a way to generate this dynamically?
 
 If you can generate the list (e.g. with the find command you cited), you
 can add maildir sources with sup-add directly, instead of having to go
 through sup-config.
 
 If you want to automatically detect and add new folders, we could d
 something similar in the startup hook. Something like (completely
 untested):
 
   dirs = `find ~/Mail/whatever...`
   dirs.each do |d|
     uri = "maildir:#{d}"
     log "trying #{uri}..."
     unless SourceManager.source_for uri
       source = Maildir.new uri
       SourceManager.add_source source
       log "Added #{uri}"
     end
   end
 
 > p.s. sup-sync has been at it on my lkml folder with ~40K mail messages
 > for 30mins now.
 
 Yep, indexing stuff is slow. FWIW, you only have to do it once, and
 there are new index backends that are significantly faster. (But still
 far from instantaneous.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marco-oweber@gmx.de  Thu Sep  3 12:21:31 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Thu, 03 Sep 2009 18:21:31 +0200
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1251991420-sup-3869@masanjin.net>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 Message-ID: <1251994802-sup-8575@nixos>
 
 Hi William.
 
 I guess it was.
 
 The second dump looks very similar to the first one now.
 Only the order of flags is different now which doesn't matter.
 
 However threads which have been killed do show up in inbox:
 http://mawercer.de/~marc/sup.png
 All seven mails of the first thread are labeled by
   killed inbox deleted
 
 So they shouldn't appear, should they?
 
 Same happens to thread where all mails are labeled by 
   killed, inbox
 
 Did the view behaviour change here?
 
 Sincerly
 Marc
 
 From mzulak@gmail.com  Thu Sep  3 12:38:53 2009
 From: mzulak@gmail.com (Matt Zulak)
 Date: Thu,  3 Sep 2009 12:38:53 -0400
 Subject: [sup-talk] [PATCH] decrypt returns 3 elem array if gpg is
 	unavailable
 Message-ID: <1251995933-2252-1-git-send-email-mzulak@gmail.com>
 
 CryptoManager's decrypt method returns a CryptoNotice if the GPG binary
 can't be found on the path; however, the Message class expects a 3
 element array with either a RMail::Message or nil at index 0.
 This patch ensures sup plays nice when importing encrypted messages from
 a mail-store on an environment that does not have GPG.
 ---
  lib/sup/crypto.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
 index 7f044b9..afbc445 100644
 --- a/lib/sup/crypto.rb
 +++ b/lib/sup/crypto.rb
 @@ -105,7 +105,7 @@ class CryptoManager
  
    ## returns decrypted_message, status, desc, lines
    def decrypt payload # a RubyMail::Message object
 -    return unknown_status(cant_find_binary) unless @cmd
 +    return [nil, nil, unknown_status(cant_find_binary)] unless @cmd
  
      payload_fn = Tempfile.new "redwood.payload"
      payload_fn.write payload.to_s
 -- 
 1.6.2.1
 
 
 From rlane@club.cc.cmu.edu  Thu Sep  3 12:42:55 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 03 Sep 2009 12:42:55 -0400
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1251994802-sup-8575@nixos>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 	<1251994802-sup-8575@nixos>
 Message-ID: <1251995984-sup-7983@zyrg.net>
 
 Excerpts from Marc Weber's message of Thu Sep 03 12:21:31 -0400 2009:
 > However threads which have been killed do show up in inbox:
 > http://mawercer.de/~marc/sup.png
 > All seven mails of the first thread are labeled by
 >   killed inbox deleted
 > 
 > So they shouldn't appear, should they?
 > 
 > Same happens to thread where all mails are labeled by 
 >   killed, inbox
 > 
 > Did the view behaviour change here?
 
 I added support for thread killing in 4d82ef88, which hasn't been merged
 to master yet. If you'd like to use the Xapian index I suggest using
 next for now.
 
 From rlane@club.cc.cmu.edu  Thu Sep  3 12:52:27 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 03 Sep 2009 12:52:27 -0400
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1251792282-sup-2057@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> <1248713376-sup-5163@cannonball>
 	<1251792282-sup-2057@cannonball>
 Message-ID: <1251996241-sup-5112@zyrg.net>
 
 Excerpts from Ingmar Vanhassel's message of Tue Sep 01 04:07:27 -0400 2009:
 > Excerpts from Ingmar Vanhassel's message of Mon Jul 27 18:56:28 +0200 2009:
 > > Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 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? ('@')
 > > 
 > > It's true in both cases. Even after a sync, 'U' still produces read
 > > messages (among unread), and a search for label:foo has threads without
 > > that label. If you quit sup & restart it things work as expected for a
 > > while.
 > 
 > I can still reproduce this for a more specific case, with xapian 1.0.15.
 > 
 > Searching for is:unread (hit U), works as expected. When I filter
 > that with threads having a second label (hit |, label:foo), then it
 > shows threads with label:foo, but it loses the is:unread constraint.
 > 
 > Same for immediately doing is:unread label:foo, which gives me unread
 > threads, but not always with the foo label.
 
 I've reproduced this and it looks like a query parsing problem. Multiple
 terms on the same field are OR'd together instead of AND [1]. Adding an
 explicit AND works. I'll see if Xapian::QueryParser can be convinced to
 do what we want here.
 
 [1] http://trac.xapian.org/ticket/157
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 13:12:25 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 10:12:25 -0700
 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the
 	left column
 In-Reply-To: <1251323127-sup-5162@yoom.home.cworth.org>
 References: <1250749447-sup-1744@yoom.home.cworth.org>
 	<1251050007-sup-9740@masanjin.net>
 	<1251323127-sup-5162@yoom.home.cworth.org>
 Message-ID: <1251997795-sup-8368@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-26:
 > And I still haven't figured out what loose_alignment means and which
 > actions will cause loose vs. non-loose layout.
 
 Yeah, it's not really clear where I was going with that. The whole thing
 was in need of some rethinking and additional comments. I've made a
 branch 'alignment-tweaks', merged into next, which I think has the
 behavior you were looking for: left-column movement is minimized when
 using 'n' and 'p' to jump between messages. You can also use 'z' to
 align the left column with the current message.
 
 Check it out and let me know what you think. If this bugs people, also
 let me know. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 13:13:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 10:13:59 -0700
 Subject: [sup-talk] sup crashed: NoMethodError
 In-Reply-To: <20090828225041.GA22963@gmail.com>
 References: <20090827200317.GA3065@gmail.com>
 	<1251492008-sup-6128@masanjin.net>
 	<20090828225041.GA22963@gmail.com>
 Message-ID: <1251997975-sup-8342@masanjin.net>
 
 Reformatted excerpts from Sean Escriva's message of 2009-08-28:
 > was my install process wrong for switching to the git -next branch?
 
 Nope, it was fine. Transitioning between master and next should
 generally be painless.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 13:16:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 10:16:41 -0700
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1251995984-sup-7983@zyrg.net>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 	<1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net>
 Message-ID: <1251998177-sup-3432@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-03:
 > I added support for thread killing in 4d82ef88, which hasn't been
 > merged to master yet. If you'd like to use the Xapian index I suggest
 > using next for now.
 
 If you feel it's reasonably stable, I can merge it into master.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marco-oweber@gmx.de  Thu Sep  3 13:26:59 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Thu, 03 Sep 2009 19:26:59 +0200
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1251995984-sup-7983@zyrg.net>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 	<1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net>
 Message-ID: <1251998504-sup-6794@nixos>
 
 
 > I added support for thread killing in 4d82ef88, which hasn't been merged
 > to master yet. If you'd like to use the Xapian index I suggest using
 > next for now.
 
 Hi Rich, using next I get the following error:
 
 + ruby -Ilib bin/sup-sync --all --all-sources --restore /tmp/dump-file-new
 ./lib/sup/crypto.rb:17: warning: Insecure world writable dir /pr/webkos
 in PATH, mode 040777
 Loading state dump from /tmp/dump-file-new...
 Read 39048 entries from dump file.
 ./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
 
 I looked at strace to and noticed that sup only accessed the new
 ~/.sup-new-test direcotry which was empty. So there is no v0 at all)
 
 Marc Weber
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 13:58:16 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 10:58:16 -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: <1252000456-sup-1452@masanjin.net>
 
 Both of these patches are on the branch preemptive-loading, merged into
 next. Thanks! It's a nice touch.
 
 I didn't really notice any differe from thread prioritization and
 Thread.pass call, but maybe that's my setup. Regardless, it can't hurt.
 
 I also reworked the load-more callback mechanism to be a little more
 thread safe and a little less insane. Now it uses a queue and has a
 dedicated loader thread pulling things off of it. Message thread loading
 is currently configured to just drop concurrent calls, so it should work
 fine.
 
 Now, all we need is a faster cursor in thread-index-mode. I will grant a
 Sup medal to anyone who can make that happen!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 14:06:55 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 11:06:55 -0700
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1251325542-sup-3105@yoom.home.cworth.org>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 Message-ID: <1252000831-sup-9922@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-26:
 > These behave identically to the existing ",a" and ",d" commands, (that
 > is they archive or delete the current thread and then view the next).
 
 Sorry it's taken me so long to look at this. Thanks for the patch!
 
 I'm curious what other people think about this. On the one hand, it's
 only additional keybindings, so it's not going to adversely affect
 anyone. On the other hand, there is a nice balance with the ".", ","
 and "]" commands which this disrupts, and it can't be extended to the
 other commands from thread-index-mode. And on the third hand, I'm happy
 to have keybinding hooks.
 
 I guess if most people primarily closes their thread-view-modes using
 ",a" and ",d", then I'm fine with this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 14:32:54 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 11:32:54 -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: <1252002193-sup-3879@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-26:
 > 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
 
 is_relevant? is currently only used for determining when to add messages
 to a thread-index-mode (e.g. when a new message is picked up during a
 poll). Determining whether to drop a message is currently done
 "manually" by inbox-mode, and not at all by search-results-mode.
 
 > That single-message index and search sounds exactly like what I want,
 > and not insane at all.
 
 Hm. Well, you could certainly try it. I've assumed it would be too slow,
 but it's possible it'd be fast enough. I think it's the only option
 though, if you want this to work with arbitrary queries.
 
 > (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.)
 
 Excellent, ask Rich. :)
 
 > 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.
 
 Yeah, there's no good reason for this. I was just being overly
 protective. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Thu Sep  3 14:35:05 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 03 Sep 2009 14:35:05 -0400
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1251998504-sup-6794@nixos>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 	<1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net>
 	<1251998504-sup-6794@nixos>
 Message-ID: <1252002797-sup-6522@zyrg.net>
 
 Excerpts from Marc Weber's message of Thu Sep 03 13:26:59 -0400 2009:
 > 
 > > I added support for thread killing in 4d82ef88, which hasn't been merged
 > > to master yet. If you'd like to use the Xapian index I suggest using
 > > next for now.
 > 
 > Hi Rich, using next I get the following error:
 > 
 > + ruby -Ilib bin/sup-sync --all --all-sources --restore /tmp/dump-file-new
 > ./lib/sup/crypto.rb:17: warning: Insecure world writable dir /pr/webkos
 > in PATH, mode 040777
 > Loading state dump from /tmp/dump-file-new...
 > Read 39048 entries from dump file.
 > ./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
 > 
 > I looked at strace to and noticed that sup only accessed the new
 > ~/.sup-new-test direcotry which was empty. So there is no v0 at all)
 
 That's strange, because this codepath (xapian_index.rb:32) is only hit
 when the xapian directory already exists. Can you add a log message to
 output the "path" variable and see if it looks correct?
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 14:36:42 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 11:36:42 -0700
 Subject: [sup-talk] On making inbox-mode and search-results-mode more
 	similar
 In-Reply-To: <1251341286-sup-9400@zyrg.net>
 References: <1251323747-sup-1595@yoom.home.cworth.org>
 	<1251341286-sup-9400@zyrg.net>
 Message-ID: <1252002783-sup-3659@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-08-26:
 > 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.
 
 But it's not just a label issue. Determining whether a given message
 belongs in a general search buffer requires the full engine. And even if
 the query is just on labels, it can contain arbitrary boolean
 expressions, and I don't want to be the one having to parse that, and
 parse it in such a way that it matches what the search engine is doing.
 
 > I have a patch I plan to mail out soon that makes changing labels with
 > Xapian much quicker, so that should help.
 
 This is definitely good, either way.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 14:39:58 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 11:39:58 -0700
 Subject: [sup-talk] On making inbox-mode and search-results-mode more
 	similar
 In-Reply-To: <1251327030-sup-7342@yoom.home.cworth.org>
 References: <1251323747-sup-1595@yoom.home.cworth.org>
 	<1251327030-sup-7342@yoom.home.cworth.org>
 Message-ID: <1252003008-sup-8596@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-26:
 > 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?
 
 Instead of -label:killed, you want to specify :skip_killed to
 #load_thread. Killed messages require special semantics.
 
 > 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?)
 
 There is not a consistent one, though there might be something useful on
 the wiki. The general answer is, whatever Ferret/Xapian supports, plus
 the tweaks in #parse_query.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Thu Sep  3 14:44:06 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 03 Sep 2009 14:44:06 -0400
 Subject: [sup-talk] On making inbox-mode and search-results-mode more
 	similar
 In-Reply-To: <1252002783-sup-3659@masanjin.net>
 References: <1251323747-sup-1595@yoom.home.cworth.org>
 	<1251341286-sup-9400@zyrg.net> <1252002783-sup-3659@masanjin.net>
 Message-ID: <1252003316-sup-2379@zyrg.net>
 
 Excerpts from William Morgan's message of Thu Sep 03 14:36:42 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-08-26:
 > > 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.
 > 
 > But it's not just a label issue. Determining whether a given message
 > belongs in a general search buffer requires the full engine. And even if
 > the query is just on labels, it can contain arbitrary boolean
 > expressions, and I don't want to be the one having to parse that, and
 > parse it in such a way that it matches what the search engine is doing.
 
 You're right that it require the full engine. If we're immediately
 saving the label changes to the (on-disk) index, we can simply query it
 and get the correct answer.
 
 From marka@pobox.com  Thu Sep  3 14:37:34 2009
 From: marka@pobox.com (Mark Alexander)
 Date: Thu, 03 Sep 2009 14:37:34 -0400
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252000831-sup-9922@masanjin.net>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net>
 Message-ID: <1252002852-sup-8688@r50p>
 
 Excerpts from William Morgan's message of Thu Sep 03 14:06:55 -0400 2009:
 > I guess if most people primarily closes their thread-view-modes using
 > ",a" and ",d", then I'm fine with this.
 
 Those are perhaps my most-commonly used commands in sup, so having
 them shortened is a very nice improvement.
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 14:47:19 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 11:47:19 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1251387376-sup-7180@javelin>
 References: <1251387376-sup-7180@javelin>
 Message-ID: <1252003380-sup-272@masanjin.net>
 
 I'm not sure how I feel about this patch. The semantics of being killed
 are very tied to the inbox. I'm reluctant to start spreading them to
 other types of buffers.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 14:50:25 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 11:50:25 -0700
 Subject: [sup-talk] On making inbox-mode and search-results-mode more
 	similar
 In-Reply-To: <1252003316-sup-2379@zyrg.net>
 References: <1251323747-sup-1595@yoom.home.cworth.org>
 	<1251341286-sup-9400@zyrg.net> <1252002783-sup-3659@masanjin.net>
 	<1252003316-sup-2379@zyrg.net>
 Message-ID: <1252003719-sup-1602@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-03:
 > You're right that it require the full engine. If we're immediately
 > saving the label changes to the (on-disk) index, we can simply query
 > it and get the correct answer.
 
 Oh, as opposed to a new in-memory index. Yeah.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Thu Sep  3 14:57:14 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 03 Sep 2009 14:57:14 -0400
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252003380-sup-272@masanjin.net>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 Message-ID: <1252004144-sup-6662@javelin>
 
 Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009:
 > I'm not sure how I feel about this patch. The semantics of being killed
 > are very tied to the inbox. I'm reluctant to start spreading them to
 > other types of buffers.
 
 The reason why I request this is because I have a distinction between
 unread messages in my inbox and unread messages not in my inbox and
 unread messages that are killed.  The 1st is for messages that I
 should read (or at least ack), the second is for mailing list messages
 and the third is for "I don't actually ever want to see this again,
 no really".
 
 Cheers,
 Edward
 
 From me@nicholasbs.net  Thu Sep  3 14:58:45 2009
 From: me@nicholasbs.net (Nicholas Bergson-Shilcock)
 Date: Thu, 03 Sep 2009 14:58:45 -0400
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252002852-sup-8688@r50p>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net> <1252002852-sup-8688@r50p>
 Message-ID: <1252004295-sup-6234@twoface>
 
 Excerpts from Mark Alexander's message of Thu Sep 03 14:37:34 -0400 2009:
 > Excerpts from William Morgan's message of Thu Sep 03 14:06:55 -0400 2009:
 > > I guess if most people primarily closes their thread-view-modes using
 > > ",a" and ",d", then I'm fine with this.
 > 
 > Those are perhaps my most-commonly used commands in sup, so having
 > them shortened is a very nice improvement.
 
 +1. These would be quite helpful for me.
 
 From wmorgan-sup@masanjin.net  Thu Sep  3 14:58:55 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 03 Sep 2009 11:58:55 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252004144-sup-6662@javelin>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin>
 Message-ID: <1252004285-sup-476@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
 > The 1st is for messages that I should read (or at least ack), the
 > second is for mailing list messages and the third is for "I don't
 > actually ever want to see this again, no really".
 
 What if you just delete messages in the the third condition?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Thu Sep  3 15:01:55 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 03 Sep 2009 15:01:55 -0400
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252004285-sup-476@masanjin.net>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net>
 Message-ID: <1252004504-sup-3189@javelin>
 
 Excerpts from William Morgan's message of Thu Sep 03 14:58:55 -0400 2009:
 > Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
 > > The 1st is for messages that I should read (or at least ack), the
 > > second is for mailing list messages and the third is for "I don't
 > > actually ever want to see this again, no really".
 > 
 > What if you just delete messages in the the third condition?
 
 Then replies show up. :-)
 
 Cheers,
 Edward
 
 From bwalton@artsci.utoronto.ca  Thu Sep  3 15:13:15 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 03 Sep 2009 15:13:15 -0400
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252003380-sup-272@masanjin.net>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 Message-ID: <1252005121-sup-3946@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009:
 > I'm not sure how I feel about this patch. The semantics of being killed
 > are very tied to the inbox. I'm reluctant to start spreading them to
 > other types of buffers.
 
 The 'U' key binding just drives a preset search.  This wouldn't be
 spreading the special status of killed into other buffer types more
 than a manual search using the same terms.
 
 -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/20090903/e97c30e8/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Thu Sep  3 15:25:03 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 03 Sep 2009 15:25:03 -0400
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1251388546-sup-7744@javelin>
 References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin>
 Message-ID: <1252005520-sup-9555@zyrg.net>
 
 Excerpts from Edward Z. Yang's message of Thu Aug 27 11:56:32 -0400 2009:
 > 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.
 
 By default Index#load_messages_in_thread_for does skip killed threads,
 so you should already have the behavior you want without modifying the
 query (unless you're using an old xapian-index version that doesn't
 support killed threads). Adding a !label:killed term will actually cause
 threads that are "killed" (have at least one message labeled killed) but
 also have a message not labeled killed that matches the query to be
 displayed, which I don't think is the behavior you're looking for.
 
 From cworth@cworth.org  Thu Sep  3 19:06:50 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 03 Sep 2009 16:06:50 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252005520-sup-9555@zyrg.net>
 References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin>
 	<1252005520-sup-9555@zyrg.net>
 Message-ID: <1252010283-sup-4453@yoom.home.cworth.org>
 
 Excerpts from Rich Lane's message of Thu Sep 03 12:25:03 -0700 2009:
 > By default Index#load_messages_in_thread_for does skip killed threads,
 > so you should already have the behavior you want without modifying the
 > query (unless you're using an old xapian-index version that doesn't
 > support killed threads). Adding a !label:killed term will actually cause
 > threads that are "killed" (have at least one message labeled killed) but
 > also have a message not labeled killed that matches the query to be
 > displayed, which I don't think is the behavior you're looking for.
 
 Wow, that's surprising!
 
 But thanks for explaining that since that's the exact behavior I've
 been getting since I starting using queries with "!label:killed" in
 them, (I'm trying to get views that act like filtered versions of the
 inbox).
 
 Excerpts from William Morgan's message of Thu Sep 03:
 > I'm not sure how I feel about this patch. The semantics of being killed
 > are very tied to the inbox. I'm reluctant to start spreading them to
 > other types of buffers.
 
 William, perhaps you can take this chance to explain something to
 me. I've been trying to figure out the philosophy and the mechanics of
 sup labels and searching.
 
 >From the point-of-view of a naive user it has seemed to me like the
 philosophy is that threads are the primary objects so all labels apply
 to a thread as a whole, and all searches return results consisting of
 entire threads. And this all seems very good to me.
 
 But the above discussion of "killed" suggests that the mechanics
 aren't at all like that. But that instead, labels are applied to
 individual messages, and searches match individual messages and then
 construct threads from the results. Is that more or less how things
 work?
 
 So is there a mismatch between the philosophy and the mechanics, or
 did I just misunderstand the philosophy?
 
 That is, do current users of sup ever distinguish between searching
 for messages with specific labels as opposed to searching for threads
 that contain messages with specific labels?
 
 If not, it seems like it would be possible for a query like
 "!label:killed" to do exactly what is wanted without needing any
 special treatment for killed internally. And I'd like this, because I
 would sometimes want to do a similar negative filter based on my own
 custom labels.
 
 Does that make sense?
 
 -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/20090903/b204c976/attachment.bin>
 
 From richard@infoarts.info  Thu Sep  3 19:08:11 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Fri, 4 Sep 2009 09:08:11 +1000
 Subject: [sup-talk] Can't add source when tracking next
 Message-ID: <20090903230808.GA2983@114.73.135.126.optusnet.com.au>
 
 Hi there
 
 I'm tracking next via git and am having trouble adding a mail source.
 
 I've removed any existing ~/.sup directory, then run sup-config and
 all is OK until sup-config runs sup-add maildir when I get this
 message:
 
 "Ok, trying to run "/Users/richard/src/sup/bin/sup-add
 maildir:/Users/richard/mail/gmail/INBOX"...
 /Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for
 false:FalseClass (NoMethodError)
        from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
 `gem_original_require'
        from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
        from /Users/richard/src/sup/lib/sup.rb:277
        from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
 `gem_original_require'
        from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
        from /Users/richard/src/sup/bin/sup-add:7
 
 So I'm thinking this might have something to do with my environment
 setup on OS X.
 
 I'm running sup from ~/src/sup and am mirroring my gmail mail to
 ~/mail/gmail via offlineimap - this all seems fine.
 
 I've  added: 'export RUBYLIB="~/src/sup/lib" ' to my .bash_profile but
 it still fails on the 'require "sup"' line in sup-add
 
 I've checked that I have all the required gem dependencies and that
 seems fine too.
 
 And I installed the sup-999 gems.
 
 What could I be missing here?
 
 Any clues appreciated...
 
 --
 Richard
 
 From bwalton@artsci.utoronto.ca  Thu Sep  3 22:13:11 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 03 Sep 2009 22:13:11 -0400
 Subject: [sup-talk] more xapian/label woes
 Message-ID: <1252030139-sup-6351@ntdws12.chass.utoronto.ca>
 
 
 Hi All,
 
 I've tried the xapian conversion again and am now back in ferret
 land.  In this case, I don't think the issues are xapian related...it
 seems to the labels that are biting me again.
 
 I get exceptions with non-Symbol labels being passed around again.  To
 finish the import of my ferret dumpfile, I had to do the following:
 
 --snip--
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 1395601..4b3b022 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -111,7 +111,7 @@ class XapianIndex < BaseIndex
        :replytos => (entry[:replytos] || m.replytos),
      }
  
 -    labels.each { |l| LabelManager << l }
 +    labels.each { |l| LabelManager << l.to_sym }
 --snip--
 
 This got me to the point where I could fire up sup with
 SUP_INDEX=xapian, but the initial poll caused the attached exception.
 I wonder if LabelManager should simply call .to_sym (.intern) on
 everything passed to it?  That's a big hammer, I realize...maybe
 .to_sym/.intern in cases where the unexpected object is a String?
 
 Thoughts?
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090903/48d07caf/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/20090903/48d07caf/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Fri Sep  4 09:56:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 04 Sep 2009 06:56:41 -0700
 Subject: [sup-talk] [PATCH] Identify list messages by list-id if
 	list-post is not present
 In-Reply-To: <1251794935-sup-3802@elly>
 References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net>
 	<1251794935-sup-3802@elly>
 Message-ID: <1252072500-sup-8128@masanjin.net>
 
 Reformatted excerpts from Israel Herraiz's message of 2009-09-01:
 > Yes, although list-id is not an address (it does not contain the "@"
 > symbol for instance). But I am happy with that patch :-).
 
 Actually you're right. I think I prefer your patch. But based on the
 code, it seems like reply-mode would crash if it got a message that
 claims it's a list message but doesn't have a list address. Does it
 actually work?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Sep  4 10:34:11 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 04 Sep 2009 07:34:11 -0700
 Subject: [sup-talk] [PATCH] decrypt returns 3 elem array if gpg is
 	unavailable
 In-Reply-To: <1251995933-2252-1-git-send-email-mzulak@gmail.com>
 References: <1251995933-2252-1-git-send-email-mzulak@gmail.com>
 Message-ID: <1252074791-sup-9657@masanjin.net>
 
 Reformatted excerpts from Matt Zulak's message of 2009-09-03:
 > CryptoManager's decrypt method returns a CryptoNotice if the GPG
 > binary can't be found on the path; however, the Message class expects
 > a 3 element array with either a RMail::Message or nil at index 0.
 
 Thanks. I've fixed this in a slightly different way, by returning the
 notice as the first element. I think the code is a little easier to read
 that way. Let me know if it doesn't work.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Sep  4 10:41:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 04 Sep 2009 07:41:49 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252010283-sup-4453@yoom.home.cworth.org>
 References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin>
 	<1252005520-sup-9555@zyrg.net>
 	<1252010283-sup-4453@yoom.home.cworth.org>
 Message-ID: <1252074924-sup-1994@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-09-03:
 > But the above discussion of "killed" suggests that the mechanics
 > aren't at all like that. But that instead, labels are applied to
 > individual messages, and searches match individual messages and then
 > construct threads from the results. Is that more or less how things
 > work?
 
 Yes. That's why killed is special; it requires work at threading time to
 drop threads in which any message has a killed label, regardless of
 whether that's the message that matched the query.
 
 > So is there a mismatch between the philosophy and the mechanics, or
 > did I just misunderstand the philosophy?
 
 Not sure. Maybe both. :) The philosophy is more about the UI, IMO, than
 specific implementation details (though obviosuly there's some
 trickle-up).
 
 The other way to implement this, FWIW, is to have labels automatically
 spread to all messages in a thread when they're applied. I think that is
 probably a better implementation, though it increases the cost at
 labeling time. I've been toying with this idea in the sup server code.
 
 > If not, it seems like it would be possible for a query like
 > "!label:killed" to do exactly what is wanted without needing any
 > special treatment for killed internally.
 
 I think the above implementation would allow this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Fri Sep  4 11:12:01 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Fri, 04 Sep 2009 08:12:01 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252074924-sup-1994@masanjin.net>
 References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin>
 	<1252005520-sup-9555@zyrg.net>
 	<1252010283-sup-4453@yoom.home.cworth.org>
 	<1252074924-sup-1994@masanjin.net>
 Message-ID: <1252076900-sup-274@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Fri Sep 04 07:41:49 -0700 2009:
 > Yes. That's why killed is special; it requires work at threading time to
 > drop threads in which any message has a killed label, regardless of
 > whether that's the message that matched the query.
 
 Good. I'm glad I'm at least understanding how things work here.
 
 > The other way to implement this, FWIW, is to have labels automatically
 > spread to all messages in a thread when they're applied. I think that is
 > probably a better implementation, though it increases the cost at
 > labeling time. I've been toying with this idea in the sup server code.
 > 
 > > If not, it seems like it would be possible for a query like
 > > "!label:killed" to do exactly what is wanted without needing any
 > > special treatment for killed internally.
 > 
 > I think the above implementation would allow this.
 
 Yes, that would do the trick. It would require extra work both at the
 time a label is attached to a message and then again at the time a new
 message is associated with an existing thread. But it would give me
 the behavior I want "for free" after that.
 
 If such an implementation would be acceptable, then it would seem that
 a better long-term solution would be to apply labels only to "thread
 objects" and to index and search for those rather than individuals
 messages (at least as far as label searching goes). Of course, I'm
 talking from an entirely naive point-of-view with regard to the
 implementation impact of such a change, but I would imagine it
 wouldn't be trivial.
 
 -Carl
 
 From wmorgan-sup@masanjin.net  Fri Sep  4 11:22:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 04 Sep 2009 08:22:21 -0700
 Subject: [sup-talk] Can't add source when tracking next
 In-Reply-To: <20090903230808.GA2983@114.73.135.126.optusnet.com.au>
 References: <20090903230808.GA2983@114.73.135.126.optusnet.com.au>
 Message-ID: <1252077695-sup-9520@masanjin.net>
 
 Reformatted excerpts from Richard Sandilands's message of 2009-09-03:
 > "Ok, trying to run "/Users/richard/src/sup/bin/sup-add
 > maildir:/Users/richard/mail/gmail/INBOX"...
 > /Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for
 > false:FalseClass (NoMethodError)
 
 Whoops, this was a bug. I've fixed it in next, if you want to try again.
 You may have to delete your ~/.sup/config.yaml file (it will yell at you
 if so.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Sep  4 11:30:11 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 04 Sep 2009 08:30:11 -0700
 Subject: [sup-talk] more xapian/label woes
 In-Reply-To: <1252030139-sup-6351@ntdws12.chass.utoronto.ca>
 References: <1252030139-sup-6351@ntdws12.chass.utoronto.ca>
 Message-ID: <1252077954-sup-8898@masanjin.net>
 
 Reformatted excerpts from Ben Walton's message of 2009-09-03:
 > I get exceptions with non-Symbol labels being passed around again.  To
 > finish the import of my ferret dumpfile, I had to do the following:
 
 Is this with a recent next, and after deleting any vestigal
 ~/.sup/xapian directory and .db files? If so, there really shouldn't be
 any label issues. If there are, can you attach the original exception?
 Also, does your sources.yaml file have something weird for labels?
 
 > This got me to the point where I could fire up sup with
 > SUP_INDEX=xapian, but the initial poll caused the attached exception.
 > I wonder if LabelManager should simply call .to_sym (.intern) on
 > everything passed to it?
 
 Certainly an option, but I'm hoping to keep the "fail fast" behavior for
 now since it is revealing underlying problems.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Sep  4 11:53:12 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 04 Sep 2009 08:53:12 -0700
 Subject: [sup-talk] [PATCH] handle malformed multiplart messages
 In-Reply-To: <20090728165823.GA29533@solar.cslab.ece.ntua.gr>
 References: <20090728165823.GA29533@solar.cslab.ece.ntua.gr>
 Message-ID: <1252079569-sup-6888@masanjin.net>
 
 Reformatted excerpts from Kornilios Kourtis's message of 2009-07-28:
 > I've tried to use sup-mail, but sup-sync blows up due to some malformed
 > messages I keep in my mailbox. Below is a quick patch that seems to fix the
 > above issue for me.
 
 Sorry for the delay. I think this is good. Applied. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marco-oweber@gmx.de  Fri Sep  4 12:25:39 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Fri, 04 Sep 2009 18:25:39 +0200
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1252002797-sup-6522@zyrg.net>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 	<1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net>
 	<1251998504-sup-6794@nixos> <1252002797-sup-6522@zyrg.net>
 Message-ID: <1252081334-sup-213@nixos>
 
 Sorry.
 
 It was my fault. I had a ~/.sup/xapian I forgot about. That made the
 trouble causing the correct error message.
 
 So I think it's safe to switch to Xapian. You may use this script.
 It will copy the existing  ~/.sup and create a new directory $NEW with
 the xapian index. You cane set SUP_BASE to run the new sup to try it
 out. Next feels so much better in various ways (speed, search in threads etc.)
 
 Thanks for your all this work!
 
   set -x
   set -e
   OLD=~/.sup
   NEW=/pr/sup-new-test
   DUMP=/tmp/dump-file-new
   DUMP2=/tmp/dump-file-new2
   SYNC_LOG=/tmp/sup-sync-log
   GIT_REPO=~/managed_repos/sup_mainline
 
   rm -fr $NEW
 
   export SUP_BASE=$OLD
   sup-dump > $DUMP
 
   # from now on operate on the new base only
   export SUP_BASE=$NEW
   cp -r $OLD $NEW
   rm -fr $NEW/ferret
   rm -fr $NEW/xapian # remove old xapian cruft!
   mv $NEW/{hooks,hooks-disabled}
 
   # echo loading stuff..
   export SUP_INDEX=xapian
   cd $GIT_REPO 
   echo "syncing.. this will take long. use tail -f $SYNC_LOG to watch progress"
   ruby -Ilib bin/sup-sync --all --all-sources --restore $DUMP &> $SYNC_LOG
 
   echo "writing dump"
   ruby -Ilib bin/sup-dump # > $DUMP2
 
 Marc Weber
 
 From rlane@club.cc.cmu.edu  Fri Sep  4 13:00:57 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 04 Sep 2009 13:00:57 -0400
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1251998177-sup-3432@masanjin.net>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 	<1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net>
 	<1251998177-sup-3432@masanjin.net>
 Message-ID: <1252083532-sup-2011@zyrg.net>
 
 Excerpts from William Morgan's message of Thu Sep 03 13:16:41 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-09-03:
 > > I added support for thread killing in 4d82ef88, which hasn't been
 > > merged to master yet. If you'd like to use the Xapian index I suggest
 > > using next for now.
 > 
 > If you feel it's reasonably stable, I can merge it into master.
 
 I think it's ok to merge.
 
 From wmorgan-sup@masanjin.net  Fri Sep  4 13:29:23 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 04 Sep 2009 10:29:23 -0700
 Subject: [sup-talk] Trouble loading dump into Xapian index
 In-Reply-To: <1252083532-sup-2011@zyrg.net>
 References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net>
 	<1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net>
 	<1251998177-sup-3432@masanjin.net> <1252083532-sup-2011@zyrg.net>
 Message-ID: <1252085325-sup-2315@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-04:
 > I think it's ok to merge.
 
 Merged!
 
 If you're running a Xapian from master (weird!) you will have to rebuild
 your index after removing ~/.sup/{xapian,*.db}.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From sean.escriva@gmail.com  Fri Sep  4 15:13:32 2009
 From: sean.escriva@gmail.com (Sean Escriva)
 Date: Fri, 4 Sep 2009 12:13:32 -0700
 Subject: [sup-talk] a few questions on mail handling with sup
 Message-ID: <20090904191332.GA5525@gmail.com>
 
 I've got sup working with the exchange server at work thanks to
 offlineimap, but I have a few questions I was hope to get some input
 on.
 
 Currently I have no way to way move messages out of my inbox on the
 imap server, since I'm accessing a local maildir created by
 offlineimap. This is only an issue since mailboxes have a limit of
 800mb in size on the server and given the volume of mail I have that
 will be reached every other month. I've looked at imap filter and this
 could possibly work, but anyone have experience with this sort of
 sitatuation?
 
 Additionally, since sup doesn't actually change the
 maildir, messages in the maildir do not seem be getting marked as not
 new when reading them with sup and offlineimap then doesn't update the
 message state on the server. Is there any way to addess this?
 
 thanks!
 
 From bwalton@artsci.utoronto.ca  Fri Sep  4 16:47:39 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 04 Sep 2009 16:47:39 -0400
 Subject: [sup-talk] more xapian/label woes
 In-Reply-To: <1252077954-sup-8898@masanjin.net>
 References: <1252030139-sup-6351@ntdws12.chass.utoronto.ca>
 	<1252077954-sup-8898@masanjin.net>
 Message-ID: <1252081294-sup-4119@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Fri Sep 04 11:30:11 -0400 2009:
 
 > Is this with a recent next, and after deleting any vestigal
 > ~/.sup/xapian directory and .db files? If so, there really shouldn't be
 > any label issues. If there are, can you attach the original exception?
 > Also, does your sources.yaml file have something weird for labels?
 
 It was with cdb1017, but I likely did have a ~/.sup/xapian directory
 from previous attempts.  I'll try again tonight with that cleared out.
 
 > > This got me to the point where I could fire up sup with
 > > SUP_INDEX=xapian, but the initial poll caused the attached exception.
 > > I wonder if LabelManager should simply call .to_sym (.intern) on
 > > everything passed to it?
 > 
 > Certainly an option, but I'm hoping to keep the "fail fast" behavior for
 > now since it is revealing underlying problems.
 
 Ok, I think this is likely the best approach too.  Strings and symbols
 have a somewhat special relationship in ruby though, so I thought it
 might be ok to force a coercion in that case.  Lets make it the last
 resort as you suggest.
 
 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/20090904/aa7e19d8/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Fri Sep  4 17:01:11 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 04 Sep 2009 17:01:11 -0400
 Subject: [sup-talk] a few questions on mail handling with sup
 In-Reply-To: <20090904191332.GA5525@gmail.com>
 References: <20090904191332.GA5525@gmail.com>
 Message-ID: <1252098027-sup-4487@ntdws12.chass.utoronto.ca>
 
 Excerpts from Sean Escriva's message of Fri Sep 04 15:13:32 -0400 2009:
 
 > Currently I have no way to way move messages out of my inbox on the
 > imap server, since I'm accessing a local maildir created by
 > offlineimap. This is only an issue since mailboxes have a limit of
 > 800mb in size on the server and given the volume of mail I have that
 > will be reached every other month. I've looked at imap filter and this
 > could possibly work, but anyone have experience with this sort of
 > sitatuation?
 
 Could you pull it down with fetchmail into a local MTA setup that only
 handles local delivery?  Fetchmail has the 'delete on server' option
 if offlineimap doesn't.
 
 -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/20090904/7e4f505a/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Sat Sep  5 15:08:52 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 05 Sep 2009 15:08:52 -0400
 Subject: [sup-talk] new exception
 Message-ID: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 
 
 This attached exception log was generated after sending a reply,
 before the inbox buffer was redisplayed.
 
 I have the following small modifications to 99e62d55 included (still
 required for importing to xapian in my case):
 
 --snip--
 -    raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol
 +    t = t.intern if t.is_a? String
 +
 +    unless t.is_a? Symbol
 +      m = "expecting a symbol, got a #{t.class} (#{t.to_s})"
 +      raise ArgumentError, m
 +    end
 +
 --snip--
 
 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: exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090905/ef8749ed/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/20090905/ef8749ed/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Sat Sep  5 15:30:04 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 05 Sep 2009 15:30:04 -0400
 Subject: [sup-talk] new exception
 In-Reply-To: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 References: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 Message-ID: <1252178309-sup-7297@zyrg.net>
 
 Excerpts from Ben Walton's message of Sat Sep 05 15:08:52 -0400 2009:
 > --- RuntimeError from thread: main
 > DocNotFoundError: No termlist found for document 2478134195
 > /usr/lib/ruby/site_ruby/1.8/xapian.rb:239:in `doclength'
 > /usr/lib/ruby/site_ruby/1.8/xapian.rb:239:in `postlist'
 > /usr/lib/ruby/site_ruby/1.8/xapian.rb:59:in `_safelyIterate'
 > /usr/lib/ruby/site_ruby/1.8/xapian.rb:237:in `postlist'
 > ./sup/xapian_index.rb:361:in `term_docids'
 
 I'm guessing you're using the Chert Xapian backend. When I moved all the
 index data into Xapian it started triggering this Chert bug.
 Unfortunately, it's nondeterministic and very hard to reproduce in a
 small testcase. I've been holding off filing a bug upstream until I had
 a better failing testcase than "run sup-sync". If anyone would like to
 familiarize themselves with the xapian-index internals and narrow this
 bug down a bit I'd be very glad for the help.
 
 The Flint Xapian backend seems to work fine, so for now I suggest using that.
 
 From bwalton@artsci.utoronto.ca  Sat Sep  5 15:35:50 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 05 Sep 2009 15:35:50 -0400
 Subject: [sup-talk] new exception
 In-Reply-To: <1252178309-sup-7297@zyrg.net>
 References: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 	<1252178309-sup-7297@zyrg.net>
 Message-ID: <1252179264-sup-8449@ntdws12.chass.utoronto.ca>
 
 Excerpts from Rich Lane's message of Sat Sep 05 15:30:04 -0400 2009:
 > I'm guessing you're using the Chert Xapian backend. When I moved all the
 > index data into Xapian it started triggering this Chert bug.
 > Unfortunately, it's nondeterministic and very hard to reproduce in a
 > small testcase. I've been holding off filing a bug upstream until I had
 > a better failing testcase than "run sup-sync". If anyone would like to
 > familiarize themselves with the xapian-index internals and narrow this
 > bug down a bit I'd be very glad for the help.
 
 Your guess is as good as mine here...I didn't realize there were
 different back ends.  How would I go about switching?
 
 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/20090905/2217f134/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Sat Sep  5 15:55:12 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 05 Sep 2009 15:55:12 -0400
 Subject: [sup-talk] new exception
 In-Reply-To: <1252179264-sup-8449@ntdws12.chass.utoronto.ca>
 References: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 	<1252178309-sup-7297@zyrg.net>
 	<1252179264-sup-8449@ntdws12.chass.utoronto.ca>
 Message-ID: <1252179965-sup-8043@zyrg.net>
 
 Excerpts from Ben Walton's message of Sat Sep 05 15:35:50 -0400 2009:
 > Your guess is as good as mine here...I didn't realize there were
 > different back ends.  How would I go about switching?
 
 Interesting, AFAIK Flint is still the default. Check for a
 .sup/xapian/iamchert file to see if it's really a Chert DB. If it is
 Chert, you'll have to delete the xapian directory before you can switch
 to Flint. The environment variable XAPIAN_PREFER_CHERT controls which
 backend is used. Set it to the empty string to make sure you're getting
 Flint.
 
 From bwalton@artsci.utoronto.ca  Sat Sep  5 17:57:41 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 05 Sep 2009 17:57:41 -0400
 Subject: [sup-talk] new exception
 In-Reply-To: <1252179965-sup-8043@zyrg.net>
 References: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 	<1252178309-sup-7297@zyrg.net>
 	<1252179264-sup-8449@ntdws12.chass.utoronto.ca>
 	<1252179965-sup-8043@zyrg.net>
 Message-ID: <1252187828-sup-3676@ntdws12.chass.utoronto.ca>
 
 Excerpts from Rich Lane's message of Sat Sep 05 15:55:12 -0400 2009:
 
 > Interesting, AFAIK Flint is still the default. Check for a
 > .sup/xapian/iamchert file to see if it's really a Chert DB. If it is
 
 Nope.  I've got ~/.sup/xapian/iamflint though...
 
 Thanks for the info.
 
 -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/20090905/ef9fc4c3/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Sat Sep  5 20:19:06 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 05 Sep 2009 20:19:06 -0400
 Subject: [sup-talk] sources.yaml labels
 Message-ID: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 
 
 Hi All,
 
 After still requiring modifications to the LabelManager to manage my
 xapian conversion, I'm wondering if I've done something wrong in my
 sources.yaml (most of which was put together by hand instead of via
 sup-add).  What format should a labels definition be using?  On of my
 sources looks like:
 
 --snip--
 - !masanjin.net,2006-10-01/Redwood/Maildir 
   uri: maildir:///u/bwalton/Maildir/.systemtap/
   cur_offset: 12264068440005086
   usual: true
   archived: false
   id: 6
   labels: 
   - systemtap
   mtimes: 
     cur: 2008-10-23 13:22:54 -04:00
     new: 2008-11-11 07:34:04 -05:00
 --snip--
 
 Should the '- systemtap' be '- :systemtap'?
 
 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/20090905/7dc9994f/attachment.bin>
 
 From richard@infoarts.info  Sun Sep  6 05:40:57 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Sun, 06 Sep 2009 19:40:57 +1000
 Subject: [sup-talk] Sent messages and Sent label
 Message-ID: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local>
 
 Hi there
 
 I've set:
 
 :sent_source: sup://sent
 
 in my config.yaml and am sending using msmtp succesfully, however I'm not
 seeing my sent mail anywhere in Sup. I'm assuming that it is labelled as
 'Sent' and accessible via the 'Sent' label.
 
 But no mail is visible under that label - should I be adding a hook to label
 outgoing mail as 'Sent' or am I missing something obvious?
 
 -- 
 Richard Sandilands
 
 From richard@infoarts.info  Sun Sep  6 05:42:50 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Sun, 06 Sep 2009 19:42:50 +1000
 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view?
 Message-ID: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local>
 
 Hi there
 
 Am just playing with colors.yaml and was looking to change the colors of the
 highlight line that indicates a selected thread in inbox view.
 
 Is there a setting for this element?
 
 -- 
 Richard Sandilands
 
 From richard@infoarts.info  Sun Sep  6 05:40:57 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Sun, 06 Sep 2009 19:40:57 +1000
 Subject: [sup-talk] Sent messages and Sent label
 Message-ID: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local>
 
 Hi there
 
 I've set:
 
 :sent_source: sup://sent
 
 in my config.yaml and am sending using msmtp succesfully, however I'm not
 seeing my sent mail anywhere in Sup. I'm assuming that it is labelled as
 'Sent' and accessible via the 'Sent' label.
 
 But no mail is visible under that label - should I be adding a hook to label
 outgoing mail as 'Sent' or am I missing something obvious?
 
 -- 
 Richard Sandilands
 
 From wmorgan-sup@masanjin.net  Sun Sep  6 09:07:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 06 Sep 2009 06:07:48 -0700
 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view?
 In-Reply-To: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local>
 References: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local>
 Message-ID: <1252241877-sup-6125@masanjin.net>
 
 Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
 > Am just playing with colors.yaml and was looking to change the colors
 > of the highlight line that indicates a selected thread in inbox view.
 > 
 > Is there a setting for this element?
 
 Currently the highlight color is generated programmatically, so there's
 no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa
 line 82) if you want.
 
 Ideas on how to move this configuration to colors.yaml (or some other
 configuration mechanism) welcome.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Sep  6 09:22:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 06 Sep 2009 06:22:21 -0700
 Subject: [sup-talk] sources.yaml labels
 In-Reply-To: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 Message-ID: <1252242820-sup-1452@masanjin.net>
 
 Reformatted excerpts from Ben Walton's message of 2009-09-05:
 > Should the '- systemtap' be '- :systemtap'?
 
 The former is "correct". But if you put in the latter, it should be
 converted automatically, and written out as the former when you exit
 Sup.
 
 I'm a little disturbed that you're still seeing problems with this. Can
 you confirm that SerializeLabelsNicely#after_unmarshal! (source.rb circa
 line 167) is being run in your sources after they're loaded from
 sources.yaml? That should ensure that you end up with a Set of symbols
 when Sup's running, regardless of what's in the file.
 
 The other source of bad labels is the serialized version of the messages
 stored by Xapian, if you use Xapian. But if you've regenerated your
 Xapian index recently, this shouldn't be a problem...
 
 It strikes me now that the other possible source of non-symbol labels is
 a hook like before-add. Are you using that to call Message#add_label
 with a string argument, by any chance?
 
 If none of the above, can you post the latest version of the exceptions
 you're seeing?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Sun Sep  6 09:47:06 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 06 Sep 2009 09:47:06 -0400
 Subject: [sup-talk] sources.yaml labels
 In-Reply-To: <1252242820-sup-1452@masanjin.net>
 References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 	<1252242820-sup-1452@masanjin.net>
 Message-ID: <1252244621-sup-3579@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Sun Sep 06 09:22:21 -0400 2009:
 > The former is "correct". But if you put in the latter, it should be
 > converted automatically, and written out as the former when you exit
 > Sup.
 
 Ok, so my sources.yaml is 'good.'
 
 > I'm a little disturbed that you're still seeing problems with this. Can
 > you confirm that SerializeLabelsNicely#after_unmarshal! (source.rb circa
 > line 167) is being run in your sources after they're loaded from
 > sources.yaml? That should ensure that you end up with a Set of symbols
 > when Sup's running, regardless of what's in the file.
 
 Yes, I added a debug in that method and saw a message for each source.
 
 > The other source of bad labels is the serialized version of the messages
 > stored by Xapian, if you use Xapian. But if you've regenerated your
 > Xapian index recently, this shouldn't be a problem...
 
 I generated this about 2 days ago with a current (at the time) head of
 next.
 
 > It strikes me now that the other possible source of non-symbol labels is
 > a hook like before-add. Are you using that to call Message#add_label
 > with a string argument, by any chance?
 
 I was doing this.  I had a hook from my very early sup days still in
 play.  Since it was actually completely redundant (procmail filtering
 and autolabelling via sources) now, I've simply removed it.
 
 > If none of the above, can you post the latest version of the exceptions
 > you're seeing?
 
 I still can't load sup without coercing strings to symbols in the <<
 method though.  The exception log is attached (from a clean startup).
 
 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: exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/8e8d8383/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/20090906/8e8d8383/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Sun Sep  6 09:50:35 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 06 Sep 2009 06:50:35 -0700
 Subject: [sup-talk] Sent messages and Sent label
 In-Reply-To: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local>
 References: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local>
 Message-ID: <1252244925-sup-2820@masanjin.net>
 
 Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
 > But no mail is visible under that label - should I be adding a hook to
 > label outgoing mail as 'Sent' or am I missing something obvious?
 
 Whoops, this is a bug I introduced recently. I've fixed it now. Please
 git pull and try again.
 
 To apply the sent label to previously-sent messages, please run:
   sup-tweak-labels -a sent sup://sent
 
 Sorry about that!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Sun Sep  6 10:07:55 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 06 Sep 2009 10:07:55 -0400
 Subject: [sup-talk] sources.yaml labels
 In-Reply-To: <1252242820-sup-1452@masanjin.net>
 References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 	<1252242820-sup-1452@masanjin.net>
 Message-ID: <1252246006-sup-3945@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Sun Sep 06 09:22:21 -0400 2009:
 
 > The other source of bad labels is the serialized version of the messages
 > stored by Xapian, if you use Xapian. But if you've regenerated your
 > Xapian index recently, this shouldn't be a problem...
 
 Since I had a bad hook and imported to Xapian with that hook live,
 should I reimport my dumpfile after having the hook removed?  I'm
 thinking that I did the damage in a permanent fashion while doing the
 import...
 
 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/20090906/e357aff1/attachment.bin>
 
 From ingmar@exherbo.org  Sun Sep  6 10:16:56 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Sun, 06 Sep 2009 16:16:56 +0200
 Subject: [sup-talk] sources.yaml labels
 In-Reply-To: <1252244621-sup-3579@ntdws12.chass.utoronto.ca>
 References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 	<1252242820-sup-1452@masanjin.net>
 	<1252244621-sup-3579@ntdws12.chass.utoronto.ca>
 Message-ID: <1252246564-sup-241@cannonball>
 
 Excerpts from Ben Walton's message of Sun Sep 06 15:47:06 +0200 2009:
 > I still can't load sup without coercing strings to symbols in the <<
 > method though.  The exception log is attached (from a clean startup).
 
 That looks like you're using labels as strings, or at least not as
 symbols, in one of your hooks.
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From wmorgan-sup@masanjin.net  Sun Sep  6 11:06:16 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 06 Sep 2009 08:06:16 -0700
 Subject: [sup-talk] sources.yaml labels
 In-Reply-To: <1252246006-sup-3945@ntdws12.chass.utoronto.ca>
 References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 	<1252242820-sup-1452@masanjin.net>
 	<1252246006-sup-3945@ntdws12.chass.utoronto.ca>
 Message-ID: <1252248461-sup-5213@masanjin.net>
 
 Reformatted excerpts from Ben Walton's message of 2009-09-06:
 > Since I had a bad hook and imported to Xapian with that hook live,
 > should I reimport my dumpfile after having the hook removed?  I'm
 > thinking that I did the damage in a permanent fashion while doing the
 > import...
 
 I suspect that would fix it. I've just pushed a change to to make
 Message#add_label coerce arguments to symbols, anyways, so that writing
 your hook wrong won't destroy your index for all eternity.
 
 Sorry about all this. The silver lining is that it's a side effect of
 lots of development activity. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Sun Sep  6 11:26:26 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 06 Sep 2009 11:26:26 -0400
 Subject: [sup-talk] sources.yaml labels
 In-Reply-To: <1252248461-sup-5213@masanjin.net>
 References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 	<1252242820-sup-1452@masanjin.net>
 	<1252246006-sup-3945@ntdws12.chass.utoronto.ca>
 	<1252248461-sup-5213@masanjin.net>
 Message-ID: <1252250590-sup-9666@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Sun Sep 06 11:06:16 -0400 2009:
 > I suspect that would fix it. I've just pushed a change to to make
 > Message#add_label coerce arguments to symbols, anyways, so that writing
 > your hook wrong won't destroy your index for all eternity.
 
 Ok, that's cool.  I was going to write the same change but with a
 'raise ArgumentError' similar to the one in << to stick with the fail
 fast approach you prefer.
 
 > Sorry about all this. The silver lining is that it's a side effect of
 > lots of development activity. :)
 
 Hey, it's not a problem.  I don't mind guinea pigging this stuff at
 all.  Sup has steadily improved since I've been using it, so I'm a
 happy camper.  [Plus, I'm running next, so I 'get what I get.']
 
 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/20090906/26890640/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Sun Sep  6 12:41:48 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 06 Sep 2009 12:41:48 -0400
 Subject: [sup-talk] sources.yaml labels
 In-Reply-To: <1252248461-sup-5213@masanjin.net>
 References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca>
 	<1252242820-sup-1452@masanjin.net>
 	<1252246006-sup-3945@ntdws12.chass.utoronto.ca>
 	<1252248461-sup-5213@masanjin.net>
 Message-ID: <1252255225-sup-9921@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Sun Sep 06 11:06:16 -0400 2009:
 
 > I suspect that would fix it. I've just pushed a change to to make
 > Message#add_label coerce arguments to symbols, anyways, so that writing
 > your hook wrong won't destroy your index for all eternity.
 
 Verified.  I've re-imported my dump file after removing my hook.  The
 import ran successfully with an unmodified sup.
 
 I think this makes me a full-time xapian convert.
 
 Thanks for all your effort on this William and Rich!
 -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/20090906/6eddaa77/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Sun Sep  6 13:02:19 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 06 Sep 2009 13:02:19 -0400
 Subject: [sup-talk] new exception
 In-Reply-To: <1252187828-sup-3676@ntdws12.chass.utoronto.ca>
 References: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 	<1252178309-sup-7297@zyrg.net>
 	<1252179264-sup-8449@ntdws12.chass.utoronto.ca>
 	<1252179965-sup-8043@zyrg.net>
 	<1252187828-sup-3676@ntdws12.chass.utoronto.ca>
 Message-ID: <1252255655-sup-2460@zyrg.net>
 
 Excerpts from Ben Walton's message of Sat Sep 05 17:57:41 -0400 2009:
 > Excerpts from Rich Lane's message of Sat Sep 05 15:55:12 -0400 2009:
 > 
 > > Interesting, AFAIK Flint is still the default. Check for a
 > > .sup/xapian/iamchert file to see if it's really a Chert DB. If it is
 > 
 > Nope.  I've got ~/.sup/xapian/iamflint though...
 
 Well, that's not good. How often does this bug occur? What version of
 Xapian are you running? How many messages are in your index?
 
 From bwalton@artsci.utoronto.ca  Sun Sep  6 13:22:39 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 06 Sep 2009 13:22:39 -0400
 Subject: [sup-talk] new exception
 In-Reply-To: <1252255655-sup-2460@zyrg.net>
 References: <1252177626-sup-316@ntdws12.chass.utoronto.ca>
 	<1252178309-sup-7297@zyrg.net>
 	<1252179264-sup-8449@ntdws12.chass.utoronto.ca>
 	<1252179965-sup-8043@zyrg.net>
 	<1252187828-sup-3676@ntdws12.chass.utoronto.ca>
 	<1252255655-sup-2460@zyrg.net>
 Message-ID: <1252257711-sup-2477@ntdws12.chass.utoronto.ca>
 
 Excerpts from Rich Lane's message of Sun Sep 06 13:02:19 -0400 2009:
 > Well, that's not good. How often does this bug occur? What version of
 > Xapian are you running? How many messages are in your index?
 
 It's only occurred twice, but both were with my polluted index of ~77k
 messages.  Let me run for a bit now that I've cleaned out my string
 labels and see what happens.
 
 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/20090906/5f1cedfa/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Sun Sep  6 14:08:42 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sun, 06 Sep 2009 14:08:42 -0400
 Subject: [sup-talk] [PATCH] small sent labels fixup
 Message-ID: <1252260470-sup-6960@ntdws12.chass.utoronto.ca>
 
 Hi William,
 
 I still wasn't seeing the sent label applied to things in my maildir.
 The attached patch restores the behaviour for non sup://sent sent
 sources.
 
 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: 0001-always-apply-label-sent-to-messages-in-sentmanager.patch
 Type: application/octet-stream
 Size: 689 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090906/2f2c39fa/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/20090906/2f2c39fa/attachment.bin>
 
 From nicolas.pouillard@gmail.com  Sun Sep  6 15:43:06 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sun, 06 Sep 2009 21:43:06 +0200
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252000831-sup-9922@masanjin.net>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net>
 Message-ID: <1252266137-sup-4139@peray>
 
 Excerpts from William Morgan's message of Thu Sep 03 20:06:55 +0200 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-26:
 > > These behave identically to the existing ",a" and ",d" commands, (that
 > > is they archive or delete the current thread and then view the next).
 > 
 > Sorry it's taken me so long to look at this. Thanks for the patch!
 > 
 > I'm curious what other people think about this. On the one hand, it's
 > only additional keybindings, so it's not going to adversely affect
 > anyone. On the other hand, there is a nice balance with the ".", ","
 > and "]" commands which this disrupts, and it can't be extended to the
 > other commands from thread-index-mode. And on the third hand, I'm happy
 > to have keybinding hooks.
 > 
 > I guess if most people primarily closes their thread-view-modes using
 > ",a" and ",d", then I'm fine with this.
 
 I personally do prefer ]a and ]d, to read mail in the chronological order.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From michael@content-space.de  Sun Sep  6 17:04:22 2009
 From: michael@content-space.de (Michael Hamann)
 Date: Sun,  6 Sep 2009 23:04:22 +0200
 Subject: [sup-talk] [PATCH] sort labels in the dump
 Message-ID: <1252271062-8775-1-git-send-email-michael@content-space.de>
 
 Sorting labels in the dump is useful when you e.g. want to keep track of
 your dump using an incremental backup system that records diffs, with
 this patch lines in the dump will only change when there is a real
 change and no longer just because the random order of the labels
 changes.
 ---
  bin/sup-dump |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/bin/sup-dump b/bin/sup-dump
 index 8b5bf07..7b33be5 100755
 --- a/bin/sup-dump
 +++ b/bin/sup-dump
 @@ -26,5 +26,5 @@ Redwood::SourceManager.init
  index.load
  
  index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m|
 -  puts "#{m.id} (#{m.labels.to_a * ' '})"
 +  puts "#{m.id} (#{m.labels.to_a.sort_by { |l| l.to_s } * ' '})"
  end
 -- 
 1.6.4.2
 
 
 From nicolas.pouillard@gmail.com  Mon Sep  7 07:03:43 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 07 Sep 2009 13:03:43 +0200
 Subject: [sup-talk] [PATCH] sort labels in the dump
 In-Reply-To: <1252271062-8775-1-git-send-email-michael@content-space.de>
 References: <1252271062-8775-1-git-send-email-michael@content-space.de>
 Message-ID: <1252321409-sup-2683@peray>
 
 Excerpts from Michael Hamann's message of Sun Sep 06 23:04:22 +0200 2009:
 > Sorting labels in the dump is useful when you e.g. want to keep track of
 > your dump using an incremental backup system that records diffs, with
 > this patch lines in the dump will only change when there is a real
 > change and no longer just because the random order of the labels
 > changes.
 
 +1 for this change.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From richard@infoarts.info  Mon Sep  7 07:47:53 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Mon, 7 Sep 2009 21:47:53 +1000
 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox
 Message-ID: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com>
 
 Am tracking 'next' branch and moved to Xapian earlier today.
 
 I had Sup running when I slept my OS X laptop by shutting the lid.
 Upon awakening, Sup raised the following error. Upon trying to run Sup
 again from the prompt, the same error re-occurs:
 
 I'm populating my local Maildirs using getmail from Gmail via POP.
 
 ===========
 --- ArgumentError from thread: poll after loading inbox
 expecting a symbol
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/label.rb:64:in `<<'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:114:in
 `sync_message'
 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in
 `each'
 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in
 `each_key'
 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in
 `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:114:in
 `sync_message'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:87:in `add_message'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:166:in `add_new_message'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:110:in `do_poll'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:152:in `each_message_from'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in `each_message_from'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:93:in `do_poll'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `do_poll'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `synchronize'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `do_poll'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:48:in `poll'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /Users/richard/src/mainline/bin/sup:196
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 /Users/richard/src/mainline/bin/sup:196
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
 `call'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
 `__unprotected_load_threads'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
 `call'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
 `load_n_threads_background'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in
 `load_n_threads_background'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in
 `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /Users/richard/src/mainline/bin/sup:196
 ==============
 
 -- 
 Richard
 
 From andrew@pimlott.net  Mon Sep  7 13:04:50 2009
 From: andrew@pimlott.net (Andrew Pimlott)
 Date: Mon, 7 Sep 2009 10:04:50 -0700
 Subject: [sup-talk] sup-sync and xapian memory usage
 Message-ID: <20090907170450.GO14010@pimlott.net>
 
 Last time I tried to use sup[1], I posted about sup-sync crashing with
 various symptoms of memory exhaustion[2].  I've tried again (using git
 mainline), with similar results, but now I have a bit more to say about
 it.
 
 I am running on a fairly low-memory virtual machine.  I think some of
 the variability in what I was seeing before had to do with what other
 things were running.  Sorry about not being aware of this before.  In
 the following, I have pretty well controlled for other system memory
 use.  All of these tests are done on the same mbox with all indices
 cleared.
 
 Some of the failures I see are out of memory when running gpg
 ("Errno::ENOMEM Exception: Cannot allocate memory - /usr/bin/gpg" ...).
 I stopped at that point in the debugger and found that at this point,
 the ruby backtick operator fails the same way on any command.  Using
 strace, I saw a failure in clone:
 
 20528 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7cb3908) = -1 ENOMEM (Cannot allocate memory)
 
 top reports 2.5M of physical and 30M of swap free, so I don't really
 know why clone fails, but I guess there's not much you can do about
 that.
 
 Other failures were the result of sup blowing up on messages with large
 attachments.  sup's memory use is many times the attachment size.
 Testing on an mbox with a single message with 4 ~5M (encoded size)
 attachments (total file size ~21M), sup goes up to ~150M.  Accounting
 for baseline, that's about 6 times the file size.  I hope that can be
 improved.  FWIW, mutt never seems to try to load a whole attachment into
 memory.
 
 Using the ferret index, the memory (virtual as reported by Linux)
 behaviour of sup-sync is pretty good.  It starts out 25M and levels out
 around 31M.  It spikes from time to time, presumably because of large
 messages, but it comes right back.  After processing the last message,
 it uses another 10M to finish up.
 
 Using the xapian index, things are different.  It starts at 32M and
 steadily climbs to 77M after ~3500 messages, or around 1M every 100
 messages.  It does seem to climb faster at first and then more slowly.
 Either xapian is keeping a cache (but some searches suggest it doesn't),
 it's leaking memory, or it's allocating memory in a way that the the
 allocator can't reclaim the VM space.  Any ideas?
 
 BTW, is there really no way to ask for ruby's heap size with (unpatched)
 ruby 1.8?
 
 Andrew
 
 [1] This is about the fourth time.  I seem to be easily discouraged.
 [2] http://rubyforge.org/pipermail/sup-talk/2009-May/002171.html
 
 From bwalton@artsci.utoronto.ca  Mon Sep  7 14:14:41 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 07 Sep 2009 14:14:41 -0400
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <20090907170450.GO14010@pimlott.net>
 References: <20090907170450.GO14010@pimlott.net>
 Message-ID: <1252347051-sup-135@ntdws12.chass.utoronto.ca>
 
 Excerpts from Andrew Pimlott's message of Mon Sep 07 13:04:50 -0400 2009:
 
 > I am running on a fairly low-memory virtual machine.  I think some of
 > the variability in what I was seeing before had to do with what
 > other
 
 I'm running sup on real hardware w/1GB physical ram.
 
 > things were running.  Sorry about not being aware of this before.  In
 > the following, I have pretty well controlled for other system memory
 > use.  All of these tests are done on the same mbox with all indices
 > cleared.
 > 
 > Some of the failures I see are out of memory when running gpg
 > ("Errno::ENOMEM Exception: Cannot allocate memory - /usr/bin/gpg" ...).
 > I stopped at that point in the debugger and found that at this point,
 > the ruby backtick operator fails the same way on any command.  Using
 > strace, I saw a failure in clone:
 
 I found sup crashed this morning too with an ENOMEM on a gpg
 operation.  I thought I may actually have been at the memory
 exhaustion point normally though as I run screen and tend to leave
 lots of sessions going all the time.
 
 > Using the xapian index, things are different.  It starts at 32M and
 > steadily climbs to 77M after ~3500 messages, or around 1M every 100
 > messages.  It does seem to climb faster at first and then more
 > slowly.
 
 I've never paid attention to this before, but currently, my sup
 process (running for about 6 hours now) looks like it's using ~77M
 virtual with 59 of that resident.
 
 This has only happened to me once, but since you reported it, I
 thought I'd chime in with some extra data.
 
 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/20090907/4318eb38/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Mon Sep  7 14:33:06 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 07 Sep 2009 14:33:06 -0400
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <20090907170450.GO14010@pimlott.net>
 References: <20090907170450.GO14010@pimlott.net>
 Message-ID: <1252348258-sup-415@zyrg.net>
 
 Excerpts from Andrew Pimlott's message of Mon Sep 07 13:04:50 -0400 2009:
 > Using the xapian index, things are different.  It starts at 32M and
 > steadily climbs to 77M after ~3500 messages, or around 1M every 100
 > messages.  It does seem to climb faster at first and then more slowly.
 > Either xapian is keeping a cache (but some searches suggest it doesn't),
 > it's leaking memory, or it's allocating memory in a way that the the
 > allocator can't reclaim the VM space.  Any ideas?
 
 Xapian keeps writes buffered in memory. Try setting the environment
 variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
 documents) and see if that helps.
 
 From bwalton@artsci.utoronto.ca  Mon Sep  7 15:11:58 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 07 Sep 2009 15:11:58 -0400
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252348258-sup-415@zyrg.net>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 Message-ID: <1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 
 Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
 > Xapian keeps writes buffered in memory. Try setting the environment
 > variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
 > documents) and see if that helps.
 
 Does this explain the lag at shutdown?  Xapian is flushing writes to
 disk?
 
 -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/20090907/b8fec298/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Mon Sep  7 15:15:08 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 07 Sep 2009 15:15:08 -0400
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 	<1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 Message-ID: <1252350896-sup-5026@zyrg.net>
 
 Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
 > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
 > > Xapian keeps writes buffered in memory. Try setting the environment
 > > variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
 > > documents) and see if that helps.
 > 
 > Does this explain the lag at shutdown?  Xapian is flushing writes to
 > disk?
 
 Yep.
 
 From andrew@pimlott.net  Mon Sep  7 15:26:11 2009
 From: andrew@pimlott.net (Andrew Pimlott)
 Date: Mon, 7 Sep 2009 12:26:11 -0700
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252348258-sup-415@zyrg.net>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 Message-ID: <20090907192611.GQ14010@pimlott.net>
 
 On Mon, Sep 07, 2009 at 02:33:06PM -0400, Rich Lane wrote:
 > Xapian keeps writes buffered in memory. Try setting the environment
 > variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000
 > documents) and see if that helps.
 
 Thanks--it was hard for me to find that kind of information.  I first
 tried setting XAPIAN_FLUSH_THRESHOLD to 1, and sup-sync ran slowly and
 just kept getting slower:
 
 ## read 139m (about 7%) @ 9.2m/s. 0:00:15 elapsed, about 0:03:21 remaining
 ...
 ## read 1238m (about 35%) @ 3.1m/s. 0:06:36 elapsed, about 0:12:08 remaining
 
 I stopped at this point because it was taking too long.  The memory use
 seemed stable, but that could have been because it was making such slow
 progress.  I guess xapian gets a lot slower writing as the db grows?
 That's a bit discouraging.  Using ferret, sup-sync only dropped from
 28.1m/s to 27.3m/s during its run.  For reference, when I didn't set
 XAPIAN_FLUSH_THRESHOLD, I was getting 35-36m/s until it ran out of
 memory.
 
 I then set XAPIAN_FLUSH_THRESHOLD to 100 and got more reasonable
 results.  It started at 25.6m/s and slowed to 17.8m/s.  It stabilized at
 around 41M virtual memory used and finished successfuly.  I also note
 that the memory use didn't jump during the finish-up phase ("Deleting
 missing messages") as it had with ferret.
 
 Finally, I set XAPIAN_FLUSH_THRESHOLD to 1000.  It started at 34.6m/s
 and dropped to 29.8m/s., stabilized at around 51M virtual memory, and
 finished successfully.  In this case, it stays faster than ferret, but
 it sill bugs me that xapian still slows down while ferret doesn't.
 
 So I conclude... I don't know what I conclude.  Letting xapian use a lot
 of memory sure helps its performance.  And a big sup-sync should only
 have to be done rarely.  So maybe just document that those on low-memory
 systems should consider using XAPIAN_FLUSH_THRESHOLD during sup-sync.
 
 Thanks again for your help!
 
 Andrew
 
 From infoarts@gmail.com  Thu Sep  3 19:02:12 2009
 From: infoarts@gmail.com (infoarts at gmail.com)
 Date: Fri, 4 Sep 2009 09:02:12 +1000
 Subject: [sup-talk] Can't add a local maildir source
 Message-ID: <2e8d08f0909031602r37472cdcjcf4826f7cd2b48c7@mail.gmail.com>
 
 Hi there
 
 I'm tracking next via git and am having trouble adding a mail source.
 
 I've removed any existing ~/.sup directory, then run sup-config and
 all is OK until sup-config runs sup-add maildir when I get this
 message:
 
 "Ok, trying to run "/Users/richard/src/sup/bin/sup-add
 maildir:/Users/richard/mail/gmail/INBOX"...
 /Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for
 false:FalseClass (NoMethodError)
 	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
 `gem_original_require'
 	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
 	from /Users/richard/src/sup/lib/sup.rb:277
 	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in
 `gem_original_require'
 	from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require'
 	from /Users/richard/src/sup/bin/sup-add:7
 
 So I'm thinking this might have something to do with my environment
 setup on OS X.
 
 I'm running sup from ~/src/sup and am mirroring my gmail mail to
 ~/mail/gmail via offlineimap - this all seems fine.
 
 I've  added: 'export RUBYLIB="~/src/sup/lib" ' to my .bash_profile but
 it still fails on the 'require "sup"' line in sup-add
 
 I've checked that I have all the required gem dependencies and that
 seems fine too.
 
 And I installed the sup-999 gems.
 
 What could I be missing here?
 
 Any clues appreciated...
 
 -- 
 Richard
 
 From eg@gaute.vetsj.com  Mon Sep  7 12:21:35 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Mon, 07 Sep 2009 18:21:35 +0200
 Subject: [sup-talk] lbdb module for sup
 Message-ID: <1252340369-sup-9611@qwerzila>
 
 Greetings,
 
 attached is a lbdb (http://sup.rubyforge.org/wiki/wiki.pl?LbdbIntegration)
 module for the sup contact list. Useful if you want access to the sup
 contact list from Vim.
 
 put in .lbdb/modules and add .lbdb/modules to your MODULES_PATH in
 .lbdbrc aswell as adding the m_sup module to the modules list.
 
 - gaute
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: m_sup
 Type: application/octet-stream
 Size: 289 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090907/8dd9e60d/attachment.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 198 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090907/8dd9e60d/attachment.bin>
 
 From isra@herraiz.org  Mon Sep  7 18:46:50 2009
 From: isra@herraiz.org (Israel Herraiz)
 Date: Tue, 08 Sep 2009 00:46:50 +0200
 Subject: [sup-talk] [PATCH] Identify list messages by list-id if
 	list-post is not present
 In-Reply-To: <1252072500-sup-8128@masanjin.net>
 References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net>
 	<1251794935-sup-3802@elly> <1252072500-sup-8128@masanjin.net>
 Message-ID: <1252363563-sup-1774@elly>
 
 Excerpts from William Morgan's message of Fri Sep 04 15:56:41 +0200 2009:
 > Actually you're right. I think I prefer your patch. But based on the
 > code, it seems like reply-mode would crash if it got a message that
 > claims it's a list message but doesn't have a list address. Does it
 > actually work?
 
 Umm. Yes, you are right. It fails because there is no list
 address. Let me figure out another solution for this, I will send
 another patch to the list.
 
 Cheers,
 Israel
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 08:25:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 05:25:50 -0700
 Subject: [sup-talk] [PATCH] Identify list messages by list-id if
 	list-post is not present
 In-Reply-To: <1252363563-sup-1774@elly>
 References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net>
 	<1251794935-sup-3802@elly> <1252072500-sup-8128@masanjin.net>
 	<1252363563-sup-1774@elly>
 Message-ID: <1252412603-sup-9617@masanjin.net>
 
 Reformatted excerpts from Israel Herraiz's message of 2009-09-07:
 > Umm. Yes, you are right. It fails because there is no list
 > address. Let me figure out another solution for this, I will send
 > another patch to the list.
 
 We need to figure out what the right behavior should be when replying to
 a message that you know is a list message, but where you don't know the
 list address. If there's a reliable way of extracting the list address
 from another header (From?), we can use that, but I suspect there isn't.
 If there isn't a reliable wa, then maybe the original behavior is fine
 (don't treat it specially at all).
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From isra@herraiz.org  Tue Sep  8 08:41:51 2009
 From: isra@herraiz.org (Israel Herraiz)
 Date: Tue, 08 Sep 2009 14:41:51 +0200
 Subject: [sup-talk] [PATCH] Identify list messages by list-id if
 	list-post is not present
 In-Reply-To: <1252412603-sup-9617@masanjin.net>
 References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net>
 	<1251794935-sup-3802@elly> <1252072500-sup-8128@masanjin.net>
 	<1252363563-sup-1774@elly> <1252412603-sup-9617@masanjin.net>
 Message-ID: <1252413599-sup-7371@elly>
 
 Excerpts from William Morgan's message of Tue Sep 08 14:25:50 +0200 2009:
 > We need to figure out what the right behavior should be when replying to
 > a message that you know is a list message, but where you don't know the
 > list address. If there's a reliable way of extracting the list address
 > from another header (From?), we can use that, but I suspect there isn't.
 > If there isn't a reliable wa, then maybe the original behavior is fine
 > (don't treat it specially at all).
 
 Well, yes, after all, the broken thing here is the list, that does not
 have a list-post header. So I guess that what should be fixed is that
 list, not Sup :-).
 
 I did not realize about the list address bug before sending the patch,
 that's why I asked it to be merged. However, I am afraid you are
 right, and I think it is worthless to implement this behavior.
 
 Cheers,
 Israel
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 09:15:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 06:15:49 -0700
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <20090907170450.GO14010@pimlott.net>
 References: <20090907170450.GO14010@pimlott.net>
 Message-ID: <1252415545-sup-3158@masanjin.net>
 
 Reformatted excerpts from Andrew Pimlott's message of 2009-09-07:
 > Last time I tried to use sup[1], I posted about sup-sync crashing with
 > various symptoms of memory exhaustion[2].
 
 Excellent resolution to that thread.
 
 > sup's memory use is many times the attachment size.  Testing on an
 > mbox with a single message with 4 ~5M (encoded size) attachments
 > (total file size ~21M), sup goes up to ~150M.  Accounting for
 > baseline, that's about 6 times the file size.  I hope that can be
 > improved.
 
 Sup uses the unmaintained RubyMail for MIME handling. I'm sure this
 behavior can be improved if you can find someone who wants to write some
 MIME handling code. Personally that's near the bottom of my list.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 09:39:12 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 06:39:12 -0700
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252350896-sup-5026@zyrg.net>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 	<1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 	<1252350896-sup-5026@zyrg.net>
 Message-ID: <1252415772-sup-7288@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-07:
 > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
 > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
 > > > Xapian keeps writes buffered in memory. Try setting the
 > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
 > > > (the default is 10000 documents) and see if that helps.
 > > 
 > > Does this explain the lag at shutdown?  Xapian is flushing writes to
 > > disk?
 > 
 > Yep.
 
 Good to know. Is there a way to force a flush in Xapian? Just curious.
 The delay is a little scary sometimes. Maybe it just needs an
 appropriate message somewhere.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Tue Sep  8 09:58:15 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 08 Sep 2009 09:58:15 -0400
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252415772-sup-7288@masanjin.net>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 	<1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 	<1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net>
 Message-ID: <1252418267-sup-8800@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Tue Sep 08 09:39:12 -0400 2009:
 > Good to know. Is there a way to force a flush in Xapian? Just curious.
 > The delay is a little scary sometimes. Maybe it just needs an
 > appropriate message somewhere.
 
 ...even just a message indicating that xapian is flushing the buffered
 writes would be a good thing.
 
 -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/20090908/fa461b0e/attachment.bin>
 
 From rgh@roughage.com.au  Tue Sep  8 10:27:10 2009
 From: rgh@roughage.com.au (Richard Heycock)
 Date: Wed, 09 Sep 2009 00:27:10 +1000
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252415772-sup-7288@masanjin.net>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 	<1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 	<1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net>
 Message-ID: <1252419716-sup-3031@roughage.com.au>
 
 Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-09-07:
 > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
 > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
 > > > > Xapian keeps writes buffered in memory. Try setting the
 > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
 > > > > (the default is 10000 documents) and see if that helps.
 > > > 
 > > > Does this explain the lag at shutdown?  Xapian is flushing writes to
 > > > disk?
 > > 
 > > Yep.
 > 
 > Good to know. Is there a way to force a flush in Xapian? Just curious.
 > The delay is a little scary sometimes. Maybe it just needs an
 > appropriate message somewhere.
 
 Xapian, by default, flushes every 10 000 documents which in email terms
 is a pretty long time! You can force a flush but it does increase your
 IO significantly. Having said that emails are fairly small so flushing
 every 10 or 20 emails might not be too bad.
 
 Maybe it could be dynamic, if there is a high volume of incoming emails
 flushing could be done after 50 or 100 emails or a timer based flush
 might be easier.
 
 rgh
 
 From nicolas.pouillard@gmail.com  Tue Sep  8 11:14:22 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 08 Sep 2009 17:14:22 +0200
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252419716-sup-3031@roughage.com.au>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 	<1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 	<1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net>
 	<1252419716-sup-3031@roughage.com.au>
 Message-ID: <1252422827-sup-805@peray>
 
 Excerpts from Richard Heycock's message of Tue Sep 08 16:27:10 +0200 2009:
 > Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009:
 > > Reformatted excerpts from Rich Lane's message of 2009-09-07:
 > > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
 > > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
 > > > > > Xapian keeps writes buffered in memory. Try setting the
 > > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
 > > > > > (the default is 10000 documents) and see if that helps.
 > > > > 
 > > > > Does this explain the lag at shutdown?  Xapian is flushing writes to
 > > > > disk?
 > > > 
 > > > Yep.
 > > 
 > > Good to know. Is there a way to force a flush in Xapian? Just curious.
 > > The delay is a little scary sometimes. Maybe it just needs an
 > > appropriate message somewhere.
 > 
 > Xapian, by default, flushes every 10 000 documents which in email terms
 > is a pretty long time! You can force a flush but it does increase your
 > IO significantly. Having said that emails are fairly small so flushing
 > every 10 or 20 emails might not be too bad.
 > 
 > Maybe it could be dynamic, if there is a high volume of incoming emails
 > flushing could be done after 50 or 100 emails or a timer based flush
 > might be easier.
 
 Should the '$' command, force a write of the Xapian database?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wirtwolff@gmail.com  Tue Sep  8 11:17:18 2009
 From: wirtwolff@gmail.com (Wirt Wolff)
 Date: Tue, 08 Sep 2009 09:17:18 -0600
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252000831-sup-9922@masanjin.net>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net>
 Message-ID: <1252422961-sup-9843@chigamba>
 
 Excerpts from William Morgan's message of Thu Sep 03 12:06:55 -0600 2009:
 > Reformatted excerpts from Carl Worth's message of 2009-08-26:
 > > These behave identically to the existing ",a" and ",d" commands, (that
 > > is they archive or delete the current thread and then view the next).
 >
 > Sorry it's taken me so long to look at this. Thanks for the patch!
 >
 > I'm curious what other people think about this. On the one hand, it's
 > only additional keybindings, so it's not going to adversely affect
 > anyone. On the other hand, there is a nice balance with the ".", ","
 > and "]" commands which this disrupts, and it can't be extended to the
 > other commands from thread-index-mode. And on the third hand, I'm happy
 > to have keybinding hooks.
 >
 > I guess if most people primarily closes their thread-view-modes using
 > ",a" and ",d", then I'm fine with this.
 
 Don't mind having 'a' and 'd' around, but likely won't use them.
 Generally I pass down index with &, A, S, etc. occaisionally reading
 high priority thread, then ]n, ]a etc. back up in thread view.
 
 --
 wmw
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 15:21:47 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 12:21:47 -0700
 Subject: [sup-talk] [PATCH] small sent labels fixup
 In-Reply-To: <1252260470-sup-6960@ntdws12.chass.utoronto.ca>
 References: <1252260470-sup-6960@ntdws12.chass.utoronto.ca>
 Message-ID: <1252437698-sup-9601@masanjin.net>
 
 Reformatted excerpts from Ben Walton's message of 2009-09-06:
 > I still wasn't seeing the sent label applied to things in my maildir.
 > The attached patch restores the behaviour for non sup://sent sent
 > sources.
 
 Applied, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 15:45:32 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 12:45:32 -0700
 Subject: [sup-talk] master branch merge report
 Message-ID: <1252438950-sup-3895@masanjin.net>
 
 On preparation for an 0.9 release, I've merged the following branches
 into master (in case anyone's keeping track!): console-mode,
 reply-all-keybindings, restore-state, logging-tweaks,
 enclosed-message-display-tweaks, hook-local-vars.
 
 If anyone's running master, keep an eye out for changes and problems.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Tue Sep  8 15:51:56 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 08 Sep 2009 21:51:56 +0200
 Subject: [sup-talk] master branch merge report
 In-Reply-To: <1252438950-sup-3895@masanjin.net>
 References: <1252438950-sup-3895@masanjin.net>
 Message-ID: <1252439403-sup-6192@peray>
 
 Excerpts from William Morgan's message of Tue Sep 08 21:45:32 +0200 2009:
 > On preparation for an 0.9 release, I've merged the following branches
 > into master (in case anyone's keeping track!): console-mode,
 > reply-all-keybindings, restore-state, logging-tweaks,
 > enclosed-message-display-tweaks, hook-local-vars.
 > 
 > If anyone's running master, keep an eye out for changes and problems.
 
 Thanks for these reports on the status of branches. They are really precious.
 May ask for more? :) I would like you to also report on the status of what is
 merged in next (or not yet merged in master).
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 16:05:14 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 13:05:14 -0700
 Subject: [sup-talk] master branch merge report
 In-Reply-To: <1252439403-sup-6192@peray>
 References: <1252438950-sup-3895@masanjin.net> <1252439403-sup-6192@peray>
 Message-ID: <1252440062-sup-8543@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-09-08:
 > Thanks for these reports on the status of branches. They are really
 > precious.  May ask for more? :) I would like you to also report on the
 > status of what is merged in next (or not yet merged in master).
 
 The only branches not merged into master at this point are
 preemptive-loading and alignment-tweaks. This is based on a gut estimate
 of whether they need to bake a little longer.
 
 You can always get a complete report by using git wtf
 (http://git-wt-commit.rubyforge.org/git-wtf). `git wtf -r -s master` and
 `git wtf -r -s next` will show you what's merged into master and next
 respectively.
 
 I've also just merged custom-search-hook into master, with some effort.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 16:08:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 13:08:03 -0700
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252422961-sup-9843@chigamba>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net> <1252422961-sup-9843@chigamba>
 Message-ID: <1252440374-sup-9813@masanjin.net>
 
 Reformatted excerpts from Wirt Wolff's message of 2009-09-08:
 > Don't mind having 'a' and 'd' around, but likely won't use them.
 
 So far I'm counting 3 yes votes (including patch submitter), 3 "won't
 use them" votes (including me), and no one being offended. I think I'm
 going to apply this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Tue Sep  8 16:26:45 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 08 Sep 2009 13:26:45 -0700
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252266137-sup-4139@peray>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net> <1252266137-sup-4139@peray>
 Message-ID: <1252441461-sup-5330@yoom.home.cworth.org>
 
 Excerpts from Nicolas Pouillard's message of Sun Sep 06 12:43:06 -0700 2009:
 > I personally do prefer ]a and ]d, to read mail in the chronological order.
 
 What if there were a way to reverse the sort order for the index view?
 That would then change the meaning of "next" and "previous" and then
 you could use the single letter 'a' and 'd' commands to read your mail
 in chronological order.
 
 Would that make sense? Because that is something I would like to do on
 occasion.
 
 -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/20090908/01fd44fe/attachment.bin>
 
 From nicolas.pouillard@gmail.com  Tue Sep  8 16:28:56 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 08 Sep 2009 22:28:56 +0200
 Subject: [sup-talk] master branch merge report
 In-Reply-To: <1252440062-sup-8543@masanjin.net>
 References: <1252438950-sup-3895@masanjin.net> <1252439403-sup-6192@peray>
 	<1252440062-sup-8543@masanjin.net>
 Message-ID: <1252441390-sup-9847@peray>
 
 Excerpts from William Morgan's message of Tue Sep 08 22:05:14 +0200 2009:
 > Reformatted excerpts from Nicolas Pouillard's message of 2009-09-08:
 > > Thanks for these reports on the status of branches. They are really
 > > precious.  May ask for more? :) I would like you to also report on the
 > > status of what is merged in next (or not yet merged in master).
 > 
 > The only branches not merged into master at this point are
 > preemptive-loading and alignment-tweaks. This is based on a gut estimate
 > of whether they need to bake a little longer.
 
 OK nice.
 
 > You can always get a complete report by using git wtf
 > (http://git-wt-commit.rubyforge.org/git-wtf). `git wtf -r -s master` and
 > `git wtf -r -s next` will show you what's merged into master and next
 > respectively.
 
 I already use git-wtf (thanks for this tool BTW), with still some pain though.
 
 These two commands outputs ~60 lines about dozen of branches. However that's
 mainly due to the fact that I do have private branches.
 
 It would be nice to simply ask differences between to branches in terms of
 merged branches: git wtf mainline/master..mainline/next
 
 > I've also just merged custom-search-hook into master, with some effort.
 
 Thanks
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From nicolas.pouillard@gmail.com  Tue Sep  8 16:33:13 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 08 Sep 2009 22:33:13 +0200
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252441461-sup-5330@yoom.home.cworth.org>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net> <1252266137-sup-4139@peray>
 	<1252441461-sup-5330@yoom.home.cworth.org>
 Message-ID: <1252441854-sup-203@peray>
 
 Excerpts from Carl Worth's message of Tue Sep 08 22:26:45 +0200 2009:
 > Excerpts from Nicolas Pouillard's message of Sun Sep 06 12:43:06 -0700 2009:
 > > I personally do prefer ]a and ]d, to read mail in the chronological order.
 > 
 > What if there were a way to reverse the sort order for the index view?
 > That would then change the meaning of "next" and "previous" and then
 > you could use the single letter 'a' and 'd' commands to read your mail
 > in chronological order.
 > 
 > Would that make sense? Because that is something I would like to do on
 > occasion.
 
 Yes it does make sense. This change would both improve this feature and
 will reduce the default enforcement.
 
 Regards,
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 16:38:35 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 13:38:35 -0700
 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox
 In-Reply-To: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com>
 References: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com>
 Message-ID: <1252442225-sup-154@masanjin.net>
 
 Reformatted excerpts from Richard Sandilands's message of 2009-09-07:
 > Am tracking 'next' branch and moved to Xapian earlier today.
 
 Do you have a before-add-message hook? If so, I'm sorry to say that you
 will have to regenerate your index to fix this. There was a problem with
 next for a while that allowed that hook to add non-symbol labels to
 messages, and those got serialized into Xapian's index.
 
 If not, regenerating it will probably help, but it would be good to find
 the source of the non-symbol labels.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 16:45:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 13:45:08 -0700
 Subject: [sup-talk] lbdb module for sup
 In-Reply-To: <1252340369-sup-9611@qwerzila>
 References: <1252340369-sup-9611@qwerzila>
 Message-ID: <1252442690-sup-9709@masanjin.net>
 
 Reformatted excerpts from Gaute Hope's message of 2009-09-07:
 > attached is a lbdb (http://sup.rubyforge.org/wiki/wiki.pl?LbdbIntegration)
 > module for the sup contact list. Useful if you want access to the sup
 > contact list from Vim.
 
 Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Sep  8 16:47:18 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 08 Sep 2009 13:47:18 -0700
 Subject: [sup-talk] Can't add a local maildir source
 In-Reply-To: <2e8d08f0909031602r37472cdcjcf4826f7cd2b48c7@mail.gmail.com>
 References: <2e8d08f0909031602r37472cdcjcf4826f7cd2b48c7@mail.gmail.com>
 Message-ID: <1252442749-sup-842@masanjin.net>
 
 Reformatted excerpts from infoarts's message of 2009-09-03:
 > I'm tracking next via git and am having trouble adding a mail source.
 
 This should be fixed in the latest next. Sorry about that!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Tue Sep  8 16:50:52 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 08 Sep 2009 13:50:52 -0700
 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view?
 In-Reply-To: <1252241877-sup-6125@masanjin.net>
 References: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local>
 	<1252241877-sup-6125@masanjin.net>
 Message-ID: <1252442174-sup-1472@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Sun Sep 06 06:07:48 -0700 2009:
 > Reformatted excerpts from Richard Sandilands's message of 2009-09-06:
 > > Is there a setting for this element?
 > 
 > Currently the highlight color is generated programmatically, so there's
 > no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa
 > line 82) if you want.
 
 Thanks for pointing this out. The highlight color has been one of the
 last color annoyances for me, but I hadn't done the effort to find
 this in the code yet.
 
 > Ideas on how to move this configuration to colors.yaml (or some other
 > configuration mechanism) welcome.
 
 What I think I would really like is a mode where none of the
 foreground colors/attributes change at all, (it seems distracting to
 have the text invert while trying to process mail quickly).
 
 Instead, I'd like the highlight to be a subtle change in the
 background color, (but still light or dark like the background so that
 the foreground colors are all still readable).
 
 I poked around at this, and my terminal does have two variants of each
 of 8 colors available (one brighter than the other), so it seemed like
 I should be able to use one as the normal background and one as the
 highlight background. But on looking closer, it appears that the
 terminal color support here is to name the 8 different colors and to
 select the variant for each with the bold attribute. So if I'm
 understanding that correctly, that's 16 colors available for the
 foreground, but only 8 for the background. That's frustrating.
 
 Such a limited color selection is almost unimaginable with hardware
 capability today. (I do see references to "xterm-256color"[*] terminal
 definitions. Could sup start depending on things like that? Are there
 users of sup using the Linux console or so, and does that support
 256-color escape codes?).
 
 Anyway, I gave up for now and decided not to use color for highlight
 at all. Instead, I did:
 
   def highlight_for fg, bg, attrs
     [fg, bg, attrs + [Curses::A_UNDERLINE]]
 
 I should figure out how to make the underline vs. color choice for
 highlighting to be a configuration option in order to propose this as
 a proper patch. But I still would prefer a subtle change in the
 background color instead of an underline if anyone can figure out how
 to give me that[**].
 
 -Car
 
 [*] And even 256 colors is antiquated. Anything requiring a fixed
 palette is very constraining on an application author today.
 
 [**] Of course, one way is to go away from a curses-based
 interface. That might very well make sense in the future where sup is
 implemented as a protocol and we can easily have multiple clients. For
 me, a graphical client won't be of any interest unless it allows full
 keyboard control exactly as sup does, but if it does that and renders
 text as well as my terminal, I could imagine using it.
 
 From richard@infoarts.info  Tue Sep  8 17:13:07 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Wed, 9 Sep 2009 07:13:07 +1000
 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox
 In-Reply-To: <1252442225-sup-154@masanjin.net>
 References: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com>
 	<1252442225-sup-154@masanjin.net>
 Message-ID: <2e8d08f0909081413i402cbb71sfbff3b1fb5e59a2f@mail.gmail.com>
 
 On Wed, Sep 9, 2009 at 6:38 AM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 
 > Do you have a before-add-message hook? If so, I'm sorry to say that you
 > will have to regenerate your index to fix this. There was a problem with
 > next for a while that allowed that hook to add non-symbol labels to
 > messages, and those got serialized into Xapian's index.
 
 I do indeed, as follows:
 
    if message.subj =~ /\[sup-talk\]/
     message.add_label "sup"
     message.add_label "list"
   end
 
 
 > If not, regenerating it will probably help, but it would be good to find
 > the source of the non-symbol labels.
 
 I do have some labels prepended with an ! to force them to sort to the
 top of the 'L' list - such as '!followup', '!hold' etc. Could that be
 an issue?
 
 -- 
 Richard
 
 From sean.escriva@gmail.com  Tue Sep  8 17:50:23 2009
 From: sean.escriva@gmail.com (Sean Escriva)
 Date: Tue, 8 Sep 2009 14:50:23 -0700
 Subject: [sup-talk] a few questions on mail handling with sup
 In-Reply-To: <1252098027-sup-4487@ntdws12.chass.utoronto.ca>
 References: <20090904191332.GA5525@gmail.com>
 	<1252098027-sup-4487@ntdws12.chass.utoronto.ca>
 Message-ID: <20090908215023.GA7134@gmail.com>
 
 Excerpts from Ben Walton's message of Fri Sep 04 05:01:11 -0400 2009:
 > Excerpts from Sean Escriva's message of Fri Sep 04 15:13:32 -0400 2009:
 > 
 > > Currently I have no way to way move messages out of my inbox on the
 > > imap server, since I'm accessing a local maildir created by
 > > offlineimap. This is only an issue since mailboxes have a limit of
 > > 800mb in size on the server and given the volume of mail I have that
 > > will be reached every other month. I've looked at imap filter and this
 > > could possibly work, but anyone have experience with this sort of
 > > sitatuation?
 > 
 > Could you pull it down with fetchmail into a local MTA setup that only
 > handles local delivery?  Fetchmail has the 'delete on server' option
 > if offlineimap doesn't.
 
 thanks for the reply. fetchmail/procmail is a better option in this
 case than offlineimap. No need to setup a whole different MTA since I
 am already using msmtp for sending...
 
 thanks again.
 
 -sme
 
 From rlane@club.cc.cmu.edu  Wed Sep  9 02:18:09 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 09 Sep 2009 02:18:09 -0400
 Subject: [sup-talk] sup-sync and xapian memory usage
 In-Reply-To: <1252422827-sup-805@peray>
 References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net>
 	<1252350686-sup-8800@ntdws12.chass.utoronto.ca>
 	<1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net>
 	<1252419716-sup-3031@roughage.com.au> <1252422827-sup-805@peray>
 Message-ID: <1252427486-sup-8093@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Tue Sep 08 11:14:22 -0400 2009:
 > Excerpts from Richard Heycock's message of Tue Sep 08 16:27:10 +0200 2009:
 > > Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009:
 > > > Reformatted excerpts from Rich Lane's message of 2009-09-07:
 > > > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009:
 > > > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009:
 > > > > > > Xapian keeps writes buffered in memory. Try setting the
 > > > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value
 > > > > > > (the default is 10000 documents) and see if that helps.
 > > > > > 
 > > > > > Does this explain the lag at shutdown?  Xapian is flushing writes to
 > > > > > disk?
 > > > > 
 > > > > Yep.
 > > > 
 > > > Good to know. Is there a way to force a flush in Xapian? Just curious.
 > > > The delay is a little scary sometimes. Maybe it just needs an
 > > > appropriate message somewhere.
 > > 
 > > Xapian, by default, flushes every 10 000 documents which in email terms
 > > is a pretty long time! You can force a flush but it does increase your
 > > IO significantly. Having said that emails are fairly small so flushing
 > > every 10 or 20 emails might not be too bad.
 > > 
 > > Maybe it could be dynamic, if there is a high volume of incoming emails
 > > flushing could be done after 50 or 100 emails or a timer based flush
 > > might be easier.
 > 
 > Should the '$' command, force a write of the Xapian database?
 
 I think once we're saving label changes to the index immediately we
 could re-purpose '$' for this. I've also been considering a timer, as
 Richard suggests, which would trigger a flush once the user has been
 idle for some time.
 
 A fatal exception in Sup is still a clean exit as far as SWIG is
 concerned and the Xapian database destructor will do the flush for us in
 that case, so don't worry about random Sup exceptions causing data loss.
 
 From eg@gaute.vetsj.com  Wed Sep  9 03:54:53 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Wed, 09 Sep 2009 09:54:53 +0200
 Subject: [sup-talk] Exception when trying to open console view
 Message-ID: <1252482842-sup-4833@qwerzila>
 
 Greetings,
 
 I get this exception when pressing '~' in the main view:
 
 --- ArgumentError from thread: main
 wrong number of arguments (0 for 1)
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302:in `new'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/buffer.rb:341:in `spawn_unless_exists'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302
 /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
 /home/gaute/.gem/ruby/1.8/bin/sup:19
 
 Cheers, Gaute
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 198 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/b3e999f6/attachment.bin>
 
 From eg@gaute.vetsj.com  Wed Sep  9 04:49:21 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Wed, 09 Sep 2009 10:49:21 +0200
 Subject: [sup-talk] updated before-poll hook for offlineimap
 Message-ID: <1252485986-sup-4958@qwerzila>
 
 Greetings,
 
 Here's an updated before-poll.rb hook for offlineimap working with
 latest git. I'm suppressing some nasty python deprecation errors as
 well.
 
 before-poll.rb:
 def offlineimap(*folders)
   cmd = "offlineimap -u Noninteractive.Basic 2>&1"
   cmd << " -f #{folders * ','}" unless folders.compact.empty?
   `#{cmd}`
 end
 
 def folder_names(sources)
   sources.map { |s| s.uri.split('/').last }
 end
 
 def inbox_sources(sources = SourceManager.sources)
   sources.find_all { |s| !s.archived? }.sort_by {|s| s.id }
 end
 
 if (@last_fetch || Time.at(0)) < Time.now - 120
   say "Running offlineimap..."
   # only check non-auto-archived sources on the first run
   log offlineimap(@last_fetch ? nil : folder_names(inbox_sources))
   say "Finished offlineimap."
 end
 @last_fetch = Time.now
 
 Cheers, Gaute
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 198 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/1b71019d/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Wed Sep  9 09:54:55 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 09 Sep 2009 09:54:55 -0400
 Subject: [sup-talk] U (unread) search is off
 Message-ID: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 
 
 Since my update to Xapian, my U searches to display on unread mail
 aren't working correctly any more.  I get lots of mail that is
 definitely read (doesn't show as new in the search buffer).  Is anyone
 else seeing this?  I'm hoping to dig into it later today, but wanted
 to fire of the query first.
 
 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/20090909/f80057be/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Wed Sep  9 10:14:16 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 09 Sep 2009 07:14:16 -0700
 Subject: [sup-talk] Exception when trying to open console view
 In-Reply-To: <1252482842-sup-4833@qwerzila>
 References: <1252482842-sup-4833@qwerzila>
 Message-ID: <1252505638-sup-6887@masanjin.net>
 
 Reformatted excerpts from Gaute Hope's message of 2009-09-09:
 > --- ArgumentError from thread: main
 > wrong number of arguments (0 for 1)
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize'
 
 Fixed in master and next. Sorry about that.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep  9 10:20:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 09 Sep 2009 07:20:03 -0700
 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox
 In-Reply-To: <2e8d08f0909081413i402cbb71sfbff3b1fb5e59a2f@mail.gmail.com>
 References: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com>
 	<1252442225-sup-154@masanjin.net>
 	<2e8d08f0909081413i402cbb71sfbff3b1fb5e59a2f@mail.gmail.com>
 Message-ID: <1252505721-sup-2684@masanjin.net>
 
 Reformatted excerpts from Richard Sandilands's message of 2009-09-08:
 > I do indeed, as follows:
 
 Excellent.
 
 > I do have some labels prepended with an ! to force them to sort to the
 > top of the 'L' list - such as '!followup', '!hold' etc. Could that be
 > an issue?
 
 Nope, it was the hook above. (Which is fine, btw, it just triggered
 something bad.) You will need to regenerate the index and everything
 should be fine. Sorry about that.
 
 If you don't have a recent dumpfile, you may have to apply the following
 patch to get sup-dump to work. Then you should be able to git fetch,
 reset the head to origin/next, and run `sup-sync --restored --restore
 <dumpfile> --all-sources`.
 
 Let me know if you run into problems.
 
 diff --git a/lib/sup/label.rb b/lib/sup/label.rb
 index 67474c2..b94474d 100644
 --- a/lib/sup/label.rb
 +++ b/lib/sup/label.rb
 @@ -61,7 +61,7 @@ class LabelManager
    end
  
    def << t
 -    raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol
 +    t = t.to_sym
      unless @labels.member?(t) || RESERVED_LABELS.member?(t)
        @labels[t] = true
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep  9 10:30:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 09 Sep 2009 07:30:43 -0700
 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view?
 In-Reply-To: <1252442174-sup-1472@yoom.home.cworth.org>
 References: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local>
 	<1252241877-sup-6125@masanjin.net>
 	<1252442174-sup-1472@yoom.home.cworth.org>
 Message-ID: <1252506333-sup-9244@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-09-08:
 > So if I'm understanding that correctly, that's 16 colors available for
 > the foreground, but only 8 for the background. That's frustrating.
 
 Yup. Curses is happy to welcome you to 1982!
 
 > Such a limited color selection is almost unimaginable with hardware
 > capability today.
 
 FWIW, most terminal emulators allow you to tweak the actual colors that
 the curses colors refer to. So you have some flexibility about the
 actual colors, just a small palette.
 
 > (I do see references to "xterm-256color"[*] terminal definitions.
 > Could sup start depending on things like that? Are there users of sup
 > using the Linux console or so, and does that support 256-color escape
 > codes?).
 
 I'm not sure. I suspect no, but I would be interested in learning more.
 
 > I should figure out how to make the underline vs. color choice for
 > highlighting to be a configuration option in order to propose this as
 > a proper patch.
 
 I think the only patch I would accept at this point for tweaking the
 highlight would be a new hook.
 
 > Of course, one way is to go away from a curses-based interface. That
 > might very well make sense in the future where sup is implemented as a
 > protocol and we can easily have multiple clients.
 
 That is one of the goals.
 
 > For me, a graphical client won't be of any interest unless it allows
 > full keyboard control exactly as sup does, but if it does that and
 > renders text as well as my terminal, I could imagine using it.
 
 I agree completely.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep  9 10:37:16 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 09 Sep 2009 07:37:16 -0700
 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to
 	thread-view-mode to archive/delete current thread
 In-Reply-To: <1252440374-sup-9813@masanjin.net>
 References: <1251325542-sup-3105@yoom.home.cworth.org>
 	<1252000831-sup-9922@masanjin.net> <1252422961-sup-9843@chigamba>
 	<1252440374-sup-9813@masanjin.net>
 Message-ID: <1252507021-sup-715@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-09-08:
 > So far I'm counting 3 yes votes (including patch submitter), 3 "won't
 > use them" votes (including me), and no one being offended. I think I'm
 > going to apply this.
 
 Applied to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep  9 10:38:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 09 Sep 2009 07:38:59 -0700
 Subject: [sup-talk] [PATCH] sort labels in the dump
 In-Reply-To: <1252271062-8775-1-git-send-email-michael@content-space.de>
 References: <1252271062-8775-1-git-send-email-michael@content-space.de>
 Message-ID: <1252507122-sup-5429@masanjin.net>
 
 Applied to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Wed Sep  9 13:24:13 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 09 Sep 2009 10:24:13 -0700
 Subject: [sup-talk] Thoughts on simplifying thread-view-mode keybindings
 Message-ID: <1252516237-sup-9414@yoom.home.cworth.org>
 
 I only just barely got my proposal for new 'a' and 'd' keybindings
 into master, and now I'm rethinking them to some extent.
 
 Take a look at the existing keybindings for navigating away from the
 current thread:
 
       .a : Archive this thread and kill buffer
       .d : Delete this thread and kill buffer
       .s : Mark this thread as spam and kill buffer
       .N : Mark this thread as unread and kill buffer
       ,a : Archive this thread, kill buffer, and view next
       ,d : Delete this thread, kill buffer, and view next
       ,s : Mark this thread as spam, kill buffer, and view next
       ,N : Mark this thread as unread, kill buffer, and view next
       ,n : Kill buffer, and view next
       ]a : Archive this thread, kill buffer, and view previous
       ]d : Delete this thread, kill buffer, and view previous
       ]s : Mark this thread as spam, kill buffer, and view previous
       ]N : Mark this thread as unread, kill buffer, and view previous
       ]n : Kill buffer, and view previous
 
 Each of these keybindings involve two keys, and each command involves
 two actions. But the order of the keybindings and actions are reversed.
 
 Imagine, for a moment, what would happen if the keybinding order was
 "fixed" to match the order of the commands, (that is, things like "a,"
 for archive, then view next). With that change, we would no longer
 need dual-key bindings as the single-key actions could be easily
 combined with the same effect.
 
 That is, we could have just:
 
       a : Archive this thread
       d : Delete this thread
       s : Mark this thread as spam
       N : Mark this thread as unread
       ., x : Kill this buffer
       , : View next thread
       ] : View previous thread
 
 That's definitely a simpler amount of documentation to have to grasp,
 and shouldn't be any less work to actually use, (other than the pain
 of having to retrain muscle memory to do things like "a," instead of
 ",a").
 
 The next tweak I'd make is to choose keybdindings for 'next' and
 'previous' that more obviously go together. (Such as '[' and ']', but
 then I think I'd also expect '[' to mean previous and ']' to mean next
 which might wreak havoc on muscle memory).
 
 Finally, I'd personally still want a single-key keybinding to do my
 most frequent combination, (such as archive-and-view-next as with the
 current 'a' that just landed in master), but maybe that makes more
 sense to happen only in a hook.
 
 What do you all think?
 
 Me, I'm pretty new to sup, so the muscle-memory thing isn't *too* big
 an issue. Is sup still young enough as a tool to be able to accept
 interface changes like this?
 
 -Carl
 
 From cworth@cworth.org  Wed Sep  9 13:32:30 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 09 Sep 2009 10:32:30 -0700
 Subject: [sup-talk] How hard would a universal undo be?
 Message-ID: <1252517083-sup-58@yoom.home.cworth.org>
 
 Being a ruthless mail-processor, I sometimes archive or delete a
 message hastily and realize a moment later that I actually want to
 look at the message again.
 
 Of course, if that happens when I'm in a thread-index-mode, then I can
 just hit 'u' to undo and all is fine.
 
 But if I make the same mistake in thread-view-mode then I'm currently
 out of luck.
 
 Would it be a small change to move the undo keybinding to somewhere
 more universal?
 
 As a first cut, I'd be happy if it just undid the changes to the
 index, even without undoing any interface changes. That is, if my
 previous command was archive-thread-and-view-next-thread, it would be
 OK if it just undid the archiving part. Bonus points if it also undoes
 the view-next part, but I can imagine that being more work.
 
 Again, this is a feature I'd be happy to spend some time investigating
 myself when I get the chance. I'd just be happy to hear any thoughts
 on feasibility. And I'm trying to get in the habit of mentioning
 issues as I run into them rather than waiting until I have the chance
 to actually work on them, (at which point I may have forgotten the
 issues).
 
 -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/20090909/28acedf6/attachment.bin>
 
 From eg@gaute.vetsj.com  Wed Sep  9 13:37:29 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Wed, 09 Sep 2009 19:37:29 +0200
 Subject: [sup-talk] updated before-poll hook for offlineimap
 In-Reply-To: <1252485986-sup-4958@qwerzila>
 References: <1252485986-sup-4958@qwerzila>
 Message-ID: <1252517773-sup-6259@qwerzila>
 
 Greetings,
 
 It seems like the before-poll.rb hooks is not run when i manually poll
 for messages; pressing P. Could this be correct?
 
 Running 8903cdedc81
 
 - gaute
 
 Excerpts from Gaute Hope's message of on. sep. 09 10:49:21 +0200 2009:
 > Greetings,
 > 
 > Here's an updated before-poll.rb hook for offlineimap working with
 > latest git. I'm suppressing some nasty python deprecation errors as
 > well.
 > 
 > before-poll.rb:
 > def offlineimap(*folders)
 >   cmd = "offlineimap -u Noninteractive.Basic 2>&1"
 >   cmd << " -f #{folders * ','}" unless folders.compact.empty?
 >   `#{cmd}`
 > end
 > 
 > def folder_names(sources)
 >   sources.map { |s| s.uri.split('/').last }
 > end
 > 
 > def inbox_sources(sources = SourceManager.sources)
 >   sources.find_all { |s| !s.archived? }.sort_by {|s| s.id }
 > end
 > 
 > if (@last_fetch || Time.at(0)) < Time.now - 120
 >   say "Running offlineimap..."
 >   # only check non-auto-archived sources on the first run
 >   log offlineimap(@last_fetch ? nil : folder_names(inbox_sources))
 >   say "Finished offlineimap."
 > end
 > @last_fetch = Time.now
 > 
 > Cheers, Gaute
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 198 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090909/ea954818/attachment.bin>
 
 From ingmar@exherbo.org  Thu Sep 10 07:22:30 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Thu, 10 Sep 2009 13:22:30 +0200
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 Message-ID: <1252581713-sup-9701@cannonball>
 
 Excerpts from Ben Walton's message of Wed Sep 09 15:54:55 +0200 2009:
 > 
 > Since my update to Xapian, my U searches to display on unread mail
 > aren't working correctly any more.  I get lots of mail that is
 > definitely read (doesn't show as new in the search buffer).  Is anyone
 > else seeing this?  I'm hoping to dig into it later today, but wanted
 > to fire of the query first.
 > 
 > Thanks
 > -Ben
 
 Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and
 Rich's answer to my mail.
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From wmorgan-sup@masanjin.net  Thu Sep 10 09:59:13 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 10 Sep 2009 06:59:13 -0700
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252581713-sup-9701@cannonball>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball>
 Message-ID: <1252590993-sup-3885@masanjin.net>
 
 Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10:
 > Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and
 > Rich's answer to my mail.
 
 Actually, I haven't been following this too closely, but what is the status?
 I noticed we have this in xapian_index.rb:
     qp.default_op = Xapian::Query::OP_AND
 
 Is that not sufficient (combined with a newish Xapian, I guess?) to fix
 the problem?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Thu Sep 10 09:57:42 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Thu, 10 Sep 2009 15:57:42 +0200
 Subject: [sup-talk] GPG: Sending mail to people without a trust-path
 Message-ID: <1252590996-sup-4087@midna>
 
 Hi,
 
 occasionally, I receive E-Mail by people who do not have any signatures or
 at least no trust-path to me. sup (or GPG?) rejects to encrypt mail for such
 people, just stating:
 
 There is no indication that the key belongs to this user
 
 It would be good if we can fix this somehow.
 
 Best regards,
 Michael
 
 From bwalton@artsci.utoronto.ca  Thu Sep 10 10:04:02 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 10 Sep 2009 10:04:02 -0400
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252590993-sup-3885@masanjin.net>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 Message-ID: <1252591407-sup-1747@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009:
 
 > Is that not sufficient (combined with a newish Xapian, I guess?) to fix
 > the problem?
 
 I'm running 1.0.14.  Maybe I need to update to 1.0.15 then?
 
 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/20090910/d6b22755/attachment.bin>
 
 From ingmar@exherbo.org  Thu Sep 10 10:08:15 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Thu, 10 Sep 2009 16:08:15 +0200
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252590993-sup-3885@masanjin.net>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 Message-ID: <1252591597-sup-1906@cannonball>
 
 Excerpts from William Morgan's message of Thu Sep 10 15:59:13 +0200 2009:
 > Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10:
 > > Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and
 > > Rich's answer to my mail.
 > 
 > Actually, I haven't been following this too closely, but what is the status?
 > I noticed we have this in xapian_index.rb:
 >     qp.default_op = Xapian::Query::OP_AND
 > 
 > Is that not sufficient (combined with a newish Xapian, I guess?) to fix
 > the problem?
 
 Refining a query still doesn't work: Searching for label:foo, then
 piping through label:bar gives messages that even have neither label.
 
 This is on xapian 1.0.15
 -- 
 Exherbo KDE, X.org maintainer
 
 From wmorgan-sup@masanjin.net  Thu Sep 10 10:13:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 10 Sep 2009 07:13:50 -0700
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <1252517083-sup-58@yoom.home.cworth.org>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 Message-ID: <1252591706-sup-7219@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-09-09:
 > Would it be a small change to move the undo keybinding to somewhere
 > more universal?
 
 The undo keybinding could definitely be moved from thread-index-mode to
 the main event loop. That's a small change. The bigger amount of work is
 writing undo lambdas for every operation you want to be able to undo,
 e.g. every command in thread-view-mode. It's not complicated, just a
 little tedious, IMO.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Sep 10 10:34:01 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 10 Sep 2009 07:34:01 -0700
 Subject: [sup-talk] updated before-poll hook for offlineimap
 In-Reply-To: <1252517773-sup-6259@qwerzila>
 References: <1252485986-sup-4958@qwerzila> <1252517773-sup-6259@qwerzila>
 Message-ID: <1252592969-sup-418@masanjin.net>
 
 Reformatted excerpts from Gaute Hope's message of 2009-09-09:
 > It seems like the before-poll.rb hooks is not run when i manually poll
 > for messages; pressing P. Could this be correct?
 
 It should be. Are you sure the before-poll hook isn't dying the first
 time it's run (automatically), causing Sup to skip it the second time
 (when you press P)? You can look in the log buffer.
 
 If that's not the case, can you confirm that PollManager#poll gets
 invoked in both cases?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marco-oweber@gmx.de  Thu Sep 10 10:35:46 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Thu, 10 Sep 2009 16:35:46 +0200
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <1252517083-sup-58@yoom.home.cworth.org>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 Message-ID: <1252592875-sup-5649@nixos>
 
 Excerpts from Carl Worth's message of Wed Sep 09 19:32:30 +0200 2009:
 > Being a ruthless mail-processor, I sometimes archive or delete a
 > message hastily and realize a moment later that I actually want to
 > look at the message again.
 
 What about a "last viewed history" list?
 Then you could use that to review the threads?
 
 Maybe its best to add a property:
 last-viewed-on: timestamp.
 
 Then you can even use the existing search engine to view those threads ?
 
 Marc Weber
 
 From wmorgan-sup@masanjin.net  Thu Sep 10 10:36:22 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 10 Sep 2009 07:36:22 -0700
 Subject: [sup-talk] GPG: Sending mail to people without a trust-path
 In-Reply-To: <1252590996-sup-4087@midna>
 References: <1252590996-sup-4087@midna>
 Message-ID: <1252593258-sup-7506@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-10:
 > occasionally, I receive E-Mail by people who do not have any signatures or
 > at least no trust-path to me. sup (or GPG?) rejects to encrypt mail for such
 > people, just stating:
 > 
 > There is no indication that the key belongs to this user
 > 
 > It would be good if we can fix this somehow.
 
 It's a GPG behavior, which we can work around by adding --always-trust
 to the GPG commandline, but I'm pretty sure someone will object to that.
 Patches for a hook to run gpg in a user-defined matter will be accepted.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Thu Sep 10 12:16:35 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 10 Sep 2009 12:16:35 -0400
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252590993-sup-3885@masanjin.net>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 Message-ID: <1252595946-sup-171@zyrg.net>
 
 There are actually 2 bugs in this thread. Ben is still using Xapian
 1.0.14 which doesn't have my fix for the phantom labels problem.
 Ingmar's message was about the surprise Xapian::QueryParser feature.
 
 Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009:
 > Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10:
 > > Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and
 > > Rich's answer to my mail.
 > 
 > Actually, I haven't been following this too closely, but what is the status?
 > I noticed we have this in xapian_index.rb:
 >     qp.default_op = Xapian::Query::OP_AND
 > 
 > Is that not sufficient (combined with a newish Xapian, I guess?) to fix
 > the problem?
 
 I thought it was, but it turns out that unless you explicitly add AND
 operators Xapian will OR terms over the same field such that
 "label:foo label:bar" gives you the union instead of the intersection.
 
 We could fix this by patching Xapian to make this behavior configurable,
 or we could come up with an index-agnostic simple query language that
 doesn't support boolean operators. The native query language would still
 be available, of course, but the simple one would suffice for most usage
 and potentially have Sup-specific features.
 
 From rlane@club.cc.cmu.edu  Thu Sep 10 12:17:11 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 10 Sep 2009 12:17:11 -0400
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252591407-sup-1747@ntdws12.chass.utoronto.ca>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 	<1252591407-sup-1747@ntdws12.chass.utoronto.ca>
 Message-ID: <1252599402-sup-3970@zyrg.net>
 
 Excerpts from Ben Walton's message of Thu Sep 10 10:04:02 -0400 2009:
 > Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009:
 > 
 > > Is that not sufficient (combined with a newish Xapian, I guess?) to fix
 > > the problem?
 > 
 > I'm running 1.0.14.  Maybe I need to update to 1.0.15 then?
 
 Yes, upgrading to 1.0.15 will fix this problem.
 
 From bwalton@artsci.utoronto.ca  Thu Sep 10 13:13:32 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 10 Sep 2009 13:13:32 -0400
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252599402-sup-3970@zyrg.net>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 	<1252591407-sup-1747@ntdws12.chass.utoronto.ca>
 	<1252599402-sup-3970@zyrg.net>
 Message-ID: <1252602768-sup-3245@ntdws12.chass.utoronto.ca>
 
 Excerpts from Rich Lane's message of Thu Sep 10 12:17:11 -0400 2009:
 
 > Yes, upgrading to 1.0.15 will fix this problem.
 
 Ok, I rolled rpms for 1.0.16 (available to anyone else if they
 want/need them) and updated.  This has resolved the issue for me.
 
 Thanks Rich! :)
 -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/20090910/ec4dc234/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Thu Sep 10 18:45:20 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 10 Sep 2009 18:45:20 -0400
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <1252517083-sup-58@yoom.home.cworth.org>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 Message-ID: <1252599828-sup-7368@zyrg.net>
 
 Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
 > Would it be a small change to move the undo keybinding to somewhere
 > more universal?
 
 No :(
 
 > As a first cut, I'd be happy if it just undid the changes to the
 > index, even without undoing any interface changes. That is, if my
 > previous command was archive-thread-and-view-next-thread, it would be
 > OK if it just undid the archiving part. Bonus points if it also undoes
 > the view-next part, but I can imagine that being more work.
 
 I know I sound a bit like a broken record here, but immediate
 label changes will solve this problem. Then, the undo system would just
 need to keep a global stack of (msgid, previous_labels). I'm just hoping
 somebody will volunteer for this - it will be a big patch.
 
 From nicolas.pouillard@gmail.com  Fri Sep 11 05:16:49 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Fri, 11 Sep 2009 11:16:49 +0200
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <1252599828-sup-7368@zyrg.net>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 	<1252599828-sup-7368@zyrg.net>
 Message-ID: <1252660564-sup-4253@peray>
 
 Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
 > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
 > > Would it be a small change to move the undo keybinding to somewhere
 > > more universal?
 > 
 > No :(
 > 
 > > As a first cut, I'd be happy if it just undid the changes to the
 > > index, even without undoing any interface changes. That is, if my
 > > previous command was archive-thread-and-view-next-thread, it would be
 > > OK if it just undid the archiving part. Bonus points if it also undoes
 > > the view-next part, but I can imagine that being more work.
 > 
 > I know I sound a bit like a broken record here, but immediate
 > label changes will solve this problem. Then, the undo system would just
 > need to keep a global stack of (msgid, previous_labels). I'm just hoping
 > somebody will volunteer for this - it will be a big patch.
 
 What prevent us from having a global stack of (msgid, previous_labels) in
 the actual settings?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From bgamari.foss@gmail.com  Fri Sep 11 12:58:31 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Fri, 11 Sep 2009 12:58:31 -0400
 Subject: [sup-talk] Crash while scrolling
 Message-ID: <20090911165830.GA11260@ben-laptop>
 
 Recently I've been seeing this crash[1] pretty consistently on the next
 branch with the Xapian backend. All I need to do to reproduce the crash
 is move to the last thread in the thread-index-mode and attempt to move
 to the next thread.
 
 I can also produce a very similar crash[2] by attempting to load all
 threads. Thanks,
 
 - Ben
 
 
 [1] Crash while scrolling:
 
 --- RuntimeError from thread: load threads for thread-index-mode
 wrong id called on nil
 /opt/exp/sup/lib/sup.rb:17:in `id'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
 /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
 /opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
 /opt/exp/sup/lib/sup.rb:75:in `initialize'
 /opt/exp/sup/lib/sup.rb:75:in `new'
 /opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /opt/exp/sup/lib/sup/mode.rb:51:in `send'
 /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
 /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
 /usr/bin/sup:238
 
 
 [2] Crash after attempting to load all threads
 --- RuntimeError from thread: load threads for thread-index-mode
 wrong id called on nil
 /opt/exp/sup/lib/sup.rb:17:in `id'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
 /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads'
 /opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads'
 /opt/exp/sup/lib/sup/xapian_index.rb:151:in `each_id_by_date'
 /opt/exp/sup/lib/sup/xapian_index.rb:144:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:144:in `each'
 /opt/exp/sup/lib/sup/xapian_index.rb:144:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:151:in `each_id_by_date'
 /opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
 /opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
 /opt/exp/sup/lib/sup.rb:75:in `initialize'
 /opt/exp/sup/lib/sup.rb:75:in `new'
 /opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:658:in `load_all_threads'
 /opt/exp/sup/lib/sup/mode.rb:51:in `send'
 /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input'
 /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input'
 /usr/bin/sup:238
 
 From rlane@club.cc.cmu.edu  Fri Sep 11 15:52:24 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 11 Sep 2009 15:52:24 -0400
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <1252660564-sup-4253@peray>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 	<1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray>
 Message-ID: <1252685502-sup-8928@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
 > Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
 > > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
 > > > Would it be a small change to move the undo keybinding to somewhere
 > > > more universal?
 > > 
 > > No :(
 > > 
 > > > As a first cut, I'd be happy if it just undid the changes to the
 > > > index, even without undoing any interface changes. That is, if my
 > > > previous command was archive-thread-and-view-next-thread, it would be
 > > > OK if it just undid the archiving part. Bonus points if it also undoes
 > > > the view-next part, but I can imagine that being more work.
 > > 
 > > I know I sound a bit like a broken record here, but immediate
 > > label changes will solve this problem. Then, the undo system would just
 > > need to keep a global stack of (msgid, previous_labels). I'm just hoping
 > > somebody will volunteer for this - it will be a big patch.
 > 
 > What prevent us from having a global stack of (msgid, previous_labels) in
 > the actual settings?
 
 Hmm, you may be right. I was thinking that changes weren't propagated
 between buffers except on save, but that's wrong because UpdateManager
 is called in the keybinding. In that case, the user sees a mostly*
 linear series of label changes, so it's safe to have a global undo
 stack.
 
 *
  User opens thread-index-mode A containing message M with labels L1
  User changes labels on A.M to L2
  User opens thread-index-mode B containing message M with labels L1
  User changes labels on B.M to L3
  UpdateManager changes labels on A.M to L3
  User hits 'u' - now A.M and B.M have labels L1
 
 From nicolas.pouillard@gmail.com  Fri Sep 11 17:25:06 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Fri, 11 Sep 2009 23:25:06 +0200
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <1252685502-sup-8928@zyrg.net>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 	<1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray>
 	<1252685502-sup-8928@zyrg.net>
 Message-ID: <cd67f63a0909111425q7d04332fvd7e23b48e6dab06a@mail.gmail.com>
 
 On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote:
 > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
 >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
 >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
 >> > > Would it be a small change to move the undo keybinding to somewhere
 >> > > more universal?
 >> >
 >> > No :(
 >> >
 >> > > As a first cut, I'd be happy if it just undid the changes to the
 >> > > index, even without undoing any interface changes. That is, if my
 >> > > previous command was archive-thread-and-view-next-thread, it would be
 >> > > OK if it just undid the archiving part. Bonus points if it also undoes
 >> > > the view-next part, but I can imagine that being more work.
 >> >
 >> > I know I sound a bit like a broken record here, but immediate
 >> > label changes will solve this problem. Then, the undo system would just
 >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping
 >> > somebody will volunteer for this - it will be a big patch.
 >>
 >> What prevent us from having a global stack of (msgid, previous_labels) in
 >> the actual settings?
 >
 > Hmm, you may be right. I was thinking that changes weren't propagated
 > between buffers except on save, but that's wrong because UpdateManager
 > is called in the keybinding. In that case, the user sees a mostly*
 > linear series of label changes, so it's safe to have a global undo
 > stack.
 
 he next question is, what else is needed on this undo stack?
 
 Are labels the only interaction we have? Here is what come to my mind:
 
 * contacts (I more and more think that contacts should not be handled by
   sup directly, but that's another topic)
 * drafts
 
 -- 
 Nicolas Pouillard
 
 From wmorgan-sup@masanjin.net  Sat Sep 12 12:35:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 12 Sep 2009 09:35:21 -0700
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <20090911165830.GA11260@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 Message-ID: <1252773189-sup-246@masanjin.net>
 
 Reformatted excerpts from Ben Gamari's message of 2009-09-11:
 > Recently I've been seeing this crash[1] pretty consistently on the next
 > branch with the Xapian backend.
 
 Is your Xapian index somewhat old? There have been index format changes
 that have caused this type of thing recently. You might try rebuilding
 it.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 12 12:47:14 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 12 Sep 2009 09:47:14 -0700
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252595946-sup-171@zyrg.net>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 	<1252595946-sup-171@zyrg.net>
 Message-ID: <1252773806-sup-11@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-10:
 > I thought it was, but it turns out that unless you explicitly add AND
 > operators Xapian will OR terms over the same field such that
 > "label:foo label:bar" gives you the union instead of the intersection.
 
 Ok. I only ask because I'm considering how to present the Xapian index
 option in 0.9---the options are to not say anything about it, to force
 everyone to switch to it, or anywhere in between. 
 
 > We could fix this by patching Xapian to make this behavior
 > configurable, or we could come up with an index-agnostic simple query
 > language that doesn't support boolean operators.
 
 The former sounds easier to me. Especially since it seems like this is
 something Xapian should have...
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 12 13:08:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 12 Sep 2009 10:08:50 -0700
 Subject: [sup-talk] [PATCH] Fix parsing of encrypted messages that
 	contain further multipart elements
 In-Reply-To: <6fd87965a2e243b190678edb6c4b9cefbde9ae66.1248369563.git.dato@net.com.org.es>
 References: <ff7df0405d003a8f4e88f0dd191d8bf4875f73f3.1248368899.git.dato@net.com.org.es>
 	<6fd87965a2e243b190678edb6c4b9cefbde9ae66.1248369563.git.dato@net.com.org.es>
 Message-ID: <1252775304-sup-291@masanjin.net>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
 > Amended patch follows, with a better wording that I had seemingly not
 > committed. Sorry for the noise.
 
 Not sure why I missed this. Branch crypto-mime-fix, merged into next.
 Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From kevinr@free-dissociation.com  Sat Sep 12 15:10:03 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Sat, 12 Sep 2009 15:10:03 -0400
 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail
 	stupidity?
 Message-ID: <1252781841-sup-6303@black-opal.mit.edu>
 
 Several people from whom I receive e-mail regularly use a MUA which 
 generates Content-Type: headers of the form
 > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
 
 The symptoms I see are that I don't get any preview text, and Sup shows
 the message as consisting only of a spurious attachment of the form: 
 > - Attachment: sup-attachment-1252774311-2202. (8 lines) 
 (Note no file-type suffix.)
 
 RFC 2045 (the MIME specification) section 5.1 says in part
 > The type, subtype, and parameter names are not case sensitive.  For
 > example, TEXT, Text, and TeXt are all equivalent top-level media
 > types.
 So the above should be handled just like the many mails with headers of
 the form
 > Content-Type: text/plain; charset="us-ascii"; format=flowed
 I get, which Sup handles perfectly.
 
 I theorize that RubyMail is being case-sensitive where it shouldn't.
 
 Given the number of work-arounds Sup has had to implement to compensate
 for RubyMail's stupidity, and that RubyMail is currently unmaintained,
 has any thought been given to switching Sup to eg. TMail 
 (http://tmail.rubyforge.org), which is maintained?
 
 Failing that, thoughts on how best to work around this problem in Sup?
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 http://free-dissociation.com
 
 From gigabo@gmail.com  Sat Sep 12 17:01:17 2009
 From: gigabo@gmail.com (Bo Borgerson)
 Date: Sat, 12 Sep 2009 17:01:17 -0400
 Subject: [sup-talk] Hello and thanks
 Message-ID: <1252787425-sup-4073@longword>
 
 Hi,
 
 I just started using sup yesterday.  I'm really impressed by it.
 
 As I've been using it I've been thinking of little tweaks to get it working
 exactly how I like.  Some of these will work with hooks (that's a nice system),
 but some seem better suited to small patches.
 
 I'm going to submit some of these patches to see if they're useful enough to
 include upstream.  A git-send-email out of the blue isn't necessarily the
 friendliest of introductions, though, so I just wanted to write first and say
 thanks to William and everyone who has contributed to sup.  It's pretty
 awesome.
 
 Thanks.
 
 Bo
 
 From gigabo@gmail.com  Sat Sep 12 17:04:05 2009
 From: gigabo@gmail.com (Bo Borgerson)
 Date: Sat, 12 Sep 2009 17:04:05 -0400
 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode
 Message-ID: <1252789445-30193-1-git-send-email-gigabo@gmail.com>
 
 Register label-list-mode with the UpdateManager and handle added
 updates with a reload to keep unread message counts up to date
 ---
  lib/sup/modes/label-list-mode.rb |   10 ++++++++++
  1 files changed, 10 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/modes/label-list-mode.rb b/lib/sup/modes/label-list-mode.rb
 index d94f56f..f0084a9 100644
 --- a/lib/sup/modes/label-list-mode.rb
 +++ b/lib/sup/modes/label-list-mode.rb
 @@ -31,9 +31,15 @@ EOS
      @text = []
      @unread_only = false
      super
 +    UpdateManager.register self
      regen_text
    end
  
 +  def cleanup
 +    UpdateManager.unregister self
 +    super
 +  end
 +
    def lines; @text.length end
    def [] i; @text[i] end
  
 @@ -52,6 +58,10 @@ EOS
      reload # make sure unread message counts are up-to-date
    end
  
 +  def handle_added_update sender, m
 +    reload
 +  end
 +
  protected
  
    def toggle_show_unread_only
 -- 
 1.6.0.4
 
 
 From gigabo@gmail.com  Sun Sep 13 10:38:35 2009
 From: gigabo@gmail.com (Bo Borgerson)
 Date: Sun, 13 Sep 2009 10:38:35 -0400
 Subject: [sup-talk] [PATCH] Add command for polling unusual sources
 Message-ID: <1252852715-9601-1-git-send-email-gigabo@gmail.com>
 
 bin/sup: Add new global key binding, '{', to poll unusual sources
 (requires confirmation).  This allows update of unusual sources
 without having to leave sup to run a sync.
 
 lib/sup/poll.rb: Add new method, poll_unusual.  Both the pre-existing
 poll method and the new poll_unusual method are now wrappers around
 new poll_with_sources method that contains the bulk of functionality
 previously in poll.
 
 lib/sup/source.rb: Add new accessor for unusual_sources
 ---
  bin/sup           |    5 +++++
  lib/sup/poll.rb   |   23 +++++++++++++++++++----
  lib/sup/source.rb |    1 +
  3 files changed, 25 insertions(+), 4 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 76a0438..996c99e 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -75,6 +75,7 @@ global_keymap = Keymap.new do |k|
    k.add :search_unread, "Show all unread messages", 'U'
    k.add :list_labels, "List labels", 'L'
    k.add :poll, "Poll for new messages", 'P'
 +  k.add :poll_unusual, "Poll for new messages from unusual sources", '{'
    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'
 @@ -282,6 +283,10 @@ begin
        ComposeMode.spawn_nicely
      when :poll
        reporting_thread("user-invoked poll") { PollManager.poll }
 +    when :poll_unusual
 +      if BufferManager.ask_yes_or_no "Really poll unusual sources?"
 +        reporting_thread("user-invoked unusual poll") { PollManager.poll_unusual }
 +      end
      when :recall_draft
        case Index.num_results_for :label => :draft
        when 0
 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb
 index b59237f..ec51dec 100644
 --- a/lib/sup/poll.rb
 +++ b/lib/sup/poll.rb
 @@ -35,12 +35,11 @@ EOS
      @thread = nil
      @last_poll = nil
      @polling = false
 +    @poll_sources = nil
      @mode = nil
    end
  
 -  def poll
 -    return if @polling
 -    @polling = true
 +  def poll_with_sources
      @mode ||= PollMode.new
      HookManager.run "before-poll"
  
 @@ -54,6 +53,22 @@ EOS
  
      HookManager.run "after-poll", :num => num, :num_inbox => numi, :from_and_subj => from_and_subj, :from_and_subj_inbox => from_and_subj_inbox, :num_inbox_total_unread => lambda { Index.num_results_for :labels => [:inbox, :unread] }
  
 +  end
 +
 +  def poll
 +    return if @polling
 +    @polling = true
 +    @poll_sources = SourceManager.usual_sources
 +    num, numi = poll_with_sources
 +    @polling = false
 +    [num, numi]
 +  end
 +
 +  def poll_unusual
 +    return if @polling
 +    @polling = true
 +    @poll_sources = SourceManager.unusual_sources
 +    num, numi = poll_with_sources
      @polling = false
      [num, numi]
    end
 @@ -78,7 +93,7 @@ EOS
      from_and_subj_inbox = []
  
      @mutex.synchronize do
 -      SourceManager.usual_sources.each do |source|
 +      @poll_sources.each do |source|
  #        yield "source #{source} is done? #{source.done?} (cur_offset #{source.cur_offset} >= #{source.end_offset})"
          begin
            yield "Loading from #{source}... " unless source.done? || (source.respond_to?(:has_errors?) && source.has_errors?)
 diff --git a/lib/sup/source.rb b/lib/sup/source.rb
 index 78386ff..6fe7bfb 100644
 --- a/lib/sup/source.rb
 +++ b/lib/sup/source.rb
 @@ -207,6 +207,7 @@ class SourceManager
  
    def source_for uri; sources.find { |s| s.is_source_for? uri }; end
    def usual_sources; sources.find_all { |s| s.usual? }; end
 +  def unusual_sources; sources.find_all { |s| !s.usual? }; end
  
    def load_sources fn=Redwood::SOURCE_FN
      source_array = (Redwood::load_yaml_obj(fn) || []).map { |o| Recoverable.new o }
 -- 
 1.6.0.4
 
 
 From bgamari.foss@gmail.com  Sun Sep 13 11:02:32 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Sun, 13 Sep 2009 11:02:32 -0400
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1252773189-sup-246@masanjin.net>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 Message-ID: <20090913150232.GB10024@ben-laptop>
 
 On Sat, Sep 12, 2009 at 09:35:21AM -0700, William Morgan wrote:
 > Reformatted excerpts from Ben Gamari's message of 2009-09-11:
 > > Recently I've been seeing this crash[1] pretty consistently on the next
 > > branch with the Xapian backend.
 > 
 > Is your Xapian index somewhat old? There have been index format changes
 > that have caused this type of thing recently. You might try rebuilding
 > it.
 
 I wish I could say it was unfortunately I just rebuilt it two days ago,
 suspecting that might be part of the issue. I'll try again, just to make
 sure but I'm fairly certain the index is up-to-date.
 
 - Ben
 
 
 From rlane@club.cc.cmu.edu  Sun Sep 13 14:44:09 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 13 Sep 2009 11:44:09 -0700
 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state
 Message-ID: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
 
 Refactor index_message so that we do the minimal amount of work based on what
 state the user has modified.
 ---
  lib/sup/xapian_index.rb |  241 +++++++++++++++++++++++++++--------------------
  1 files changed, 137 insertions(+), 104 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index e1cfe65..ad45b0e 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -42,8 +42,6 @@ EOS
        @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
      @enquire.weighting_scheme = Xapian::BoolWeight.new
      @enquire.docid_order = Xapian::Enquire::ASCENDING
 @@ -91,41 +89,9 @@ EOS
      m
    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
 -
 -  def sync_message m, opts={}
 -    entry = synchronize { get_entry m.id }
 -    snippet = m.snippet
 -    entry ||= {}
 -    labels = m.labels
 -    entry = {} if opts[:force_overwrite]
 -
 -    d = {
 -      :message_id => m.id,
 -      :source_id => m.source.id,
 -      :source_info => m.source_info,
 -      :date => (entry[:date] || m.date),
 -      :snippet => snippet,
 -      :labels => labels,
 -      :from => (entry[:from] || [m.from.email, m.from.name]),
 -      :to => (entry[:to] || m.to.map { |p| [p.email, p.name] }),
 -      :cc => (entry[:cc] || m.cc.map { |p| [p.email, p.name] }),
 -      :bcc => (entry[:bcc] || m.bcc.map { |p| [p.email, p.name] }),
 -      :subject => m.subj,
 -      :refs => (entry[:refs] || m.refs),
 -      :replytos => (entry[:replytos] || m.replytos),
 -    }
 -
 -    labels.each { |l| LabelManager << l }
 -
 -    synchronize do
 -      index_message m, d, opts
 -    end
 -    true
 -  end
 -  private :sync_message
 +  def add_message m; sync_message m, true end
 +  def update_message m; sync_message m, true end
 +  def update_message_state m; sync_message m, false end
  
    def num_results_for query={}
      xapian_query = build_xapian_query query
 @@ -153,7 +119,6 @@ EOS
  
    def each_message_in_thread_for m, opts={}
      # TODO thread by subject
 -    # TODO handle killed threads
      return unless doc = find_doc(m.id)
      queue = doc.value(THREAD_VALUENO).split(',')
      msgids = [m.id]
 @@ -438,100 +403,140 @@ EOS
      end
    end
  
 -  def index_message m, entry, opts
 -    terms = []
 -    text = []
 +  def sync_message m, overwrite
 +    doc = synchronize { find_doc(m.id) }
 +    existed = doc != nil
 +    doc ||= Xapian::Document.new
 +    do_index_static = overwrite || !existed
 +    old_entry = !do_index_static && doc.entry
 +    snippet = do_index_static ? m.snippet : old_entry[:snippet]
  
 -    subject_text = m.indexable_subject
 -    body_text = m.indexable_body
 +    entry = {
 +      :message_id => m.id,
 +      :source_id => m.source.id,
 +      :source_info => m.source_info,
 +      :date => m.date,
 +      :snippet => snippet,
 +      :labels => m.labels.to_a,
 +      :from => [m.from.email, m.from.name],
 +      :to => m.to.map { |p| [p.email, p.name] },
 +      :cc => m.cc.map { |p| [p.email, p.name] },
 +      :bcc => m.bcc.map { |p| [p.email, p.name] },
 +      :subject => m.subj,
 +      :refs => m.refs.to_a,
 +      :replytos => m.replytos.to_a,
 +    }
  
 +    if do_index_static
 +      doc.clear_terms
 +      doc.clear_values
 +      index_message_static m, doc, entry
 +    end
 +
 +    index_message_threading doc, entry, old_entry
 +    index_message_labels doc, entry[:labels], (do_index_static ? [] : old_entry[:labels])
 +    doc.entry = entry
 +
 +    synchronize do
 +      unless docid = existed ? doc.docid : assign_docid(m, truncate_date(m.date))
 +        # Could be triggered by spam
 +        warn "docid underflow, dropping #{m.id.inspect}"
 +        return
 +      end
 +      @xapian.replace_document docid, doc
 +    end
 +
 +    m.labels.each { |l| LabelManager << l }
 +    true
 +  end
 +
 +  ## Index content that can't be changed by the user
 +  def index_message_static m, doc, entry
      # Person names are indexed with several prefixes
      person_termer = lambda do |d|
        lambda do |p|
          ["#{d}_name", "name", "body"].each do |x|
 -          text << [p.name, PREFIX[x]]
 +          doc.index_text p.name, PREFIX[x]
          end if p.name
 -        [d, :any].each { |x| terms << mkterm(:email, x, p.email) }
 +        [d, :any].each { |x| doc.add_term mkterm(:email, x, p.email) }
        end
      end
  
      person_termer[:from][m.from] if m.from
      (m.to+m.cc+m.bcc).each(&(person_termer[:to]))
  
 -    terms << mkterm(:date,m.date) if m.date
 -    m.labels.each { |t| terms << mkterm(:label,t) }
 -    terms << mkterm(:type, 'mail')
 -    terms << mkterm(:msgid, m.id)
 -    terms << mkterm(:source_id, m.source.id)
 +    # Full text search content
 +    subject_text = m.indexable_subject
 +    body_text = m.indexable_body
 +    doc.index_text subject_text, PREFIX['subject']
 +    doc.index_text subject_text, PREFIX['body']
 +    doc.index_text body_text, PREFIX['body']
 +    m.attachments.each { |a| doc.index_text a, PREFIX['attachment'] }
 +
 +    # Miscellaneous terms
 +    doc.add_term mkterm(:date, m.date) if m.date
 +    doc.add_term mkterm(:type, 'mail')
 +    doc.add_term mkterm(:msgid, m.id)
 +    doc.add_term mkterm(:source_id, m.source.id)
      m.attachments.each do |a|
        a =~ /\.(\w+)$/ or next
 -      t = mkterm(:attachment_extension, $1)
 -      terms << t
 +      doc.add_term mkterm(:attachment_extension, $1)
 +    end
 +
 +    # Date value for range queries
 +    date_value = begin
 +      Xapian.sortable_serialise m.date.to_i
 +    rescue TypeError
 +      Xapian.sortable_serialise 0
      end
  
 -    ## Thread membership
 -    children = term_docids(mkterm(:ref, m.id)).map { |docid| @xapian.document docid }
 -    parent_ids = m.refs + m.replytos
 +    doc.add_value MSGID_VALUENO, m.id
 +    doc.add_value DATE_VALUENO, date_value
 +  end
 +
 +  def index_message_labels doc, new_labels, old_labels
 +    return if new_labels == old_labels
 +    added = new_labels.to_a - old_labels.to_a
 +    removed = old_labels.to_a - new_labels.to_a
 +    added.each { |t| doc.add_term mkterm(:label,t) }
 +    removed.each { |t| doc.remove_term mkterm(:label,t) }
 +  end
 +
 +  ## Assign a set of thread ids to the document. This is a hybrid of the runtime
 +  ## search done by the Ferret index and the index-time union done by previous
 +  ## versions of the Xapian index. We first find the thread ids of all messages
 +  ## with a reference to or from us. If that set is empty, we use our own
 +  ## message id. Otherwise, we use all the thread ids we previously found. In
 +  ## the common case there's only one member in that set, but if we're the
 +  ## missing link between multiple previously unrelated threads we can have
 +  ## more. XapianIndex#each_message_in_thread_for follows the thread ids when
 +  ## searching so the user sees a single unified thread.
 +  def index_message_threading doc, entry, old_entry
 +    return if old_entry && (entry[:refs] == old_entry[:refs]) && (entry[:replytos] == old_entry[:replytos])
 +    children = term_docids(mkterm(:ref, entry[:message_id])).map { |docid| @xapian.document docid }
 +    parent_ids = entry[:refs] + entry[: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? ? [entry[:message_id]] : thread_members.keys
 +    thread_ids.each { |thread_id| doc.add_term mkterm(:thread, thread_id) }
 +    parent_ids.each { |ref| doc.add_term mkterm(:ref, ref) }
 +    doc.add_value THREAD_VALUENO, (thread_ids * ',')
 +  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']]
 -    text << [body_text, PREFIX['body']]
 -    m.attachments.each { |a| text << [a, PREFIX['attachment']] }
 -
 -    truncated_date = if m.date < MIN_DATE
 -      debug "warning: adjusting too-low date #{m.date} for indexing"
 +  def truncate_date date
 +    if date < MIN_DATE
 +      debug "warning: adjusting too-low date #{date} for indexing"
        MIN_DATE
 -    elsif m.date > MAX_DATE
 -      debug "warning: adjusting too-high date #{m.date} for indexing"
 +    elsif date > MAX_DATE
 +      debug "warning: adjusting too-high date #{date} for indexing"
        MAX_DATE
      else
 -      m.date
 -    end
 -
 -    # Date value for range queries
 -    date_value = begin
 -      Xapian.sortable_serialise truncated_date.to_i
 -    rescue TypeError
 -      Xapian.sortable_serialise 0
 -    end
 -
 -    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
 +      date
      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 = Marshal.dump entry
 -
 -    @xapian.replace_document docid, doc
    end
  
    # Construct a Xapian term
 @@ -561,6 +566,34 @@ EOS
      end
    end
  
 +  module DocumentMethods
 +    def entry
 +      Marshal.load data
 +    end
 +
 +    def entry=(x)
 +      self.data = Marshal.dump x
 +    end
 +
 +    def index_text text, prefix, weight=1
 +      term_generator = Xapian::TermGenerator.new
 +      term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE)
 +      term_generator.document = self
 +      term_generator.index_text text, weight, prefix
 +    end
 +
 +    def add_term term
 +      if term.length <= MAX_TERM_LENGTH
 +        super term
 +      else
 +        warn "dropping excessively long term #{term}"
 +      end
 +    end
 +  end
 +end
 +
  end
  
 +class Xapian::Document
 +  include Redwood::XapianIndex::DocumentMethods
  end
 -- 
 1.6.4.2
 
 
 From rlane@club.cc.cmu.edu  Sun Sep 13 17:40:05 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 13 Sep 2009 17:40:05 -0400
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <cd67f63a0909111425q7d04332fvd7e23b48e6dab06a@mail.gmail.com>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 	<1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray>
 	<1252685502-sup-8928@zyrg.net>
 	<cd67f63a0909111425q7d04332fvd7e23b48e6dab06a@mail.gmail.com>
 Message-ID: <1252877576-sup-8500@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Fri Sep 11 17:25:06 -0400 2009:
 > On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote:
 > > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
 > >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
 > >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
 > >> > > Would it be a small change to move the undo keybinding to somewhere
 > >> > > more universal?
 > >> >
 > >> > No :(
 > >> >
 > >> > > As a first cut, I'd be happy if it just undid the changes to the
 > >> > > index, even without undoing any interface changes. That is, if my
 > >> > > previous command was archive-thread-and-view-next-thread, it would be
 > >> > > OK if it just undid the archiving part. Bonus points if it also undoes
 > >> > > the view-next part, but I can imagine that being more work.
 > >> >
 > >> > I know I sound a bit like a broken record here, but immediate
 > >> > label changes will solve this problem. Then, the undo system would just
 > >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping
 > >> > somebody will volunteer for this - it will be a big patch.
 > >>
 > >> What prevent us from having a global stack of (msgid, previous_labels) in
 > >> the actual settings?
 > >
 > > Hmm, you may be right. I was thinking that changes weren't propagated
 > > between buffers except on save, but that's wrong because UpdateManager
 > > is called in the keybinding. In that case, the user sees a mostly*
 > > linear series of label changes, so it's safe to have a global undo
 > > stack.
 > 
 > he next question is, what else is needed on this undo stack?
 > 
 > Are labels the only interaction we have? Here is what come to my mind:
 > 
 > * contacts (I more and more think that contacts should not be handled by
 >   sup directly, but that's another topic)
 > * drafts
 > 
 
 What actions on drafts are you thinking of making undoable? Could we
 implement them with reserved labels?
 
 From dato@net.com.org.es  Sun Sep 13 19:17:53 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Mon, 14 Sep 2009 00:17:53 +0100
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
  variable with the attachment charset
 In-Reply-To: <1251048347-sup-5075@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>
 	<20090822191617.GA26897@chistera.yi.org>
 	<1251048347-sup-5075@masanjin.net>
 Message-ID: <20090913231753.GA20849@chistera.yi.org>
 
 + William Morgan (Sun, 23 Aug 2009 10:34:10 -0700):
 
 > 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()".
 
 Works for me, thanks.
 
 Now that that fix is in, can you merge the mime-decode improvement from
 <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato at net.com.org.es>?
 Thanks!
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From rlane@club.cc.cmu.edu  Sun Sep 13 20:31:23 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 13 Sep 2009 20:31:23 -0400
 Subject: [sup-talk] U (unread) search is off
 In-Reply-To: <1252773806-sup-11@masanjin.net>
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 	<1252595946-sup-171@zyrg.net> <1252773806-sup-11@masanjin.net>
 Message-ID: <1252878152-sup-9190@zyrg.net>
 
 Excerpts from William Morgan's message of Sat Sep 12 12:47:14 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-09-10:
 > > I thought it was, but it turns out that unless you explicitly add AND
 > > operators Xapian will OR terms over the same field such that
 > > "label:foo label:bar" gives you the union instead of the intersection.
 > 
 > Ok. I only ask because I'm considering how to present the Xapian index
 > option in 0.9---the options are to not say anything about it, to force
 > everyone to switch to it, or anywhere in between. 
 
 Yeah, we do need the query behavior to be reasonable before advertising
 the Xapian index. What's your timeline on 0.9?
 
 > > We could fix this by patching Xapian to make this behavior
 > > configurable, or we could come up with an index-agnostic simple query
 > > language that doesn't support boolean operators.
 > 
 > The former sounds easier to me. Especially since it seems like this is
 > something Xapian should have...
 
 Agreed that Xapian should have this, and I'll probably implement it. We
 still need to support people using older Xapian versions though. Whether
 this means a log message telling them to use explicit ANDs in their
 query, or automatically transforming simple-enough queries into what we
 think they actually want, I don't know. I'll also need to add a
 workaround for the earlier Xapian bug before this index gets wider
 usage.
 
 As far as which index to make the default, Ferret has the advantage of
 being installable as a gem dependency. I think this ease of installation
 is important enough to block Xapian for now, unless someone can create a
 Xapian gem. There's been interest in this before:
 http://article.gmane.org/gmane.comp.search.xapian.devel/1408/
 
 From nicolas.pouillard@gmail.com  Mon Sep 14 12:29:09 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 14 Sep 2009 18:29:09 +0200
 Subject: [sup-talk] How hard would a universal undo be?
 In-Reply-To: <1252877576-sup-8500@zyrg.net>
 References: <1252517083-sup-58@yoom.home.cworth.org>
 	<1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray>
 	<1252685502-sup-8928@zyrg.net>
 	<cd67f63a0909111425q7d04332fvd7e23b48e6dab06a@mail.gmail.com>
 	<1252877576-sup-8500@zyrg.net>
 Message-ID: <1252945595-sup-1907@peray>
 
 Excerpts from Rich Lane's message of Sun Sep 13 23:40:05 +0200 2009:
 > Excerpts from Nicolas Pouillard's message of Fri Sep 11 17:25:06 -0400 2009:
 > > On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane<rlane at club.cc.cmu.edu> wrote:
 > > > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009:
 > > >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009:
 > > >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009:
 > > >> > > Would it be a small change to move the undo keybinding to somewhere
 > > >> > > more universal?
 > > >> >
 > > >> > No :(
 > > >> >
 > > >> > > As a first cut, I'd be happy if it just undid the changes to the
 > > >> > > index, even without undoing any interface changes. That is, if my
 > > >> > > previous command was archive-thread-and-view-next-thread, it would be
 > > >> > > OK if it just undid the archiving part. Bonus points if it also undoes
 > > >> > > the view-next part, but I can imagine that being more work.
 > > >> >
 > > >> > I know I sound a bit like a broken record here, but immediate
 > > >> > label changes will solve this problem. Then, the undo system would just
 > > >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping
 > > >> > somebody will volunteer for this - it will be a big patch.
 > > >>
 > > >> What prevent us from having a global stack of (msgid, previous_labels) in
 > > >> the actual settings?
 > > >
 > > > Hmm, you may be right. I was thinking that changes weren't propagated
 > > > between buffers except on save, but that's wrong because UpdateManager
 > > > is called in the keybinding. In that case, the user sees a mostly*
 > > > linear series of label changes, so it's safe to have a global undo
 > > > stack.
 > > 
 > > he next question is, what else is needed on this undo stack?
 > > 
 > > Are labels the only interaction we have? Here is what come to my mind:
 > > 
 > > * contacts (I more and more think that contacts should not be handled by
 > >   sup directly, but that's another topic)
 > > * drafts
 > > 
 > 
 > What actions on drafts are you thinking of making undoable? Could we
 > implement them with reserved labels?
 
 No I think that's fine for now to consider, discarding, editing...
 non-undoable actions.
 
 Basically I agree with a global undo stack of labels, I'm just searching for
 issues ahead.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From olly@survex.com  Tue Sep 15 03:18:51 2009
 From: olly@survex.com (Olly Betts)
 Date: Tue, 15 Sep 2009 07:18:51 +0000 (UTC)
 Subject: [sup-talk] U (unread) search is off
 References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca>
 	<1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net>
 	<1252595946-sup-171@zyrg.net> <1252773806-sup-11@masanjin.net>
 	<1252878152-sup-9190@zyrg.net>
 Message-ID: <loom.20090915T090521-2@post.gmane.org>
 
 Rich Lane <rlane at club.cc.cmu.edu> writes:
 > Agreed that Xapian should have this, and I'll probably implement it. We
 > still need to support people using older Xapian versions though. Whether
 > this means a log message telling them to use explicit ANDs in their
 > query, or automatically transforming simple-enough queries into what we
 > think they actually want, I don't know. I'll also need to add a
 > workaround for the earlier Xapian bug before this index gets wider
 > usage.
 
 I've now opened a Xapian ticket for this:
 
 http://trac.xapian.org/ticket/402
 
 Patches are certainly most welcome, especially as I'm currently trying to
 focus on getting Xapian 1.2.0 out of the door.
 
 I don't see a satisfactory workaround for it, sadly.
 
 > As far as which index to make the default, Ferret has the advantage of
 > being installable as a gem dependency. I think this ease of installation
 > is important enough to block Xapian for now, unless someone can create a
 > Xapian gem. There's been interest in this before:
 > http://article.gmane.org/gmane.comp.search.xapian.devel/1408/
 
 I recently noticed this gem version of (modified) xapian-bindings:
 
 http://groups.google.com/group/acts_as_xapian/msg/1bbb1e0d3753a0b7
 
 I've not had a chance to look at it yet though, so I don't know if the
 changes mentioned are compatible or not.  Assuming they're useful, they
 probably should be folded in upstream - more idiomatic wrappers are a
 desirable improvement (though if they're incompatible we'd need some
 sort of migration plan).  It doesn't seem productive to have forked
 versions like this either.
 
 Cheers,
     Olly
 
 
 From michael@content-space.de  Tue Sep 15 12:20:59 2009
 From: michael@content-space.de (Michael Hamann)
 Date: Tue, 15 Sep 2009 18:20:59 +0200
 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
 Message-ID: <1253030868-sup-8556@mithink>
 
 Hi,
 
 as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
 Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
 sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
 http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
 
 After that I tried running sup and after seeing the main screen for a few
 moments sup crashed with the following error (I'm using the latest version from
 next, but with master it's the same):
 
 ThreadError from thread: load threads for thread-index-mode
 deadlock; recursive locking
 <internal:prelude>:6:in `lock'
 <internal:prelude>:6:in `synchronize'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:757:in `regen_text'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:687:in `resize'
 /home/michitux/pub/software/sup/lib/sup/buffer.rb:87:in `resize'
 /home/michitux/pub/software/sup/lib/sup/buffer.rb:328:in `draw_screen'
 /home/michitux/pub/software/sup/lib/sup/buffer.rb:728:in `flash'
 /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
 /home/michitux/pub/software/sup/lib/sup/hook.rb:87:in `rescue in run'
 /home/michitux/pub/software/sup/lib/sup/hook.rb:81:in `run'
 /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:714:in `size_widget_for_thread'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `block (2 levels) in update'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `map'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `block in update'
 <internal:prelude>:8:in `synchronize'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:223:in `update'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:637:in `load_n_threads'
 (eval):12:in `load_n_threads'
 /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:609:in `block in load_n_threads_background'
 /home/michitux/pub/software/sup/lib/sup.rb:77:in `block in reporting_thread
 
 I then tried running sup-dump, it worked without problems, the results looks
 correct (just a few changed lines that represent the changes of the last days).
 
 I then installed xapian and tried reimporting my mails and all I've got after
 importing 46 mails of about 44000 is:
 
 Scanning maildir:/home/michitux/mail...
 /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `gsub': invalid byte sequence in US-ASCII (ArgumentError)
 from /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `parse_header'
 from /home/michitux/pub/software/sup/lib/sup/message.rb:238:in `load_from_source!'
 from /home/michitux/pub/software/sup/lib/sup/message.rb:335:in `build_from_source'
 from /home/michitux/pub/software/sup/lib/sup/poll.rb:145:in `block in each_message_from'
 from /home/michitux/pub/software/sup/lib/sup/maildir.rb:160:in `block in each'
 from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `upto'
 from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `each'
 from /home/michitux/pub/software/sup/lib/sup/util.rb:560:in `__pass'
 from /home/michitux/pub/software/sup/lib/sup/util.rb:547:in `method_missing'
 from /home/michitux/pub/software/sup/lib/sup/poll.rb:139:in `each_message_from'
 from /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
 from bin/sup-sync:146:in `block in <main>'
 from bin/sup-sync:141:in `each'
 from bin/sup-sync:141:in `<main>'
 
 Running sup with xapian and ruby 1.9.1 works as long as there aren't any mails
 displayed, when I e.g. select a label that contains mails, sub crashes again
 with the same exception as with ferret.
 
 Is there anything I'm missing, is sup just not ready for Ruby 1.9.1 or is there
 another issue?
 
 Greetings
 Michael Hamann
 
 From sean.escriva@gmail.com  Tue Sep 15 13:53:39 2009
 From: sean.escriva@gmail.com (Sean Escriva)
 Date: Tue, 15 Sep 2009 10:53:39 -0700
 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
 In-Reply-To: <1253030868-sup-8556@mithink>
 References: <1253030868-sup-8556@mithink>
 Message-ID: <20090915175339.GA15735@gmail.com>
 
 Excerpts from Michael Hamann's message of Tue Sep 15 06:20:59 +0200 2009: 
 > Hi,
 > 
 > as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
 > Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
 > sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
 > http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
 
 I followed a similar path after the recent upgrade to no avail. In the
 end I downgraded ruby back to 1.8.7_p160 from older arch packages
 available here: 
 
     http://www.schlunix.org/archlinux/extra/os/x86_64/
 
 I'd like a better solution, but I've become dependent on sup for daily
 work. 
 
 > [..snip..]
 
 From mailinglist@flasht.de  Tue Sep 15 16:21:59 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Tue, 15 Sep 2009 22:21:59 +0200
 Subject: [sup-talk] Fixing header for encrypted messages (might be an old
 	issue)
 Message-ID: <1253045775-sup-210@thinkpad-ubuntu>
 
 Hi!
 
 I've been having problems with encrypting messages. No idea where this
 came from, but somehow the protocol part in encrypted messages had an
 extra pair of quotes, e.g.: protocol=""application/pgp-encrypted""
 which caused it to not be recognized by some clients (e.g. mutt as far as I know).
 
 Here's a simple fix. I have no idea, why this suddenly came up. Might
 be that it had been like this all the time, just no one had a problem
 with it? (I highly doubt that though!)  
 
 If this is an old issue and I'm just using an old version, feel free
 to ignore this. I've tried using the current master or next branch,
 but that causes a crash when trying to open encrypted emails. Maybe
 someone else is having a similar problem?
 
 Greetings,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: protocol-fix.patch
 Type: application/octet-stream
 Size: 509 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090915/462fe7d5/attachment.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 835 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090915/462fe7d5/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Tue Sep 15 16:32:42 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 15 Sep 2009 16:32:42 -0400
 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
 In-Reply-To: <1253030868-sup-8556@mithink>
 References: <1253030868-sup-8556@mithink>
 Message-ID: <1253043209-sup-8800@zyrg.net>
 
 Excerpts from Michael Hamann's message of Tue Sep 15 12:20:59 -0400 2009:
 > Hi,
 > 
 > as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
 > Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
 > sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
 > http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
 > 
 > After that I tried running sup and after seeing the main screen for a few
 > moments sup crashed with the following error (I'm using the latest version from
 > next, but with master it's the same):
 > 
 > ThreadError from thread: load threads for thread-index-mode
 > deadlock; recursive locking
 > <internal:prelude>:6:in `lock'
 > <internal:prelude>:6:in `synchronize'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:757:in
 > `regen_text'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:687:in
 > `resize'
 > /home/michitux/pub/software/sup/lib/sup/buffer.rb:87:in `resize'
 > /home/michitux/pub/software/sup/lib/sup/buffer.rb:328:in `draw_screen'
 > /home/michitux/pub/software/sup/lib/sup/buffer.rb:728:in `flash'
 > /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
 > /home/michitux/pub/software/sup/lib/sup/hook.rb:87:in `rescue in run'
 > /home/michitux/pub/software/sup/lib/sup/hook.rb:81:in `run'
 > /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:714:in
 > `size_widget_for_thread'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in
 > `block (2 levels) in update'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `map'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in
 > `block in update'
 > <internal:prelude>:8:in `synchronize'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:223:in
 > `update'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:637:in
 > `load_n_threads'
 > (eval):12:in `load_n_threads'
 > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:609:in
 > `block in load_n_threads_background'
 > /home/michitux/pub/software/sup/lib/sup.rb:77:in `block in reporting_thread
 > 
 
 We're calling the size widget hook while holding the thread-index-mode
 lock, then the hook throws an exception that results in trying to
 acquire the lock again. We shouldn't be calling arbitrary code with
 locks held. Until we figure that change out we could just change the
 mutex to be a monitor.
 
 > I then tried running sup-dump, it worked without problems, the results looks
 > correct (just a few changed lines that represent the changes of the last days).
 > 
 > I then installed xapian and tried reimporting my mails and all I've got after
 > importing 46 mails of about 44000 is:
 > 
 > Scanning maildir:/home/michitux/mail...
 > /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `gsub': invalid byte
 > sequence in US-ASCII (ArgumentError)
 > from /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `parse_header'
 > from /home/michitux/pub/software/sup/lib/sup/message.rb:238:in
 > `load_from_source!'
 > from /home/michitux/pub/software/sup/lib/sup/message.rb:335:in
 > `build_from_source'
 > from /home/michitux/pub/software/sup/lib/sup/poll.rb:145:in `block in
 > each_message_from'
 > from /home/michitux/pub/software/sup/lib/sup/maildir.rb:160:in `block in each'
 > from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `upto'
 > from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `each'
 > from /home/michitux/pub/software/sup/lib/sup/util.rb:560:in `__pass'
 > from /home/michitux/pub/software/sup/lib/sup/util.rb:547:in `method_missing'
 > from /home/michitux/pub/software/sup/lib/sup/poll.rb:139:in `each_message_from'
 > from /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing'
 > from bin/sup-sync:146:in `block in <main>'
 > from bin/sup-sync:141:in `each'
 > from bin/sup-sync:141:in `<main>'
 
 This is a 1.9 encoding issue. I imagine we have a number of these, even
 outside of rmail.
 
 > Running sup with xapian and ruby 1.9.1 works as long as there aren't any mails
 > displayed, when I e.g. select a label that contains mails, sub crashes again
 > with the same exception as with ferret.
 > 
 > Is there anything I'm missing, is sup just not ready for Ruby 1.9.1 or is there
 > another issue?
 
 I think William said he's been doing some 1.9 work recently. I wouldn't
 say it's ready just yet.
 
 From ef_dva@yahoo.com  Tue Sep 15 17:24:58 2009
 From: ef_dva@yahoo.com (Dusan)
 Date: Tue, 15 Sep 2009 23:24:58 +0200
 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
 In-Reply-To: <20090915175339.GA15735@gmail.com>
 References: <1253030868-sup-8556@mithink> <20090915175339.GA15735@gmail.com>
 Message-ID: <1253049733-sup-276@archpc>
 
 Excerpts from Sean Escriva's message of Tue Sep 15 19:53:39 +0200 2009:
 > Excerpts from Michael Hamann's message of Tue Sep 15 06:20:59 +0200 2009: 
 > > Hi,
 > > 
 > > as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got
 > > Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of
 > > sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at
 > > http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/.
 > 
 > I followed a similar path after the recent upgrade to no avail. In the
 > end I downgraded ruby back to 1.8.7_p160 from older arch packages
 > available here: 
 > 
 >     http://www.schlunix.org/archlinux/extra/os/x86_64/
 > 
 > I'd like a better solution, but I've become dependent on sup for daily
 > work. 
 > 
 > > [..snip..]
 
 This is pretty big question for arch users, including me. I can block
 ruby upgrade but it's few month before other distros start using 1.9
 
 From dato@net.com.org.es  Tue Sep 15 18:21:19 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Tue, 15 Sep 2009 23:21:19 +0100
 Subject: [sup-talk] Fixing header for encrypted messages (might be an
  old issue)
 In-Reply-To: <1253045775-sup-210@thinkpad-ubuntu>
 References: <1253045775-sup-210@thinkpad-ubuntu>
 Message-ID: <20090915222119.GA5290@chistera.yi.org>
 
 + Christopher Bertels (Tue, 15 Sep 2009 22:21:59 +0200):
 
 > Hi!
 
 Hello!
 
 > I've been having problems with encrypting messages. No idea where this
 > came from, but somehow the protocol part in encrypted messages had an
 > extra pair of quotes, e.g.: protocol=""application/pgp-encrypted""
 > which caused it to not be recognized by some clients (e.g. mutt as far as I know).
 
 > Here's a simple fix. I have no idea, why this suddenly came up. Might
 > be that it had been like this all the time, just no one had a problem
 > with it? (I highly doubt that though!)  
 
 It's been like that all the time, but AFAIK only Mutt has problem
 opening those messages. FWIW, it's a bug in RMail (another one to add to
 the pile...):
 
     http://rubyforge.org/tracker/index.php?func=detail&aid=2170&group_id=446&atid=1754
     http://rubyforge.org/tracker/index.php?func=detail&aid=2661&group_id=446&atid=1756
 
 I advice against using your patch, since it depends on broken behavior
 of RMail to produce correct results, and people may be using fixed
 versions of the library. For example, I uploaded fixed packages of RMail
 to Debian, and they'll become available in Ubuntu at some point.
 
 Instead, you can find a patch to fix the issue in your system's RMail in
 one bugs linked above.
 
 > If this is an old issue and I'm just using an old version, feel free
 > to ignore this. I've tried using the current master or next branch,
 > but that causes a crash when trying to open encrypted emails. Maybe
 > someone else is having a similar problem?
 
 No, I've recently started experiencing this as well, asuming you're
 talking about:
 
 --- NoMethodError from thread: load messages for thread-view-mode
 undefined method `expandable?' for #<Array:0x7faa50e2d978>
 /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text'
 /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each'
 /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text'
 /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each'
 /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff'
 [...]
 
 Cheers,
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From bgamari.foss@gmail.com  Wed Sep 16 13:23:40 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Wed, 16 Sep 2009 13:23:40 -0400
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1252773189-sup-246@masanjin.net>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 Message-ID: <20090916172340.GA20566@ben-laptop>
 
 On Sat, Sep 12, 2009 at 09:35:21AM -0700, William Morgan wrote:
 > Reformatted excerpts from Ben Gamari's message of 2009-09-11:
 > > Recently I've been seeing this crash[1] pretty consistently on the next
 > > branch with the Xapian backend.
 > 
 > Is your Xapian index somewhat old? There have been index format changes
 > that have caused this type of thing recently. You might try rebuilding
 > it.
 
 Well, after several attempts at rebuilding my index, I finally got lucky
 and sup-sync ran to completion. Unfortunately, sup now fails to even
 start, failing out with the following exception while loading threads
 for inbox-mode,
 
 	$ sup
 	--- SystemExit from thread: main
 	Thread#join: deadlock 0x7f592eec4d78 - mutual join(0x7f592f01d6e8)
 	/opt/exp/sup/lib/sup/message.rb:240:in `select'
 	/opt/exp/sup/lib/sup/buffer.rb:35:in `nonblocking_getch'
 	/usr/bin/sup:213
 
 However, at this point during debugging I happened to pipe stderr to a
 file and accidentally found that most of the backtrace was actually
 being hidden by curses.  Examining the full output on stderr reveals,
 
 	/usr/bin/sup:213(eval):3:in `synchronize': Thread#join: deadlock 0x7f4d5da565c0 - mutual join(0x7f4d5daf8be0) (ThreadError)
 		from (eval):3:in `raw_header'
 		from /opt/exp/sup/lib/sup/imap.rb:98:in `load_header'
 		from /opt/exp/sup/lib/sup/util.rb:560:in `send'
 		from /opt/exp/sup/lib/sup/util.rb:560:in `__pass'
 		from /opt/exp/sup/lib/sup/util.rb:547:in `method_missing'
 		from /opt/exp/sup/lib/sup/message.rb:238:in `load_from_source!'
 		from /opt/exp/sup/lib/sup/message.rb:219:in `chunks'
 		from /opt/exp/sup/lib/sup/message.rb:164:in `snippet'
 		from /opt/exp/sup/lib/sup/thread.rb:91:in `snippet'
 		from /opt/exp/sup/lib/sup/imap.rb:259:in `select'
 		from /opt/exp/sup/lib/sup/thread.rb:68:in `each'
 		from /opt/exp/sup/lib/sup/thread.rb:168:in `each_with_stuff'
 		from /opt/exp/sup/lib/sup/thread.rb:67:in `each'
 		from /opt/exp/sup/lib/sup/thread.rb:91:in `select'
 		from /opt/exp/sup/lib/sup/thread.rb:91:in `snippet'
 		from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:840:in `text_for_thread_at'
 		from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:758:in `regen_text'
 		from /opt/exp/sup/lib/sup/util.rb:364:in `map_with_index'
 		from /opt/exp/sup/lib/sup/imap.rb:259:in `each_with_index'
 		from /opt/exp/sup/lib/sup/util.rb:364:in `each'
 		from /opt/exp/sup/lib/sup/util.rb:364:in `each_with_index'
 		from /opt/exp/sup/lib/sup/util.rb:364:in `map_with_index'
 		from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:758:in `regen_text'
 		from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:687:in `resize'
 		from /opt/exp/sup/lib/sup/buffer.rb:88:in `resize'
 		from /opt/exp/sup/lib/sup/buffer.rb:329:in `draw_screen'
 		from /opt/exp/sup/lib/sup/buffer.rb:745:in `clear'
 		from /opt/exp/sup/lib/sup/util.rb:520:in `send'
 		from /opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
 		from /opt/exp/sup/lib/sup/imap.rb:283:in `shutup'
 		from /opt/exp/sup/lib/sup/imap.rb:270:in `unsafe_connect'
 		from /opt/exp/sup/lib/sup/imap.rb:244:in `initialize'
 		from /opt/exp/sup/lib/sup/imap.rb:244:in `new'
 		from /opt/exp/sup/lib/sup/imap.rb:244:in `unsafe_connect'
 		from /opt/exp/sup/lib/sup/imap.rb:331:in `safely'
 		from /opt/exp/sup/lib/sup/imap.rb:148:in `unsynchronized_connect'
 		from (eval):3:in `connect'
 		from (eval):3:in `synchronize'
 		from (eval):3:in `connect'
 		from /opt/exp/sup/lib/sup/util.rb:560:in `send'
 		from /opt/exp/sup/lib/sup/util.rb:560:in `__pass'
 		from /opt/exp/sup/lib/sup/util.rb:547:in `method_missing'
 		from /usr/bin/sup:189
 		from /opt/exp/sup/lib/sup.rb:77:in `reporting_thread'
 		from /opt/exp/sup/lib/sup.rb:75:in `initialize'
 		from /opt/exp/sup/lib/sup.rb:75:in `new'
 		from /opt/exp/sup/lib/sup.rb:75:in `reporting_thread'
 		from /usr/bin/sup:187
 		from /usr/bin/sup:185:in `each'
 		from /usr/bin/sup:185
 		[Wed Sep 16 13:01:11 -0400 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
 		----------------------------------------------------------------
 
 
 with the first stacktrace following this on stdout. With this
 information it looks like this bug should become much more debuggable.
 Being in the imap module, it seems likely that it is my gmail source
 that is causing the failure. Unfortunately I have no way to verify that
 the problem is limited to the gmail source as sup raises as exception
 when it encounters an unknown source, precluding the option of simply
 commenting out the source in sources.yaml.
 
 Anyways, this is the current status of things on my machine. William, do
 you have any ideas what might cause such a backtrace. At this point
 classes have started and I really have no more time to devote to
 getting sup working. If there isn't a fairly simple solution here I guess
 I'll just need to stick with mutt (ugh). Anyways, thanks for your work.
 
 Cheers,
 - Ben
 
 
 From mailinglist@flasht.de  Tue Sep 15 18:42:04 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Wed, 16 Sep 2009 00:42:04 +0200
 Subject: [sup-talk] Fixing header for encrypted messages (might be an
 	old issue)
 In-Reply-To: <20090915222119.GA5290@chistera.yi.org>
 References: <1253045775-sup-210@thinkpad-ubuntu>
 	<20090915222119.GA5290@chistera.yi.org>
 Message-ID: <1253054438-sup-8449@thinkpad-ubuntu>
 
 Excerpts from Adeodato Sim?'s message of Mi Sep 16 00:21:19 +0200 2009:
 > It's been like that all the time, but AFAIK only Mutt has problem
 > opening those messages. FWIW, it's a bug in RMail (another one to add to
 > the pile...):
 
 Alright, good to know.
 
 > I advice against using your patch, since it depends on broken behavior
 > of RMail to produce correct results, and people may be using fixed
 > versions of the library. For example, I uploaded fixed packages of RMail
 > to Debian, and they'll become available in Ubuntu at some point.
 > 
 > Instead, you can find a patch to fix the issue in your system's RMail in
 > one bugs linked above.
 
 Alright, thanks. I'll just leave it for me like this until I've got a
 new version of RMail then.
 
 > > If this is an old issue and I'm just using an old version, feel free
 > > to ignore this. I've tried using the current master or next branch,
 > > but that causes a crash when trying to open encrypted emails. Maybe
 > > someone else is having a similar problem?
 > 
 > No, I've recently started experiencing this as well, asuming you're
 > talking about:
 > 
 > --- NoMethodError from thread: load messages for thread-view-mode
 > undefined method `expandable?' for #<Array:0x7faa50e2d978>
 > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text'
 > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each'
 > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text'
 > /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each'
 > /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff'
 > [...]
 
 Yes, it's the same error I get. Any insights as to what is causing this?
 
 Cheers,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 835 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090916/7f6fbfa9/attachment.bin>
 
 From cworth@cworth.org  Thu Sep 17 16:05:45 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 17 Sep 2009 13:05:45 -0700
 Subject: [sup-talk] [PATCH] Fix message_to_chunks for the m.body == nil case.
 Message-ID: <1253217341-sup-8631@yoom.home.cworth.org>
 
 The code was previously broken in calling EnclosedMessage.new with
 only 2 instead of 5 arguments.
 ---
 
 A friend of mine couldn't import his mail into sup due to the crash
 fixed by this patch. It looks like the message he had that was causing
 this infrequently-used (and obviously broken) code to be executed had
 some mime pieces corrupted.
 
 The message consisted of several mime-attached messages looking like:
 
 	--==_Exmh_5062123120
 	Content-Type: message/rfc822 ; name="5714"
 	Content-Description: 5714
 	Content-Disposition: attachment; filename="5714"
 	
 	Return-path: <omitted>
 	...
 
 but one part was missing the mime searpate and Content-Type and
 instead just looked like:
 
 	Content-Description: 5692
 	Content-Disposition: attachment; filename="5692"
 
 	Return-path: <omitted>
 	...
 
 I tried fixing this first by adding several more empty-string
 arguments, that is:
 
 	[Chunk::EnclosedMessage.new(nil, "", "", "", "")]
 
 but that ended up causing this exception instead:
 
 	./lib/sup/message-chunks.rb:212:in `initialize': undefined
 	method `full_adress' for nil:NilClass (NoMethodError)
 
 So I'm not 100% sure that this patch is correct, but it does allow
 sup-sync to proceed and the message appears in sup as well as could be
 expected, (the "extra" headers from the corrupted mime part appear in
 the body as one might expect here).
 
 -Carl
 
  lib/sup/message.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index afa8f00..579c1e5 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -453,7 +453,7 @@ private
          cc_people = cc ? Person.from_address_list(cc) : nil
          [Chunk::EnclosedMessage.new(from_person, to_people, cc_people, msgdate, subj)] + message_to_chunks(payload, encrypted)
        else
 -        [Chunk::EnclosedMessage.new(nil, "")]
 +        []
        end
      else
        filename =
 -- 
 1.6.4.3
 
 
 From web-sup@superscript.com  Fri Sep 18 15:50:13 2009
 From: web-sup@superscript.com (William Erik Baxter)
 Date: Fri, 18 Sep 2009 15:50:13 -0400
 Subject: [sup-talk] Hello,
 	and before-add-message hook for applying labels per CDB
 Message-ID: <1253303164-sup-1138@kronos>
 
 Hello fellow sup users.  I began using sup last week, spent some time setting
 it up in parallel with mutt, and have not used mutt since, except through
 accident of habit.  Thanks to all developers for your excellent work.
 
 A before-add-message hook follows.  It applies labels per entries in a CDB
 constructed externally.  I hope you find it useful.
 
 Cheers, W.
 
 
 #### Automatically add labels.
 
 require 'cdb';
 
 @cdb ||= CDB.new("/home/web/Mail/suplabel.cdb");
 
 # Mark by a recipient (to/cc)
 # Construct [ [ prefix, string ] ... ].
 # Look up "prefix:string" in CDB to obtain a list of labels to apply.
 
 a = []
 a += [ [ "from", message.from.email ] ]
 a += message.recipients.map{ |x| [ "recipient", x.email ] }
 
 a.each { |pair|
   key = pair[0] + ":" + pair[1];
   @cdb.each(key) { |value|
     value.split.each { |label|  message.add_label(label) }
   }
 }
 
 From web-sup@superscript.com  Fri Sep 18 15:54:18 2009
 From: web-sup@superscript.com (William Erik Baxter)
 Date: Fri, 18 Sep 2009 15:54:18 -0400
 Subject: [sup-talk] [PATCH] Add hooks to sort and format label-list-mode
 	display.
 Message-ID: <1253303493-sup-288@kronos>
 
 ---
 lib/sup/modes/label-list-mode.rb |   37 ++++++++++++++++++++++++++++++++++---
 1 files changed, 34 insertions(+), 3 deletions(-)
 
 diff --git a/lib/sup/modes/label-list-mode.rb b/lib/sup/modes/label-list-mode.rb
 index f65ec2e..d94f56f 100644
 --- a/lib/sup/modes/label-list-mode.rb
 +++ b/lib/sup/modes/label-list-mode.rb
 @@ -8,6 +8,24 @@ class LabelListMode < LineCursorMode
    k.add :toggle_show_unread_only, "Toggle between showing all labels and those with unread mail", 'u'
  end
 
 +  HookManager.register "label-list-filter", <<EOS
 +Filter the label list, typically to sort.
 +Variables:
 +  counted: an array of counted labels.
 +Return value:
 +  An array of counted labels with sort_by output structure.
 +EOS
 +
 +  HookManager.register "label-list-format", <<EOS
 +Create the sprintf format string for label-list-mode.
 +Variables:
 +  width: the maximum label width
 +  tmax: the maximum total message count
 +  umax: the maximum unread message count
 +Return value:
 +  A format string for sprintf
 +EOS
 +
  def initialize
    @labels = []
    @text = []
 @@ -50,14 +68,22 @@ protected
    @text = []
    labels = LabelManager.all_labels
 
 -    counts = labels.map do |label|
 +    counted = labels.map do |label|
      string = LabelManager.string_for label
      total = Index.num_results_for :label => label
      unread = (label == :unread)? total : Index.num_results_for(:labels => [label, :unread])
      [label, string, total, unread]
 -    end.sort_by { |l, s, t, u| s.downcase }
 +    end
 +
 +    if HookManager.enabled? "label-list-filter"
 +      counts = HookManager.run "label-list-filter", :counted => counted
 +    else
 +      counts = counted.sort_by { |l, s, t, u| s.downcase }
 +    end
  
      width = counts.max_of { |l, s, t, u| s.length }
 +    tmax  = counts.max_of { |l, s, t, u| t }
 +    umax  = counts.max_of { |l, s, t, u| u }
  
      if @unread_only
        counts.delete_if { | l, s, t, u | u == 0 }
 @@ -78,8 +104,13 @@ protected
          next
        end
  
 +      fmt = HookManager.run "label-list-format", :width => width, :tmax => tmax, :umax => umax
 +      if !fmt
 +        fmt = "%#{width + 1}s %5d %s, %5d unread"
 +      end
 +
        @text << [[(unread == 0 ? :labellist_old_color : :labellist_new_color),
 -          sprintf("%#{width + 1}s %5d %s, %5d unread", string, total, total == 1 ? " message" : "messages", unread)]]
 +          sprintf(fmt, string, total, total == 1 ? " message" : "messages", unread)]]
        @labels << [label, unread]
        yield i if block_given?
      end.compact
 -- 
 1.5.3.2
 
 
 From richard@infoarts.info  Fri Sep 18 18:15:03 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Sat, 19 Sep 2009 08:15:03 +1000
 Subject: [sup-talk] Trouble implementing UTF-8 ncurses fix
 Message-ID: <1253311953-sup-3472@Richard-Sandilandss-MacBook-Pro.local>
 
 
 Hi there
 
 I'm trying to implement the fix found here:
 <http://sup.rubyforge.org/wiki/wiki.pl?UTF8>
 
 but am running into trouble when I run 'run-this-for-sup.sh'. I've
 installed the ncurses-5.7 library on my Mac 10.6 machine, but the shell
 script above gives this output to mkmf.log: <http://pastie.org/622306>
 
 Any clues on what I might be missing would be appreciated.
 
 -- 
 Richard Sandilands
 
 From michael+sup@stapelberg.de  Sun Sep 20 15:46:24 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sun, 20 Sep 2009 21:46:24 +0200
 Subject: [sup-talk] Bug: Converting the index to xapian fails with a message
 	with very old date
 Message-ID: <1253475875-sup-5119@midna.zekjur.net>
 
 Hi,
 
 I have a spam mail in one of my sources. This mail has the following Date-line:
 
 Date: Mon, 1 Jan 1601 00:48:33 +0500
 
 This makes sup/xapian/ruby (one of them) go crazy and abort with an exception:
 ## read 5856m (about 72%) @ 10.0m/s. 0:09:47 elapsed, about 0:03:44 remaining
 /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `_dump': year too big to marshal (ArgumentError)
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `dump'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `index_message'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message'
         from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:398:in `synchronize'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:123:in `sync_message'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:94:in `add_message'
         from /home/michael/software/sup-mainline/bin/sup-sync:211
         from /usr/lib/ruby/1.8/sup/poll.rb:151:in `each_message_from'
         from /usr/lib/ruby/1.8/sup/imap.rb:197:in `each'
         from /usr/lib/ruby/1.8/sup/imap.rb:185:in `upto'
         from /usr/lib/ruby/1.8/sup/imap.rb:185:in `each'
         from /usr/lib/ruby/1.8/sup/util.rb:560:in `send'
         from /usr/lib/ruby/1.8/sup/util.rb:560:in `__pass'
         from /usr/lib/ruby/1.8/sup/util.rb:547:in `method_missing'
         from /usr/lib/ruby/1.8/sup/poll.rb:139:in `each_message_from'
         from /usr/lib/ruby/1.8/sup/util.rb:520:in `send'
         from /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing'
         from /home/michael/software/sup-mainline/bin/sup-sync:146
         from /home/michael/software/sup-mainline/bin/sup-sync:141:in `each'
         from /home/michael/software/sup-mainline/bin/sup-sync:141
 
 I used revision 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf of sup.
 
 Best regards,
 Michael
 
 From michael+sup@stapelberg.de  Sun Sep 20 15:51:38 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sun, 20 Sep 2009 21:51:38 +0200
 Subject: [sup-talk] Bug: Opening PGP encrypted mails fails with latest
 	revision
 Message-ID: <1253476236-sup-9371@midna.zekjur.net>
 
 Hi,
 
 when opening PGP encrypted mails (MIME), sup crashes with the following
 exception:
 
 --- NoMethodError from thread: load messages for thread-view-mode
 undefined method `expandable?' for nil:NilClass
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:621:in `regen_text'
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:616:in `each'
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:616:in `regen_text'
 /usr/lib/ruby/1.8/sup/thread.rb:68:in `each'
 /usr/lib/ruby/1.8/sup/thread.rb:168:in `each_with_stuff'
 /usr/lib/ruby/1.8/sup/thread.rb:67:in `each'
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:585:in `regen_text'
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:135:in `initialize'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:112:in `new'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:112:in `select'
 /usr/lib/ruby/1.8/sup.rb:77:in `reporting_thread'
 /usr/lib/ruby/1.8/sup.rb:75:in `initialize'
 /usr/lib/ruby/1.8/sup.rb:75:in `new'
 /usr/lib/ruby/1.8/sup.rb:75:in `reporting_thread'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:102:in `select'
 /usr/lib/ruby/1.8/sup/mode.rb:50:in `send'
 /usr/lib/ruby/1.8/sup/mode.rb:50:in `handle_input'
 /usr/lib/ruby/1.8/sup/buffer.rb:265:in `handle_input'
 bin/sup:236
 
 Best regards,
 Michael
 
 From alip@exherbo.org  Sun Sep 20 17:16:34 2009
 From: alip@exherbo.org (Ali Polatel)
 Date: Mon, 21 Sep 2009 00:16:34 +0300
 Subject: [sup-talk] Problem with lbdb and extra contacts hook
 Message-ID: <1253481392-sup-4891@harikalardiyari>
 
 Hello,
 I've just started using sup and I'm really loving it.
 Thanks for the great software.
 
 I have a problem with extra-contact-addresses hook and lbdb.
 Using the hook in the wiki:
 contacts = []
 `lbdbq |awk -F"\t" '{print $2 , "<"$1">"}'`.each { |c| contacts.push(c) }
 return contacts
 
 I get error running hook and here's the message that appears in the log:
 [Sun Sep 20 23:50:17 +0300 2009] hook: error running hook: unexpected return
 [Sun Sep 20 23:50:17 +0300 2009] hook:
 /home/alip/.sup/hooks/extra-contact-addresses.rb:7:in `__run'
 /home/alip/src/sup/lib/sup/hook.rb:42:in `__run'
 /home/alip/src/sup/lib/sup/hook.rb:82:in `run'
 /home/alip/src/sup/lib/sup/util.rb:520:in `send'
 /home/alip/src/sup/lib/sup/util.rb:520:in `method_missing'
 /home/alip/src/sup/lib/sup/buffer.rb:540:in `ask_for_contacts'
 /home/alip/src/sup/lib/sup/util.rb:520:in `send'
 /home/alip/src/sup/lib/sup/util.rb:520:in `method_missing'
 /home/alip/src/sup/lib/sup/modes/compose-mode.rb:24:in `spawn_nicely'
 /home/alip/src/sup/bin/sup:282
 
 This is with current master 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf
 
 -- 
 Regards,
 Ali Polatel
 
 From alip@exherbo.org  Sun Sep 20 19:11:04 2009
 From: alip@exherbo.org (Ali Polatel)
 Date: Mon, 21 Sep 2009 02:11:04 +0300
 Subject: [sup-talk] Problem with lbdb and extra contacts hook
 In-Reply-To: <1253481392-sup-4891@harikalardiyari>
 References: <1253481392-sup-4891@harikalardiyari>
 Message-ID: <1253488117-sup-4560@harikalardiyari>
 
 Ali Polatel yazm??:
 > Hello,
 > I've just started using sup and I'm really loving it.
 > Thanks for the great software.
 > 
 > I have a problem with extra-contact-addresses hook and lbdb.
 > Using the hook in the wiki:
 > contacts = []
 > `lbdbq |awk -F"\t" '{print $2 , "<"$1">"}'`.each { |c| contacts.push(c) }
 > return contacts
 
 Answering myself, removing return from the last line works as expected!
 I'll see if I can edit the wiki.
 
 -- 
 Regards,
 Ali Polatel
 
 From michael+sup@stapelberg.de  Tue Sep 22 13:05:48 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Tue, 22 Sep 2009 19:05:48 +0200
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 Message-ID: <1253638189-sup-7758@midna.zekjur.net>
 
 Hi,
 
 I noticed that emails sent by Thunderbird which contain inline GPG messages
 are not decrypted at all. I?ve attached such a message so you can verify
 it. Unfortunately my ruby skills did not suffice to fix this on my own.
 
 Thanks and best regards,
 Michael
 -------------- next part --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: crypted.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090922/628024f2/attachment.txt>
 
 From michael+sup@stapelberg.de  Tue Sep 22 13:24:24 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Tue, 22 Sep 2009 19:24:24 +0200
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 In-Reply-To: <1253638189-sup-7758@midna.zekjur.net>
 References: <1253638189-sup-7758@midna.zekjur.net>
 Message-ID: <1253640093-sup-48@midna.zekjur.net>
 
 Hi,
 
 Excerpts from Michael Stapelberg's message of Di Sep 22 19:05:48 +0200 2009:
 > I noticed that emails sent by Thunderbird which contain inline GPG messages
 > are not decrypted at all. I?ve attached such a message so you can verify
 > it. Unfortunately my ruby skills did not suffice to fix this on my own.
 Addition: Probably I was able to fix it, but the other bug I reported about
 not being able to open GPG encrypted email at all was the one I was seeing.
 So, fix should be easy (untested, because of the other bug):
 
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -436,6 +436,16 @@ private
        end
  
        chunks
 +    elsif m.header.content_type == "application/pgp"
 +     notice, sig, decryptedm = CryptoManager.decrypt m.body
 +     if decryptedm # managed to decrypt
 +       children = message_to_chunks(decryptedm, true)
 +       chunks = [notice, sig, children]
 +     else
 +       chunks = [notice]
 +     end
 +
 +     chunks
      elsif m.header.content_type == "message/rfc822"
        if m.body
          payload = RMail::Parser.read(m.body)
 
 Best regards,
 Michael
 
 From david.pflug@hostdime.com  Tue Sep 22 14:01:50 2009
 From: david.pflug@hostdime.com (David Pflug)
 Date: Tue, 22 Sep 2009 14:01:50 -0400
 Subject: [sup-talk] Exception while marking mail as read
 Message-ID: <1253642183-sup-1331@dpflug-desktop>
 
 Hi there,
 
 I'm using :next, having used the fix from :ncursesw.
 
 I've got some unread threads that are 300+ messages long (threaded by subject) from automated processes. I did a search for is:unread and started marking them read, and saved my changes (or, at least, pressed $ while sup was chugging through the last thread). It's possible a poll started at the same time, but I can't be sure.
 
 Here's exception.log:
 --- Ferret::StateError from thread: load threads for thread-index-mode
 State Error occured at <except.c>:93 in xraise
 Error occured in index.c:4150 - sr_get_lazy_doc
     Document 9233 has already been deleted
 
 /usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]'
 /usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:413:in `[]'
 ./lib/sup/ferret_index.rb:163:in `each_id_by_date'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 ./lib/sup/ferret_index.rb:163:in `each_id_by_date'
 ./lib/sup/ferret_index.rb:162:in `each'
 ./lib/sup/ferret_index.rb:162:in `each_id_by_date'
 ./lib/sup/thread.rb:328:in `load_n_threads'
 ./lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 ./lib/sup/modes/thread-index-mode.rb:609: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:608:in `load_n_threads_background'
 ./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 ./lib/sup/modes/thread-index-mode.rb:81:in `initialize'
 ./lib/sup/modes/line-cursor-mode.rb:22:in `call'
 ./lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 ./lib/sup/modes/line-cursor-mode.rb:22:in `each'
 ./lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 ./lib/sup/modes/line-cursor-mode.rb:19:in `new'
 ./lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
 ./lib/sup/modes/thread-index-mode.rb:54:in `initialize'
 ./lib/sup/modes/search-results-mode.rb:6:in `initialize'
 ./lib/sup/modes/search-results-mode.rb:30:in `new'
 ./lib/sup/modes/search-results-mode.rb:30:in `spawn_from_query'
 bin/sup:270
 
 
 Regards,
 David
 -- 
 David Pflug
 System Technician
 Hostdime.com, Inc.
 
 From michael+sup@stapelberg.de  Fri Sep 25 15:08:52 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Fri, 25 Sep 2009 21:08:52 +0200
 Subject: [sup-talk] Bug: Opening PGP encrypted mails fails with latest
 	revision
 In-Reply-To: <1253476236-sup-9371@midna.zekjur.net>
 References: <1253476236-sup-9371@midna.zekjur.net>
 Message-ID: <1253905662-sup-1750@midna.zekjur.net>
 
 Hi,
 
 Excerpts from Michael Stapelberg's message of So Sep 20 21:51:38 +0200 2009:
 > when opening PGP encrypted mails (MIME), sup crashes with the following
 > exception:
 Further debugging revealed that this has been introduced in revision
 927b7df4b2052a6b3c2ae1f2b44a6bc901315f8d and can be fixed with the following
 patch:
 
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -413,7 +413,7 @@ private
      notice, sig, decryptedm = CryptoManager.decrypt payload
      if decryptedm # managed to decrypt
        children = message_to_chunks(decryptedm, true)
 -      [notice, sig, children]
 +      [notice, sig, children].flatten.compact
      else
        [notice]
      end
 
 Best regards,
 Michael
 
 From michael+sup@stapelberg.de  Fri Sep 25 15:10:11 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Fri, 25 Sep 2009 21:10:11 +0200
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 In-Reply-To: <1253640093-sup-48@midna.zekjur.net>
 References: <1253638189-sup-7758@midna.zekjur.net>
 	<1253640093-sup-48@midna.zekjur.net>
 Message-ID: <1253905743-sup-419@midna.zekjur.net>
 
 Hi,
 
 after fixing the other bug related to GPG messages, this patch has to be
 modified, too:
 
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -436,6 +436,16 @@ private
        end
  
        chunks
 +    elsif m.header.content_type == "application/pgp"
 +     notice, sig, decryptedm = CryptoManager.decrypt m.body
 +     if decryptedm # managed to decrypt
 +       children = message_to_chunks(decryptedm, true)
 +       chunks = [notice, sig, children].flatten.compact
 +     else
 +       chunks = [notice]
 +     end
 +
 +     chunks
      elsif m.header.content_type == "message/rfc822"
        if m.body
          payload = RMail::Parser.read(m.body)
 
 Best regards,
 Michael
 
 From michael+sup@stapelberg.de  Fri Sep 25 15:13:29 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Fri, 25 Sep 2009 21:13:29 +0200
 Subject: [sup-talk] Bug: Killed threads coming up again
 Message-ID: <1253905917-sup-5964@midna.zekjur.net>
 
 Hi,
 
 I noticed that killed messages sometimes appear in my inbox again. This might
 be caused by a new label coming up by a new message for this thread, which
 arrived through a different source (in my case, a message was marked as spam,
 thus arrived in a new IMAP folder and thus a new source in sup and therefore
 came up with the label spam).
 
 Did anyone of you notice the same? Can you reproduce this?
 
 Best regards,
 Michael
 
 From cworth@cworth.org  Fri Sep 25 16:46:31 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Fri, 25 Sep 2009 13:46:31 -0700
 Subject: [sup-talk] [PATCH] Fix uninitialized @name member in person.rb.
 Message-ID: <1253911543-sup-7680@yoom.home.cworth.org>
 
 Apparently a Person can be initialized with a nil name, (presumably
 from a message where there's no name given), which before this commit
 resulted in the following warning:
 
 ./lib/sup/person.rb:46: warning: instance variable @name not initialized
 
 This warning was especially unpleasant since it appeared in the current
 window, causing the terminal contents to incorrectly scroll up, (as
 opposed to just appearing in the log or so).
 ---
  lib/sup/person.rb |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/person.rb b/lib/sup/person.rb
 index c4f40a5..cd5b1ea 100644
 --- a/lib/sup/person.rb
 +++ b/lib/sup/person.rb
 @@ -11,6 +11,8 @@ class Person
        if @name =~ /^(['"]\s*)(.*?)(\s*["'])$/
          @name = $2
        end
 +    else
 +      @name = nil
      end
  
      @email = email.gsub(/^\s+|\s+$/, "").gsub(/\s+/, " ").downcase
 -- 
 1.6.4.3
 
 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 190 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/26a4d1df/attachment.bin>
 
 From cworth@cworth.org  Fri Sep 25 17:08:23 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Fri, 25 Sep 2009 14:08:23 -0700
 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first
 Message-ID: <1253911610-sup-2052@yoom.home.cworth.org>
 
 Keith and I both want to read our email in chronological order,
 (reading oldest messages first), so we believe it makes sense to
 present the inbox mode in this order, (with the oldest messages at the
 top).
 
 This is distinct from the order for global searches where having the
 newest messages first does seem obviously correct.
 
 The below patches are a first cut at implementing this. They provide a
 new configuration option, (:inbox_newest_first), which can be used to
 control the default sorting for the inbox. Keith's original patch
 doesn't change sup's behavior unless the user manually configures this
 option to false. My second patch changes the default. Obviously, it
 would be easy to accept Keith's version without changing the default
 for sup.
 
 One nice thing about the inmplentation is that any refined searches
 inherit the mode of the parent search, which makes it easy to maintain
 oldest-message-first for "reading" and newest-message-first for
 "searching".
 
 Also note that there's a new command 'o' to toggle the search order
 for a current view. This is a feature that we talked about earlier as
 a way to avoid the need for the distinction between the ',' and ']'
 commands in thread-view-mode. If the user can control the sort of the
 search view, then it would be more natural to have commands that
 simply advance to the "next" message, (since the user can choose in
 advance what "next" means).
 
 A couple of caveats with respect to the patch as it exists so far:
 
 1. When doing oldest-first searching, it wasn't obvious if it's even
    possible to query for only the N oldest messages (to lazily load
    new threads while navigating as sup currently does). So the patch
    currently loads all threads when in oldest-first mode.
 
    In my use so far this has worked well since I generally have a
    small number of messages in my inbox (and even fewer in my refined
    views of my inbox) and those are the only places where I use
    oldest-first sorting. For global searches, I do have an effectively
    infinite number of messages, but there I do use newest-first
    searching which still has the lazy loading.
 
 2. Currently sup uses the date of the newest message in a thread as
    the key for sorting that message. This is correct for newest-first
    sorting. But when doing the new oldest-first sorting, the patch
    really should be augmented to instead use the date of the oldest
    message in a thread that matches the current search criteria.
 
    We haven't looked yet into how hard this would be to fix. (And we'd
    of course be glad for any help or pointers.)
 
 -Carl
 
 PS. We're still total ruby newbies, so please point out any silly
 mistakes we're missing with respect to ruby idioms.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Allow-thread-index-view-to-sort-oldest-first.patch
 Type: application/octet-stream
 Size: 7849 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0002-Change-the-default-sort-for-inbox-mode-to-be-oldest-.patch
 Type: application/octet-stream
 Size: 777 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment-0001.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 190 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090925/8fd3d30c/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 09:48:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 06:48:04 -0700
 Subject: [sup-talk] Problem with lbdb and extra contacts hook
 In-Reply-To: <1253488117-sup-4560@harikalardiyari>
 References: <1253481392-sup-4891@harikalardiyari>
 	<1253488117-sup-4560@harikalardiyari>
 Message-ID: <1253972856-sup-3123@masanjin.net>
 
 Reformatted excerpts from Ali Polatel's message of 2009-09-20:
 > Answering myself, removing return from the last line works as
 > expected!  I'll see if I can edit the wiki.
 
 Yep, that was the problem. Hooks shouldn't call return. Nice work. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 09:50:29 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 06:50:29 -0700
 Subject: [sup-talk] Trouble implementing UTF-8 ncurses fix
 In-Reply-To: <1253311953-sup-3472@Richard-Sandilandss-MacBook-Pro.local>
 References: <1253311953-sup-3472@Richard-Sandilandss-MacBook-Pro.local>
 Message-ID: <1253972920-sup-9313@masanjin.net>
 
 Reformatted excerpts from Richard Sandilands's message of 2009-09-18:
 > but am running into trouble when I run 'run-this-for-sup.sh'. I've
 > installed the ncurses-5.7 library on my Mac 10.6 machine, but the shell
 > script above gives this output to mkmf.log: <http://pastie.org/622306>
 
 I'm not sure of how to do it on your particular system, but you need to
 install libncursesw (note the "w"). Maybe someone else who runs Sup on a
 mac can help.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 09:56:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 06:56:04 -0700
 Subject: [sup-talk] Bug: Converting the index to xapian fails with a
 	message with very old date
 In-Reply-To: <1253475875-sup-5119@midna.zekjur.net>
 References: <1253475875-sup-5119@midna.zekjur.net>
 Message-ID: <1253973258-sup-3347@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-20:
 > This makes sup/xapian/ruby (one of them) go crazy and abort with an exception:
 > ## read 5856m (about 72%) @ 10.0m/s. 0:09:47 elapsed, about 0:03:44 remaining
 > /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `_dump': year too big to marshal
 > (ArgumentError)
 
 Interesting. The Xapian index has had some trouble with crazy dates in
 the past, but that should be fixed. Can you apply the following debug
 patch and send the output for that message?
 
 Thanks!
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index ab25ea0..b94c8b0 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -509,6 +509,9 @@ EOS
        Xapian.sortable_serialise 0
      end
  
 +    puts "> truncated date is #{truncated_date.inspect}"
 +    puts "> date_value is #{date_value.inspect}"
 +
      docid = nil
      unless doc = find_doc(m.id)
        doc = Xapian::Document.new
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 09:58:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 06:58:59 -0700
 Subject: [sup-talk] Hello,
 	and before-add-message hook for applying labels per CDB
 In-Reply-To: <1253303164-sup-1138@kronos>
 References: <1253303164-sup-1138@kronos>
 Message-ID: <1253973470-sup-620@masanjin.net>
 
 Reformatted excerpts from William Erik Baxter's message of 2009-09-18:
 > Hello fellow sup users.  I began using sup last week, spent some time setting
 > it up in parallel with mutt, and have not used mutt since, except through
 > accident of habit.  Thanks to all developers for your excellent work.
 
 Great! Welcome!
 
 > A before-add-message hook follows.  It applies labels per entries in a CDB
 > constructed externally.  I hope you find it useful.
 
 Thanks! If you get a chance, please add it to the wiki:
 http://sup.rubyforge.org/wiki/wiki.pl?Hooks
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 10:31:56 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 07:31:56 -0700
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <20090916172340.GA20566@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 Message-ID: <1253975267-sup-8308@masanjin.net>
 
 Sorry it's taken me so long to get back to this.
 
 Reformatted excerpts from Ben Gamari's message of 2009-09-16:
 >     Thread#join: deadlock 0x7f592eec4d78 - mutual join(0x7f592f01d6e8)
 >     /opt/exp/sup/lib/sup/message.rb:240:in `select'
 >     /opt/exp/sup/lib/sup/buffer.rb:35:in `nonblocking_getch'
 >     /usr/bin/sup:213
 > 
 > However, at this point during debugging I happened to pipe stderr to a
 > file and accidentally found that most of the backtrace was actually
 > being hidden by curses.  Examining the full output on stderr reveals,
 > 
 >     /usr/bin/sup:213(eval):3:in `synchronize': Thread#join: deadlock
 > 0x7f4d5da565c0 - mutual join(0x7f4d5daf8be0) (ThreadError)
 >         from (eval):3:in `raw_header'
 >         from /opt/exp/sup/lib/sup/imap.rb:98:in `load_header'
 
 I definitely am not sure why there's a deadlock happening, but I am
 guessing, based on the line numbers in that first exception, that it's
 being triggered by an underlying problem with the source. If you run
 sup with -n, does that change anything? (Or produce a better exception?)
 
 > Anyways, this is the current status of things on my machine. William, do
 > you have any ideas what might cause such a backtrace. At this point
 > classes have started and I really have no more time to devote to
 > getting sup working. If there isn't a fairly simple solution here I guess
 > I'll just need to stick with mutt (ugh). Anyways, thanks for your work.
 
 Well, there's a workaround, which is to switch over to an offlineimap
 setup where your Gmail is mirrored locally and Sup reads the mirror
 (which is what you want anyways if you're serious about using Sup with
 an IMAP client). I don't know what's causing the deadlock, but I will
 try and reproduce it on my end.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 10:40:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 07:40:59 -0700
 Subject: [sup-talk] Fixing header for encrypted messages (might be an
 	old issue)
 In-Reply-To: <1253054438-sup-8449@thinkpad-ubuntu>
 References: <1253045775-sup-210@thinkpad-ubuntu>
 	<20090915222119.GA5290@chistera.yi.org>
 	<1253054438-sup-8449@thinkpad-ubuntu>
 Message-ID: <1253976007-sup-711@masanjin.net>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-09-15:
 > Excerpts from Adeodato Sim?'s message of Mi Sep 16 00:21:19 +0200 2009:
 > > --- NoMethodError from thread: load messages for thread-view-mode
 > > undefined method `expandable?' for #<Array:0x7faa50e2d978>
 > > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text'
 > > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each'
 > > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text'
 > > /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each'
 > > /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff'
 > > [...]
 > 
 > Yes, it's the same error I get. Any insights as to what is causing this?
 
 Just to confirm---both of you are seeing this error, with a recent git
 master, when opening encrypted messages?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 10:48:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 07:48:48 -0700
 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock?
 In-Reply-To: <1253043209-sup-8800@zyrg.net>
 References: <1253030868-sup-8556@mithink> <1253043209-sup-8800@zyrg.net>
 Message-ID: <1253976432-sup-3851@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-15:
 > I think William said he's been doing some 1.9 work recently. I wouldn't
 > say it's ready just yet.
 
 My current plan is to release an 0.9 tomorrow or so (probably without
 advertising the Xapian support), and to focus on Ruby 1.9 support for
 the next release.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 10:49:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 07:49:41 -0700
 Subject: [sup-talk] Fixing header for encrypted messages (might be an
 	old issue)
 In-Reply-To: <1253976007-sup-711@masanjin.net>
 References: <1253045775-sup-210@thinkpad-ubuntu>
 	<20090915222119.GA5290@chistera.yi.org>
 	<1253054438-sup-8449@thinkpad-ubuntu>
 	<1253976007-sup-711@masanjin.net>
 Message-ID: <1253976576-sup-8002@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-09-26:
 > Just to confirm---both of you are seeing this error, with a recent git
 > master, when opening encrypted messages?
 
 Ah, looks like Michael Stapelberg's patch will fix this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 10:56:14 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 07:56:14 -0700
 Subject: [sup-talk] Hello and thanks
 In-Reply-To: <1252787425-sup-4073@longword>
 References: <1252787425-sup-4073@longword>
 Message-ID: <1253976950-sup-8220@masanjin.net>
 
 Hi Bo,
 
 Reformatted excerpts from Bo Borgerson's message of 2009-09-12:
 > A git-send-email out of the blue isn't necessarily the friendliest of
 > introductions, though, so I just wanted to write first and say thanks
 > to William and everyone who has contributed to sup.  It's pretty
 > awesome.
 
 Thanks for the kind words, and welcome!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 13:45:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 10:45:49 -0700
 Subject: [sup-talk] [PATCH] Fix uninitialized @name member in person.rb.
 In-Reply-To: <1253911543-sup-7680@yoom.home.cworth.org>
 References: <1253911543-sup-7680@yoom.home.cworth.org>
 Message-ID: <1253987121-sup-2390@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-09-25:
 > Apparently a Person can be initialized with a nil name, (presumably
 > from a message where there's no name given), which before this commit
 > resulted in the following warning:
 >
 > ./lib/sup/person.rb:46: warning: instance variable @name not initialized
 
 Thanks, I have fixed this in master. Let me know if it doesn't work!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 13:50:42 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 10:50:42 -0700
 Subject: [sup-talk] Bug: Killed threads coming up again
 In-Reply-To: <1253905917-sup-5964@midna.zekjur.net>
 References: <1253905917-sup-5964@midna.zekjur.net>
 Message-ID: <1253987261-sup-6729@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-25:
 > I noticed that killed messages sometimes appear in my inbox again.
 
 Rats. I thought we had this problem licked.
 
 > Did anyone of you notice the same? Can you reproduce this?
 
 I haven't seen this recently. Are you using 0.8.1 or git? Does anyone
 else see this with git?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Sat Sep 26 14:03:53 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sat, 26 Sep 2009 20:03:53 +0200
 Subject: [sup-talk] Bug: Killed threads coming up again
 In-Reply-To: <1253987261-sup-6729@masanjin.net>
 References: <1253905917-sup-5964@midna.zekjur.net>
 	<1253987261-sup-6729@masanjin.net>
 Message-ID: <1253988170-sup-189@midna.zekjur.net>
 
 Hi,
 
 Excerpts from William Morgan's message of Sa Sep 26 19:50:42 +0200 2009:
 > Rats. I thought we had this problem licked.
 Unfortunately not. Also, this also happened with a thread which got no new
 labels today, so my guess in the last mail was not correct.
 
 > I haven't seen this recently. Are you using 0.8.1 or git? Does anyone
 > else see this with git?
 I am using git version 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf.
 
 Best regards,
 Michael
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 14:09:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 11:09:36 -0700
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 In-Reply-To: <1253905743-sup-419@midna.zekjur.net>
 References: <1253638189-sup-7758@midna.zekjur.net>
 	<1253640093-sup-48@midna.zekjur.net>
 	<1253905743-sup-419@midna.zekjur.net>
 Message-ID: <1253988435-sup-8649@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-25:
 > after fixing the other bug related to GPG messages, this patch has to be
 > modified, too:
 
 I believe I've fixed this in git. Thunderbird is not producing
 RFC3156-compliant encrypted emails, but by the Postel's Law we will
 accomodate their errors. Let me know if it doesn't work.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 14:10:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 11:10:04 -0700
 Subject: [sup-talk] Bug: Opening PGP encrypted mails fails with latest
 	revision
 In-Reply-To: <1253905662-sup-1750@midna.zekjur.net>
 References: <1253476236-sup-9371@midna.zekjur.net>
 	<1253905662-sup-1750@midna.zekjur.net>
 Message-ID: <1253988590-sup-9530@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-25:
 > Further debugging revealed that this has been introduced in revision
 > 927b7df4b2052a6b3c2ae1f2b44a6bc901315f8d and can be fixed with the
 > following patch:
 
 Thanks, this should be fixed in git. Give it a try.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Sat Sep 26 14:09:56 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sat, 26 Sep 2009 20:09:56 +0200
 Subject: [sup-talk] Hook, again
 Message-ID: <1253988011-sup-8497@altis>
 
 Sorry to come back again with that issue, but I'm having trouble with
 the reply-from hook. Here's what I have:
 
 message.recipients.each {
     |person|
 	if (person.email =~ /addr at site.com/) != nil
 		Person.from_address "Foo  <bar at site.org>"
 	end 
 }
 
 But it doesn't seem to work. 
 If I reply to a mail addressed to addr at site.com, the log says nothing, but the from field isn't changed.
 If I reply to any other mail, le log complains I didn't return a Person
 And if I just put Person.from_address "Foo  <addr at site.org>" in the
 hook, the from field is correctly changed.
 
 I'm a bit lost on that one (still not knowing alot of ruby doesn't help
 I must say). Am I missing the obvious here?
 
 Cheers.
 
 -- 
 Guillaume
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 14:12:24 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 11:12:24 -0700
 Subject: [sup-talk] [PATCH] Fix message_to_chunks for the m.body == nil
 	case.
 In-Reply-To: <1253217341-sup-8631@yoom.home.cworth.org>
 References: <1253217341-sup-8631@yoom.home.cworth.org>
 Message-ID: <1253988663-sup-3838@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-09-17:
 > The code was previously broken in calling EnclosedMessage.new with
 > only 2 instead of 5 arguments.
 
 Thanks, this has been applied.
 
 > So I'm not 100% sure that this patch is correct, but it does allow
 > sup-sync to proceed and the message appears in sup as well as could be
 > expected, (the "extra" headers from the corrupted mime part appear in
 > the body as one might expect here).
 
 Yeah, I think that's the best we can hope for here.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 14:12:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 11:12:50 -0700
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
 	variable with the attachment charset
 In-Reply-To: <20090913231753.GA20849@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>
 	<1251048347-sup-5075@masanjin.net>
 	<20090913231753.GA20849@chistera.yi.org>
 Message-ID: <1253988754-sup-7987@masanjin.net>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-09-13:
 > Now that that fix is in, can you merge the mime-decode improvement from
 > <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato at net.com.org.es>?
 
 Applied directly to master. Sorry for the grand delay.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 14:17:14 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 11:17:14 -0700
 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail
 	stupidity?
 In-Reply-To: <1252781841-sup-6303@black-opal.mit.edu>
 References: <1252781841-sup-6303@black-opal.mit.edu>
 Message-ID: <1253988779-sup-2896@masanjin.net>
 
 Reformatted excerpts from Kevin Riggle's message of 2009-09-12:
 > I theorize that RubyMail is being case-sensitive where it shouldn't.
 
 Although I love criticizing RubyMail, I think this is Sup's fault. I
 don't think it's in RubyMail's proper purview to canonicalize header
 values (though header names are fine).
 
 Anyways, I think I've fixed this in git. Give it a try.
 
 > Given the number of work-arounds Sup has had to implement to
 > compensate for RubyMail's stupidity, and that RubyMail is currently
 > unmaintained, has any thought been given to switching Sup to eg. TMail
 > (http://tmail.rubyforge.org), which is maintained?
 
 It's certainly an option, but with so many workarounds invested in
 RubyMail, I'm not sure it's a win. A patch that magically makes
 everything work would certainly be considered.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 14:23:34 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 11:23:34 -0700
 Subject: [sup-talk] sup 0.9 pre-release checkin
 Message-ID: <1253989249-sup-3372@masanjin.net>
 
 Hi all,
 
 I'm getting to release Sup 0.9. I have applied all outstanding bugfixes
 I've found, and have merged preemptive-loading into master, which was
 the only remaining unmerged feature branch.
 
 If there's anything obviously missing, or obviously wrong with the state
 of git master, now's a good time to point it out!
 
 Other pending patches will be merged into next afterwards, and targeted
 for an 0.10 release.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Sat Sep 26 16:28:54 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sat, 26 Sep 2009 22:28:54 +0200
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 In-Reply-To: <1253988435-sup-8649@masanjin.net>
 References: <1253638189-sup-7758@midna.zekjur.net>
 	<1253640093-sup-48@midna.zekjur.net>
 	<1253905743-sup-419@midna.zekjur.net>
 	<1253988435-sup-8649@masanjin.net>
 Message-ID: <1253996823-sup-6670@midna.zekjur.net>
 
 Hi,
 
 Excerpts from William Morgan's message of Sa Sep 26 20:09:36 +0200 2009:
 > I believe I've fixed this in git. Thunderbird is not producing
 > RFC3156-compliant encrypted emails, but by the Postel's Law we will
 > accomodate their errors. Let me know if it doesn't work.
 The changes basically work. The message itself is opened and decrypted
 correctly. However, when handling some messages, an exception occurs
 (downcase called on NilClass), which can be fixed like this:
 
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -436,7 +436,7 @@ private
        end
  
        chunks
 -    elsif m.header.content_type.downcase == "message/rfc822"
 +    elsif m.header.content_type && m.header.content_type.downcase == "message/rfc822"
        if m.body
          payload = RMail::Parser.read(m.body)
          from = payload.header.from.first ? payload.header.from.first.format : ""
 @@ -456,7 +456,7 @@ private
          debug "no body for message/rfc822 enclosure; skipping"
          []
        end
 -    elsif m.header.content_type.downcase == "application/pgp" && m.body
 +    elsif m.header.content_type && m.header.content_type.downcase == "application/pgp" && m.body
        ## apparently some versions of Thunderbird generate encryped email that
        ## does not follow RFC3156, e.g. messages with X-Enigmail-Version: 0.95.0
        ## they have no MIME multipart and just set the body content type to
 
 Best regards,
 Michael
 
 From kevinr@free-dissociation.com  Sat Sep 26 17:35:31 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Sat, 26 Sep 2009 17:35:31 -0400
 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail
 	stupidity?
 In-Reply-To: <1253988779-sup-2896@masanjin.net>
 References: <1252781841-sup-6303@black-opal.mit.edu>
 	<1253988779-sup-2896@masanjin.net>
 Message-ID: <1254000848-sup-7848@black-opal.mit.edu>
 
 Excerpts from William Morgan's message of Sat Sep 26 14:17:14 -0400 2009:
 > Reformatted excerpts from Kevin Riggle's message of 2009-09-12:
 > > I theorize that RubyMail is being case-sensitive where it shouldn't.
 > 
 > Although I love criticizing RubyMail, I think this is Sup's fault. I
 > don't think it's in RubyMail's proper purview to canonicalize header
 > values (though header names are fine).
 > 
 > Anyways, I think I've fixed this in git. Give it a try.
 > 
 Updated to next, restarted Sup, went to open a message, and got this crash:
 (Appears to be individual messages, not all messages.)
 
 --- NoMethodError from thread: load messages for thread-view-mode
 undefined method `downcase' for nil:NilClass
 ./lib/sup/message.rb:439:in `message_to_chunks'
 ./lib/sup/message.rb:239:in `load_from_source!'
 ./lib/sup/modes/thread-index-mode.rb:108:in `select'
 ./lib/sup/hook.rb:121:in `each_with_index'
 ./lib/sup/thread.rb:68:in `each'
 ./lib/sup/thread.rb:168:in `each_with_stuff'
 ./lib/sup/thread.rb:67:in `each'
 ./lib/sup/modes/thread-index-mode.rb:105:in `each_with_index'
 ./lib/sup/modes/thread-index-mode.rb:105:in `select'
 ./lib/sup/buffer.rb:716:in `say'
 ./lib/sup/util.rb:520:in `send'
 ./lib/sup/util.rb:520:in `method_missing'
 ./lib/sup/modes/thread-index-mode.rb:104:in `select'
 ./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:101:in `select'
 ./lib/sup/mode.rb:51:in `send'
 ./lib/sup/mode.rb:51:in `handle_input'
 ./lib/sup/buffer.rb:267:in `handle_input'
 bin/sup:238
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 http://free-dissociation.com
 
 From bwalton@artsci.utoronto.ca  Sat Sep 26 17:37:53 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 26 Sep 2009 17:37:53 -0400
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 In-Reply-To: <1253996823-sup-6670@midna.zekjur.net>
 References: <1253638189-sup-7758@midna.zekjur.net>
 	<1253640093-sup-48@midna.zekjur.net>
 	<1253905743-sup-419@midna.zekjur.net>
 	<1253988435-sup-8649@masanjin.net>
 	<1253996823-sup-6670@midna.zekjur.net>
 Message-ID: <1254001034-sup-5895@ntdws12.chass.utoronto.ca>
 
 Excerpts from Michael Stapelberg's message of Sat Sep 26 16:28:54 -0400 2009:
 > The changes basically work. The message itself is opened and decrypted
 > correctly. However, when handling some messages, an exception occurs
 > (downcase called on NilClass), which can be fixed like this:
 
 +1 for this patch.  I need it after updating too.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 
 From michael+sup@stapelberg.de  Sat Sep 26 17:38:49 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sat, 26 Sep 2009 23:38:49 +0200
 Subject: [sup-talk] Bug: Converting the index to xapian fails with a
 	message with very old date
 In-Reply-To: <1253973258-sup-3347@masanjin.net>
 References: <1253475875-sup-5119@midna.zekjur.net>
 	<1253973258-sup-3347@masanjin.net>
 Message-ID: <1254001080-sup-5742@midna.zekjur.net>
 
 Hi,
 
 Excerpts from William Morgan's message of Sa Sep 26 15:56:04 +0200 2009:
 > Interesting. The Xapian index has had some trouble with crazy dates in
 > the past, but that should be fixed. Can you apply the following debug
 > patch and send the output for that message?
 Yes, here we go:
 
 truncated date is Thu Jan 01 01:00:00 +0100 1970
 date_value is "\200"
 /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `_dump': year too big to marshal (ArgumentError)
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `dump'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `index_message'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message'
         from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:398:in `synchronize'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:123:in `sync_message'
         from /usr/lib/ruby/1.8/sup/xapian_index.rb:94:in `add_message'
         from /home/michael/software/sup-mainline/bin/sup-sync:211
         from /usr/lib/ruby/1.8/sup/poll.rb:151:in `each_message_from'
         from /usr/lib/ruby/1.8/sup/imap.rb:197:in `each'
         from /usr/lib/ruby/1.8/sup/imap.rb:185:in `upto'
         from /usr/lib/ruby/1.8/sup/imap.rb:185:in `each'
         from /usr/lib/ruby/1.8/sup/util.rb:560:in `send'
         from /usr/lib/ruby/1.8/sup/util.rb:560:in `__pass'
         from /usr/lib/ruby/1.8/sup/util.rb:547:in `method_missing'
         from /usr/lib/ruby/1.8/sup/poll.rb:139:in `each_message_from'
         from /usr/lib/ruby/1.8/sup/util.rb:520:in `send'
         from /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing'
         from /home/michael/software/sup-mainline/bin/sup-sync:146
         from /home/michael/software/sup-mainline/bin/sup-sync:141:in `each'
         from /home/michael/software/sup-mainline/bin/sup-sync:141
 
 Best regards,
 Michael
 
 From michael+sup@stapelberg.de  Sat Sep 26 17:41:58 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sat, 26 Sep 2009 23:41:58 +0200
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 In-Reply-To: <1253996823-sup-6670@midna.zekjur.net>
 References: <1253638189-sup-7758@midna.zekjur.net>
 	<1253640093-sup-48@midna.zekjur.net>
 	<1253905743-sup-419@midna.zekjur.net>
 	<1253988435-sup-8649@masanjin.net>
 	<1253996823-sup-6670@midna.zekjur.net>
 Message-ID: <1254001238-sup-5754@midna.zekjur.net>
 
 Hi,
 
 Excerpts from Michael Stapelberg's message of Sa Sep 26 22:28:54 +0200 2009:
 > The changes basically work. The message itself is opened and decrypted
 > correctly. However, when handling some messages, an exception occurs
 > (downcase called on NilClass), which can be fixed like this:
 I noticed that this is not the only place where this was wrong. Complete
 patch attached (also fixes mixups like control.header.downcase.content_type
 vs. control.header.content_type.downcase).
 
 Best regards,
 Michael
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-downcase.patch
 Type: application/octet-stream
 Size: 2375 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090926/da544580/attachment.obj>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 21:27:57 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 18:27:57 -0700
 Subject: [sup-talk] Hook, again
 In-Reply-To: <1253988011-sup-8497@altis>
 References: <1253988011-sup-8497@altis>
 Message-ID: <1254014763-sup-4749@masanjin.net>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-09-26:
 > message.recipients.each {
 >     |person|
 >     if (person.email =~ /addr at site.com/) != nil
 >         Person.from_address "Foo  <bar at site.org>"
 >     end 
 > }
 
 The problem is that #each returns the original array, i.e.
 message.recipients. Your Person object is getting constructed and then
 forgotten.
 
 Try:
 
 if messages.recipients.any? { |p| p.email =~ /addr at site\.com/ }
   Person.from_address "Foo <bar at site.org>"
 end
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 21:40:06 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 18:40:06 -0700
 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted
 In-Reply-To: <1254001238-sup-5754@midna.zekjur.net>
 References: <1253638189-sup-7758@midna.zekjur.net>
 	<1253640093-sup-48@midna.zekjur.net>
 	<1253905743-sup-419@midna.zekjur.net>
 	<1253988435-sup-8649@masanjin.net>
 	<1253996823-sup-6670@midna.zekjur.net>
 	<1254001238-sup-5754@midna.zekjur.net>
 Message-ID: <1254015511-sup-5690@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-26:
 > I noticed that this is not the only place where this was wrong. Complete
 > patch attached (also fixes mixups like control.header.downcase.content_type
 > vs. control.header.content_type.downcase).
 
 Applied, thanks. BTW it will be slightly easier on me if you commit
 changes and use git format-patch to send them (or git send-email). That
 will also put your name in the automatically-generated contributors
 list.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Sep 26 21:46:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 26 Sep 2009 18:46:03 -0700
 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail
 	stupidity?
 In-Reply-To: <1254000848-sup-7848@black-opal.mit.edu>
 References: <1252781841-sup-6303@black-opal.mit.edu>
 	<1253988779-sup-2896@masanjin.net>
 	<1254000848-sup-7848@black-opal.mit.edu>
 Message-ID: <1254015946-sup-7518@masanjin.net>
 
 Reformatted excerpts from Kevin Riggle's message of 2009-09-26:
 > undefined method `downcase' for nil:NilClass
 
 Should be fix0red.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From kevinr@free-dissociation.com  Sun Sep 27 03:10:51 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Sun, 27 Sep 2009 03:10:51 -0400
 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail
 	stupidity?
 In-Reply-To: <1254015946-sup-7518@masanjin.net>
 References: <1252781841-sup-6303@black-opal.mit.edu>
 	<1253988779-sup-2896@masanjin.net>
 	<1254000848-sup-7848@black-opal.mit.edu>
 	<1254015946-sup-7518@masanjin.net>
 Message-ID: <1254035436-sup-1220@black-opal.mit.edu>
 
 Excerpts from William Morgan's message of Sat Sep 26 21:46:03 -0400 2009:
 > Reformatted excerpts from Kevin Riggle's message of 2009-09-26:
 > > undefined method `downcase' for nil:NilClass
 > 
 > Should be fix0red.
 
 Looks like it is -- thanks!
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 http://free-dissociation.com
 
 From dato@net.com.org.es  Sun Sep 27 08:48:56 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Sun, 27 Sep 2009 13:48:56 +0100
 Subject: [sup-talk] Fixing header for encrypted messages (might be an
  old issue)
 In-Reply-To: <1253976576-sup-8002@masanjin.net>
 References: <1253045775-sup-210@thinkpad-ubuntu>
 	<20090915222119.GA5290@chistera.yi.org>
 	<1253054438-sup-8449@thinkpad-ubuntu>
 	<1253976007-sup-711@masanjin.net>
 	<1253976576-sup-8002@masanjin.net>
 Message-ID: <20090927124856.GA322@chistera.yi.org>
 
 + William Morgan (Sat, 26 Sep 2009 07:49:41 -0700):
 
 > Reformatted excerpts from William Morgan's message of 2009-09-26:
 > > Just to confirm---both of you are seeing this error, with a recent git
 > > master, when opening encrypted messages?
 
 > Ah, looks like Michael Stapelberg's patch will fix this.
 
 I can confirm it works again on master (and next), thanks!
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From web-sup@superscript.com  Sun Sep 27 13:04:39 2009
 From: web-sup@superscript.com (William Erik Baxter)
 Date: Sun, 27 Sep 2009 13:04:39 -0400
 Subject: [sup-talk] Why inbox-mode instead of default search?
 Message-ID: <1254070015-sup-5151@kronos>
 
 Why does sup have a separate mode for viewing the inbox rather than simply
 applying a default search (possibly configurable) and displaying the results
 with search-results-mode?  Like a number of other posters to the list, I wanted
 to refine my inbox search.  But the requisite key binding exists only in
 search-results-mode and not in inbox-mode.
 
 Using inbox as an ordinary label with search-results-mode instead of inbox-mode
 offers several advantages over the separate inbox-mode: less code, less
 separate modality, ability to refine the inbox search.  It introduces the
 possibility of closing the inbox window, readily addressed with a key binding
 to perform the default search.  What are the disadvantages?  One loses the
 difference in the archiving behavior between the two modes.  The inbox label
 would appear in the label editors.  The program may need new code to handle a
 new no-windows case.  Perhaps efficiency considerations enter here. 
 
 Thanks, W.
 
 From wmorgan-sup@masanjin.net  Sun Sep 27 13:46:00 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 27 Sep 2009 10:46:00 -0700
 Subject: [sup-talk] Why inbox-mode instead of default search?
 In-Reply-To: <1254070015-sup-5151@kronos>
 References: <1254070015-sup-5151@kronos>
 Message-ID: <1254073440-sup-2700@masanjin.net>
 
 Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
 > Why does sup have a separate mode for viewing the inbox rather than
 > simply applying a default search (possibly configurable) and
 > displaying the results with search-results-mode?
 
 Because there are two special actions that are specific to inboxes:
 archiving and killing.
 
 > Like a number of other posters to the list, I wanted to refine my
 > inbox search.  But the requisite key binding exists only in
 > search-results-mode and not in inbox-mode.
 
 It would be easy enough to add a "|" command to inbox mode that would
 spawn a search buffer with label:inbox and the rest of your search
 terms.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From web-sup@superscript.com  Sun Sep 27 14:50:08 2009
 From: web-sup@superscript.com (William Erik Baxter)
 Date: Sun, 27 Sep 2009 14:50:08 -0400
 Subject: [sup-talk] Why inbox-mode instead of default search?
 In-Reply-To: <1254073440-sup-2700@masanjin.net>
 References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net>
 Message-ID: <1254074517-sup-4465@kronos>
 
 Excerpts from William Morgan's message of Sun Sep 27 13:46:00 -0400 2009:
 > Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
 > > Why does sup have a separate mode for viewing the inbox rather than
 > > simply applying a default search (possibly configurable) and
 > > displaying the results with search-results-mode?
 > 
 > Because there are two special actions that are specific to inboxes:
 > archiving and killing.
 
 Both modes support archive and kill in some form.  So I don't understand how
 this argues for splitting as opposed to consolidating the two modes.  The need
 for preallocated, special-purpose labels like inbox and killed seems clear
 enough.  However, minimizing the amount of magical behavior they exhibit also
 seems beneficial, if only for the sake of consistency.  Treating the inbox as
 something other than an ordinary label search is magical.
 
 > It would be easy enough to add a "|" command to inbox mode that would
 > spawn a search buffer with label:inbox and the rest of your search
 > terms.
 
 A patch to add this command to inbox-mode appears in the August sup-talk
 archive.  I would like to see this feature become part of the base system.
 
 Cheers, W.
 
 From bgamari.foss@gmail.com  Mon Sep 28 14:10:06 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Mon, 28 Sep 2009 14:10:06 -0400
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1253975267-sup-8308@masanjin.net>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 	<1253975267-sup-8308@masanjin.net>
 Message-ID: <1254160696-sup-3522@ben-laptop>
 
 Excerpts from William Morgan's message of Sat Sep 26 10:31:56 -0400 2009:
 > Sorry it's taken me so long to get back to this.
 
 Quite alright. I know we're all busy.
 
 > 
 > I definitely am not sure why there's a deadlock happening, but I am
 > guessing, based on the line numbers in that first exception, that it's
 > being triggered by an underlying problem with the source. If you run
 > sup with -n, does that change anything? (Or produce a better exception?)
 
 Well, things definitely failed a bit differently. I tried this a few
 times and after seeing no real improvement, I moved on to your
 suggestion below. 
 
 > 
 > > Anyways, this is the current status of things on my machine. William, do
 > > you have any ideas what might cause such a backtrace. At this point
 > > classes have started and I really have no more time to devote to
 > > getting sup working. If there isn't a fairly simple solution here I guess
 > > I'll just need to stick with mutt (ugh). Anyways, thanks for your work.
 > 
 > Well, there's a workaround, which is to switch over to an offlineimap
 > setup where your Gmail is mirrored locally and Sup reads the mirror
 > (which is what you want anyways if you're serious about using Sup with
 > an IMAP client). I don't know what's causing the deadlock, but I will
 > try and reproduce it on my end.
 
 This is definitely what I should have done from the beginning. Given
 that sup seems to work fine after removing my imap sources, it seems
 that that might be the source of the above deadlock. I think I'll just
 stick with offlineimap for now.
 
 This does raise one important question, however. It seems that
 offlineimap will delete messages if they are found to have been deleted
 in the remote respository. Is there any way that you know of to disable
 this behavior, such that it will only drop new messages into the local
 repository, thus making it somewhat compatible with sup's add-only
 source requirement? It is awfully nice to be able to use GMail's web
 interface when I'm away from my computer, but needing to re-sync sup
 afterwards becomes quite tiresome.
 
 This actually brings up a larger question. How difficult would it be to
 relax sup's assumption that sources are add-only? This seems like a
 horribly restriction to have in an email program. I understand that in
 the case of sources such as imap where there is no globally unique
 message identifier trying to track message changes could be quite
 difficult, but for local sources (especially maildirs) it seems like
 this should be quite possible.
 
 Anyways, thanks a ton for your work. Now since I finally have sup up and
 running reliably, it's been a joy to use. Leaps and bounds above my
 former mutt-based system.
 
 - Ben
 
 From cworth@cworth.org  Mon Sep 28 18:57:38 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Mon, 28 Sep 2009 15:57:38 -0700
 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option.
 Message-ID: <1254178611-sup-369@yoom.home.cworth.org>
 
 For example, users that want to sign all outgoing messages by default
 can set:
 
 	:crypto_default: :sign
 
 in ~/.sup/config.yaml. Configuring an invalid value will cause a list
 of the valid values to be logged at the "error" level.
 ---
  lib/sup/horizontal-selector.rb     |    8 +++++++-
  lib/sup/modes/edit-message-mode.rb |    7 ++++++-
  2 files changed, 13 insertions(+), 2 deletions(-)
 
 diff --git a/lib/sup/horizontal-selector.rb b/lib/sup/horizontal-selector.rb
 index aef16d4..13c63ed 100644
 --- a/lib/sup/horizontal-selector.rb
 +++ b/lib/sup/horizontal-selector.rb
 @@ -12,7 +12,13 @@ class HorizontalSelector
      @selection = 0
    end
  
 -  def set_to val; @selection = @vals.index(val) end
 +  def set_to val
 +    if @vals.index(val)
 +      @selection = @vals.index(val)
 +    else
 +      error "Invalid option ", val.inspect, " (valid options: ", @vals.inspect, ")"
 +    end
 +  end
  
    def val; @vals[@selection] end
  
 diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
 index 8da316f..3449503 100644
 --- a/lib/sup/modes/edit-message-mode.rb
 +++ b/lib/sup/modes/edit-message-mode.rb
 @@ -89,7 +89,12 @@ EOS
        if CryptoManager.have_crypto?
          HorizontalSelector.new "Crypto:", [:none] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.keys, ["None"] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.values
        end
 -    add_selector @crypto_selector if @crypto_selector
 +    if @crypto_selector
 +      if !$config[:crypto_default].nil?
 +        @crypto_selector.set_to $config[:crypto_default]
 +      end
 +      add_selector @crypto_selector
 +    end
      
      HookManager.run "before-edit", :header => @header, :body => @body
  
 -- 
 1.6.4.3
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 190 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090928/cc5a4c98/attachment.bin>
 
 From michael+sup@stapelberg.de  Tue Sep 29 14:43:09 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Tue, 29 Sep 2009 20:43:09 +0200
 Subject: [sup-talk] [BUG] [PATCH] Encrypted messages without signature
 	generate an exception
 Message-ID: <1254249719-sup-3652@midna.zekjur.net>
 
 Hi,
 
 when viewing (or replying to) an encrypted message without a signature,
 sup throws an exception because of a nil chunk. I?ve attached a patch
 which fixes the issue by instead providing a message stating that this
 mail is not signed.
 
 Best regards,
 Michael
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Bugfix-Display-a-notice-when-a-mail-is-not-signed.patch
 Type: application/octet-stream
 Size: 1212 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090929/1351e062/attachment.obj>
 
 From stettberger@dokucode.de  Tue Sep 29 14:14:58 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Tue, 29 Sep 2009 20:14:58 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 Message-ID: <1254247706-sup-2745@peer.zerties.org>
 
 Hey there,
 i am using sup now for just a few weeks and it is just amazing how
 good it works (the lack of folders iritated me a little bit at
 first).
 
 But now to my Request, i would like to have something like datelines
 in index mode, like:
 
 ,-----------------
 | -- Today
 | 12:23 ...
 | 23:42 ...
 | -- Yesterday
 | Yest. 9 ....
 | Yest. 4....
 | -- Last week
 | .....
 .---------------
 
 I think this would cause an bigger overview over the mails,
 especially in the inbox.
 
 I tried to implement the feature by my self, but the mapping
 beetween `curpos' and `@threads' in modes/thread-index-mode.rb made this
 a little bit hard, and i didn't know how to solve this problem
 without breaking sup. Perhaps you can give me a hint, how this
 problem with the direct mapping can be solved.
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 11:16:35 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 08:16:35 -0700
 Subject: [sup-talk] Why inbox-mode instead of default search?
 In-Reply-To: <1254074517-sup-4465@kronos>
 References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net>
 	<1254074517-sup-4465@kronos>
 Message-ID: <1254323181-sup-1735@masanjin.net>
 
 Reformatted excerpts from William Erik Baxter's message of 2009-09-27:
 > Both modes support archive and kill in some form.  So I don't
 > understand how this argues for splitting as opposed to consolidating
 > the two modes.
 
 How does the notion of killing a thread that makes sense except in the
 context of having an special inbox mode?
 
 > The need for preallocated, special-purpose labels like
 > inbox and killed seems clear enough.  However, minimizing the amount
 > of magical behavior they exhibit also seems beneficial, if only for
 > the sake of consistency.  Treating the inbox as something other than
 > an ordinary label search is magical.
 
 The inbox is magical, because you do different things with your inbox
 than you do with non-inbox buffers: you classify threads into a) I'm
 done with this thread for now, but let me know if someone replies
 (archive); b) I'm done with this thread for now and don't let me know if
 someone replies (kill); c) I'll deal with this later (ignore).
 
 > A patch to add this command to inbox-mode appears in the August sup-talk
 > archive.  I would like to see this feature become part of the base system.
 
 I agree.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Wed Sep 30 12:12:35 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 30 Sep 2009 09:12:35 -0700
 Subject: [sup-talk] Why inbox-mode instead of default search?
 In-Reply-To: <1254323181-sup-1735@masanjin.net>
 References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net>
 	<1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net>
 Message-ID: <1254326318-sup-904@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Wed Sep 30 08:16:35 -0700 2009:
 > How does the notion of killing a thread that makes sense except in the
 > context of having an special inbox mode?
 
 The kill-thread notion can be handled in multiple ways without a
 special inbox mode.
 
 One way would be to simply not apply the inbox label to new messages
 belonging to killed threads.
 
 A better way would be to expand the search capability to something like:
 
   Search for all threads containing messages matching <include-condition>
   AND exclude all threads containing messages matching <exclude-condition>
 
 I'd be happy to have that kind of functionality for arbitrary labels
 that would function like killed for specific searches.
 
 > The inbox is magical, because you do different things with your inbox
 > than you do with non-inbox buffers: you classify threads into a) I'm
 > done with this thread for now, but let me know if someone replies
 > (archive); b) I'm done with this thread for now and don't let me know if
 > someone replies (kill); c) I'll deal with this later (ignore).
 
 It's definitely true that reading new mail is a different activity
 than searching old mail, (note my recent patch that provides different
 sort orders for these two operations).
 
 But there are at least two problems with the current inbox mode
 implemented separately from the search mode:
 
 1. Some functionality appears in only one or the other of the modes.
 
    Refine search is the easy-to-notice one that we've talked
    about. But really, any keybindings performing distinct actions in
    these two modes is just confusing. The two modes are far too
    similar to have independent lists of possible actions and
    bindings. This should be unified.
 
 2. There are some things that are currently implemented as "magic" in
    inbox mode that should really be made available to all searches.
 
    Things like the archive operation making a message disappear from
    the inbox. Instead, any operation making a message no longer
    satisfy the current search should cause it to disappear from the
    current view.
 
 > > A patch to add this command to inbox-mode appears in the August sup-talk
 > > archive.  I would like to see this feature become part of the base system.
 > 
 > I agree.
 
 One shortcoming of that patch is that refined versions of the inbox
 come up in search-results-mode, not inbox-mode. So you don't actually
 get what you want yet, (such as archiving no longer works the same in
 a refined inbox as it does in the raw inbox).
 
 Or said another way, you would get exactly what you want if there was
 nothing magic about inbox.
 
 -Carl
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 190 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/1641d2ef/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Wed Sep 30 13:47:53 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 30 Sep 2009 13:47:53 -0400
 Subject: [sup-talk] Why inbox-mode instead of default search?
 In-Reply-To: <1254326318-sup-904@yoom.home.cworth.org>
 References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net>
 	<1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net>
 	<1254326318-sup-904@yoom.home.cworth.org>
 Message-ID: <1254331067-sup-9065@zyrg.net>
 
 Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009:
 > Or said another way, you would get exactly what you want if there was
 > nothing magic about inbox.
 
 I've been working on a patch to do this. You can see the current state
 at http://github.com/rlane/sup/tree/personal/. It's still buggy and
 needs to be cleaned up a lot before I submit it. The basic idea is that
 ThreadSet becomes tightly coupled to the Index and stays in sync with
 it. This lets us use the index to determine whether a message is
 relevant to a query, which was the main cause of magic previously. It
 also makes ThreadIndexMode much simpler in general resulting in a net
 code reduction. 
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 14:04:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 11:04:52 -0700
 Subject: [sup-talk] Why inbox-mode instead of default search?
 In-Reply-To: <1254331067-sup-9065@zyrg.net>
 References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net>
 	<1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net>
 	<1254326318-sup-904@yoom.home.cworth.org>
 	<1254331067-sup-9065@zyrg.net>
 Message-ID: <1254333819-sup-408@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-30:
 > This lets us use the index to determine whether a message is relevant
 > to a query, which was the main cause of magic previously. It also
 > makes ThreadIndexMode much simpler in general resulting in a net code
 > reduction.
 
 Now you're talking my language. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 14:17:55 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 11:17:55 -0700
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1254247706-sup-2745@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 Message-ID: <1254334371-sup-5145@masanjin.net>
 
 Reformatted excerpts from Christian Dietrich's message of 2009-09-29:
 > i am using sup now for just a few weeks and it is just amazing how
 > good it works (the lack of folders iritated me a little bit at
 > first).
 
 Welcome!
 
 > But now to my Request, i would like to have something like datelines
 > in index mode, like:
 
 Cool idea. I'd like to see how this looks.
 
 > I tried to implement the feature by my self, but the mapping beetween
 > `curpos' and `@threads' in modes/thread-index-mode.rb made this a
 > little bit hard, and i didn't know how to solve this problem without
 > breaking sup. Perhaps you can give me a hint, how this problem with
 > the direct mapping can be solved.
 
 If you look at #regen_text, @text and @lines are the two variables that
 control the display. @text is an array of the GUI elements for each line
 of the display. Right now it's just set to one line for each thread. You
 want to add one additional element at the appropriate position. for each
 date line. GUI elements are represented as arrays of [color, text]
 pairs; you can look at #text_for_thread_at for an example.
 
 Then, you want to make sure that @lines is set correctly. @lines is a
 map (hash) from line number to thread (so that when the user presses a
 key, we know which thread the cursor is resting on).
 
 Hope that helps.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 14:21:46 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 11:21:46 -0700
 Subject: [sup-talk] sup 0.9 pre-release checkin
 In-Reply-To: <1253989249-sup-3372@masanjin.net>
 References: <1253989249-sup-3372@masanjin.net>
 Message-ID: <1254334862-sup-8690@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-09-26:
 > If there's anything obviously missing, or obviously wrong with the
 > state of git master, now's a good time to point it out!
 
 I've just made a few more bugfix changes, so I'm giving this another day
 of baking.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Wed Sep 30 14:55:30 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Wed, 30 Sep 2009 20:55:30 +0200
 Subject: [sup-talk] sup 0.9 pre-release checkin
 In-Reply-To: <1254334862-sup-8690@masanjin.net>
 References: <1253989249-sup-3372@masanjin.net>
 	<1254334862-sup-8690@masanjin.net>
 Message-ID: <1254336855-sup-2395@midna.zekjur.net>
 
 Hi William,
 
 Excerpts from William Morgan's message of Mi Sep 30 20:21:46 +0200 2009:
 > I've just made a few more bugfix changes, so I'm giving this another day
 > of baking.
 I am not sure if you have not noticed my patch, but in any case I would like
 to see it in 0.9:
 
 http://rubyforge.org/pipermail/sup-talk/2009-September/003189.html
 
 It fixes a crash when opening PGP encrypted (but not signed) emails.
 
 Best regards,
 Michael
 
 From cworth@cworth.org  Wed Sep 30 15:12:45 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Wed, 30 Sep 2009 12:12:45 -0700
 Subject: [sup-talk] Why inbox-mode instead of default search?
 In-Reply-To: <1254331067-sup-9065@zyrg.net>
 References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net>
 	<1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net>
 	<1254326318-sup-904@yoom.home.cworth.org>
 	<1254331067-sup-9065@zyrg.net>
 Message-ID: <1254337861-sup-4368@yoom.home.cworth.org>
 
 Excerpts from Rich Lane's message of Wed Sep 30 10:47:53 -0700 2009:
 > Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009:
 > > Or said another way, you would get exactly what you want if there was
 > > nothing magic about inbox.
 > 
 > I've been working on a patch to do this. You can see the current state
 > at http://github.com/rlane/sup/tree/personal/. It's still buggy and
 > needs to be cleaned up a lot before I submit it.
 
 Very nice stuff, Rich!
 
 It's great to see this coming along so far already.
 
 Please let me know if there are specific bugs or issues you'd like
 help fixing, and I'll be glad to try out where I can. Or even if there
 are just specific things you'd like tested---I'm not too afraid of
 running half-baked sup branches. :-)
 
 -Carl
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 236 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/c996cd28/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 15:33:34 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 12:33:34 -0700
 Subject: [sup-talk] sup 0.9 pre-release checkin
 In-Reply-To: <1254336855-sup-2395@midna.zekjur.net>
 References: <1253989249-sup-3372@masanjin.net>
 	<1254334862-sup-8690@masanjin.net>
 	<1254336855-sup-2395@midna.zekjur.net>
 Message-ID: <1254339174-sup-648@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-30:
 > http://rubyforge.org/pipermail/sup-talk/2009-September/003189.html
 > 
 > It fixes a crash when opening PGP encrypted (but not signed) emails.
 
 Can you please try the branch i-suck?
 
 About five patches later, I've come in a full circle with this bit of
 code.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 15:40:32 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 12:40:32 -0700
 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state
 In-Reply-To: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1254339542-sup-886@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-13:
 > Refactor index_message so that we do the minimal amount of work based
 > on what state the user has modified.
 
 Branch xapian-message-state, merged into next. Thanks!
 
 BTW I'm excited about the direction this is going. State changes on
 large numbers of messages seem significantly faster with this.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Wed Sep 30 15:53:03 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Wed, 30 Sep 2009 21:53:03 +0200
 Subject: [sup-talk] sup 0.9 pre-release checkin
 In-Reply-To: <1254339174-sup-648@masanjin.net>
 References: <1253989249-sup-3372@masanjin.net>
 	<1254334862-sup-8690@masanjin.net>
 	<1254336855-sup-2395@midna.zekjur.net>
 	<1254339174-sup-648@masanjin.net>
 Message-ID: <1254340355-sup-5292@midna.zekjur.net>
 
 Hi William,
 
 Excerpts from William Morgan's message of Mi Sep 30 21:33:34 +0200 2009:
 > Can you please try the branch i-suck?
 > 
 > About five patches later, I've come in a full circle with this bit of
 > code.
 Hehe. Yes, the version in this branch works.
 
 Thanks for fixing it,
 Best regards,
 Michael
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 15:56:55 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 12:56:55 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1252004504-sup-3189@javelin>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net>
 	<1252004504-sup-3189@javelin>
 Message-ID: <1254339746-sup-79@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-09-03:
 > > What if you just delete messages in the the third condition?
 > 
 > Then replies show up. :-)
 
 I am still thinking about this, BTW. I think solution will either be:
 treat deleted like killed for the purposes of inbox-mode (so a thread
 with at least one deleted message will just never appear in inbox-mode),
 or have a combined delete-and-kill command.
 
 FWIW, I believe Gmail will pull a thread with a deleted message back
 into the inbox if someone replies.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Wed Sep 30 16:01:33 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Wed, 30 Sep 2009 22:01:33 +0200
 Subject: [sup-talk] [PATCH] Save all attachments to a folder
 Message-ID: <1254340829-sup-2273@midna.zekjur.net>
 
 Hi,
 
 I finally implemented saving all attachments of a message to a folder. Please
 review and test this patch, I would be happy if we could merge it into
 mainline.
 
 Best regards,
 Michael
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Implement-saving-all-attachments-to-a-folder-keybind.patch
 Type: application/octet-stream
 Size: 2438 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/5873ce53/attachment.obj>
 
 From ezyang@MIT.EDU  Wed Sep 30 16:05:28 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Wed, 30 Sep 2009 16:05:28 -0400
 Subject: [sup-talk] [PATCH] Save all attachments to a folder
 In-Reply-To: <1254340829-sup-2273@midna.zekjur.net>
 References: <1254340829-sup-2273@midna.zekjur.net>
 Message-ID: <1254341104-sup-4958@javelin>
 
 Excerpts from Michael Stapelberg's message of Wed Sep 30 16:01:33 -0400 2009:
 > I finally implemented saving all attachments of a message to a folder. Please
 > review and test this patch, I would be happy if we could merge it into
 > mainline.
 
 +1 for this functionality.  Haven't looked at the patch; I'll let
 William do that. :-)
 
 Cheers,
 Edward
 
 From rlane@club.cc.cmu.edu  Wed Sep 30 16:16:53 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 30 Sep 2009 16:16:53 -0400
 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state
 In-Reply-To: <1254339542-sup-886@masanjin.net>
 References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1254339542-sup-886@masanjin.net>
 Message-ID: <1254341186-sup-4357@zyrg.net>
 
 Excerpts from William Morgan's message of Wed Sep 30 15:40:32 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-09-13:
 > > Refactor index_message so that we do the minimal amount of work based
 > > on what state the user has modified.
 > 
 > Branch xapian-message-state, merged into next. Thanks!
 > 
 > BTW I'm excited about the direction this is going. State changes on
 > large numbers of messages seem significantly faster with this.
 
 They're about 3 times faster on my machine with this patch. An
 optimization the Xapian devs have been planning to make (and that this
 patch is necessary to take advantage of) should increase performance
 much more.
 
 From michael+sup@stapelberg.de  Wed Sep 30 16:43:13 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Wed, 30 Sep 2009 22:43:13 +0200
 Subject: [sup-talk] [PATCH] When providing a wildcard as file for an
 	attachment, correctly expand it
 Message-ID: <1254343324-sup-7275@midna.zekjur.net>
 
 Hi,
 
 the attached patch will expand wildcards given as filename when adding
 attachments to a message. Thus, you can now add ~/work/foo/* at once.
 
 As with the last patch, please review, test and merge.
 
 Best regards,
 Michael
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-When-providing-a-wildcard-as-file-for-an-attachment-.patch
 Type: application/octet-stream
 Size: 1050 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/03cfa6ab/attachment.obj>
 
 From kevinr@free-dissociation.com  Wed Sep 30 16:54:21 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Wed, 30 Sep 2009 16:54:21 -0400
 Subject: [sup-talk] [PATCH] Save all attachments to a folder
 In-Reply-To: <1254340829-sup-2273@midna.zekjur.net>
 References: <1254340829-sup-2273@midna.zekjur.net>
 Message-ID: <1254343903-sup-2789@black-opal.mit.edu>
 
 Excerpts from Michael Stapelberg's message of Wed Sep 30 16:01:33 -0400 2009:
 > Hi,
 > 
 > I finally implemented saving all attachments of a message to a folder. Please
 > review and test this patch, I would be happy if we could merge it into
 > mainline.
 > 
 
 +1.  And what do you know, I hadn't noticed the :default_attachment_save_dir: 
 config option and had set myself a to-do list item to implement that, so now I
 don't have to, and thanks for drawing it to my attention!
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 http://free-dissociation.com
 
 From wmorgan-sup@masanjin.net  Wed Sep 30 17:21:01 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 30 Sep 2009 14:21:01 -0700
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <20090916172340.GA20566@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 Message-ID: <1254345607-sup-2358@masanjin.net>
 
 Reformatted excerpts from Ben Gamari's message of 2009-09-16:
 > Well, after several attempts at rebuilding my index, I finally got
 > lucky and sup-sync ran to completion. Unfortunately, sup now fails to
 > even start, failing out with the following exception while loading
 > threads for inbox-mode,
 
 Hey, I just started seeing this too, Xapian only. I think I've fixed in
 master.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Wed Sep 30 18:08:39 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Thu, 01 Oct 2009 00:08:39 +0200
 Subject: [sup-talk] [PATCH] more inline GPG madness
 Message-ID: <1254348163-sup-6170@midna.zekjur.net>
 
 Hi,
 
 browsing some older emails, I noticed that the inline GPG patch I sent earlier
 was not completely correct. It only handled messages which were encrypted *and*
 signed, but not messages which were signed only.
 
 Attached comes a patch which fixes the behaviour. However (!) the patch is not
 well aligned, the error case (else) is untested and should probably be handled
 differently and the old_charset line can probably be written more elegantly in
 ruby. By the way, the charset stuff is necessary to get the correct character
 set for messages which are sent inline. I really start to dislike Thunderbird
 and other crappy software for that :-\.
 
 So, please, clean up the patch and merge it. I have also attached a message
 which was sent using thunderbird and contains inline crypto. If the patch works
 correctly, you should be able to open it and see some umlauts.
 
 Best regards,
 Michael
 -------------- next part --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: sign.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/f9f6851c/attachment.txt>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: inline-gpg.patch
 Type: application/octet-stream
 Size: 1394 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/f9f6851c/attachment.obj>
 
 From mailinglist@flasht.de  Wed Sep 30 19:30:54 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 01 Oct 2009 01:30:54 +0200
 Subject: [sup-talk] i18n?
 Message-ID: <1254353101-sup-1021@thinkpad-ubuntu>
 
 Hi,
 
 are there any plans on doing some internationalization?  If not, would
 people like to have something like this, now that I have mentioned it? ;)
 
 I guess something yaml-based could work, there are some good libraries
 out there afaik.
 
 Why this came to my mind: I usually write mails in german and english
 and have done a custom patch to check for the german word for
 "attachment" to warn me before sending an email, if I haven't yet
 added an attachment to a composed mail. This obviously works for
 english right now, but I wanted to have a similar feature in german.
 Since adding language specific options all over the code really isn't
 the right way, maybe having some kind of language packs would be
 nice. I could take care of some german translation (and I suppose I'm
 not the only one on this list ;))
 
 Cheers,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 902 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/d6569555/attachment.bin>