sup

community/pipermail-archives/sup-talk/2009-10.txt (325942B) - raw

 From nicolas.pouillard@gmail.com  Thu Oct  1 03:36:00 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Thu, 01 Oct 2009 09:36:00 +0200
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1254339746-sup-79@masanjin.net>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net>
 	<1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net>
 Message-ID: <1254382434-sup-4435@peray>
 
 Excerpts from William Morgan's message of Wed Sep 30 21:56:55 +0200 2009:
 > 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.
 
 Yes I think so (and merely hope so).
 
 Notice that while GMail do not have the kill thread feature, Google Wave does
 have a "mute this thread" button, that will cause these threads to no longer
 appear in the inbox, however you can still search for is:mute threads.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 09:34:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 06:34:50 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1254382434-sup-4435@peray>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net>
 	<1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net>
 	<1254382434-sup-4435@peray>
 Message-ID: <1254404057-sup-2374@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01:
 > Notice that while GMail do not have the kill thread feature
 
 I think it does (but it didn't always). They also call it "mute".
 http://mail.google.com/support/bin/answer.py?hl=en&answer=47787
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 09:43:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 06:43:48 -0700
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1254160696-sup-3522@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 	<1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop>
 Message-ID: <1254404181-sup-8448@masanjin.net>
 
 Reformatted excerpts from Ben Gamari's message of 2009-09-28:
 > 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?
 
 Maybe someone who uses offlineimap can comment on this. In the worst
 case, I'm sure the patch wouldn't be too hard.
 
 > This actually brings up a larger question. How difficult would it be
 > to relax sup's assumption that sources are add-only?
 
 It's not difficult per se, it just requires scanning over the entire
 source, which is slow. Removing this assumption would be tantamount to
 running sup-sync -c every time you start up sup.
 
 Here's the idea: scanning over a mailstore is slow. Much of this
 slowness is due to Ruby. So let's rewrite this code in C. Then we would
 have something as fast as, say, Mutt. But Mutt bogs down on my mbox file
 because it's too big. So my *only* reasonable choice with a large
 mailstore is Sup and the assumption that the source is add only.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 09:46:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 06:46:20 -0700
 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state
 In-Reply-To: <1254341186-sup-4357@zyrg.net>
 References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1254339542-sup-886@masanjin.net> <1254341186-sup-4357@zyrg.net>
 Message-ID: <1254404707-sup-9253@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-09-30:
 > 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.
 
 Awesome. Out of curiousity, what's the optimization?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 09:49:54 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 06:49:54 -0700
 Subject: [sup-talk] Bug: Converting the index to xapian fails with a
 	message with very old date
 In-Reply-To: <1254001080-sup-5742@midna.zekjur.net>
 References: <1253475875-sup-5119@midna.zekjur.net>
 	<1253973258-sup-3347@masanjin.net>
 	<1254001080-sup-5742@midna.zekjur.net>
 Message-ID: <1254404956-sup-6574@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-26:
 > 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'
 
 At this point I'm hoping that Rich will chime in. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Thu Oct  1 10:07:01 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Thu, 1 Oct 2009 16:07:01 +0200
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1254404057-sup-2374@masanjin.net>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net>
 	<1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net>
 	<1254382434-sup-4435@peray> <1254404057-sup-2374@masanjin.net>
 Message-ID: <cd67f63a0910010707q620016bwb899095fb6a50765@mail.gmail.com>
 
 On Thu, Oct 1, 2009 at 3:34 PM, William Morgan <wmorgan-sup at masanjin.net> wrote:
 > Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01:
 >> Notice that while GMail do not have the kill thread feature
 >
 > I think it does (but it didn't always). They also call it "mute".
 > http://mail.google.com/support/bin/answer.py?hl=en&answer=47787
 
 The name and semantics seems just great.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From gregor@hoffleit.de  Thu Oct  1 11:47:17 2009
 From: gregor@hoffleit.de (Gregor Hoffleit)
 Date: Thu, 01 Oct 2009 17:47:17 +0200
 Subject: [sup-talk] Bug: store_message writes invalid From lines with
 	locales set
 Message-ID: <1254411555-sup-7650@sam>
 
 Obviously store_message uses the current locale settings to dump the
 date into the From line (loader.rb, line 179):
 
       f.puts "From #{from_email} #{date.utc}"
 
 The result: Using LANG=de_DE, sup crashed on me today when I had sent my
 first mail of October. Problem was that sup failed to grok the localized
 abbreviated month name ("Okt") in the From line:
 
     From gregor at hoffleit.de Do Okt 01 14:39:43 UTC 2009
 
 which in turn was written by loader.rb (eat your own food, you know).
 
 Everything worked fine for me in August and September, since those month
 names are spelled the same in German and English ;-).
 
 
 Regards,
     Gregor Hoffleit
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 12:38:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 09:38:36 -0700
 Subject: [sup-talk] Bug: store_message writes invalid From lines with
 	locales set
 In-Reply-To: <1254411555-sup-7650@sam>
 References: <1254411555-sup-7650@sam>
 Message-ID: <1254414095-sup-8087@masanjin.net>
 
 Reformatted excerpts from Gregor Hoffleit's message of 2009-10-01:
 >       f.puts "From #{from_email} #{date.utc}"
 
 Whoops. That should be date.rfc2822. I've fixed in git and this will go
 out in 0.9.
 
 > Everything worked fine for me in August and September, since those
 > month names are spelled the same in German and English ;-).
 
 You expect your email client to work for more than two months a year?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 12:44:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 09:44:43 -0700
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254353101-sup-1021@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 Message-ID: <1254415145-sup-635@masanjin.net>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-09-30:
 > 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 have no immediate plans personally, but I would love to have this in
 Sup.
 
 > I guess something yaml-based could work, there are some good libraries
 > out there afaik.
 
 There is a Ruby-Gettext package, which we already use for other reasons.
 I think this is probably the best thing to start with, unless it turns
 out to be too hard to use, in which case we could consider a custom
 solution.
 
 http://www.yotabanana.com/hiki/ruby-gettext.html
 
 > I could take care of some german translation (and I suppose I'm not
 > the only one on this list ;))
 
 I know we have a fair amount of German and French representation on the
 list, and that's probably representative of the user population in
 general. So you should have an appreciative audience.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 12:53:15 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 09:53:15 -0700
 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode
 In-Reply-To: <1252789445-30193-1-git-send-email-gigabo@gmail.com>
 References: <1252789445-30193-1-git-send-email-gigabo@gmail.com>
 Message-ID: <1254415913-sup-6275@masanjin.net>
 
 Reformatted excerpts from Bo Borgerson's message of 2009-09-12:
 > Register label-list-mode with the UpdateManager and handle added
 > updates with a reload to keep unread message counts up to date
 
 Branch label-list-mode-auto-update, merged into next. I'm a little
 concerned with performance, but we'll see how it goes.
 
 What do you think about handling labeled and deleted updates as well?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 12:54:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 09:54:48 -0700
 Subject: [sup-talk] [PATCH] Add command for polling unusual sources
 In-Reply-To: <1252852715-9601-1-git-send-email-gigabo@gmail.com>
 References: <1252852715-9601-1-git-send-email-gigabo@gmail.com>
 Message-ID: <1254416074-sup-7585@masanjin.net>
 
 Reformatted excerpts from Bo Borgerson's message of 2009-09-13:
 > 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.
 
 Branch poll-unusual, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 12:58:16 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 09:58:16 -0700
 Subject: [sup-talk] [PATCH] Add hooks to sort and format label-list-mode
 	display.
 In-Reply-To: <1253303493-sup-288@kronos>
 References: <1253303493-sup-288@kronos>
 Message-ID: <1254416245-sup-4497@masanjin.net>
 
 Hi William,
 
 Sorry for the delay. I like this patch but I can't get it to apply
 cleanly to master. git am -3 complains:
 
   Did you hand edit your patch?
   It does not apply to blobs recorded in its index.
   Cannot fall back to three-way merge.
   Patch failed at 0001.
 
 If you can resubmit against a recent master, I will apply it. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Thu Oct  1 13:02:18 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 01 Oct 2009 13:02:18 -0400
 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state
 In-Reply-To: <1254404707-sup-9253@masanjin.net>
 References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1254339542-sup-886@masanjin.net> <1254341186-sup-4357@zyrg.net>
 	<1254404707-sup-9253@masanjin.net>
 Message-ID: <1254416360-sup-8957@zyrg.net>
 
 Excerpts from William Morgan's message of Thu Oct 01 09:46:20 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-09-30:
 > > 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.
 > 
 > Awesome. Out of curiousity, what's the optimization?
 
 replace_document currently deletes all the old postings and inserts new
 ones. It can be optimized to make the minimal set of modifications.
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 13:04:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 10:04:52 -0700
 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first
 In-Reply-To: <1253911610-sup-2052@yoom.home.cworth.org>
 References: <1253911610-sup-2052@yoom.home.cworth.org>
 Message-ID: <1254416597-sup-8156@masanjin.net>
 
 Hi Carl,
 
 I am interested in trying these changes but I think these patches were
 generated against a custom version of master (e.g. I see the inbox
 refine-search command in the context, which hasn't been published yet).
 Can you rebase them onto a recent non-modified master so that I can
 apply? Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 13:07:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 10:07:20 -0700
 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option.
 In-Reply-To: <1254178611-sup-369@yoom.home.cworth.org>
 References: <1254178611-sup-369@yoom.home.cworth.org>
 Message-ID: <1254416783-sup-5518@masanjin.net>
 
 I like the idea, but how about a hook instead? I think the reply-mode
 hook is exactly equivalent to this. (Which maybe I will one day rename
 to default-reply-mode.)
 
 I have a strong aversion to adding configuration options.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 13:10:12 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 10:10:12 -0700
 Subject: [sup-talk] [PATCH] When providing a wildcard as file for an
 	attachment, correctly expand it
 In-Reply-To: <1254343324-sup-7275@midna.zekjur.net>
 References: <1254343324-sup-7275@midna.zekjur.net>
 Message-ID: <1254416978-sup-2395@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-30:
 > the attached patch will expand wildcards given as filename when adding
 > attachments to a message. Thus, you can now add ~/work/foo/* at once.
 
 Branch attach-wildcards, merged into next. Thanks! This is awesome.
 
 > As with the last patch, please review, test and merge.
 
 I changed one minor thing: Dir["#{fn}"] -> Dir[fn]. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Thu Oct  1 13:13:47 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 01 Oct 2009 10:13:47 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <cd67f63a0910010707q620016bwb899095fb6a50765@mail.gmail.com>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net>
 	<1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net>
 	<1254382434-sup-4435@peray> <1254404057-sup-2374@masanjin.net>
 	<cd67f63a0910010707q620016bwb899095fb6a50765@mail.gmail.com>
 Message-ID: <1254417174-sup-3659@yoom.home.cworth.org>
 
 Excerpts from Nicolas Pouillard's message of Thu Oct 01 07:07:01 -0700 2009:
 > On Thu, Oct 1, 2009 at 3:34 PM, William Morgan <wmorgan-sup at masanjin.net> wrote:
 > > Reformatted excerpts from Nicolas Pouillard's message of 2009-10-01:
 > >> Notice that while GMail do not have the kill thread feature
 > >
 > > I think it does (but it didn't always). They also call it "mute".
 > > http://mail.google.com/support/bin/answer.py?hl=en&answer=47787
 > 
 > The name and semantics seems just great.
 
 It seems a simple, little thing. But I'm all in favor of non-violent
 metaphors in the interfaces of programs I use.
 
 -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/20091001/d6d54b07/attachment.bin>
 
 From michael+sup@stapelberg.de  Thu Oct  1 13:27:40 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Thu, 01 Oct 2009 19:27:40 +0200
 Subject: [sup-talk] [PATCH] more inline GPG madness
 In-Reply-To: <1254348163-sup-6170@midna.zekjur.net>
 References: <1254348163-sup-6170@midna.zekjur.net>
 Message-ID: <1254417896-sup-2359@midna.zekjur.net>
 
 Hi,
 
 Excerpts from Michael Stapelberg's message of Do Okt 01 00:08:39 +0200 2009:
 > 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 :-\.
 
 I am sorry for the confusion. Please do not merge this patch without close
 review if these PGP headers are valid at all. Turns out the headers were
 produced by a custom procmail rule I had forgotton about.
 
 I will instead implement support for "correct" inline GPG.
 
 Best regards,
 Michael
 
 From cworth@cworth.org  Thu Oct  1 13:31:00 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 01 Oct 2009 10:31:00 -0700
 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option.
 In-Reply-To: <1254416783-sup-5518@masanjin.net>
 References: <1254178611-sup-369@yoom.home.cworth.org>
 	<1254416783-sup-5518@masanjin.net>
 Message-ID: <1254417826-sup-6584@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Thu Oct 01 10:07:20 -0700 2009:
 > I like the idea, but how about a hook instead? I think the reply-mode
 > hook is exactly equivalent to this. (Which maybe I will one day rename
 > to default-reply-mode.)
 > 
 > I have a strong aversion to adding configuration options.
 
 I'm intrigued.
 
 What makes a hook preferable over a configuration option?
 
 I've been getting concerned watching the number of hooks in sup grow
 as each creates a maintenance burden. Either:
 
 1. All hooks are supported forever with consistent
    arguments/semantics, (which may make it more difficult to make
    changes in sup than it would be otherwise)
 
 OR:
 
 2. Hooks are not supported forever, in which case users may find that
    things just start working when upgrading.
 
 Neither of those seem options look nice to me, and both seem easy to
 avoid with configuration options.
 
 If the plan is to go with (1) I'm concerned that I don't see sup
 shipping documentation for the current possible hooks. (This applies
 to configuration options too though. I think the maintainer should
 reject patches that add either without also adding documentation to
 the standard list.[*])
 
 [*] Assuming the pre-condition of such documentation existing of
 course.
 
 On the other hand, I also dislike configuration options (and hooks,
 equally), to the extent that they might be used as an excuse to avoid
 putting the most sane and useful default functionality into sup
 itself. Obviously, this can be complicated by some people not agreeing
 on what the most sane and useful behavior is.
 
 -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/20091001/55fc7ab2/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 13:37:06 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 10:37:06 -0700
 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: <1254418612-sup-4759@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-09-30:
 > 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.
 
 Branch save-all-attachments, merged into next.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Thu Oct  1 13:38:27 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 01 Oct 2009 13:38:27 -0400
 Subject: [sup-talk] Bugfix for custom-search
 Message-ID: <1254418685-sup-6611@javelin>
 
 I think there's a slight bug in the custom-search implementation.
 Patch is here:
 
 >From cea17180933469570e9502ffa7bf67ccaa8ccfc7 Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <edwardzyang at thewritingpot.com>
 Date: Wed, 10 Jun 2009 01:42:50 -0400
 Subject: [PATCH] Fix bug in which custom-search substitutions are not used.
 
 Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
 ---
  lib/sup/ferret_index.rb |    2 +-
  lib/sup/xapian_index.rb |    2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
 index d605e8d..34dff87 100644
 --- a/lib/sup/ferret_index.rb
 +++ b/lib/sup/ferret_index.rb
 @@ -340,7 +340,7 @@ EOS
      query = {}
  
      subs = HookManager.run("custom-search", :subs => s) || s
 -    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 +    subs = subs.gsub(/\b(to|from):(\S+)\b/) do
        field, name = $1, $2
        if(p = ContactManager.contact_for(name))
          [field, p.email]
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index ab25ea0..e1cfe65 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -193,7 +193,7 @@ EOS
      query = {}
  
      subs = HookManager.run("custom-search", :subs => s) || s
 -    subs = s.gsub(/\b(to|from):(\S+)\b/) do
 +    subs = subs.gsub(/\b(to|from):(\S+)\b/) do
        field, name = $1, $2
        if(p = ContactManager.contact_for(name))
          [field, p.email]
 -- 
 1.6.4.4
 
 From cworth@cworth.org  Thu Oct  1 13:43:25 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 01 Oct 2009 10:43:25 -0700
 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first
 In-Reply-To: <1254416597-sup-8156@masanjin.net>
 References: <1253911610-sup-2052@yoom.home.cworth.org>
 	<1254416597-sup-8156@masanjin.net>
 Message-ID: <1254418822-sup-7654@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Thu Oct 01 10:04:52 -0700 2009:
 > I am interested in trying these changes but I think these patches were
 > generated against a custom version of master (e.g. I see the inbox
 > refine-search command in the context, which hasn't been published yet).
 
 Guilty as charged.
 
 > Can you rebase them onto a recent non-modified master so that I can
 > apply? Thanks!
 
 See the attached patches.
 
 And as before, the behavior is split into two commits so that you can
 decide whether to change the default or not.
 
 And there's still the one minor bug that the oldest-first mode doesn't
 actually guarantee that the oldest message is displayed first when
 newer messages arrive for an old thread.
 
 -Carl
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Allow-thread-index-view-to-sort-oldest-first.patch
 Type: application/octet-stream
 Size: 7502 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/ec87d014/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/20091001/ec87d014/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/20091001/ec87d014/attachment.bin>
 
 From bgamari.foss@gmail.com  Thu Oct  1 13:44:19 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Thu, 01 Oct 2009 13:44:19 -0400
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1254404181-sup-8448@masanjin.net>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 	<1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop>
 	<1254404181-sup-8448@masanjin.net>
 Message-ID: <1254418089-sup-5800@ben-laptop>
 
 Excerpts from William Morgan's message of Thu Oct 01 09:43:48 -0400 2009:
 > Reformatted excerpts from Ben Gamari's message of 2009-09-28:
 > > This actually brings up a larger question. How difficult would it be
 > > to relax sup's assumption that sources are add-only?
 > 
 > It's not difficult per se, it just requires scanning over the entire
 > source, which is slow. Removing this assumption would be tantamount to
 > running sup-sync -c every time you start up sup.
 > 
 > Here's the idea: scanning over a mailstore is slow. Much of this
 > slowness is due to Ruby. So let's rewrite this code in C. Then we would
 > have something as fast as, say, Mutt. But Mutt bogs down on my mbox file
 > because it's too big. So my *only* reasonable choice with a large
 > mailstore is Sup and the assumption that the source is add only.
 
 It seems that C would definitely be a good start (or perhaps C++ would
 be a better idea as that is the language in which Xapian is written).
 However, I think one of the real issues is the exclusive nature of index
 access.  In fact, this is one of my primary gripes with the sup
 workflow. After processing a large number of messages, the write-out
 time can be quite substantial upon killing the buffer. This can be a
 noticeable interruption to workflow. It seems to me that index access
 should be asynchronous at least.
 
 If this were the case, then we could get support for mutable sources for
 free, as we could synchronize against sources without interrupting
 workflow (although keeping the view in sync with the backend would be a
 bit tricky).
 
 As an aside, it would be quite nice if one could run multiple
 simultaneous instances of sup. It seems that if one only held write access
 to the index during writes (is this the case presently?), there should
 be nothing preventing this from being possible.
 
 Correct me if I'm wrong in any part of my above assessment. Hope things
 are going well,
 
 - Ben
 
 From ezyang@MIT.EDU  Thu Oct  1 13:56:12 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 01 Oct 2009 13:56:12 -0400
 Subject: [sup-talk] Configurable poll time
 Message-ID: <1254419578-sup-5569@javelin>
 
 Hey all,
 
 I know William is generally opposed to configuration values, but
 I think I've found one that would be good to do: DELAY in poll.rb.
 I specifically have had to reduce this value in order to prevent
 a naughty IMAP server from silently dropping the connection (and
 causing sup to consequently hang).
 
 I'll cook up a patch if people are receptive.
 
 Cheers,
 Edward
 
 From mailinglist@flasht.de  Thu Oct  1 14:15:50 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 01 Oct 2009 20:15:50 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254415145-sup-635@masanjin.net>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 Message-ID: <1254420802-sup-3742@thinkpad-ubuntu>
 
 Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009:
 > I have no immediate plans personally, but I would love to have this in
 > Sup.
 
 Alright, good to know.
 
 > There is a Ruby-Gettext package, which we already use for other reasons.
 > I think this is probably the best thing to start with, unless it turns
 > out to be too hard to use, in which case we could consider a custom
 > solution.
 > 
 > http://www.yotabanana.com/hiki/ruby-gettext.html
 
 Cool, I'll have a look at it.
 
 Another reason for adding this would be that for example gpg's output
 is different for me (in german) than what sup expects. So trust-paths
 for example aren't recognized by default, since the regular expression
 in crypto.rb only looks for english output. I fixed this for myself
 but I figured it would make more sense to put this kind of stuff to a
 central location.
 -- 
 ================================
 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/20091001/cf2f42a4/attachment.bin>
 
 From mailinglist@flasht.de  Thu Oct  1 14:21:48 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 01 Oct 2009 20:21:48 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254415145-sup-635@masanjin.net>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 Message-ID: <1254421306-sup-8840@thinkpad-ubuntu>
 
 Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009:
 > I have no immediate plans personally, but I would love to have this in
 > Sup.
 
 Ok, great!
 
 > There is a Ruby-Gettext package, which we already use for other reasons.
 > I think this is probably the best thing to start with, unless it turns
 > out to be too hard to use, in which case we could consider a custom
 > solution.
 > 
 > http://www.yotabanana.com/hiki/ruby-gettext.html
 
 Thanks, I'll have a look at it.
 
 Btw, another reason for adding something like this would be that sup
 depends on an english version of gpg. For checking a trust-path, for
 example, it uses a regular expression that checks for a certain output
 of gpg (in english).  Since I have a german version, this obviously
 doesn't work (I had to patch it for my needs).  I guess there probably
 are more things where different languages could play a role, so
 putting it in a central, well-defined location makes sense.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 14:22:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 11:22:44 -0700
 Subject: [sup-talk] Configurable poll time
 In-Reply-To: <1254419578-sup-5569@javelin>
 References: <1254419578-sup-5569@javelin>
 Message-ID: <1254421340-sup-4697@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-10-01:
 > I know William is generally opposed to configuration values, but I
 > think I've found one that would be good to do: DELAY in poll.rb.  I
 > specifically have had to reduce this value in order to prevent a
 > naughty IMAP server from silently dropping the connection (and causing
 > sup to consequently hang).
 
 I'd be fine with this one, especially if it were a per-source
 configuration that lived in sources.yaml.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 14:24:57 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 11:24:57 -0700
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254420802-sup-3742@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 Message-ID: <1254421405-sup-8083@masanjin.net>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-10-01:
 > Another reason for adding this would be that for example gpg's output
 > is different for me (in german) than what sup expects. So trust-paths
 > for example aren't recognized by default, since the regular expression
 > in crypto.rb only looks for english output.
 
 It will be interesting to see how gettext handles the case of regular
 expressions (which is also probably what you want for the "attachment"
 detector). If it's not natural to wedge regexen into gettext, we should
 consider a custom solution.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 14:31:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 11:31:20 -0700
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1254418089-sup-5800@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 	<1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop>
 	<1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop>
 Message-ID: <1254421545-sup-8303@masanjin.net>
 
 Reformatted excerpts from Ben Gamari's message of 2009-10-01:
 > It seems that C would definitely be a good start (or perhaps C++ would
 > be a better idea as that is the language in which Xapian is written).
 
 I was proposing that as a strawman argument. C does not solve my
 problem.
 
 > However, I think one of the real issues is the exclusive nature of
 > index access.  In fact, this is one of my primary gripes with the sup
 > workflow. After processing a large number of messages, the write-out
 > time can be quite substantial upon killing the buffer.
 
 It is possible to address this in a variety of ways, many of which have
 been discussed over the years, but yes, I agree that a delay is
 nonideal.
 
 > If this were the case, then we could get support for mutable sources
 > for free, as we could synchronize against sources without interrupting
 > workflow (although keeping the view in sync with the backend would be
 > a bit tricky).
 
 Making message state saving fast, or backgrounded, is a different beast
 from scanning over a mailstore.
 
 I have been working on a Sup server for quite some time that would
 address many of these problems, but progress is slow.
 
 > As an aside, it would be quite nice if one could run multiple
 > simultaneous instances of sup. It seems that if one only held write
 > access to the index during writes (is this the case presently?), there
 > should be nothing preventing this from being possible.
 
 It might be possible to do this with Xapian, especially if there were no
 expectation of updates being transmitted across processes. With Ferret,
 if it is possible, it's only with a tremendous amount of effort.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From mailinglist@flasht.de  Thu Oct  1 14:33:03 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 01 Oct 2009 20:33:03 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254415145-sup-635@masanjin.net>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 Message-ID: <1254421963-sup-7532@thinkpad-ubuntu>
 
 Please excuse my double posting. Sup crashed after sending a message.
 I have the exception log attached.
 Seems like it has a problem with the sent.mbox and wants me to 
       sup-sync --changed sup://sent
 
 I switched from ferret to xapian today and the error clearly happens there.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 -------------- next part --------------
 An embedded and charset-unspecified text was scrubbed...
 Name: exception-log.txt
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091001/8366e0e9/attachment.txt>
 
 From cworth@cworth.org  Thu Oct  1 14:41:59 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 01 Oct 2009 11:41:59 -0700
 Subject: [sup-talk] Writing time-sensitive portions of sup in C
 In-Reply-To: <1254418089-sup-5800@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 	<1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop>
 	<1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop>
 Message-ID: <1254421959-sup-9506@yoom.home.cworth.org>
 
 Excerpts from Ben Gamari's message of Thu Oct 01 10:44:19 -0700 2009:
 > Excerpts from William Morgan's message of Thu Oct 01 09:43:48 -0400 2009:
 > > Here's the idea: scanning over a mailstore is slow. Much of this
 > > slowness is due to Ruby. So let's rewrite this code in C. Then we would
 > > have something as fast as, say, Mutt. But Mutt bogs down on my mbox file
 > > because it's too big. So my *only* reasonable choice with a large
 > > mailstore is Sup and the assumption that the source is add only.
 > 
 > It seems that C would definitely be a good start (or perhaps C++ would
 > be a better idea as that is the language in which Xapian is written).
 
 I've started some experiments along these lines, (basically just
 writing C code (with C++ where necessary) using the Xapian tutorial
 and little peeks into sup/xapian-index.rb to get the right prefix
 values, etc.).
 
 > However, I think one of the real issues is the exclusive nature of index
 > access.  In fact, this is one of my primary gripes with the sup
 > workflow. After processing a large number of messages, the write-out
 > time can be quite substantial upon killing the buffer. This can be a
 > noticeable interruption to workflow. It seems to me that index access
 > should be asynchronous at least.
 
 What I'm hoping to end up with is a C library that provides
 asynchronous access to a sup-compatible index. I'll keep you posted if
 I make any actual progress on this front.
 
 -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/20091001/89e0a628/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Thu Oct  1 14:43:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Oct 2009 11:43:49 -0700
 Subject: [sup-talk] [ANN] Sup 0.9 released
 Message-ID: <1254422532-sup-9948@masanjin.net>
 
 I'm pleased to announce the release of Sup 0.9.
 
 Sup is a console-based email client for people with a lot of email.
 It supports tagging, very fast full-text search, automatic contact-
 list management, and more. If you're the type of person who treats
 email as an extension of your long-term memory, Sup is for you.
 
 Get it: gem install sup
 Learn it: http://sup.rubyforge.org
 Love it: sup-talk at rubyforge.org
 
 Excitement in 0.9:
 * Experimental Xapian backend to replace Ferret. Not everything works with it,
   but it's fast and less likely to barf. See release notes.
 * New keybinding: "G" for reply-all.
 * New hook: custom-search, for adding your own query expansions.
 * Better preemptive thread loading.
 * Random UI tweaks: display labels before subjects, change thread-view-mode's
   'n' and 'p' commands slightly
 * Better killing of other Sup processes.
 * Die gracefully upon SIGKILL.
 * Finally figure out the curses+ruby magic to make SIGWINCH (i.e. xterm
   resizing) work correctly.
 * Add a console mode (press ~) for interactively playing with the index.
 * Finally figure out the curses magic to stop the weird keyboard behavior after
   leaving the editor.
 * Improved logging. Logging now supports SUP_LOG_LEVEL environment variable.
   Set this to "debug" for verbiage.
 * As always, many bugfixes and tweaks.
 
 Release notes:
 
 There's a new Xapian backend as an alternative to the Ferret one. It's still in
 a beta stage. It's much faster and much less prone to the random crashes than
 Ferret, but certain things don't work yet, most noticeably the unread message
 counts in label-list-mode.
 
 You can switch back and forth between both indexes without harm, *except* any
 new messages added to the one index won't be picked up by the other. Follow
 these instructions:
 
 To TRY the Xapian index, without screwing Ferret up:
 
 1. sup-dump > dump                              # takes a while
 2. export SUP_INDEX=xapian                      # or however you do it in your shell
 3. sup-sync --all --all-sources --restore dump  # takes a long time
 4. sup -n                # -n ensures that no polling is done. don't hit 'P' either
 
 Step 1 will take a long time, and step 3 will take a very long time.
 
 At this point, whenever you run Sup, the SUP_INDEX environment variable will
 determine which index you use. If it's unset, or "ferret", you will use the
 ferret index. If it's "xapian", the Xapian index. Make sure when you run sup
 with the Xapian index, you use -n and don't hit 'P', to avoid loading new
 messages into it.
 
 If you want to switch to Xapian permanently, you can then:
 
 1. rm -rf ~/.sup/ferret
 2. permanently set SUP_INDEX=xapian according to your shell
 3. Run sup as normal, i.e. without -n.
 
 If you want to go back to Ferret, you can just rm -rf ~/.sup/xapian and make
 sure your SUP_INDEX environment variable is unset.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Thu Oct  1 14:47:44 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 01 Oct 2009 14:47:44 -0400
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254421963-sup-7532@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254421963-sup-7532@thinkpad-ubuntu>
 Message-ID: <1254422768-sup-4646@zyrg.net>
 
 Excerpts from Christopher Bertels's message of Thu Oct 01 14:33:03 -0400 2009:
 > undefined method `[]' for nil:NilClass
 > /home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:558:in `mkterm'
 
 What commit is your tree at?
 
 From bgamari.foss@gmail.com  Thu Oct  1 14:45:20 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Thu, 01 Oct 2009 14:45:20 -0400
 Subject: [sup-talk] Crash while loading thread index buffer
 Message-ID: <1254422128-sup-970@ben-laptop>
 
 I just had this[1] crash while loading a buffer with has:lkml.
 Crash occurs in,
 
       @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse
 
 Is this perhaps the result of an index inconsistency? It seems to me
 that t.first should never be nil. Seems like sup is very susceptible to
 these nils slipping in unexpectedly. Is there perhaps a better way to
 deal with it other than crashing the client? Seems like a pretty extreme
 measure (although granted, it's a pretty serious issue as well)
 
 - Ben
 
 
 [1] Exception log
 
 --- 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'
 /opt/exp/sup/lib/sup/hook.rb:121: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/modes/label-search-results-mode.rb:33:in `spawn_nicely'
 /opt/exp/sup/lib/sup/modes/label-list-mode.rb:93:in `select_label'
 /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 bgamari.foss@gmail.com  Thu Oct  1 15:01:35 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Thu, 01 Oct 2009 15:01:35 -0400
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1254421545-sup-8303@masanjin.net>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 	<1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop>
 	<1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop>
 	<1254421545-sup-8303@masanjin.net>
 Message-ID: <1254422805-sup-9288@ben-laptop>
 
 Excerpts from William Morgan's message of Thu Oct 01 14:31:20 -0400 2009:
 > Reformatted excerpts from Ben Gamari's message of 2009-10-01:
 > > It seems that C would definitely be a good start (or perhaps C++ would
 > > be a better idea as that is the language in which Xapian is written).
 > 
 > I was proposing that as a strawman argument. C does not solve my
 > problem.
 
 Certainly, you will never be able to write a message indexer fast enough
 to index a source instantly. That is why we have an index to begin with.
 That being said, I think we can do substantially better than we are
 currently doing in a lower-level language. With mutt, I can come close
 to saturating my drive bandwidth while loading a folder. While
 synchronizing in sup, I am lucky to get a few hundred kilobytes/second.
 Certainly a large amount of that difference has to do with the amount of
 processing done by each, but even adjusting for this it seems to me that
 we should still be I/O bound (or at least close to it).
 
 > 
 > > However, I think one of the real issues is the exclusive nature of
 > > index access.  In fact, this is one of my primary gripes with the sup
 > > workflow. After processing a large number of messages, the write-out
 > > time can be quite substantial upon killing the buffer.
 > 
 > It is possible to address this in a variety of ways, many of which have
 > been discussed over the years, but yes, I agree that a delay is
 > nonideal.
 
 Glad we agree.
 
 > 
 > Making message state saving fast, or backgrounded, is a different beast
 > from scanning over a mailstore.
 
 If we are unable to update the index while the client is active,
 rescanning sources would destroy usability. I would argue that
 asynchronous writeout is very much a prerequisite for mutable sources.
 
 > 
 > I have been working on a Sup server for quite some time that would
 > address many of these problems, but progress is slow.
 
 This was largely what I had in mind. It seems like moving index
 manipulation out-of-process might be best, ultimately.
 
 > 
 > > As an aside, it would be quite nice if one could run multiple
 > > simultaneous instances of sup. It seems that if one only held write
 > > access to the index during writes (is this the case presently?), there
 > > should be nothing preventing this from being possible.
 > 
 > It might be possible to do this with Xapian, especially if there were no
 > expectation of updates being transmitted across processes.
 
 I think initially no updates between processes would be fine.
 > With Ferret,
 > if it is possible, it's only with a tremendous amount of effort.
 
 Is ferret even going to be supported after the Xapian backend
 stabilizes?
 
 Thanks for the comments and sup.
 
 - Ben
 
 From mailinglist@flasht.de  Thu Oct  1 20:19:35 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Fri, 02 Oct 2009 02:19:35 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254421405-sup-8083@masanjin.net>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 Message-ID: <1254442420-sup-3771@thinkpad-ubuntu>
 
 Excerpts from William Morgan's message of Do Okt 01 20:24:57 +0200 2009:
 > It will be interesting to see how gettext handles the case of regular
 > expressions (which is also probably what you want for the "attachment"
 > detector). If it's not natural to wedge regexen into gettext, we should
 > consider a custom solution.
 
 Hmm. Well I started working on something simple based on yaml files.
 I looked at gettext but that seemed a little weird to me.  Since
 Ruby's yaml module supports regular expressions, this is a plus point,
 I guess. It worked with the attachments example.
 -- 
 ================================
 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/20091002/9c56d49e/attachment.bin>
 
 From olly@survex.com  Fri Oct  2 03:57:55 2009
 From: olly@survex.com (Olly Betts)
 Date: Fri, 2 Oct 2009 07:57:55 +0000 (UTC)
 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state
 References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1254339542-sup-886@masanjin.net> <1254341186-sup-4357@zyrg.net>
 	<1254404707-sup-9253@masanjin.net> <1254416360-sup-8957@zyrg.net>
 Message-ID: <slrnhcbck3.5ah.olly@msgid.survex.com>
 
 On 2009-10-01, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > Excerpts from William Morgan's message of Thu Oct 01 09:46:20 -0400 2009:
 >> Reformatted excerpts from Rich Lane's message of 2009-09-30:
 >> > 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.
 >> 
 >> Awesome. Out of curiousity, what's the optimization?
 >
 > replace_document currently deletes all the old postings and inserts new
 > ones. It can be optimized to make the minimal set of modifications.
 
 This is the ticket for it:
 
 http://trac.xapian.org/ticket/250
 
 Cheers,
     Olly
 
 
 From gregor@hoffleit.de  Fri Oct  2 05:25:04 2009
 From: gregor@hoffleit.de (Gregor Hoffleit)
 Date: Fri, 02 Oct 2009 11:25:04 +0200
 Subject: [sup-talk] Bug: store_message writes invalid From lines with
 	locales set
 In-Reply-To: <1254414095-sup-8087@masanjin.net>
 References: <1254411555-sup-7650@sam> <1254414095-sup-8087@masanjin.net>
 Message-ID: <1254475145-sup-5397@sam>
 
 * William Morgan <wmorgan-sup at masanjin.net> [Thu Oct 01 18:38:36 +0200 2009]
 > > Everything worked fine for me in August and September, since those
 > > month names are spelled the same in German and English ;-).
 > 
 > You expect your email client to work for more than two months a year?
 
 Ok. I admit the right way to fix this would have been to take a time of
 absence in the months of March, May, October and December. Should have
 thought about that before complaining ;-).
 
 Thanks for the quick fix,
     Gregor
 
 From mailinglist@flasht.de  Fri Oct  2 08:52:47 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Fri, 02 Oct 2009 14:52:47 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254442420-sup-3771@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 Message-ID: <1254487575-sup-5468@thinkpad-ubuntu>
 
 I've uploaded what I've done so far to
 http://www.gitorious.org/~bakkdoor/sup/bakkdoors-clone/trees/i18n 
 You can get it via git here:
 git://gitorious.org/~bakkdoor/sup/bakkdoors-clone.git (branch: i18n)
 
 Please tell me what you think. I know it's pretty simple but for now I
 guess that's all we need. Or am I missing something?  
 
 One thing I wanted to add as well is, that if there is no translation
 found for a different language, it will default to the english version
 (instead of returning nil).
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 
 From rlane@club.cc.cmu.edu  Fri Oct  2 16:35:42 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 02 Oct 2009 16:35:42 -0400
 Subject: [sup-talk] Bug: Converting the index to xapian fails with a
 	message with very old date
 In-Reply-To: <1254404956-sup-6574@masanjin.net>
 References: <1253475875-sup-5119@midna.zekjur.net>
 	<1253973258-sup-3347@masanjin.net>
 	<1254001080-sup-5742@midna.zekjur.net>
 	<1254404956-sup-6574@masanjin.net>
 Message-ID: <1254513417-sup-8419@zyrg.net>
 
 Excerpts from William Morgan's message of Thu Oct 01 09:49:54 -0400 2009:
 > Reformatted excerpts from Michael Stapelberg's message of 2009-09-26:
 > > 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'
 > 
 > At this point I'm hoping that Rich will chime in. :)
 
 This strikes me as a bug in Marshal.dump - it should be able to handle
 arbitrary dates. I've never messed with custom marshalling functions
 before, but monkey patching one in could be a workaround. Or we could
 just truncate the dates before putting them in the index entry.
 
 From stettberger@dokucode.de  Fri Oct  2 16:48:24 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Fri, 02 Oct 2009 22:48:24 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1254334371-sup-5145@masanjin.net>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 Message-ID: <1254516195-sup-4619@peer.zerties.org>
 
 Excerpts from William Morgan's message of Mi Sep 30 20:17:55 +0200 2009:
 > 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).
 
 Thank you, that helped a much. I implemented the feature, it is
 available at git://github.com/stettberger/sup-mail.git
 branch time_marks, it is one commit ahead of next. It is enabled
 with setting the config option ":time_markers_in_index_mode: true"
 At runtime it can be toggled via '%' (just randomly choosen by me)
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From eg@gaute.vetsj.com  Sat Oct  3 06:36:39 2009
 From: eg@gaute.vetsj.com (gauteh)
 Date: Sat, 3 Oct 2009 03:36:39 -0700 (PDT)
 Subject: [sup-talk]  Bug: Xapian exception after having polled
 Message-ID: <25727581.post@talk.nabble.com>
 
 
 Greetings,
 
 Sup fails with the attached backtrace right after having polled the
 messages. The messages show up in the inbox before it fails, possibly
 failing before they are shown, but they then show up the next time, before
 the same exception happens again. It doesn't matter if I have new messages
 or not.
 
 This happenes both in f6873cee9960 and newest; 93b5552730c1
 
 I keep my messages in maildir, synced with offlineimap on a Gmail account.
 
 - gaute
 
 http://www.nabble.com/file/p25727581/exception-log.txt exception-log.txt 
 -- 
 View this message in context: http://www.nabble.com/Bug%3A-Xapian-exception-after-having-polled-tp25727581p25727581.html
 Sent from the SUP Talk mailing list archive at Nabble.com.
 
 
 From tarko@lanparty.ee  Sat Oct  3 06:31:16 2009
 From: tarko@lanparty.ee (Tarko Tikan)
 Date: Sat, 03 Oct 2009 13:31:16 +0300
 Subject: [sup-talk] labels-before-subject and ask_for_contacts config knobs
 Message-ID: <1254565800-sup-5590@lanparty.ee>
 
 hey,
 
 First, 0.9 is nice, thanks for that.
 
 I want to ask the list about a thing (2 things actually, since 0.9) that has been bugging me.
 
 ask_for_contacts is loading 10 contacts from index, imho this doesn't make a sane default (it's too low). I've always patched this to 500 on my end - yes, it takes a second or two to load that many contacts from index but this doesn't bug me as much as first looking up the person and then composing to him.
 
 second, since labels-before-subject was integrated, it's hard to follow thread index on small screen. Most of my inbox is tagged with 3 labels, mailing-list could be tagged with up to 5 labels. The problem is especially bad on very small screens (like mobiles with ssh clients).
 
 I'm tempted to submit a patch that enables to tune these behaviors via config. I don't find these hook-worthy as first is just a integer (default must stay reasonably low for people with slower computers) and second only makes sense together with full thread-index line customization (I'm not sure about the performance impact or complexity it might bring).
 
 Anyone else sharing my view or I just keep patching on my end? :)
 
 -- 
 tarko
 
 From rlane@club.cc.cmu.edu  Sat Oct  3 14:19:57 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat,  3 Oct 2009 11:19:57 -0700
 Subject: [sup-talk] [PATCH] don't downcase a nil content-type
 Message-ID: <1254593997-32634-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  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 979597a..cbedb33 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -501,7 +501,7 @@ private
          # Lowercase the filename because searches are easier that way 
          @attachments.push filename.downcase unless filename =~ /^sup-attachment-/
          add_label :attachment unless filename =~ /^sup-attachment-/
 -        content_type = m.header.content_type.downcase || "application/unknown" # sometimes RubyMail gives us nil
 +        content_type = (m.header.content_type || "application/unknown").downcase # sometimes RubyMail gives us nil
          [Chunk::Attachment.new(content_type, filename, m, sibling_types)]
  
        ## otherwise, it's body text
 -- 
 1.6.4.2
 
 
 From rlane@club.cc.cmu.edu  Sat Oct  3 14:22:34 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 03 Oct 2009 14:22:34 -0400
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <25727581.post@talk.nabble.com>
 References: <25727581.post@talk.nabble.com>
 Message-ID: <1254594099-sup-719@zyrg.net>
 
 Apply the attached patch and let us know what the new backtrace is.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: nil-msgid-asserts.patch
 Type: application/octet-stream
 Size: 1254 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091003/1c9febbc/attachment.obj>
 
 From guillaume.quintard@gmail.com  Sat Oct  3 16:04:14 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sat, 3 Oct 2009 22:04:14 +0200
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 Message-ID: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 
 Hi, I crash my computer with sup running, and it seems the index
 didn't really like. sup-sync -a didn't help, what can I do?
 
 --- RuntimeError from thread: load threads for thread-index-mode
 DocNotFoundError: Document 2461178145 not found.
 ./lib/sup/xapian_index.rb:132:in `document'
 ./lib/sup/xapian_index.rb:132:in `each_message_in_thread_for'
 ./lib/sup/xapian_index.rb:132:in `map'
 ./lib/sup/xapian_index.rb:132:in `each_message_in_thread_for'
 ./lib/sup/thread.rb:341:in `load_thread_for_message'
 ./lib/sup/thread.rb:333:in `load_n_threads'
 ./lib/sup/xapian_index.rb:117:in `each_id_by_date'
 ./lib/sup/xapian_index.rb:110:in `each_id'
 ./lib/sup/xapian_index.rb:110:in `each'
 ./lib/sup/xapian_index.rb:110:in `each_id'
 ./lib/sup/xapian_index.rb:117: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'
 bin/sup:197
 
 -- 
 Guillaume
 
 From rlane@club.cc.cmu.edu  Sat Oct  3 16:17:54 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 03 Oct 2009 16:17:54 -0400
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 In-Reply-To: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 Message-ID: <1254600926-sup-5190@zyrg.net>
 
 Excerpts from Guillaume Quintard's message of Sat Oct 03 16:04:14 -0400 2009:
 > Hi, I crash my computer with sup running, and it seems the index
 > didn't really like. sup-sync -a didn't help, what can I do?
 
 I'd hoped this kind of corruption wouldn't be possible with newer
 xapian-index versions. What sup commit are you on? What version of
 Xapian are you using? Which Xapian backend, Flint or Chert?
 
 From marco-oweber@gmx.de  Sat Oct  3 16:49:40 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Sat, 03 Oct 2009 22:49:40 +0200
 Subject: [sup-talk] next search in buffer view..
 Message-ID: <1254602805-sup-2900@nixos>
 
 
 buffer.rb
 
   def handle_input c
     if @focus_buf
       if @focus_buf.mode.in_search? && c != CONTINUE_IN_BUFFER_SEARCH_KEY[0]
         @focus_buf.mode.cancel_search!
         @focus_buf.mark_dirty
       end
       @focus_buf.mode.handle_input c
     end
   end
 
 Why is the search canceled when typing any other char?
 
 That's really annoying because there are some mails I have to use the
 same search multiple times. However I also have to scroll up /down to
 see enough context.
 
 So why has this been implemented? Is it safe to remove that if
 statement?
 Seems to work for me.
 
 
 It would be better if the next search would continue from the current
 line rather than the last search result.
 
 I'd like to see 'N' (search backward) as well.
 
 If you like these ideas I'm going to supply a patch.
 
 Comments?
 
 Marc Weber
 
 From guillaume.quintard@gmail.com  Sat Oct  3 17:06:36 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sat, 3 Oct 2009 23:06:36 +0200
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 In-Reply-To: <1254600926-sup-5190@zyrg.net>
 References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 	<1254600926-sup-5190@zyrg.net>
 Message-ID: <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com>
 
 On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > I'd hoped this kind of corruption wouldn't be possible with newer
 > xapian-index versions. What sup commit are you on? What version of
 > Xapian are you using? Which Xapian backend, Flint or Chert?
 >
 
 ubuntu 9.10
 libxapian-ruby1.8    1.0.14-1
 I'd say flink since I often have to remove flintlock after sup
 commiting suicide.
 
 and git status says
 # On branch next
 # Your branch is ahead of 'origin/next' by 6 commits.
 
 (ahead?)
 
 -- 
 Guillaume
 
 From rlane@club.cc.cmu.edu  Sat Oct  3 17:39:42 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 03 Oct 2009 17:39:42 -0400
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 In-Reply-To: <1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com>
 References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 	<1254600926-sup-5190@zyrg.net>
 	<1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com>
 Message-ID: <1254605615-sup-5636@zyrg.net>
 
 Excerpts from Guillaume Quintard's message of Sat Oct 03 17:06:36 -0400 2009:
 > On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > > I'd hoped this kind of corruption wouldn't be possible with newer
 > > xapian-index versions. What sup commit are you on? What version of
 > > Xapian are you using? Which Xapian backend, Flint or Chert?
 > >
 > 
 > ubuntu 9.10
 > libxapian-ruby1.8    1.0.14-1
 > I'd say flink since I often have to remove flintlock after sup
 > commiting suicide.
 > 
 > and git status says
 > # On branch next
 > # Your branch is ahead of 'origin/next' by 6 commits.
 > 
 > (ahead?)
 > 
 
 Please post the output of "git log --pretty=oneline 'origin/next^'.."
 
 From guillaume.quintard@gmail.com  Sat Oct  3 17:54:28 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sat, 3 Oct 2009 23:54:28 +0200
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 In-Reply-To: <1254605615-sup-5636@zyrg.net>
 References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 	<1254600926-sup-5190@zyrg.net>
 	<1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com>
 	<1254605615-sup-5636@zyrg.net>
 Message-ID: <1e5fdab70910031454n28c57ae5m1f33f10f4e4acaab@mail.gmail.com>
 
 On Sat, Oct 3, 2009 at 11:39 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > Please post the output of "git log --pretty=oneline 'origin/next^'.."
 >
 here you go
 80789d873ac555bb1979f7734e95f104d848007e Merge branch 'next' of
 git://gitorious.org/sup/mainline into next
 0eee0973223b625b66e30c196ccd45d2f7bf358b Merge branch 'master' into next
 93b5552730c10e2a352bd33f5ee98800bcd8679e more release-script updates
 d1eabf9cb21940b933464ab3efc25df3c1a5f7e1 Merge branch 'next' of
 git://gitorious.org/sup/mainline into next
 df96980d0573cf91742a8f9ae5e8a49366d338b8 Merge branch 'next' of
 git://gitorious.org/sup/mainline into next
 a6dcb02dda7dd8bb1742890d460b1b0abfc28454 Merge branch 'next' of
 git://gitorious.org/sup/mainline into next
 823148627f554fbf5a7fb13379567276eeee14c7 Merge branch 'next' of
 git://gitorious.org/sup/mainline into next
 40ecc407a8aacf16d7f9f104501311cfd1fb2eb7 Revert "Merge branch
 'after-add-message-hook' into next"
 
 
 
 -- 
 Guillaume
 
 From rlane@club.cc.cmu.edu  Sat Oct  3 18:25:19 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 03 Oct 2009 18:25:19 -0400
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 In-Reply-To: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 Message-ID: <1254607735-sup-864@zyrg.net>
 
 Excerpts from Guillaume Quintard's message of Sat Oct 03 16:04:14 -0400 2009:
 > --- RuntimeError from thread: load threads for thread-index-mode
 > DocNotFoundError: Document 2461178145 not found.
 > ./lib/sup/xapian_index.rb:132:in `document'
 
 The relevant line:
 docs = term_docids(mkterm(:thread, thread_id)).map { |x| @xapian.document x }
 
 Basically expands to:
 @xapian.postlist(term).map { |x| @xapian.document x.docid }
 
 So, Xapian is giving us docids it can't turn into documents. At this
 point I think you should just do a sup-dump (which might still work),
 move the old xapian directory out of the way, and re-sync. You can try
 running xapian-check on the corrupted version to see if it finds
 anything interesting.
 
 From nicolas.pouillard@gmail.com  Sun Oct  4 08:36:02 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sun, 04 Oct 2009 14:36:02 +0200
 Subject: [sup-talk] Simple E-Mail Delaying
 Message-ID: <1254659599-sup-7377@peray>
 
 Hi all,
 
 I've written a blog post about improving my email experience. And since it
 interacts nicely with sup it may be of some interest for you.
 
 Best Regards,
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From marcus-sup@bar-coded.net  Sun Oct  4 10:42:37 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Sun, 04 Oct 2009 15:42:37 +0100
 Subject: [sup-talk] labels-before-subject and ask_for_contacts config
 	knobs
 In-Reply-To: <1254565800-sup-5590@lanparty.ee>
 References: <1254565800-sup-5590@lanparty.ee>
 Message-ID: <1254667184-sup-153@bar-coded.net>
 
 On 3.10.2009, Tarko Tikan wrote:
 > second, since labels-before-subject was integrated, it's hard to follow thread
 > index on small screen. Most of my inbox is tagged with 3 labels, mailing-list
 > could be tagged with up to 5 labels. The problem is especially bad on very
 > small screens (like mobiles with ssh clients).
 
 If you search through the archives you should find a patch I submitted
 for an alternate view. The default alternate view I find very good on
 smaller devices and its configurable via a hook if you want anything
 more. Not sure if its going to get integrated into sup though
 (Any thoughts William? - I can resubmit if necessary)
 
 You would need to change the keypress from "~" to something that isnt
 taken (currently thats taken as a console view).
 
 HTH
 
 Marcus
 
 From sgoldman@tower-research.com  Sun Oct  4 10:46:40 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Sun, 04 Oct 2009 10:46:40 -0400
 Subject: [sup-talk] Simple E-Mail Delaying
 In-Reply-To: <1254659599-sup-7377@peray>
 References: <1254659599-sup-7377@peray>
 Message-ID: <1254667426-sup-9509@sgoldmanlinux.tower-research.com>
 
 Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
 > Hi all,
 > 
 > I've written a blog post about improving my email experience. And since it
 > interacts nicely with sup it may be of some interest for you.
 > 
 > Best Regards,
 > 
 
 This is brilliant.
 
 Can you help me get it work?
 
 What defines FULLEMAIL?  I can't get the script past that.
 
 (I'm not on the latest sup checkout, but i grepped the next branch for
 FULLEMAIL and didn't see anything.)
 
 Thanks.
 -- 
 
 Steve Goldman
 sgoldman at tower-research.com
 
 T: 212.219.6014
 F: 212.219.6007
 
 Tower Research Capital, LLC
 377 Broadway, 11th Fl.
 New York, NY 10013
 
 From web-sup@superscript.com  Sun Oct  4 11:51:51 2009
 From: web-sup@superscript.com (William Baxter)
 Date: Sun, 04 Oct 2009 11:51:51 -0400
 Subject: [sup-talk] Simple E-Mail Delaying
 In-Reply-To: <1254659599-sup-7377@peray>
 References: <1254659599-sup-7377@peray>
 Message-ID: <1254671303-sup-2911@kronos>
 
 Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
 > I've written a blog post about improving my email experience. And since it
 > interacts nicely with sup it may be of some interest for you.
 
 I also employ a tickler system in sup, one that relies exclusively on labels.
 To mark a thread for review on day DD of the month, label it with #DD.
 Obviously this extends forward only one month.  I have not found that
 problematic.  I also use #E to indicate the need to reply, #W as waiting for
 something, #A for action required, etc.
 
 The choice of # came from two considerations.  First, it sorts before letters.
 Second, it does not require quoting in searches.  The date labels could do
 without the prefix, but I began with the #<letter> labels, and like the way
 that the common prefix sets these elements apart in label-list-mode.
 
 Cheers, W.
 
 From gigabo@gmail.com  Sun Oct  4 12:23:17 2009
 From: gigabo@gmail.com (Bo Borgerson)
 Date: Sun, 04 Oct 2009 12:23:17 -0400
 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode
 In-Reply-To: <1254415913-sup-6275@masanjin.net>
 References: <1252789445-30193-1-git-send-email-gigabo@gmail.com>
 	<1254415913-sup-6275@masanjin.net>
 Message-ID: <1254669536-sup-2700@longword>
 
 Excerpts from William Morgan's message of Thu Oct 01 12:53:15 -0400 2009:
 > Reformatted excerpts from Bo Borgerson's message of 2009-09-12:
 > > Register label-list-mode with the UpdateManager and handle added
 > > updates with a reload to keep unread message counts up to date
 > 
 > Branch label-list-mode-auto-update, merged into next.
 > 
 
 Hi William.  Thanks for looking at this.
 
 > I'm a little concerned with performance, but we'll see how it goes.
 > 
 
 Yeah, I think I might be spoiled by my relatively few messages / labels.  If it
 turns out to be an issue maybe it could be made toggle-able with a key-press?
 (Default off / configurable)?
 
 I actually use the label-list-mode as my "home" screen.  I like it to stay
 up-to-date so I can quickly scan which labels have new messages.
 
 Incidentally the recent discussion in another thread about making the inbox
 more like other labels resonates with me.  My workflow for all other labels is
 just to 'x' out when I'm done, but with the inbox I have to '$'ave and
 'B'uffer-switch.
 
 > What do you think about handling labeled and deleted updates as well?
 
 Is there a way to label or delete threads without leaving the label-list-mode?
 There's already a refresh when switching back to the label-list-mode from
 elsewhere, I think, so any changes that are $aved should be reflected
 immediately when you get back.  Labels added automatically in a
 before-add-message hook should already be present when the 'added' update event
 is received, right?
 
 I'm not trying to argue against adding handlers for labeled and deleted
 updates.  I just want to make sure I understand the use cases so I know how to
 test.
 
 Thanks,
 
 Bo
 
 From rlane@club.cc.cmu.edu  Sun Oct  4 14:45:55 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 04 Oct 2009 14:45:55 -0400
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <20091004101550.GA7330@qwerzila.bluecom.no>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 Message-ID: <1254681739-sup-4089@zyrg.net>
 
 Ok, I've attached a patch with more assertions. Also, can you try with a clean
 checkout of next and see if the problem still occurs?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-more-id-assertions.patch
 Type: application/octet-stream
 Size: 1695 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091004/6622c53c/attachment.obj>
 
 From eg@gaute.vetsj.com  Sun Oct  4 14:56:31 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Sun, 4 Oct 2009 20:56:31 +0200
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <1254681739-sup-4089@zyrg.net>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 	<1254681739-sup-4089@zyrg.net>
 Message-ID: <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 
 Still having problems, but got a bit more output, see attached exception.log
 
 [sup.git](next) $ git log --oneline -6
 a209178 more id assertions
 0eee097 Merge branch 'master' into next
 93b5552 more release-script updates
 f56badb Merge branch 'master' into next
 b9071e5 change date for 0.9 release
 9a5c0d1 Merge branch 'save-all-attachments' into next
 
 - gaute
 
 On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > Ok, I've attached a patch with more assertions. Also, can you try with a clean
 > checkout of next and see if the problem still occurs?
 >
 -------------- next part --------------
 --- RuntimeError from thread: main
 @id nil
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in `build_from_source'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in `each_message_from'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in `each_message_from'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
 /home/gaute/.gem/ruby/1.8/bin/sup:19
 
 From rlane@club.cc.cmu.edu  Sun Oct  4 15:03:51 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 04 Oct 2009 15:03:51 -0400
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 	<1254681739-sup-4089@zyrg.net>
 	<5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 Message-ID: <1254682966-sup-6629@zyrg.net>
 
 Oops, sorry, bad assertions. Please move the two in
 self.build_from_source to the end of load_from_source!.
 
 Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009:
 > Still having problems, but got a bit more output, see attached exception.log
 > 
 > [sup.git](next) $ git log --oneline -6
 > a209178 more id assertions
 > 0eee097 Merge branch 'master' into next
 > 93b5552 more release-script updates
 > f56badb Merge branch 'master' into next
 > b9071e5 change date for 0.9 release
 > 9a5c0d1 Merge branch 'save-all-attachments' into next
 > 
 > - gaute
 > 
 > On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > > Ok, I've attached a patch with more assertions. Also, can you try with a clean
 > > checkout of next and see if the problem still occurs?
 > >
 > --- RuntimeError from thread: main
 > @id nil
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
 > `build_from_source'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
 > `each_message_from'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
 > `each_message_from'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 > /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
 > /home/gaute/.gem/ruby/1.8/bin/sup:19
 
 From eg@gaute.vetsj.com  Sun Oct  4 15:20:50 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Sun, 4 Oct 2009 21:20:50 +0200
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <1254682966-sup-6629@zyrg.net>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 	<1254681739-sup-4089@zyrg.net>
 	<5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 	<1254682966-sup-6629@zyrg.net>
 Message-ID: <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com>
 
 Still the same..
 
 (run without '-n' then P this time, thats the reason for the longer exception..)
 
 [sup.git](next-nil) $ git log --oneline -4
 7e99810 for your confirmation..
 eafea2b more id assertions
 0eee097 Merge branch 'master' into next
 93b5552 more release-script updates
 
 - gaute
 
 On Sun, Oct 4, 2009 at 9:03 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > Oops, sorry, bad assertions. Please move the two in
 > self.build_from_source to the end of load_from_source!.
 >
 > Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009:
 >> Still having problems, but got a bit more output, see attached exception.log
 >>
 >> [sup.git](next) $ git log --oneline -6
 >> a209178 more id assertions
 >> 0eee097 Merge branch 'master' into next
 >> 93b5552 more release-script updates
 >> f56badb Merge branch 'master' into next
 >> b9071e5 change date for 0.9 release
 >> 9a5c0d1 Merge branch 'save-all-attachments' into next
 >>
 >> - gaute
 >>
 >> On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 >> > Ok, I've attached a patch with more assertions. Also, can you try with a clean
 >> > checkout of next and see if the problem still occurs?
 >> >
 >> --- RuntimeError from thread: main
 >> @id nil
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
 >> `build_from_source'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
 >> `each_message_from'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
 >> `each_message_from'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
 >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 >> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
 >> /home/gaute/.gem/ruby/1.8/bin/sup:19
 >
 -------------- next part --------------
 --- RuntimeError from thread: poll after loading inbox
 @id nil
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in `load_from_source!'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in `build_from_source'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in `each_message_from'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in `each_message_from'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `call'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `call'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
 /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
 /home/gaute/.gem/ruby/1.8/bin/sup:19
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-for-your-confirmation.patch
 Type: text/x-patch
 Size: 1346 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091004/385603f1/attachment.bin>
 
 From guillaume.quintard@gmail.com  Sun Oct  4 15:59:44 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sun, 4 Oct 2009 21:59:44 +0200
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <20090911165830.GA11260@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 Message-ID: <1e5fdab70910041259j40ceaaeue4473d17136a5efc@mail.gmail.com>
 
 On Fri, Sep 11, 2009 at 6:58 PM, Ben Gamari <bgamari.foss at gmail.com> wrote:
 
 > I can also produce a very similar crash[2] by attempting to load all
 > threads. Thanks,
 
 I get the same thing when loading all the threads. Index has just been
 rebuilt, and I'm using an mbox file.
 
 -- 
 Guillaume
 
 From marco-oweber@gmx.de  Sun Oct  4 16:55:42 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Sun, 04 Oct 2009 22:55:42 +0200
 Subject: [sup-talk] next search in buffer view..
 In-Reply-To: <1254602805-sup-2900@nixos>
 References: <1254602805-sup-2900@nixos>
 Message-ID: <1254689522-sup-2800@nixos>
 
 Mmh. Maybe its not that a bad idea to keep the search mode.
 
 However it would be nice to provide the last search term as default.
 
 This minimal patch adds this feature.
 However the search_query_input should be global. So where is the place
 to add this "last-search-term" ? Isn't it already present in the ask
 history? Can you give me a hint to find it faster?
 
 Marc Weber
 
 diff --git a/lib/sup/modes/scroll-mode.rb b/lib/sup/modes/scroll-mode.rb
 index c131425..a97f13c 100644
 --- a/lib/sup/modes/scroll-mode.rb
 +++ b/lib/sup/modes/scroll-mode.rb
 @@ -35,6 +35,7 @@ class ScrollMode < Mode
      @slip_rows = opts[:slip_rows] || 0 # when we pgup/pgdown,
                                         # how many lines do we keep?
      @twiddles = opts.member?(:twiddles) ? opts[:twiddles] : true
 +    @search_query_input = ""
      @search_query = nil
      @search_line = nil
      @status = ""
 @@ -81,9 +82,10 @@ class ScrollMode < Mode
    end
  
    def search_in_buffer
 -    query = BufferManager.ask :search, "search in buffer: "
 +    query = BufferManager.ask :search, "search in buffer: ", @search_query_input
      return if query.nil? || query.empty?
      @search_query = Regexp.escape query
 +    @search_query_input = query
      continue_search_in_buffer
    end
  
 
 From nicolas.pouillard@gmail.com  Mon Oct  5 03:55:09 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 05 Oct 2009 09:55:09 +0200
 Subject: [sup-talk] Simple E-Mail Delaying
 In-Reply-To: <1254667426-sup-9509@sgoldmanlinux.tower-research.com>
 References: <1254659599-sup-7377@peray>
 	<1254667426-sup-9509@sgoldmanlinux.tower-research.com>
 Message-ID: <1254728881-sup-3528@peray>
 
 Excerpts from Steve Goldman's message of Sun Oct 04 16:46:40 +0200 2009:
 > Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
 > > Hi all,
 > > 
 > > I've written a blog post about improving my email experience. And since it
 > > interacts nicely with sup it may be of some interest for you.
 > > 
 > > Best Regards,
 > > 
 > 
 > This is brilliant.
 > 
 > Can you help me get it work?
 
 Of course.
 
 > What defines FULLEMAIL?  I can't get the script past that.
 
 I defined it in my shell profile (.zshrc actually),
 
 export FULLEMAIL="Nicolas Pouillard <nicolas.pouillard at gmail.com>"
 
 I know that is not standard, and I can be easily convinced to support
 something more portable.
 
 In my .zshrc I have $EMAIL, $MAILADDR as well. 
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From nicolas.pouillard@gmail.com  Mon Oct  5 03:59:45 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 05 Oct 2009 09:59:45 +0200
 Subject: [sup-talk] Simple E-Mail Delaying
 In-Reply-To: <1254671303-sup-2911@kronos>
 References: <1254659599-sup-7377@peray> <1254671303-sup-2911@kronos>
 Message-ID: <1254729313-sup-1910@peray>
 
 Excerpts from William Baxter's message of Sun Oct 04 17:51:51 +0200 2009:
 > Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
 > > I've written a blog post about improving my email experience. And since it
 > > interacts nicely with sup it may be of some interest for you.
 > 
 > I also employ a tickler system in sup, one that relies exclusively on labels.
 > To mark a thread for review on day DD of the month, label it with #DD.
 > Obviously this extends forward only one month.  I have not found that
 > problematic.  I also use #E to indicate the need to reply, #W as waiting for
 > something, #A for action required, etc.
 > 
 > The choice of # came from two considerations.  First, it sorts before letters.
 > Second, it does not require quoting in searches.  The date labels could do
 > without the prefix, but I began with the #<letter> labels, and like the way
 > that the common prefix sets these elements apart in label-list-mode.
 
 Thanks for the tip!
 
 I already use a "pending" label for a mix of "waiting",
 "need to reply", and "action required". I'm thinking about switching to
 shorter and more distinct naming like yours.
 
 However I like the system proposed because it is event based and can be more
 fine grained than "a day of the month".
 
 Best regards,
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From mailinglist@flasht.de  Mon Oct  5 12:00:25 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Mon, 05 Oct 2009 18:00:25 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254487575-sup-5468@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 Message-ID: <1254758256-sup-7400@thinkpad-ubuntu>
 
 I think I've translated most of sup's UI-related part (translating
 error messages doesn't seem like a good idea, since we really don't
 want multilingual bug-reports and exception logs...) I'd like to hear
 some feedback and/or opinions/suggestions and would like to see it
 integrated into sup. I'll add more translations, if I find anything I
 havent missed yet and that is part of the user interface.
 
 Cheers,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 
 From eg@gaute.vetsj.com  Mon Oct  5 18:01:18 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Tue, 06 Oct 2009 00:01:18 +0200
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 	<1254681739-sup-4089@zyrg.net>
 	<5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 	<1254682966-sup-6629@zyrg.net>
 	<5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com>
 Message-ID: <1254780036-sup-3214@qwerzila>
 
 Did a 'sup-sync --changed -o' and the problem seems to be gone. 
 
 - gaute
 
 Excerpts from Gaute Hope's message of su. okt. 04 21:20:50 +0200 2009:
 > Still the same..
 > 
 > (run without '-n' then P this time, thats the reason for the longer exception..)
 > 
 > [sup.git](next-nil) $ git log --oneline -4
 > 7e99810 for your confirmation..
 > eafea2b more id assertions
 > 0eee097 Merge branch 'master' into next
 > 93b5552 more release-script updates
 > 
 > - gaute
 > 
 > On Sun, Oct 4, 2009 at 9:03 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > > Oops, sorry, bad assertions. Please move the two in
 > > self.build_from_source to the end of load_from_source!.
 > >
 > > Excerpts from Gaute Hope's message of Sun Oct 04 14:56:31 -0400 2009:
 > >> Still having problems, but got a bit more output, see attached exception.log
 > >>
 > >> [sup.git](next) $ git log --oneline -6
 > >> a209178 more id assertions
 > >> 0eee097 Merge branch 'master' into next
 > >> 93b5552 more release-script updates
 > >> f56badb Merge branch 'master' into next
 > >> b9071e5 change date for 0.9 release
 > >> 9a5c0d1 Merge branch 'save-all-attachments' into next
 > >>
 > >> - gaute
 > >>
 > >> On Sun, Oct 4, 2009 at 8:45 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > >> > Ok, I've attached a patch with more assertions. Also, can you try with a clean
 > >> > checkout of next and see if the problem still occurs?
 > >> >
 > >> --- RuntimeError from thread: main
 > >> @id nil
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
 > >> `build_from_source'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
 > >> `each_message_from'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
 > >> `each_message_from'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:73:in `reporting_thread'
 > >> /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:287
 > >> /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
 > >> /home/gaute/.gem/ruby/1.8/bin/sup:19
 > >
 > --- RuntimeError from thread: poll after loading inbox
 > @id nil
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in
 > `load_from_source!'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
 > `build_from_source'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
 > `each_message_from'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/source.rb:104:in `each'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `send'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:154:in
 > `each_message_from'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:108:in `do_poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `each'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:96:in `do_poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `synchronize'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:95:in `do_poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:47:in `poll_with_sources'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:62:in `poll'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `send'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
 >  `call'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in
 >  `__unprotected_load_threads'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
 >  `call'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in
 >  `load_n_threads_background'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `initialize'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `new'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in
 >  `load_n_threads_background'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in
 >  `__unprotected_load_threads'
 > (eval):12:in `load_threads'
 > /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:197
 > /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load'
 > /home/gaute/.gem/ruby/1.8/bin/sup:19
 
 From nicolas.pouillard@gmail.com  Mon Oct  5 18:11:17 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 06 Oct 2009 00:11:17 +0200
 Subject: [sup-talk] Simple E-Mail Delaying
 In-Reply-To: <1254728881-sup-3528@peray>
 References: <1254659599-sup-7377@peray>
 	<1254667426-sup-9509@sgoldmanlinux.tower-research.com>
 	<1254728881-sup-3528@peray>
 Message-ID: <1254780524-sup-6949@peray>
 
 Excerpts from Nicolas Pouillard's message of Mon Oct 05 09:55:09 +0200 2009:
 > Excerpts from Steve Goldman's message of Sun Oct 04 16:46:40 +0200 2009:
 > > Excerpts from Nicolas Pouillard's message of Sun Oct 04 08:36:02 -0400 2009:
 > > > Hi all,
 > > > 
 > > > I've written a blog post about improving my email experience. And since it
 > > > interacts nicely with sup it may be of some interest for you.
 > > > 
 > > > Best Regards,
 > > > 
 > > 
 > > This is brilliant.
 > > 
 > > Can you help me get it work?
 > 
 > Of course.
 > 
 > > What defines FULLEMAIL?  I can't get the script past that.
 > 
 > I defined it in my shell profile (.zshrc actually),
 > 
 > export FULLEMAIL="Nicolas Pouillard <nicolas.pouillard at gmail.com>"
 > 
 > I know that is not standard, and I can be easily convinced to support
 > something more portable.
 > 
 > In my .zshrc I have $EMAIL, $MAILADDR as well. 
 
 I have updated my gist [1], to reflect two changes the first is to set the
 date at the sending time (not when running email-reminder) and the second is
 to use $EMAIL and $REALNAME which are a bit more self-explanatory.
 
 [1]: http://gist.github.com/199197
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From guillaume.quintard@gmail.com  Tue Oct  6 06:14:43 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Tue, 6 Oct 2009 12:14:43 +0200
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <1254780036-sup-3214@qwerzila>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 	<1254681739-sup-4089@zyrg.net>
 	<5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 	<1254682966-sup-6629@zyrg.net>
 	<5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com>
 	<1254780036-sup-3214@qwerzila>
 Message-ID: <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com>
 
 On Tue, Oct 6, 2009 at 12:01 AM, Gaute Hope <eg at gaute.vetsj.com> wrote:
 > Did a 'sup-sync --changed -o' and the problem seems to be gone.
 
 It doesn't for me. During sup-sync I get this:
 
 [Tue Oct 06 11:22:55 +0200 2009] hook: error running hook: cannot
 generate tempfile `/tmp/12016-9-attachments/389068.html'
 [Tue Oct 06 11:22:55 +0200 2009] hook:
 /usr/lib/ruby/1.8/tempfile.rb:52:in `initialize'
 ./lib/sup/message-chunks.rb:149:in `new'
 ./lib/sup/message-chunks.rb:149:in `write_to_disk'
 ./lib/sup/message-chunks.rb:105:in `initialize'
 ./lib/sup/hook.rb:51:in `call'
 ./lib/sup/hook.rb:51:in `filename'
 /home/shivan/.sup/hooks/mime-decode.rb:4:in `__run'
 ./lib/sup/hook.rb:42:in `__run'
 ./lib/sup/hook.rb:82:in `run'
 ./lib/sup/util.rb:520:in `send'
 ./lib/sup/util.rb:520:in `method_missing'
 ./lib/sup/message-chunks.rb:104:in `initialize'
 ./lib/sup/message.rb:503:in `new'
 ./lib/sup/message.rb:503:in `message_to_chunks'
 ./lib/sup/message.rb:435:in `message_to_chunks'
 ./lib/sup/message.rb:435:in `map'
 ./lib/sup/message.rb:435:in `message_to_chunks'
 ./lib/sup/message.rb:239:in `load_from_source!'
 ./lib/sup/message.rb:335:in `build_from_source'
 ./lib/sup/poll.rb:160:in `each_message_from'
 ./lib/sup/source.rb:104:in `each'
 ./lib/sup/util.rb:560:in `send'
 ./lib/sup/util.rb:560:in `__pass'
 ./lib/sup/util.rb:547:in `method_missing'
 ./lib/sup/poll.rb:154:in `each_message_from'
 ./lib/sup/util.rb:520:in `send'
 ./lib/sup/util.rb:520:in `method_missing'
 bin/sup-sync:146
 bin/sup-sync:141:in `each'
 bin/sup-sync:141
 
 I got rid of the hooks, ran sup-sync again, the message goes away, but
 I still get:
 
 --- RuntimeError from thread: load threads for thread-index-mode
 wrong id called on nil
 ./lib/sup.rb:17:in `id'
 ./lib/sup/modes/thread-index-mode.rb:225:in `update'
 ./lib/sup/hook.rb:121:in `sort_by'
 ./lib/sup/modes/thread-index-mode.rb:225:in `each'
 ./lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
 ./lib/sup/modes/thread-index-mode.rb:225:in `update'
 ./lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
 ./lib/sup/modes/thread-index-mode.rb:223:in `update'
 ./lib/sup/modes/thread-index-mode.rb:637: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'
 bin/sup:197
 
 upon loading
 
 -- 
 Guillaume
 
 From olly@survex.com  Tue Oct  6 08:40:25 2009
 From: olly@survex.com (Olly Betts)
 Date: Tue, 6 Oct 2009 12:40:25 +0000 (UTC)
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 	<1254600926-sup-5190@zyrg.net>
 	<1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com>
 Message-ID: <loom.20091006T143016-56@post.gmane.org>
 
 Guillaume Quintard writes:
 > On Sat, Oct 3, 2009 at 10:17 PM, Rich Lane <rlane <at> club.cc.cmu.edu> wrote:
 > > I'd hoped this kind of corruption wouldn't be possible with newer
 > > xapian-index versions. What sup commit are you on? What version of
 > > Xapian are you using? Which Xapian backend, Flint or Chert?
 > 
 > ubuntu 9.10
 > libxapian-ruby1.8    1.0.14-1
 > I'd say flink since I often have to remove flintlock after sup
 > commiting suicide.
 
 NEVER EVER remove the flintlock file.  It's not the presence of the file which
 determines the lock, but rather whether there's an fcntl() lock on it, so
 removing it smashes any lock which is currently held, but leaves the process
 which held it thinking it still has exclusive write access to the database,
 which will likely quickly lead to a corrupt database, especially if you're
 doing so because Xapian says the database is already locked.  If Xapian says
 that, then there really is a process which still has the database open for
 writing.
 
 My guess is that removing the flintlock file is the cause of the corruption
 you're seeing.  Can you reproduce it on a database where you haven't removed
 this file?
 
 Also, both chert and flint use the same locking approach with a file called
 flintlock, so that doesn't discriminate between them.  The easy way to tell
 which you have is whether there's a file called "iamflint" or "iamchert" in
 the database directory.
 
 Cheers,
     Olly
 
 
 From guillaume.quintard@gmail.com  Tue Oct  6 09:10:44 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Tue, 6 Oct 2009 15:10:44 +0200
 Subject: [sup-talk] Crash, bad index, and ensuing misery
 In-Reply-To: <loom.20091006T143016-56@post.gmane.org>
 References: <1e5fdab70910031304g255a9d13v4dc99400def375a5@mail.gmail.com>
 	<1254600926-sup-5190@zyrg.net>
 	<1e5fdab70910031406x713fad49ubb42b42463899c87@mail.gmail.com>
 	<loom.20091006T143016-56@post.gmane.org>
 Message-ID: <1e5fdab70910060610n7486dc1bi27b07c4f5f51faa6@mail.gmail.com>
 
 On Tue, Oct 6, 2009 at 2:40 PM, Olly Betts <olly at survex.com> wrote:
 > NEVER EVER remove the flintlock file.
 Ooops, didn't know, won't do it again.
 
 > My guess is that removing the flintlock file is the cause of the corruption
 > you're seeing. ?Can you reproduce it on a database where you haven't removed
 > this file?
 Unfortunately, no
 
 
 > which you have is whether there's a file called "iamflint" or "iamchert" in
 Flint then
 
 
 -- 
 Guillaume
 
 From eg@gaute.vetsj.com  Tue Oct  6 09:34:51 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Tue, 06 Oct 2009 15:34:51 +0200
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 	<1254681739-sup-4089@zyrg.net>
 	<5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 	<1254682966-sup-6629@zyrg.net>
 	<5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com>
 	<1254780036-sup-3214@qwerzila>
 	<1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com>
 Message-ID: <1254835794-sup-6000@qwerzila>
 
 Excerpts from Guillaume Quintard's message of ty. okt. 06 12:14:43 +0200 2009:
 > On Tue, Oct 6, 2009 at 12:01 AM, Gaute Hope <eg at gaute.vetsj.com> wrote:
 > > Did a 'sup-sync --changed -o' and the problem seems to be gone.
 
 > --- RuntimeError from thread: load threads for thread-index-mode
 > wrong id called on nil
 > ./lib/sup.rb:17:in `id'
 
 I was getting a slightly different error:
 
 --- RuntimeError from thread: poll after loading inbox
 @id nil
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:254:in
 `load_from_source!'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/message.rb:342:in
 `build_from_source'
 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/poll.rb:160:in
 `each_message_from'
 
 - 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/20091006/07fdbfd2/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Tue Oct  6 10:59:07 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Oct 2009 07:59:07 -0700
 Subject: [sup-talk] Bug: Xapian exception after having polled
 In-Reply-To: <1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com>
 References: <25727581.post@talk.nabble.com> <1254594099-sup-719@zyrg.net>
 	<20091004101550.GA7330@qwerzila.bluecom.no>
 	<1254681739-sup-4089@zyrg.net>
 	<5a5b14cf0910041156q7e755931w4fb75ce57f9f4339@mail.gmail.com>
 	<1254682966-sup-6629@zyrg.net>
 	<5a5b14cf0910041220p26a4c830va172df0e33542480@mail.gmail.com>
 	<1254780036-sup-3214@qwerzila>
 	<1e5fdab70910060314i6a4cce5ck92e7605ec54f98a1@mail.gmail.com>
 Message-ID: <1254840860-sup-2494@masanjin.net>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-10-06:
 > [Tue Oct 06 11:22:55 +0200 2009] hook: error running hook: cannot
 > generate tempfile `/tmp/12016-9-attachments/389068.html'
 > [Tue Oct 06 11:22:55 +0200 2009] hook:
 > /usr/lib/ruby/1.8/tempfile.rb:52:in `initialize'
 > ./lib/sup/message-chunks.rb:149:in `new'
 > ./lib/sup/message-chunks.rb:149:in `write_to_disk'
 > ./lib/sup/message-chunks.rb:105:in `initialize'
 > ./lib/sup/hook.rb:51:in `call'
 > ./lib/sup/hook.rb:51:in `filename'
 > /home/shivan/.sup/hooks/mime-decode.rb:4:in `__run'
 
 I think that's an unrelated issue, but it's weird that it couldn't
 create that file in /tmp. Are you out of disk space, missing a /tmp
 directory, or something weird like that?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Oct  6 11:38:39 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Oct 2009 08:38:39 -0700
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254758256-sup-7400@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1254758256-sup-7400@thinkpad-ubuntu>
 Message-ID: <1254842820-sup-9099@masanjin.net>
 
 Hi Christopher,
 
 Reformatted excerpts from Christopher Bertels's message of 2009-10-05:
 > I'd like to hear some feedback and/or opinions/suggestions and would
 > like to see it integrated into sup. I'll add more translations, if I
 > find anything I havent missed yet and that is part of the user
 > interface.
 
 This looks great. A couple comments:
 
 1. I would prefer that uppercase substitution symbols made lowercase.
 The uppercase seems weird and un-Rubyish to me.
 
 2. I think it would be nice to have a simple module along the lines of:
 
   module M17n
     def m s, o={}; I18n[m, o] end
   end
 
 and to have that be the primary entry point when you want a translated
 string. Then classes can include that module if they want m17n support,
 and instead of writing
 
   I18n["text", { :var => value }]
 
 you can have
 
   m("text", :var => value)
 
 which is a little easier to read, IMO.
 
 3. Should we call it m17n instead of i18n? I think that might be a
 little more accurate. Perhaps too nitpicky. What do you think?
 
 4. A finishing touch would be to have sup-config ask the user what
 language they are interested in.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bgamari.foss@gmail.com  Tue Oct  6 11:53:18 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Tue, 06 Oct 2009 11:53:18 -0400
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1254844050-sup-4148@ben-laptop>
 References: <1254844050-sup-4148@ben-laptop>
 Message-ID: <1254844166-sup-1028@ben-laptop>
 
 Well, it seems like whatever caused the crash earlier did something to
 my index. Now any attempt to open a thread-index-mode of my LKML label
 (which I was viewing in the earlier crash) causes the client to
 immediately crash.
 
 Do any of the sup utilities have any sort of index sanity checker to
 find potential causes of this sort of issue? Thanks,
 
 - Ben
 
 
 --- 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/lib64/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:117:in `each_id_by_date'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:117: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/label-search-results-mode.rb:33:in `spawn_nicely'
 /opt/exp/sup/lib/sup/modes/label-list-mode.rb:103:in `select_label'
 /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:239
 
 
 Excerpts from Ben Gamari's message of Tue Oct 06 11:47:34 -0400 2009:
 > I just had sup crash on me while reading a thread. Not really sure what
 > to make of the backtrace. Looks like it failed during polling but who
 > knows why. Thanks,
 > 
 > - Ben
 > 
 
 From bgamari.foss@gmail.com  Tue Oct  6 11:47:34 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Tue, 06 Oct 2009 11:47:34 -0400
 Subject: [sup-talk] Crash while in thread-view-mode
 Message-ID: <1254844050-sup-4148@ben-laptop>
 
 I just had sup crash on me while reading a thread. Not really sure what
 to make of the backtrace. Looks like it failed during polling but who
 knows why. Thanks,
 
 - Ben
 
 
 --- RuntimeError from thread: periodic poll
 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'
 /opt/exp/sup/lib/sup/xapian_index.rb:325: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:702:in `add_or_unhide'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:188:in `handle_added_update'
 /opt/exp/sup/lib/sup/update.rb:26:in `send'
 /opt/exp/sup/lib/sup/update.rb:26:in `relay'
 /opt/exp/sup/lib/sup/update.rb:26:in `each'
 /opt/exp/sup/lib/sup/update.rb:26:in `relay'
 /opt/exp/sup/lib/sup/util.rb:520:in `send'
 /opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
 /opt/exp/sup/lib/sup/poll.rb:181:in `add_new_message'
 /opt/exp/sup/lib/sup/poll.rb:124:in `do_poll'
 /opt/exp/sup/lib/sup/poll.rb:166:in `each_message_from'
 /opt/exp/sup/lib/sup/maildir.rb:160:in `each'
 /opt/exp/sup/lib/sup/maildir.rb:157:in `upto'
 /opt/exp/sup/lib/sup/maildir.rb:157:in `each'
 /opt/exp/sup/lib/sup/util.rb:560:in `send'
 /opt/exp/sup/lib/sup/util.rb:560:in `__pass'
 /opt/exp/sup/lib/sup/util.rb:547:in `method_missing'
 /opt/exp/sup/lib/sup/poll.rb:154:in `each_message_from'
 /opt/exp/sup/lib/sup/poll.rb:108:in `do_poll'
 /opt/exp/sup/lib/sup/poll.rb:96:in `each'
 /opt/exp/sup/lib/sup/poll.rb:96:in `do_poll'
 /opt/exp/sup/lib/sup/poll.rb:95:in `synchronize'
 /opt/exp/sup/lib/sup/poll.rb:95:in `do_poll'
 /opt/exp/sup/lib/sup/util.rb:520:in `send'
 /opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
 /opt/exp/sup/lib/sup/modes/poll-mode.rb:15:in `poll'
 /opt/exp/sup/lib/sup/poll.rb:47:in `poll_with_sources'
 /opt/exp/sup/lib/sup/poll.rb:62:in `poll'
 /opt/exp/sup/lib/sup/poll.rb:80:in `start'
 /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/poll.rb:77:in `start'
 /opt/exp/sup/lib/sup/util.rb:520:in `send'
 /opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
 /usr/bin/sup:204
 
 From bgamari.foss@gmail.com  Tue Oct  6 12:15:46 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Tue, 06 Oct 2009 12:15:46 -0400
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1254844166-sup-1028@ben-laptop>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 Message-ID: <1254845543-sup-9458@ben-laptop>
 
 Excerpts from Ben Gamari's message of Tue Oct 06 11:53:18 -0400 2009:
 > Well, it seems like whatever caused the crash earlier did something to
 > my index. Now any attempt to open a thread-index-mode of my LKML label
 > (which I was viewing in the earlier crash) causes the client to
 > immediately crash.
 > 
 
 Hmm, it seems like the problem is spreading. I now come to find out that
 another label triggers this same crash (although I guess it's possible
 that the intersection of the two labels is non-nil). I tried running a
 sup-sync -oc on the relevant sources to no avail. I really don't have
 time to devote to debugging this at the moment so it looks like I might
 need to take another hiatus from sup. Just as I was starting to get used
 to it... sigh. Anyways, if anyone has any ideas for improving things,
 let me know. Thanks!
 
 - Ben
 
 From wmorgan-sup@masanjin.net  Tue Oct  6 12:35:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Oct 2009 09:35:36 -0700
 Subject: [sup-talk] next search in buffer view..
 In-Reply-To: <1254689522-sup-2800@nixos>
 References: <1254602805-sup-2900@nixos> <1254689522-sup-2800@nixos>
 Message-ID: <1254846869-sup-9463@masanjin.net>
 
 Reformatted excerpts from Marc Weber's message of 2009-10-04:
 > However the search_query_input should be global. So where is the place
 > to add this "last-search-term" ? Isn't it already present in the ask
 > history? Can you give me a hint to find it faster?
 
 Probably the best place is to make it a class variable, i.e.
 @@search_query_input. Then it will be shared across all buffers with
 modes that have search functionality.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marka@pobox.com  Tue Oct  6 12:39:08 2009
 From: marka@pobox.com (Mark Alexander)
 Date: Tue, 06 Oct 2009 12:39:08 -0400
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1254845543-sup-9458@ben-laptop>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop>
 Message-ID: <1254846746-sup-1820@r50p>
 
 > I really don't have
 > time to devote to debugging this at the moment so it looks like I might
 > need to take another hiatus from sup.
 
 You could try running an older version.  I've been using 0.8 at
 work, and a May 20 snapshot of next at home, and both have been very
 solid.  They're good enough, in fact, that I don't feel the need to
 upgrade.  Maybe after the dust settles from all the recent code
 churn...
 
 From wmorgan-sup@masanjin.net  Tue Oct  6 13:11:06 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Oct 2009 10:11:06 -0700
 Subject: [sup-talk] Ignore killed messages in U screen
 In-Reply-To: <1254417174-sup-3659@yoom.home.cworth.org>
 References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net>
 	<1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net>
 	<1252004504-sup-3189@javelin> <1254339746-sup-79@masanjin.net>
 	<1254382434-sup-4435@peray> <1254404057-sup-2374@masanjin.net>
 	<cd67f63a0910010707q620016bwb899095fb6a50765@mail.gmail.com>
 	<1254417174-sup-3659@yoom.home.cworth.org>
 Message-ID: <1254849015-sup-5884@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-10-01:
 > It seems a simple, little thing. But I'm all in favor of non-violent
 > metaphors in the interfaces of programs I use.
 
 I will accept a patch that renames this and adds "M" as an additional
 command.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Oct  6 13:16:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Oct 2009 10:16:20 -0700
 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option.
 In-Reply-To: <1254417826-sup-6584@yoom.home.cworth.org>
 References: <1254178611-sup-369@yoom.home.cworth.org>
 	<1254416783-sup-5518@masanjin.net>
 	<1254417826-sup-6584@yoom.home.cworth.org>
 Message-ID: <1254849104-sup-6471@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-10-01:
 > What makes a hook preferable over a configuration option?
 
 I would like to support everyone's crazy desires, and a hook is worth a
 thousand configuration options.
 
 In this case, I'm sure it's only a matter of time before someone wants
 to automatically determine the crypto setting based on the recipient, or
 based on the message body. A hook would allow that.
 
 > 2. Hooks are not supported forever, in which case users may find that
 > things just start working when upgrading.
 
 I am fine with this. Users be damned! (Or at least, required to read the
 changelog.)
 
 > Neither of those seem options look nice to me, and both seem easy to
 > avoid with configuration options.
 
 How so? Configuration options can change just as easily.
 
 > If the plan is to go with (1) I'm concerned that I don't see sup
 > shipping documentation for the current possible hooks. (This applies
 > to configuration options too though. I think the maintainer should
 > reject patches that add either without also adding documentation to
 > the standard list.[*])
 
 sup -l is supposed to produce all the hook documentation you'd need,
 assuming a reasonable knowledge of Ruby.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Oct  6 13:30:09 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Oct 2009 10:30:09 -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: <1254850185-sup-1817@masanjin.net>
 
 Reformatted excerpts from Carl Worth's message of 2009-08-26:
 > This is just a copy of SearchResultsMode's refine_search command.  A
 > much cleaner, but more involved, approach would be to rework InboxMode
 > to derive from SearchResultsMode in the first place.
 
 Branch refine-inbox-mode, merged into next. Sorry for the long delay.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From mailinglist@flasht.de  Tue Oct  6 16:35:46 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Tue, 06 Oct 2009 22:35:46 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254842820-sup-9099@masanjin.net>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1254758256-sup-7400@thinkpad-ubuntu>
 	<1254842820-sup-9099@masanjin.net>
 Message-ID: <1254861112-sup-590@thinkpad-ubuntu>
 
 Excerpts from William Morgan's message of Di Okt 06 17:38:39 +0200 2009:
 > This looks great. A couple comments:
 
 Cool, good to know you like it!
 
 > 1. I would prefer that uppercase substitution symbols made lowercase.
 > The uppercase seems weird and un-Rubyish to me.
 
 Ok, sounds good. I thought making them uppercase to let them be more
 distict from the rest of the string but since we surround them by #{}
 as in Ruby, you're making a good point here. I'll change that.
 
 > 2. I think it would be nice to have a simple module along the lines of:
 > 
 >   module M17n
 >     def m s, o={}; I18n[m, o] end
 >   end
 > 
 > and to have that be the primary entry point when you want a translated
 > string. Then classes can include that module if they want m17n support,
 > and instead of writing
 > 
 >   I18n["text", { :var => value }]
 > 
 > you can have
 > 
 >   m("text", :var => value)
 > 
 > which is a little easier to read, IMO.
 
 Same here. Think this is nicer, too.
 
 > 3. Should we call it m17n instead of i18n? I think that might be a
 > little more accurate. Perhaps too nitpicky. What do you think?
 
 I couldn't care less about the name - but I guess m17n fits better,
 since it's just multilingualization. :)
 
 > 4. A finishing touch would be to have sup-config ask the user what
 > language they are interested in.
 
 Alright, cool. I'll add that as well, once I have the rest changed & working.
 
 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/20091006/d19a9780/attachment.bin>
 
 From mailinglist@flasht.de  Tue Oct  6 17:56:19 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Tue, 06 Oct 2009 23:56:19 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254861112-sup-590@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1254758256-sup-7400@thinkpad-ubuntu>
 	<1254842820-sup-9099@masanjin.net>
 	<1254861112-sup-590@thinkpad-ubuntu>
 Message-ID: <1254866136-sup-6974@thinkpad-ubuntu>
 
 OK, I've changed it as mentioned.
 See my previously mentioned gitorious branch.
 
 Cheers,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 
 From ezyang@MIT.EDU  Tue Oct  6 18:44:09 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Tue, 06 Oct 2009 18:44:09 -0400
 Subject: [sup-talk] Bugfix for custom-search
 In-Reply-To: <1254418685-sup-6611@javelin>
 References: <1254418685-sup-6611@javelin>
 Message-ID: <1254869038-sup-9250@javelin>
 
 Excerpts from Edward Z. Yang's message of Thu Oct 01 13:38:27 -0400 2009:
 > I think there's a slight bug in the custom-search implementation.
 
 Any comments?
 
 Cheers,
 Edward
 
 From rlane@club.cc.cmu.edu  Wed Oct  7 02:44:34 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 07 Oct 2009 02:44:34 -0400
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1254845543-sup-9458@ben-laptop>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop>
 Message-ID: <1254896214-sup-5969@zyrg.net>
 
 Excerpts from Ben Gamari's message of Tue Oct 06 12:15:46 -0400 2009:
 > Excerpts from Ben Gamari's message of Tue Oct 06 11:53:18 -0400 2009:
 > > Well, it seems like whatever caused the crash earlier did something to
 > > my index. Now any attempt to open a thread-index-mode of my LKML label
 > > (which I was viewing in the earlier crash) causes the client to
 > > immediately crash.
 > > 
 > 
 > Hmm, it seems like the problem is spreading. I now come to find out that
 > another label triggers this same crash (although I guess it's possible
 > that the intersection of the two labels is non-nil). I tried running a
 > sup-sync -oc on the relevant sources to no avail. I really don't have
 > time to devote to debugging this at the moment so it looks like I might
 > need to take another hiatus from sup. Just as I was starting to get used
 > to it... sigh. Anyways, if anyone has any ideas for improving things,
 > let me know. Thanks!
 
 I've been seeing this crash for a long time. I think it's a race between
 the poll thread / load-more-threads thread and the rest of the UI in the
 main thread. Basically any operation on a thread object in
 ThreadIndexMode needs to be protected against ThreadSet#add_message (and
 probably other ThreadSet methods) because add_message can remove
 containers from the thread tree, leaving you with an empty thread whose
 "date" method returns nil.
 
 You could try running sup with the -n flag to disable threading. The
 major downside is that you have to hit P to poll manually.
 
 I look forward to having a sup-server - I plan on writing a little
 android client in Scala using actors. Almost no mutable state and
 absolutely no ncurses.
 
 From guillaume.quintard@gmail.com  Wed Oct  7 04:48:56 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Wed, 7 Oct 2009 10:48:56 +0200
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1254896214-sup-5969@zyrg.net>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net>
 Message-ID: <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 
 On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > You could try running sup with the -n flag to disable threading. The
 > major downside is that you have to hit P to poll manually.
 
 That "solves" the problem for me.
 
 -- 
 Guillaume
 
 From guillaume.quintard@gmail.com  Wed Oct  7 05:07:47 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Wed, 7 Oct 2009 11:07:47 +0200
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net>
 	<1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 Message-ID: <1e5fdab70910070207q3aada8d7y2e2482e0dbbe8bd2@mail.gmail.com>
 
 On Wed, Oct 7, 2009 at 10:48 AM, Guillaume Quintard
 <guillaume.quintard at gmail.com> wrote:
 > That "solves" the problem for me.
 
 Scratch that, I just relaunched sup, and I still get the wrong id
 called on nil error.
 
 -- 
 Guillaume
 
 From gregor@hoffleit.de  Wed Oct  7 06:52:34 2009
 From: gregor@hoffleit.de (Gregor Hoffleit)
 Date: Wed, 07 Oct 2009 12:52:34 +0200
 Subject: [sup-talk] [PATCH] Attachment filenames: RFC2184 and extension
 	guessing
 Message-ID: <1254912361-sup-5340@sam.mediasupervision.de>
 
 I noticed sup has trouble handling attachments sent by Roundcube
 webmail. Somehow, those mails use an alternative encoding of filenames,
 specified in RFC2184:
 
     Content-Transfer-Encoding: base64
     Content-Type: image/jpeg;
      name*="UTF-8''20090912-i004232-gr000.jpg"; 
     Content-Disposition: attachment;
      filename*="UTF-8''20090912-i004232-gr000.jpg"; 
 
 Bugs:
 
 1. Sup fails to detect these filenames.
 
 2. When trying to save these attachements, the filenames generated by
    sup have a trailing semicolon.
 
 The attached patch is a quick and dirty fix for these specific problems.
 There's probably a better way to implement this.
 
 Regards,
     Gregor Hoffleit
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: rfc2184.diff
 Type: application/octet-stream
 Size: 954 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091007/636afab0/attachment.obj>
 
 From bgamari.foss@gmail.com  Wed Oct  7 18:42:09 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Wed, 07 Oct 2009 18:42:09 -0400
 Subject: [sup-talk] Fwd: Re:  Crash while in thread-view-mode
 Message-ID: <1254955312-sup-7085@ben-laptop>
 
 Excerpts from Guillaume Quintard's message of Wed Oct 07 04:48:56 -0400 2009:
 > On Wed, Oct 7, 2009 at 8:44 AM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > > You could try running sup with the -n flag to disable threading. The
 > > major downside is that you have to hit P to poll manually.
 > 
 > That "solves" the problem for me.
 > 
 
 After going through the process of rebuilding my index (again), things
 seem to be more stable (for now). I understand that designing software around a
 contingency like this might not be the best practice, but the frequency
 with which I've needed to rebuild really does make me think that ruby
 isn't the best language for the indexer.
 
 This is easily the fifth time I've needed to rebuild and each time it
 has taken over 30 minutes for 1.5 GB of mail. That's substantially less than
 1MB/second for what should be an I/O bound operation. Ouch. It'll be
 really interesting to see how Carl's work comes out.
 
 - Ben
 
 From bgamari.foss@gmail.com  Wed Oct  7 18:46:39 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Wed, 07 Oct 2009 18:46:39 -0400
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1254945119-sup-3401@ben-laptop>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net>
 	<1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 	<1254945119-sup-3401@ben-laptop>
 Message-ID: <1254955351-sup-5944@ben-laptop>
 
 Excerpts from Ben Gamari's message of Wed Oct 07 15:56:43 -0400 2009:
 > After going through the process of rebuilding my index (again), things
 > seem to be more stable (for now). 
 
 Well, this was true for a while. Unfortunately, it seems that my LKML
 label is yet again crashing sup. The exception is very similar to that
 which I experienced prior to rebuilding. It's quite reproducible, always
 crashing after loading a few hundred messages or so. There must be a
 better way to deal with these invalid ids than crashing. Is there any
 reason this needs to be a show-stopping event? Thanks,
 
 - Ben
 
 
 --- 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'
 /opt/exp/sup/lib/sup/hook.rb:121: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:117:in `each_id_by_date'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:117: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:81:in `initialize'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `call'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `each'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `new'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:54:in `initialize'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:9:in `initialize'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `new'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
 /opt/exp/sup/lib/sup/buffer.rb:350:in `spawn_unless_exists'
 /opt/exp/sup/lib/sup/util.rb:520:in `send'
 /opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
 /opt/exp/sup/lib/sup/modes/label-list-mode.rb:103:in `select_label'
 /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:239
 
 From stettberger@dokucode.de  Thu Oct  8 03:05:47 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Thu, 08 Oct 2009 09:05:47 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1254516195-sup-4619@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 Message-ID: <1254985425-sup-2303@peer.zerties.org>
 
 Excerpts from Christian Dietrich's message of Fr Okt 02 22:48:24 +0200 2009:
 > Thank you, that helped a much. I implemented the feature, it is
 > available at git://github.com/stettberger/sup-mail.git
 > branch time_marks, it is one commit ahead of next. It is enabled
 > with setting the config option ":time_markers_in_index_mode: true"
 > At runtime it can be toggled via '%' (just randomly choosen by me)
 
 Ok now i did a little bit of reworking the code (don't make it sup
 crash :-) and added a little bit color). The is now
 :time_marker_color. I attached a screenshot of the time_marks.
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-time-mark.png
 Type: image/png
 Size: 38362 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/89c94173/attachment.png>
 
 From mailinglist@flasht.de  Thu Oct  8 08:31:24 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 08 Oct 2009 14:31:24 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1254985425-sup-2303@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 Message-ID: <1255005056-sup-7120@thinkpad-ubuntu>
 
 Excerpts from Christian Dietrich's message of Do Okt 08 09:05:47 +0200 2009:
 > Ok now i did a little bit of reworking the code (don't make it sup
 > crash :-) and added a little bit color). The is now
 > :time_marker_color. I attached a screenshot of the time_marks.
 
 Looks really cool, I'll give it a try :)
 -- 
 ================================
 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/20091008/91e8eba7/attachment.bin>
 
 From mailinglist@flasht.de  Thu Oct  8 08:44:32 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 08 Oct 2009 14:44:32 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255005056-sup-7120@thinkpad-ubuntu>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 Message-ID: <1255005777-sup-7020@thinkpad-ubuntu>
 
 Ok, I like it so far. But what would really rock (IMO) would be the
 possibility to collapse all messages, that are from yesterday or 2
 weeks ago etc.
 What do you think?
 -- 
 ================================
 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/20091008/88002eca/attachment.bin>
 
 From stettberger@dokucode.de  Thu Oct  8 14:28:59 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Thu, 08 Oct 2009 20:28:59 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255005777-sup-7020@thinkpad-ubuntu>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 Message-ID: <1255026503-sup-3624@peer.zerties.org>
 
 Excerpts from Christopher Bertels's message of Do Okt 08 14:44:32 +0200 2009:
 > Ok, I like it so far. But what would really rock (IMO) would be the
 > possibility to collapse all messages, that are from yesterday or 2
 > weeks ago etc.
 > What do you think?
 
 Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
 (after pulling)
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From nicolas.pouillard@gmail.com  Thu Oct  8 15:24:21 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Thu, 08 Oct 2009 21:24:21 +0200
 Subject: [sup-talk] Ruby 1.9 status?
 Message-ID: <1255029826-sup-8182@peray>
 
 Hi all,
 
 I would like to know what is the sup status w.r.t ruby 1.9?
 
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From mailinglist@flasht.de  Thu Oct  8 15:33:44 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 08 Oct 2009 21:33:44 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255026503-sup-3624@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 Message-ID: <1255030392-sup-1135@thinkpad-ubuntu>
 
 Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
 > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
 > (after pulling)
 
 Indeed, very nice. Thanks :)
 I'd like to see this in sup's mainline, btw :)
 -- 
 ================================
 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: 969 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1e566f11/attachment.bin>
 
 From eg@gaute.vetsj.com  Thu Oct  8 15:44:30 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Thu, 08 Oct 2009 21:44:30 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255030392-sup-1135@thinkpad-ubuntu>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 Message-ID: <1255031039-sup-4070@qwerzila>
 
 Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009:
 > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
 > > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
 > > (after pulling)
 > 
 > Indeed, very nice. Thanks :)
 > I'd like to see this in sup's mainline, btw :)
 
 +1 ! Looks great!
 
 - 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/20091008/e0c720ab/attachment.bin>
 
 From benoit.pierre@gmail.com  Thu Oct  8 16:04:10 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Thu, 08 Oct 2009 22:04:10 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255026503-sup-3624@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 Message-ID: <1255032019-sup-3406@localdomain>
 
 Excerpts from Christian Dietrich's message of Thu Oct 08 20:28:59 +0200 2009:
 > Excerpts from Christopher Bertels's message of Do Okt 08 14:44:32 +0200 2009:
 > > Ok, I like it so far. But what would really rock (IMO) would be the
 > > possibility to collapse all messages, that are from yesterday or 2
 > > weeks ago etc.
 > > What do you think?
 > 
 > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
 > (after pulling)
 
 This is great, I love it. Attached 2 small patches:
 - fix a warning (space before opening parenthesis in function call)
 - fix a bug with thread selection when time marks are not visible
 
 Cheers,
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-warning-fix.patch
 Type: application/octet-stream
 Size: 770 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1336c51c/attachment.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0002-fix-selection-when-time-marks-are-disabled.patch
 Type: application/octet-stream
 Size: 1114 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1336c51c/attachment-0001.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 243 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/1336c51c/attachment.bin>
 
 From eg@gaute.vetsj.com  Thu Oct  8 16:12:31 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Thu, 08 Oct 2009 22:12:31 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255031039-sup-4070@qwerzila>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila>
 Message-ID: <1255032615-sup-8961@qwerzila>
 
 Excerpts from Gaute Hope's message of to. okt. 08 21:44:30 +0200 2009:
 > Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009:
 > > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
 > > > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
 > > > (after pulling)
 
 Would be nice if the '1' keybinding would select the first message and
 not the first line. Possibly another binding to collapse the current day when
 a message is selected (maybe h or E to keep things similar to the
 message view)?
 
 - 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/20091008/814823ee/attachment.bin>
 
 From benoit.pierre@gmail.com  Thu Oct  8 16:26:12 2009
 From: benoit.pierre@gmail.com (=?utf-8?q?Beno=C3=AEt_PIERRE?=)
 Date: Thu, 08 Oct 2009 22:26:12 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255032615-sup-8961@qwerzila>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 Message-ID: <1255033079-sup-8556@localdomain>
 
 Excerpts from Gaute Hope's message of Thu Oct 08 22:12:31 +0200 2009:
 > Excerpts from Gaute Hope's message of to. okt. 08 21:44:30 +0200 2009:
 > > Excerpts from Christopher Bertels's message of to. okt. 08 21:33:44 +0200 2009:
 > > > Excerpts from Christian Dietrich's message of Do Okt 08 20:28:59 +0200 2009:
 > > > > Yeah thats cool, i implemented it, just type <Enter> on a Time Mark
 > > > > (after pulling)
 > 
 > Would be nice if the '1' keybinding would select the first message and
 > not the first line. Possibly another binding to collapse the current day when
 > a message is selected (maybe h or E to keep things similar to the
 > message view)?
 
 And 't' should select the next thread, not the next line. 'a' and 'A'
 too, in fact a time tag should only be selectable manually, using
 Up/Down or 'j'/'k'. Or never if collapsing/expending is possible with a
 mapping (my vote goes to 'E').
 
 Cheers,
 -- 
 A: Because it destroys the flow of conversation.
 Q: Why is top posting dumb?
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 197 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091008/ab965140/attachment.bin>
 
 From stettberger@dokucode.de  Thu Oct  8 16:50:07 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Thu, 08 Oct 2009 22:50:07 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255032615-sup-8961@qwerzila>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 Message-ID: <1255034958-sup-5628@peer.zerties.org>
 
 > Would be nice if the '1' keybinding would select the first message and
 > not the first line. Possibly another binding to collapse the current day when
 > a message is selected (maybe h or E to keep things similar to the
 > message view)?
 
 Yeah, implemented that, and the other two patches in the branch,
 like the idea.
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From stettberger@dokucode.de  Fri Oct  9 03:19:30 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Fri, 09 Oct 2009 09:19:30 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255033079-sup-8556@localdomain>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255033079-sup-8556@localdomain>
 Message-ID: <1255072730-sup-9414@peer.zerties.org>
 
 > And 't' should select the next thread, not the next line. 'a' and 'A'
 > too, in fact a time tag should only be selectable manually, using
 > Up/Down or 'j'/'k'. Or never if collapsing/expending is possible with a
 > mapping (my vote goes to 'E').
 
 Jep thats right, i fixed that. Please pull.
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From eg@gaute.vetsj.com  Fri Oct  9 03:31:38 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Fri, 09 Oct 2009 09:31:38 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255034958-sup-5628@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 Message-ID: <1255073126-sup-6984@qwerzila>
 
 Excerpts from Christian Dietrich's message of to. okt. 08 22:50:07 +0200 2009:
 > > Would be nice if the '1' keybinding would select the first message and
 > > not the first line. Possibly another binding to collapse the current day when
 > > a message is selected (maybe h or E to keep things similar to the
 > > message view)?
 > 
 > Yeah, implemented that, and the other two patches in the branch,
 > like the idea.
 
 This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding the
 Today marker (same as hitting 'J' one time). 0 works like expected.
 
 a/A/&/d/S/t and E seems to be working alright.
 
 - 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/20091009/0258c39f/attachment.bin>
 
 From stettberger@dokucode.de  Fri Oct  9 03:44:02 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Fri, 09 Oct 2009 09:44:02 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255073126-sup-6984@qwerzila>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 	<1255073126-sup-6984@qwerzila>
 Message-ID: <1255074206-sup-7503@peer.zerties.org>
 
 Excerpts from Gaute Hope's message of Fr Okt 09 09:31:38 +0200 2009:
 > This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding
 > the
 > Today marker (same as hitting 'J' one time). 0 works like expected.
 > 
 > a/A/&/d/S/t and E seems to be working alright.
 
 Yeah ok, that should be fixed now. (I didn't even now about this
 keystroke before...)
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From eg@gaute.vetsj.com  Fri Oct  9 05:45:13 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Fri, 09 Oct 2009 11:45:13 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255074206-sup-7503@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 	<1255073126-sup-6984@qwerzila>
 	<1255074206-sup-7503@peer.zerties.org>
 Message-ID: <1255081131-sup-7915@qwerzila>
 
 Excerpts from Christian Dietrich's message of fr. okt. 09 09:44:02 +0200 2009:
 > Excerpts from Gaute Hope's message of Fr Okt 09 09:31:38 +0200 2009:
 > > This doesn't work for me: '1'/'^' just makes the view scroll one down; hiding
 > > the
 > > Today marker (same as hitting 'J' one time). 0 works like expected.
 > > 
 > > a/A/&/d/S/t and E seems to be working alright.
 > 
 > Yeah ok, that should be fixed now. (I didn't even now about this
 > keystroke before...)
 
 Just discovered a weird bug.. when this thread got polled and updated
 the message count, in this case (13), got attached to the thread
 beneath, which only had one message, and appeared where it shouldn't be
 anything.. the top thread didn't have any post count. It seemed to only
 have affected the top two messages, as the count on the third one seemed
 normal.
 
 Not entierly sure what caused it since I can't really reproduce it by
 sending myself emails.. if it happens again ill post screenshot.
 
 Im using time_marker branch rebased ontop of origin/next.
 
 - 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/20091009/8bac691b/attachment.bin>
 
 From eg@gaute.vetsj.com  Fri Oct  9 06:12:21 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Fri, 09 Oct 2009 12:12:21 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255081131-sup-7915@qwerzila>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 	<1255073126-sup-6984@qwerzila>
 	<1255074206-sup-7503@peer.zerties.org>
 	<1255081131-sup-7915@qwerzila>
 Message-ID: <1255083021-sup-226@qwerzila>
 
 Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009:
 > Not entierly sure what caused it since I can't really reproduce it by
 > sending myself emails.. if it happens again ill post screenshot.
 > 
 > Im using time_marker branch rebased ontop of origin/next.
 
 Ok.. now the top message count just got copied down to the line
 beneath (which should be empty). Sup had just been running for a while,
 no new messages, didn't happen on first pool..
 
 - gaute
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 2009-10-09-120801_634x755_scrot.png
 Type: image/png
 Size: 29135 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091009/58f1eb31/attachment.png>
 -------------- 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/20091009/58f1eb31/attachment.bin>
 
 From stettberger@dokucode.de  Fri Oct  9 06:39:27 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Fri, 09 Oct 2009 12:39:27 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255083021-sup-226@qwerzila>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 	<1255073126-sup-6984@qwerzila>
 	<1255074206-sup-7503@peer.zerties.org>
 	<1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila>
 Message-ID: <1255084730-sup-671@peer.zerties.org>
 
 Excerpts from Gaute Hope's message of Fr Okt 09 12:12:21 +0200 2009:
 > Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009:
 > > Not entierly sure what caused it since I can't really reproduce it by
 > > sending myself emails.. if it happens again ill post screenshot.
 > > 
 > > Im using time_marker branch rebased ontop of origin/next.
 > 
 > Ok.. now the top message count just got copied down to the line
 > beneath (which should be empty). Sup had just been running for a while,
 > no new messages, didn't happen on first pool..
 
 I have no idea whats causing this, seems like the data of two
 threads is mixed together?
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From eg@gaute.vetsj.com  Fri Oct  9 07:00:19 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Fri, 09 Oct 2009 13:00:19 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255084730-sup-671@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 	<1255073126-sup-6984@qwerzila>
 	<1255074206-sup-7503@peer.zerties.org>
 	<1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila>
 	<1255084730-sup-671@peer.zerties.org>
 Message-ID: <1255085867-sup-8410@qwerzila>
 
 Excerpts from Christian Dietrich's message of fr. okt. 09 12:39:27 +0200 2009:
 > Excerpts from Gaute Hope's message of Fr Okt 09 12:12:21 +0200 2009:
 > > Excerpts from Gaute Hope's message of fr. okt. 09 11:45:13 +0200 2009:
 > > > Not entierly sure what caused it since I can't really reproduce it by
 > > > sending myself emails.. if it happens again ill post screenshot.
 > > > 
 > > > Im using time_marker branch rebased ontop of origin/next.
 > > 
 > > Ok.. now the top message count just got copied down to the line
 > > beneath (which should be empty). Sup had just been running for a while,
 > > no new messages, didn't happen on first pool..
 > 
 > I have no idea whats causing this, seems like the data of two
 > threads is mixed together?
 
 Or the thread count isn't aware of the Today mark and still thinks line
 2 is thread 2? Don't really know anything about the implementation.
 
 When it happens it doesn't dissapear before I do a M or there is a pull
 that redraws the screen.. just pressing Ctrl+L or opening/closing a
 thread doesn't remove it.
 
 As said earlier it only seems to affect the top two threads.
 
 - 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/20091009/de9efe70/attachment.bin>
 
 From tero@tilus.net  Sat Oct 10 03:21:33 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Sat, 10 Oct 2009 10:21:33 +0300
 Subject: [sup-talk] [PATCH] moved deriving the cmd for bouncing to Account
 	and fixed a bug in it
 Message-ID: <1255159160-sup-8754@tilus.net>
 
 The default sendmail command used for bouncing mail was derived from
 Account#sendmail in ThreadViewMode#bounce.  Moved it to
 Account#bounce_sendmail.  Part of work towards more DRY mail bouncing
 within mark-as-spam hook. The code also had a bug, "$1" (instead of $1
 or "#{$1}").  Fixed it.
 
 Signed-off-by: Tero Tilus <tero at tilus.net>
 ---
  lib/sup/account.rb                |   11 +++++++++++
  lib/sup/modes/thread-view-mode.rb |    7 +------
  2 files changed, 12 insertions(+), 6 deletions(-)
 
 diff --git a/lib/sup/account.rb b/lib/sup/account.rb
 index eed2794..bf8a8a0 100644
 --- a/lib/sup/account.rb
 +++ b/lib/sup/account.rb
 @@ -10,6 +10,17 @@ class Account < Person
      @sendmail = h[:sendmail]
      @signature = h[:signature]
    end
 +
 +  # Default sendmail command for bouncing mail,
 +  # deduced from #sendmail
 +  def bounce_sendmail
 +    sendmail.sub(/\s(\-(ti|it|t))\b/) do |match|
 +      case $1
 +      when '-t' then ''
 +      else ' -i'
 +      end
 +    end
 +  end
  end
  
  class AccountManager
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 81197c2..e7f4a4f 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -202,12 +202,7 @@ EOS
      m = @message_lines[curpos] or return
      to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return
  
 -    defcmd = AccountManager.default_account.sendmail.sub(/\s(\-(ti|it|t))\b/) do |match|
 -      case "$1"
 -        when '-t' then ''
 -        else ' -i'
 -      end
 -    end
 +    defcmd = AccountManager.default_account.bounce_sendmail
  
      cmd = case (hookcmd = HookManager.run "bounce-command", :from => m.from, :to => to)
            when nil, /^$/ then defcmd
 -- 
 1.5.6.5
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From sven.schober@uni-ulm.de  Sat Oct 10 08:01:14 2009
 From: sven.schober@uni-ulm.de (Sven Schober)
 Date: Sat, 10 Oct 2009 14:01:14 +0200
 Subject: [sup-talk] pinentry-curses messes up sup
 Message-ID: <1255175624-sup-8207@hysbald>
 
 Hi Suppers!
 
 First of all, let me say i really enjoy using sup :) Thanks for the
 great mua!
 
 No to my problem: I'm experiencing the problem described by Nicolas
 Pouillard, here [1]. After using pinentry-curses to enter my gpg
 passphrase sup seems to be a little messed up, as the arrow keys
 won't work any more, or at least, not as expected (pressing left has
 horrendous consequences as its control sequence seems to be ^[[D,
 which caused some major mail deletion for me *g*).
 
 As that thread is rather old, i would like to now if there's been
 some development on this? Are there any console alternatives to
 pinentry-curses?
 
 
 Keep up the good work!
 
 Cheers,
  Sven
 
 
 [1]:<http://rubyforge.org/pipermail/sup-talk/2008-January/000959.html>
 -- 
 Sven Schober, sven.schober at uni-ulm.de                    |UNI ULM
 http://www-vs.informatik.uni-ulm.de/dept/staff/schober/  |DISTRIBUTED
 Room O27-346, Phone: +49-731-5024146 [+49-179-5060182]   |SYSTEMS LAB
 -------------- 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/20091010/fa2d56e4/attachment.bin>
 
 From mailinglist@flasht.de  Sat Oct 10 10:41:29 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Sat, 10 Oct 2009 16:41:29 +0200
 Subject: [sup-talk] show labels of polled messages
 Message-ID: <1255184817-sup-1561@thinkpad-ubuntu>
 
 Hi,
 
 I always thought it would be nice to see to which labels new polled
 messages have been added. Usually, when I see new messages arrived,
 most of them aren't in my inbox, since I archive the messages of most
 of my sources (e.g. mailinglists like this one).
 
 Then, I usually go and look at the labels-list-mode to see where new
 messages got added. I've attached a patch that displays the labels of
 newly polled messages at the bottom, next to the amount of total
 messages added from polling. The patch is based on my i18n branch, but
 it should be easy to rebase it on next or master.
 
 What do you think of it?
 
 Cheers,
 Christopher.
 -- 
 ================================
 Christopher Bertels
 http://www.adztec-independent.de
 GPG Key ID: 0x2345b203
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: label_notification.patch
 Type: application/octet-stream
 Size: 3505 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091010/ee06edf8/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/20091010/ee06edf8/attachment.bin>
 
 From kevinr@free-dissociation.com  Sat Oct 10 16:56:46 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Sat, 10 Oct 2009 16:56:46 -0400
 Subject: [sup-talk] Exception in thread-view-mode
 Message-ID: <1255208137-sup-835@black-opal.mit.edu>
 
 I ran a search, I hit enter to load a message, I changed my mind and 'x'ed out
 before the message finished loading, and Sup crashed with:
 
 --- NoMethodError from thread: load messages for thread-view-mode
 undefined method `content_width' for nil:NilClass
 ./lib/sup/modes/thread-index-mode.rb:882:in `from_width'
 ./lib/sup/modes/thread-index-mode.rb:807:in `text_for_thread_at'
 ./lib/sup/hook.rb:122:in `each_with_index'
 ./lib/sup/modes/thread-index-mode.rb:806:in `each'
 ./lib/sup/modes/thread-index-mode.rb:806:in `each_with_index'
 ./lib/sup/modes/thread-index-mode.rb:806:in `text_for_thread_at'
 ./lib/sup/modes/thread-index-mode.rb:751:in `update_text_for_line'
 ./lib/sup/modes/thread-index-mode.rb:119: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:239
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 http://free-dissociation.com
 
 From wmorgan-sup@masanjin.net  Sun Oct 11 16:25:33 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Oct 2009 13:25:33 -0700
 Subject: [sup-talk] pinentry-curses messes up sup
 In-Reply-To: <1255175624-sup-8207@hysbald>
 References: <1255175624-sup-8207@hysbald>
 Message-ID: <1255292709-sup-2216@masanjin.net>
 
 Reformatted excerpts from Sven Schober's message of 2009-10-10:
 > As that thread is rather old, i would like to now if there's been some
 > development on this? Are there any console alternatives to
 > pinentry-curses?
 
 I think I've fixed this in git next. Please try that.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Oct 11 16:28:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Oct 2009 13:28:48 -0700
 Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode
 In-Reply-To: <1254955312-sup-7085@ben-laptop>
 References: <1254955312-sup-7085@ben-laptop>
 Message-ID: <1255292742-sup-3957@masanjin.net>
 
 Reformatted excerpts from Ben Gamari's message of 2009-10-07:
 > I understand that designing software around a contingency like this
 > might not be the best practice, but the frequency with which I've
 > needed to rebuild really does make me think that ruby isn't the best
 > language for the indexer.
 
 The indexer isn't in Ruby, it's written in C++ in the case of Xapian and
 C in the case of Ferret.
 
 > This is easily the fifth time I've needed to rebuild and each time it
 > has taken over 30 minutes for 1.5 GB of mail. That's substantially
 > less than 1MB/second for what should be an I/O bound operation. Ouch.
 
 I think this isn't the indexer's fault so much as the mbox parsing,
 which is Ruby.
 
 I'm sorry you've had to rebuild the index so many times. The Xapian side
 of things is very new, and I think you've had a run of bad luck. But I
 am personally not motivated to improve index time performance, because
 that's not a common event. At least, it shouldn't be.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Oct 11 16:30:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Oct 2009 13:30:08 -0700
 Subject: [sup-talk] curses exception
 In-Reply-To: <ed5557340910061533w7854510tabe9bb2fc864db09@mail.gmail.com>
 References: <ed5557340910061533w7854510tabe9bb2fc864db09@mail.gmail.com>
 Message-ID: <1255292940-sup-5558@masanjin.net>
 
 Reformatted excerpts from Dan Falcone's message of 2009-10-06:
 > I'm trying to get sup running on my work machine, which is unfortunately a
 > windows box.  I have cygwin installed, along with the cygwin packages for
 > ruby and ncurses.  Here's the contents of ~/.sup/exception-log.txt:
 > 
 > --- ArgumentError from thread: main
 > couldn't initialize curses color pair 4, -1 (key 1)
 > /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/colormap.rb:133:in `color_for'
 
 Weird. We've had other people get it working on Cygwin before, I
 believe. Are you running this within Cygwin's rxvt?
 
 What if you modify lib/sup/colormap.rb so that NUM_COLORS=15?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Oct 11 16:31:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Oct 2009 13:31:49 -0700
 Subject: [sup-talk] Crash while scrolling
 In-Reply-To: <1254422805-sup-9288@ben-laptop>
 References: <20090911165830.GA11260@ben-laptop>
 	<1252773189-sup-246@masanjin.net>
 	<20090916172340.GA20566@ben-laptop>
 	<1253975267-sup-8308@masanjin.net> <1254160696-sup-3522@ben-laptop>
 	<1254404181-sup-8448@masanjin.net> <1254418089-sup-5800@ben-laptop>
 	<1254421545-sup-8303@masanjin.net> <1254422805-sup-9288@ben-laptop>
 Message-ID: <1255293077-sup-9788@masanjin.net>
 
 Reformatted excerpts from Ben Gamari's message of 2009-10-01:
 > Is ferret even going to be supported after the Xapian backend
 > stabilizes?
 
 No, I'm going to drop it at some point. I barely have enough time or
 energy for Sup's current set of problems as is. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bgamari.foss@gmail.com  Sun Oct 11 17:04:53 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Sun, 11 Oct 2009 17:04:53 -0400
 Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode
 In-Reply-To: <1255292742-sup-3957@masanjin.net>
 References: <1254955312-sup-7085@ben-laptop> <1255292742-sup-3957@masanjin.net>
 Message-ID: <1255294905-sup-8@ben-laptop>
 
 Excerpts from William Morgan's message of Sun Oct 11 16:28:48 -0400 2009:
 > Reformatted excerpts from Ben Gamari's message of 2009-10-07:
 > > I understand that designing software around a contingency like this
 > > might not be the best practice, but the frequency with which I've
 > > needed to rebuild really does make me think that ruby isn't the best
 > > language for the indexer.
 > 
 > The indexer isn't in Ruby, it's written in C++ in the case of Xapian and
 > C in the case of Ferret.
 
 Sorry, I was referring to the mail indexer (i.e. message,
 mbox/maildir parser), not the backend indexing engine (e.g. Xapian).
 Should have been more specific. 
 
 
 > 
 > > This is easily the fifth time I've needed to rebuild and each time it
 > > has taken over 30 minutes for 1.5 GB of mail. That's substantially
 > > less than 1MB/second for what should be an I/O bound operation. Ouch.
 > 
 > I think this isn't the indexer's fault so much as the mbox parsing,
 > which is Ruby.
 
 Exactly. This is where I think C++ is probably appropriate.
 > 
 > I'm sorry you've had to rebuild the index so many times. The Xapian side
 > of things is very new, and I think you've had a run of bad luck. But I
 > am personally not motivated to improve index time performance, because
 > that's not a common event. At least, it shouldn't be.
 
 Completely understandable. I really don't have a right to complain. It
 does work a large majority of the time, after all. Just figured I'd let
 you know of problems as they happen. Thanks for the awesome client.
 
 - Ben
 
 From stettberger@dokucode.de  Mon Oct 12 03:11:35 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Mon, 12 Oct 2009 09:11:35 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255085867-sup-8410@qwerzila>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 	<1255073126-sup-6984@qwerzila>
 	<1255074206-sup-7503@peer.zerties.org>
 	<1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila>
 	<1255084730-sup-671@peer.zerties.org>
 	<1255085867-sup-8410@qwerzila>
 Message-ID: <1255331296-sup-5993@peer.zerties.org>
 
 Excerpts from Gaute Hope's message of Fr Okt 09 13:00:19 +0200 2009:
 > Or the thread count isn't aware of the Today mark and still thinks line
 > 2 is thread 2? Don't really know anything about the implementation.
 > 
 > When it happens it doesn't dissapear before I do a M or there is a pull
 > that redraws the screen.. just pressing Ctrl+L or opening/closing a
 > thread doesn't remove it.
 > 
 > As said earlier it only seems to affect the top two threads.
 
 Hi,
 i also experienced now this Problem, but can't see were this problem
 is located, because i don't touch the internal states of the
 threads. There must be one @thread[curpos] left, which causes this
 Problem.
 
 greetz didi
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 08:14:42 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 05:14:42 -0700
 Subject: [sup-talk] Ruby 1.9 status?
 In-Reply-To: <1255029826-sup-8182@peray>
 References: <1255029826-sup-8182@peray>
 Message-ID: <1255349584-sup-5924@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-10-08:
 > I would like to know what is the sup status w.r.t ruby 1.9?
 
 The code is syntactically ready for 1.9. There's a Ferret 1.9 gem as of
 recently, which you can try. Someone wrote a blog post here:
 
 http://trickyco.de/2009/09/24/installing-the-sup-mua-on-64bit-arch-linux
 
 And made some patches, which I haven't had a chance to review yet.
 
 At some point I tried Xapian with 1.9 and ran into some weird errors. If
 you search the mailing list, you should find it.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 08:48:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 05:48:50 -0700
 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first
 In-Reply-To: <1253911610-sup-2052@yoom.home.cworth.org>
 References: <1253911610-sup-2052@yoom.home.cworth.org>
 Message-ID: <1255350472-sup-5679@masanjin.net>
 
 Hi Carl & Keith,
 
 Reformatted excerpts from Carl Worth's message of 2009-09-25:
 > The below patches are a first cut at implementing this.
 
 I've finally gotten a chance to look at this. It looks good so far. I
 would like to merge this in in such a way that it doesn't change
 behavior for anyone who doesn't want it.
 
 So I definitely don't want the second patch which changes the default
 order. The configuration boolean is fine. (And if you want to add a
 question to sup-config, that's icing on the cake.)
 
 I would also like to disable forcing the loading of all messages.
 Personalyl, I follow the inbox 30,000 philosophy. The 'o' keybinding is
 cool, but if I scroll down then suddenly the thread loading goes crazy.
 For those who have inboxes that are small enough to load but bigger than
 one screen (the "reverse inbox 50" crowd), I don't think that pressing
 !! is too onerous.
 
 > 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.
 
 It is possible in Ferret: remove the DESC in ferret_index.rb line 160.
 It is also possible in Xapian, but we're building the Xapian index to
 optimize newest-first access. (Of course that would also be possible to
 change, but then we're talking about a total index rebuild.)
 
 If you wanted to tweak that, the load-all-threads wouldn't be necessary.
 
 Either way, I'm happy to merge the first patch with the "n = -1" thing
 removed.
 
 > 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.)
 
 Pretty easy to change. In thread.rb, there's a date method which takes a
 max; you can make it take a min instead.
 
 The hard work for both of these things is wiring this option through.
 Although $config is a global variable, I don't really want to use it
 directly in e.g. thread.rb.
 
 > PS. We're still total ruby newbies, so please point out any silly
 > mistakes we're missing with respect to ruby idioms.
 
 Everything looks good. The only slgihtly non-idiomatic thing is using
 "if !x" instead of "unless x".
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 09:30:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 06:30:21 -0700
 Subject: [sup-talk] [PATCH] Add hooks to sort and format label-list-mode
 	display.
 In-Reply-To: <1254418284-sup-3486@kronos>
 References: <1253303493-sup-288@kronos> <1254416245-sup-4497@masanjin.net>
 	<1254418284-sup-3486@kronos>
 Message-ID: <1255354211-sup-1536@masanjin.net>
 
 Branch label-list-mode-hooks, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 09:31:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 06:31:21 -0700
 Subject: [sup-talk] [PATCH] don't downcase a nil content-type
 In-Reply-To: <1254593997-32634-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1254593997-32634-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1255354267-sup-3594@masanjin.net>
 
 Applied directly to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 09:42:10 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 06:42:10 -0700
 Subject: [sup-talk] labels-before-subject and ask_for_contacts config
 	knobs
 In-Reply-To: <1254565800-sup-5590@lanparty.ee>
 References: <1254565800-sup-5590@lanparty.ee>
 Message-ID: <1255354888-sup-8991@masanjin.net>
 
 Reformatted excerpts from Tarko Tikan's message of 2009-10-03:
 > ask_for_contacts is loading 10 contacts from index, imho this doesn't
 > make a sane default (it's too low). I've always patched this to 500 on
 > my end - yes, it takes a second or two to load that many contacts from
 > index but this doesn't bug me as much as first looking up the person
 > and then composing to him.
 
 Yeah, this number should be increased. Unfortunately the time required
 is tied to your index size and your machine, and 500 is way too slow for
 me.
 
 There are actually two numbers: the number of initial contacts, and the
 number that gets added when you press "M". I've changed the first to (2
 * # of screen rows) and the second to 100.  Hopefully that's a little
 more usable to you.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 09:43:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 06:43:48 -0700
 Subject: [sup-talk] labels-before-subject and ask_for_contacts config
 	knobs
 In-Reply-To: <1254667184-sup-153@bar-coded.net>
 References: <1254565800-sup-5590@lanparty.ee>
 	<1254667184-sup-153@bar-coded.net>
 Message-ID: <1255354943-sup-8569@masanjin.net>
 
 Reformatted excerpts from Marcus Williams's message of 2009-10-04:
 > If you search through the archives you should find a patch I submitted
 > for an alternate view. The default alternate view I find very good on
 > smaller devices and its configurable via a hook if you want anything
 > more. Not sure if its going to get integrated into sup though (Any
 > thoughts William? - I can resubmit if necessary)
 
 I'm a little wary of starting down the slippery slope of a million
 different screen configurations, but maybe it's ok to have a "small
 screen mode". Is that what the alternate view is for?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 09:46:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 06:46:44 -0700
 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode
 In-Reply-To: <1254669536-sup-2700@longword>
 References: <1252789445-30193-1-git-send-email-gigabo@gmail.com>
 	<1254415913-sup-6275@masanjin.net> <1254669536-sup-2700@longword>
 Message-ID: <1255355098-sup-4003@masanjin.net>
 
 Reformatted excerpts from Bo Borgerson's message of 2009-10-04:
 > Is there a way to label or delete threads without leaving the
 > label-list-mode?  There's already a refresh when switching back to the
 > label-list-mode from elsewhere, I think, so any changes that are $aved
 > should be reflected immediately when you get back.
 
 That's a good point. Yeah, this is unnecessary until we make some major
 interface redesigns.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 09:51:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 06:51:31 -0700
 Subject: [sup-talk] Bugfix for custom-search
 In-Reply-To: <1254869038-sup-9250@javelin>
 References: <1254418685-sup-6611@javelin> <1254869038-sup-9250@javelin>
 Message-ID: <1255355369-sup-9880@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-10-06:
 > Any comments?
 
 Sorry about the delay. Applied directly to master. I was sure I had done
 this right, but somehow it was only reflected in next, not in master. Oh
 well. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Oct 12 09:54:06 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Oct 2009 06:54:06 -0700
 Subject: [sup-talk] [PATCH] more inline GPG madness
 In-Reply-To: <1254417896-sup-2359@midna.zekjur.net>
 References: <1254348163-sup-6170@midna.zekjur.net>
 	<1254417896-sup-2359@midna.zekjur.net>
 Message-ID: <1255355627-sup-2988@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-10-01:
 > I will instead implement support for "correct" inline GPG.
 
 I've reworked this code a bit in recent commits, so make sure you have
 an up-to-date copy.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Mon Oct 12 12:35:48 2009
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 12 Oct 2009 17:35:48 +0100
 Subject: [sup-talk] labels-before-subject and ask_for_contacts config
 	knobs
 In-Reply-To: <1255354943-sup-8569@masanjin.net>
 References: <1254565800-sup-5590@lanparty.ee>
 	<1254667184-sup-153@bar-coded.net>
 	<1255354943-sup-8569@masanjin.net>
 Message-ID: <1255365030-sup-4877@bar-coded.net>
 
 On 12.10.2009, William Morgan wrote:
 > I'm a little wary of starting down the slippery slope of a million
 > different screen configurations, but maybe it's ok to have a "small
 > screen mode". Is that what the alternate view is for?
 
 Thats certainly what I use it for. The default "alternative" is just
 to strip authors/dates from the index view (see screenshot). A hook
 allows you to do what you want with it (like remove the labels). Its
 only toggleable via a keypress currently, but I find it useful on a
 smaller screen.
 
 If you're happy with it I might change the default alternative view to
 not include labels (or maybe move them to the end of the subject)
 before resubmission. My hooked version doesnt bother displaying the
 labels at all.
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup.jpg
 Type: image/jpeg
 Size: 187012 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091012/bef721fc/attachment.jpg>
 
 From stettberger@dokucode.de  Mon Oct 12 15:23:48 2009
 From: stettberger@dokucode.de (Christian Dietrich)
 Date: Mon, 12 Oct 2009 21:23:48 +0200
 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode
 In-Reply-To: <1255331296-sup-5993@peer.zerties.org>
 References: <1254247706-sup-2745@peer.zerties.org>
 	<1254334371-sup-5145@masanjin.net>
 	<1254516195-sup-4619@peer.zerties.org>
 	<1254985425-sup-2303@peer.zerties.org>
 	<1255005056-sup-7120@thinkpad-ubuntu>
 	<1255005777-sup-7020@thinkpad-ubuntu>
 	<1255026503-sup-3624@peer.zerties.org>
 	<1255030392-sup-1135@thinkpad-ubuntu>
 	<1255031039-sup-4070@qwerzila> <1255032615-sup-8961@qwerzila>
 	<1255034958-sup-5628@peer.zerties.org>
 	<1255073126-sup-6984@qwerzila>
 	<1255074206-sup-7503@peer.zerties.org>
 	<1255081131-sup-7915@qwerzila> <1255083021-sup-226@qwerzila>
 	<1255084730-sup-671@peer.zerties.org>
 	<1255085867-sup-8410@qwerzila>
 	<1255331296-sup-5993@peer.zerties.org>
 Message-ID: <1255375298-sup-2024@peer.zerties.org>
 
 Excerpts from Christian Dietrich's message of Mo Okt 12 09:11:35 +0200 2009:
 > Excerpts from Gaute Hope's message of Fr Okt 09 13:00:19 +0200 2009:
 > > Or the thread count isn't aware of the Today mark and still thinks line
 > > 2 is thread 2? Don't really know anything about the implementation.
 > > 
 > > When it happens it doesn't dissapear before I do a M or there is a pull
 > > that redraws the screen.. just pressing Ctrl+L or opening/closing a
 > > thread doesn't remove it.
 > > 
 > > As said earlier it only seems to affect the top two threads.
 > 
 > Hi,
 > i also experienced now this Problem, but can't see were this problem
 > is located, because i don't touch the internal states of the
 > threads. There must be one @thread[curpos] left, which causes this
 > Problem.
 > 
 > greetz didi
 
 Hi,
 i think i've fixed the problem now, it was a wrong mapping in
 update_text_for_line, now the situation that caused the error before
 succeeds. There was a misguiding declaration of @size_widgets in the
 init function.
 
 @size_widgets isn't a Hash, mapping line numbers to a size_widget,
 it is the same index as in @threads for the specific thread.
 
 greetz didi
 
 PS: please pull :-)
 -- 
 No documentation is better than bad documentation
 -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt.
 
 From tero@tilus.net  Mon Oct 12 17:50:20 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 13 Oct 2009 00:50:20 +0300
 Subject: [sup-talk] Oddities of marking spam
 Message-ID: <20091012215020.GA31940@tilus.net>
 
 First of all, Sup is a mindblowing experience!  Really.  Right after
 first trial I decided it will (no ifs) replace mutt as my primary MUA.
 I'll do whatever it takes to make this one work for me too.  It almost
 does already.
 
 In between tuning other things I made a couple of observations (branch
 next).  Sorry about not having a patch (not working on this, right now
 I'm trying to make Xapian eat my 100k+ mails).
 
 Marking spam in thread-view-mode does not run mark-as-spam hook.  This
 isn't intentional?
 
 If I look at spam (L, 'spam', ret) and then decide there's a false
 positive and hit S, spam-tag is removed but thread will not disappear
 from the view.  If I then view the thread, hit .s spam label is
 correctly added to the thread but at the same time it is _removed_
 from the previously mentioned spam list.  The same happens if I don't
 view the thread but hit S again.  Pressing M doesn't bring the
 re-spammed thread back to the label search view showing spam.  Killing
 the buffer and doing L, 'spam', ret again does.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Mon Oct 12 18:34:49 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 13 Oct 2009 01:34:49 +0300
 Subject: [sup-talk] Xapian: Term too long
 Message-ID: <20091012223449.GB31940@tilus.net>
 
 sup-sync blows up like this
 
 /home/terotil/src/sup/lib/sup/xapian_index.rb:446:in `replace_document': InvalidArgumentError: Term too long (> 245): Lfwd: =?iso-8859-1?q?tekij=e4n_oikeudet=5d?= (ArgumentError)
 x-enigmail-version: 0.92.0.0
 content-type: multipart/mixed;
  boundary="------------010606010007070802040301"
 x-virus-scanned: amavisd-new at cc.jyu.fi
 x-spam-status: no, hits=-2.373 required=5 tests=[awl=0.226, bayes_00=-2.599
         from /home/terotil/src/sup/lib/sup/xapian_index.rb:446:in `sync_message'
         from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
         from /home/terotil/src/sup/lib/sup/xapian_index.rb:363:in `synchronize'
         from /home/terotil/src/sup/lib/sup/xapian_index.rb:440:in `sync_message'
         from /home/terotil/src/sup/lib/sup/xapian_index.rb:92:in `add_message'
         from /home/terotil/src/sup/bin/sup-sync:211
 	...
 
 Relevant part of the problematic mail looks like this
 
 User-Agent: Debian Thunderbird 1.0.6 (X11/20050802)
 X-Accept-Language: en-us, en
 MIME-Version: 1.0
 To: mutikainen at iki.fi
 Subject: [Fwd: =?ISO-8859-1?Q?tekij=E4n_oikeudet=5D?=
 X-Enigmail-Version: 0.92.0.0
 Content-Type: multipart/mixed;
  boundary="------------010606010007070802040301"
 X-Virus-Scanned: amavisd-new at cc.jyu.fi
 X-Spam-Status: No, hits=-2.373 required=5 tests=[AWL=0.226, BAYES_00=-2.599]
 X-Spam-Level: 
 X-Sorted: Whitelist
 Content-Length: 11892
 
 This is how I solved it for me, for now
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index ad45b0e..d3b3e25 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -443,7 +443,11 @@ EOS
          warn "docid underflow, dropping #{m.id.inspect}"
          return
        end
 -      @xapian.replace_document docid, doc
 +      begin
 +        @xapian.replace_document docid, doc
 +      rescue StandardError => err
 +        warn "Failed to add message #{m.id.inspect} to Xapian index: #{err}"
 +      end
      end
  
      m.labels.each { |l| LabelManager << l }
 
 Looks like lib/sup/xapian_index.rb tries to override
 Xapian::Document#add_term with a version which is wired to ditch too
 long terms.  Only that you can't override methods just by including a
 module.  Methods of the including class override methods in included
 module.
 
 terotil at sotka:~$ irb
 > class Foo; def bar; :bar; end; end
 => nil
 > module Baz; def bar; :baz; end; end
 => nil
 > class Foo; include Baz; end
 => Foo
 > Foo.new.bar
 => :bar
 > Foo.ancestors
 => [Foo, Baz, Object, Kernel]  # Foo before Baz, methods in Foo take priority
 
 It is still Foo#bar being called, not Baz#bar.  You need to open up
 Xapian::Document and then do alias method chaining to override
 methods.  Or you could do tricks like
 http://coderrr.wordpress.com/2008/10/29/secure-alias-method-chaining/
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From cworth@cworth.org  Mon Oct 12 19:02:30 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Mon, 12 Oct 2009 16:02:30 -0700
 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first
 In-Reply-To: <1255350472-sup-5679@masanjin.net>
 References: <1253911610-sup-2052@yoom.home.cworth.org>
 	<1255350472-sup-5679@masanjin.net>
 Message-ID: <1255388543-sup-7477@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Mon Oct 12 05:48:50 -0700 2009:
 > I've finally gotten a chance to look at this. It looks good so far.
 
 Thanks for taking a look at it.
 
 > So I definitely don't want the second patch which changes the default
 > order. The configuration boolean is fine. (And if you want to add a
 > question to sup-config, that's icing on the cake.)
 
 I totally understand that, and that's why I did that part as a
 separate patch.
 
 > I would also like to disable forcing the loading of all messages.
 
 I can understand that too.
 
 > It is possible in Ferret: remove the DESC in ferret_index.rb line 160.
 > It is also possible in Xapian, but we're building the Xapian index to
 > optimize newest-first access. (Of course that would also be possible to
 > change, but then we're talking about a total index rebuild.)
 > 
 > If you wanted to tweak that, the load-all-threads wouldn't be necessary.
 
 How do we get this behavior in xapian? I'm fine if the index is not
 optimized for this. The current newest-first optimization is perfect
 for actual searching, (as opposed to reading of new messages), and the
 patches don't change that.
 
 > Either way, I'm happy to merge the first patch with the "n = -1" thing
 > removed.
 
 I wouldn't want the patch accepted with just that change. It results
 in a "broken" view, (it claims to be showing the oldest message first,
 but it doesn't, and trying to scroll "up" to see earlier messages also
 doesn't work).
 
 So I'll see if I can figure out how to just load the N oldest message
 instead. (My working theory was that this perform similarly to
 actually loading all the messages, and that's why the patch just did
 that).
 
 > Pretty easy to change. In thread.rb, there's a date method which takes a
 > max; you can make it take a min instead.
 
 Excellent. I'll take a look at that.
 
 > The hard work for both of these things is wiring this option through.
 > Although $config is a global variable, I don't really want to use it
 > directly in e.g. thread.rb.
 
 OK. I'll see if there's nearby code to mimic for this.
 
 -Carl
 
 > > PS. We're still total ruby newbies, so please point out any silly
 > > mistakes we're missing with respect to ruby idioms.
 > 
 > Everything looks good. The only slgihtly non-idiomatic thing is using
 > "if !x" instead of "unless x".
 
 Heh. Just today I noticed "unless" while poking around in some sup
 code. I have to say that "unless ... else" seems like a downright
 malicious construct to unleash against people reading code.
 -------------- 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/20091012/88815a8c/attachment.bin>
 
 From tero@tilus.net  Mon Oct 12 19:22:15 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 13 Oct 2009 02:22:15 +0300
 Subject: [sup-talk] RMail chokes on broken headers
 Message-ID: <20091012232215.GD31940@tilus.net>
 
 RMail::Header#content_type breaks when it encounters broken
 Content-Type and takes sup-sync down with it
 
 /usr/lib/ruby/gems/1.8/gems/rmail-1.0.0/lib/rmail/header.rb:537:in `content_type': undefined method `downcase' for nil:NilClass (NoMethodError)
         from /home/terotil/src/sup/lib/sup/message.rb:439:in `message_to_chunks'
         from /home/terotil/src/sup/lib/sup/message.rb:239:in `load_from_source!'
         from /home/terotil/src/sup/lib/sup/message.rb:335:in `build_from_source'
         from /home/terotil/src/sup/lib/sup/poll.rb:160:in `each_message_from'
 
 Worked around it this way
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index f9f87de..5ff3e48 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -436,7 +436,7 @@ private
        end
  
        chunks
 -    elsif m.header.content_type && m.header.content_type.downcase == "message/rfc822"
 +    elsif (m.header.content_type == "message/rfc822" rescue false) # rmail 1.0.0 may choke on broken content-type header, FIXME: fix rmail
        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 && m.header.content_type.downcase == "application/pgp" && m.body
 +    elsif (m.header.content_type.downcase == "application/pgp" rescue false) && m.body # rmail 1.0.0 may choke on broken content-type header, FIXME: fix rmail
        ## 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
 
 The problem itself is inside RMail.  I reported it.
 http://rubyforge.org/tracker/index.php?func=detail&aid=27282&group_id=446&atid=1754
 
 RMail looks abandoned.  Development is pretty much stalled.  No
 functional changes since 2004-04-27.  None of the reported bugs have
 been fixed.  Might it be worth to think about switching to another
 mail lib?  TMail author's http://github.com/mikel/mail/ looks
 promising.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From sven.schober@uni-ulm.de  Tue Oct 13 04:13:53 2009
 From: sven.schober@uni-ulm.de (Sven Schober)
 Date: Tue, 13 Oct 2009 10:13:53 +0200
 Subject: [sup-talk] pinentry-curses messes up sup
 In-Reply-To: <1255292709-sup-2216@masanjin.net>
 References: <1255175624-sup-8207@hysbald> <1255292709-sup-2216@masanjin.net>
 Message-ID: <1255421626-sup-4525@hysbald>
 
 Excerpts from William Morgan's message of Sun Oct 11 22:25:33 +0200 2009:
 > Reformatted excerpts from Sven Schober's message of 2009-10-10:
 > > As that thread is rather old, i would like to now if there's been some
 > > development on this? Are there any console alternatives to
 > > pinentry-curses?
 > 
 > I think I've fixed this in git next. Please try that.
 
 Works like a charm :) Thanks!
 -- 
 Sven Schober, sven.schober at uni-ulm.de                    |UNI ULM
 http://www-vs.informatik.uni-ulm.de/dept/staff/schober/  |DISTRIBUTED
 Room O27-346, Phone: +49-731-5024146 [+49-179-5060182]   |SYSTEMS LAB
 -------------- 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/20091013/fa723900/attachment.bin>
 
 From tero@tilus.net  Tue Oct 13 08:40:03 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 13 Oct 2009 15:40:03 +0300
 Subject: [sup-talk] IMAP and recursion
 Message-ID: <20091013124002.GA7129@tilus.net>
 
 I had quite a lot of IMAP folders to add and went looking for
 recursion.  I found old sup-talk threads on the subject and thought of
 it a while.  
 
 I might have missed something, but I could not easily get around
 sup-add asking me all the time which account she should use.  So I
 went on to add --force-account user at host to be able to batch-add IMAP
 sources.
 
 What do you think?
 
 ---
 diff --git a/bin/sup-add b/bin/sup-add
 index e27a0eb..c53378d 100755
 --- a/bin/sup-add
 +++ b/bin/sup-add
 @@ -39,6 +39,7 @@ EOS
    opt :unusual, "Do not automatically poll these sources for new messages."
    opt :labels, "A comma-separated set of labels to apply to all messages from this source", :type => String
    opt :force_new, "Create a new account for this source, even if one already exists."
 +  opt :force_account, "Reuse previously defined account user at hostname.", :type => String
  end
  
  Trollop::die "require one or more sources" if ARGV.empty?
 @@ -56,13 +57,20 @@ def get_login_info uri, sources
  
    username, password = nil, nil
    unless accounts.empty? || $opts[:force_new]
 -    say "Would you like to use the same account as for a previous source for #{uri}?"
 -    choose do |menu|
 -      accounts.each do |host, olduser, oldpw|
 -        menu.choice("Use the account info for #{olduser}@#{host}") { username, password = olduser, oldpw }
 +    if $opts[:force_account]
 +      host, username, password = accounts.find { |h, u, p| $opts[:force_account] == "#{u}@#{h}" }
 +      unless username && password
 +        say "No previous account #{$opts[:force_account].inspect} found."
 +      end
 +    else
 +      say "Would you like to use the same account as for a previous source for #{uri}?"
 +      choose do |menu|
 +        accounts.each do |host, olduser, oldpw|
 +          menu.choice("Use the account info for #{olduser}@#{host}") { username, password = olduser, oldpw }
 +        end
 +        menu.choice("Use a new account") { }
 +        menu.prompt = "Account selection? "
        end
 -      menu.choice("Use a new account") { }
 -      menu.prompt = "Account selection? "
      end
    end
 ---
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From bgamari.foss@gmail.com  Tue Oct 13 16:18:44 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Tue, 13 Oct 2009 16:18:44 -0400
 Subject: [sup-talk] Fwd: Re: Crash while in thread-view-mode
 In-Reply-To: <1255292742-sup-3957@masanjin.net>
 References: <1254955312-sup-7085@ben-laptop> <1255292742-sup-3957@masanjin.net>
 Message-ID: <1255464686-sup-4163@ben-laptop>
 
 Excerpts from William Morgan's message of Sun Oct 11 16:28:48 -0400 2009:
 > I'm sorry you've had to rebuild the index so many times. The Xapian side
 > of things is very new, and I think you've had a run of bad luck. But I
 > am personally not motivated to improve index time performance, because
 > that's not a common event. At least, it shouldn't be.
 
 Unfortunately, it seems that the crashes have returned (In fact, they
 returned only hours after I rebuilt). Interestingly, it is once again my
 LKML label that is the culprit.
 
 On the note of crashing, is it really necessary for the "wrong id called
 on nil" exception to be fatal? Couldn't the client at least make some
 attempt at recovering (skipping the problematic thread while catching
 and logging the exception)? It seems like these issues could be rather
 tricky to sort out (I've put an hour or so into tracking down the source
 of the nils to no avail), and with a dynamically typed language like
 Ruby, could occur at any time. Considering this, it seems like it might
 be a good idea to handle these failures a bit more gracefully. Would
 this be problematic?
 
 Regardless, it might be a good idea to have a hierarchy of exception
 classes instead of just throwing Strings. It seems that throwing
 specialized classes would make the above substantially easier.
 
 Thanks,
 
 - Ben
 
 
 
 --- 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/lib64/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:117:in `each_id_by_date'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each'
 /opt/exp/sup/lib/sup/xapian_index.rb:110:in `each_id'
 /opt/exp/sup/lib/sup/xapian_index.rb:117: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:81:in `initialize'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `call'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `each'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `new'
 /opt/exp/sup/lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
 /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:54:in `initialize'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:9:in `initialize'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `new'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
 /opt/exp/sup/lib/sup/buffer.rb:350:in `spawn_unless_exists'
 /opt/exp/sup/lib/sup/util.rb:520:in `send'
 /opt/exp/sup/lib/sup/util.rb:520:in `method_missing'
 /opt/exp/sup/lib/sup/modes/label-search-results-mode.rb:32:in `spawn_nicely'
 /opt/exp/sup/lib/sup/modes/label-list-mode.rb:134:in `select_label'
 /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:245
 
 From olly@survex.com  Tue Oct 13 16:51:10 2009
 From: olly@survex.com (Olly Betts)
 Date: Tue, 13 Oct 2009 20:51:10 +0000 (UTC)
 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first
 References: <1253911610-sup-2052@yoom.home.cworth.org>
 	<1255350472-sup-5679@masanjin.net>
 	<1255388543-sup-7477@yoom.home.cworth.org>
 Message-ID: <slrnhd9q1u.gga.olly@msgid.survex.com>
 
 On 2009-10-12, Carl Worth <cworth at cworth.org> wrote:
 > How do we get this behavior in xapian? I'm fine if the index is not
 > optimized for this. The current newest-first optimization is perfect
 > for actual searching, (as opposed to reading of new messages), and the
 > patches don't change that.
 
     @enquire.docid_order = Xapian::Enquire::DESCENDING
 
 This means that the docid order (which is used as the least significant
 ordering) is descending rather than ascending.  In this case (I assume)
 we're using Xapian::BoolWeight so this is the only ordering.
 
 Cheers,
     Olly
 
 
 From tero@tilus.net  Wed Oct 14 09:34:55 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Wed, 14 Oct 2009 16:34:55 +0300
 Subject: [sup-talk] Sup finds ghost messages
 Message-ID: <1255526768-sup-3152@tilus.net>
 
 sup-sync --all (using xapian) from a new source occasionally says 1-2
 messages already were in the index, even if they most certainly
 weren't.  I noticed this when I added sup-talk archives to my index.
 I'm 100% sure I did not have any sup-talk mails from somewhere
 2007-2008 in any of my other sources.  Still sup-sync said it did not
 add a couple of messages which supposedly already were in the index.
 
 ps.  Happily on sup now. \o/ All mails in, 1G index.  Xapian is
      blazing fast...
 
 pps. Why bugs to this list?  Why not use a tracker?  (besides that sup
      is awesome tracker too ;)
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Wed Oct 14 18:27:03 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Thu, 15 Oct 2009 01:27:03 +0300
 Subject: [sup-talk] Wrapping long lines
 Message-ID: <1255558925-sup-2369@tilus.net>
 
 How can I make sup wrap long lines?  I occasionally receive unwrapped
 text/plain mails and it would be cool to have the "i dont care what
 you need to do, but just fit it in the terminal window width" button.
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From michael+sup@stapelberg.de  Thu Oct 15 06:50:13 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Thu, 15 Oct 2009 12:50:13 +0200
 Subject: [sup-talk] About faking message IDs
 Message-ID: <1255603625-sup-2558@midna.zekjur.net>
 
 Hi,
 
 I just noticed that the lack of emails from my backup program seems to be
 because of the missing message ids in the mail script I use. In case of
 no message id inside the header, sup uses the md5sum of the whole header
 (see lib/sup/message.rb:74). This effectively means that messages having
 the same md5sum of their header (which happened, since the header was also
 generated completely by the script and the values did not change) will
 "overwrite" the old message.
 
 As a workaround, I now added the current time to my script, so that every
 header will have a different md5 sum. But maybe we can think of a more
 clever way to generate faked message ids? Maybe also hash the body of the
 message?
 
 Best regards,
 Michael
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 08:46:51 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 05:46:51 -0700
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1254955351-sup-5944@ben-laptop>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net>
 	<1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 	<1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop>
 Message-ID: <1255610731-sup-7030@masanjin.net>
 
 Reformatted excerpts from Ben Gamari's message of 2009-10-07:
 > There must be a better way to deal with these invalid ids than
 > crashing. Is there any reason this needs to be a show-stopping event?
 
 This is probably a symptom of some thread protection issues. You're
 right, there's no reason this needs to crash Sup. You could apply this:
 
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index 82f258b..17d5836 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -222,7 +222,7 @@ EOS
    def update
      @mutex.synchronize do
        ## let's see you do THIS in python
 -      @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t| [t.date, t.first.id] }.reverse
 +      @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t| t.first }.sort_by { |t| [t.date, t.first.id] }.reverse
        @size_widgets = @threads.map { |t| size_widget_for_thread t }
        @size_widget_width = @size_widgets.max_of { |w| w.display_length }
      end
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 08:51:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 05:51:50 -0700
 Subject: [sup-talk] curses exception
 In-Reply-To: <ed5557340910120709u62e97e67id6580f0a8ee6ec64@mail.gmail.com>
 References: <ed5557340910061533w7854510tabe9bb2fc864db09@mail.gmail.com>
 	<1255292940-sup-5558@masanjin.net>
 	<ed5557340910120709u62e97e67id6580f0a8ee6ec64@mail.gmail.com>
 Message-ID: <1255611057-sup-1320@masanjin.net>
 
 Reformatted excerpts from Dan Falcone's message of 2009-10-12:
 > Honestly, it's probably an issue with my setup... is there a guide
 > anywhere on how to get sup running in cygwin?  Maybe I'm missing a
 > required package?
 
 There's no guide per se. Other people have definitely made it work in
 the past. Are you able to get other color curses programs to work? I
 suspect it's not a Sup issue per se, but I'm not that familiar with the
 intricacies of Cygwin.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 08:56:29 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 05:56:29 -0700
 Subject: [sup-talk] Oddities of marking spam
 In-Reply-To: <20091012215020.GA31940@tilus.net>
 References: <20091012215020.GA31940@tilus.net>
 Message-ID: <1255611277-sup-9644@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-10-12:
 > Marking spam in thread-view-mode does not run mark-as-spam hook.  This
 > isn't intentional?
 
 Good point, that's a bug.
 
 > If I look at spam (L, 'spam', ret) and then decide there's a false
 > positive and hit S, spam-tag is removed but thread will not disappear
 > from the view.  If I then view the thread, hit .s spam label is
 > correctly added to the thread but at the same time it is _removed_
 > from the previously mentioned spam list.  The same happens if I don't
 > view the thread but hit S again.  Pressing M doesn't bring the
 > re-spammed thread back to the label search view showing spam.  Killing
 > the buffer and doing L, 'spam', ret again does.
 
 The auto-adding and auto-removing of threads from search-result-mode is
 only able to work in certain limited cases, in general, but this sounds
 like a bug too.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 08:59:53 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 05:59:53 -0700
 Subject: [sup-talk] Xapian: Term too long
 In-Reply-To: <20091012223449.GB31940@tilus.net>
 References: <20091012223449.GB31940@tilus.net>
 Message-ID: <1255611567-sup-8695@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-10-12:
 > Looks like lib/sup/xapian_index.rb tries to override
 > Xapian::Document#add_term with a version which is wired to ditch too
 > long terms.  Only that you can't override methods just by including a
 > module.  Methods of the including class override methods in included
 > module.
 
 Very good point. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 09:11:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 06:11:36 -0700
 Subject: [sup-talk] RMail chokes on broken headers
 In-Reply-To: <20091012232215.GD31940@tilus.net>
 References: <20091012232215.GD31940@tilus.net>
 Message-ID: <1255612194-sup-3880@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-10-12:
 > RMail looks abandoned.  Development is pretty much stalled.  No
 > functional changes since 2004-04-27.  None of the reported bugs have
 > been fixed.  Might it be worth to think about switching to another
 > mail lib?  TMail author's http://github.com/mikel/mail/ looks
 > promising.
 
 Yeah, this is certainly an option. But it seems like a lot of work. And
 every day our set of rmail workarounds grows more robust. :)
 
 Not to say I wouldn't accept a patch that magically did this all for me,
 of course.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 09:45:47 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 06:45:47 -0700
 Subject: [sup-talk] Sup finds ghost messages
 In-Reply-To: <1255526768-sup-3152@tilus.net>
 References: <1255526768-sup-3152@tilus.net>
 Message-ID: <1255612303-sup-410@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-10-14:
 > sup-sync --all (using xapian) from a new source occasionally says 1-2
 > messages already were in the index, even if they most certainly
 > weren't.  I noticed this when I added sup-talk archives to my index.
 
 Can you run with -v and grep to make sure those message ids don't
 actually appear more than once in the mbox file? If they don't, can you
 isolate a particular one and use devel/console.sh to find out where Sup
 thinks the previous occurence is?
 
 > pps. Why bugs to this list?  Why not use a tracker?  (besides that sup
 >      is awesome tracker too ;)
 
 If there's a good one out there I'd like to hear about it. We used ditz
 for a while because I hate clicking the mouse, but eventually it became
 too much effort.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Thu Oct 15 09:47:00 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Thu, 15 Oct 2009 15:47:00 +0200
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1255610731-sup-7030@masanjin.net>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net>
 	<1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 	<1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop>
 	<1255610731-sup-7030@masanjin.net>
 Message-ID: <1255614287-sup-4683@altis>
 
 Excerpts from William Morgan's message of Thu Oct 15 14:46:51 +0200 2009:
 > Reformatted excerpts from Ben Gamari's message of 2009-10-07:
 > > There must be a better way to deal with these invalid ids than
 > > crashing. Is there any reason this needs to be a show-stopping event?
 > 
 > This is probably a symptom of some thread protection issues. You're
 > right, there's no reason this needs to crash Sup. You could apply this:
 > 
 > diff --git a/lib/sup/modes/thread-index-mode.rb
 > b/lib/sup/modes/thread-index-mode.rb
 > index 82f258b..17d5836 100644
 > --- a/lib/sup/modes/thread-index-mode.rb
 > +++ b/lib/sup/modes/thread-index-mode.rb
 > @@ -222,7 +222,7 @@ EOS
 >    def update
 >      @mutex.synchronize do
 >        ## let's see you do THIS in python
 > -      @threads = @ts.threads.select { |t| !@hidden_threads[t] }.sort_by { |t|
 > [t.date, t.first.id] }.reverse
 > +      @threads = @ts.threads.select { |t| !@hidden_threads[t] }.select { |t|
 > t.first }.sort_by { |t| [t.date, t.first.id] }.reverse
 >        @size_widgets = @threads.map { |t| size_widget_for_thread t }
 >        @size_widget_width = @size_widgets.max_of { |w| w.display_length }
 >      end
 Man, I love you, I can finally use sup again.
 
 (and I love the Python comment, even if I have no effing idea of what
 the code could mean.)
 
 Thanks!
 
 -- 
 Guillaume
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 09:47:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 06:47:36 -0700
 Subject: [sup-talk] About faking message IDs
 In-Reply-To: <1255603625-sup-2558@midna.zekjur.net>
 References: <1255603625-sup-2558@midna.zekjur.net>
 Message-ID: <1255614431-sup-5910@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
 > I just noticed that the lack of emails from my backup program seems to be
 > because of the missing message ids in the mail script I use. In case of
 > no message id inside the header, sup uses the md5sum of the whole header
 > (see lib/sup/message.rb:74). This effectively means that messages having
 > the same md5sum of their header (which happened, since the header was also
 > generated completely by the script and the values did not change) will
 > "overwrite" the old message.
 
 Doesn't the header include the date?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From michael+sup@stapelberg.de  Thu Oct 15 09:55:13 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Thu, 15 Oct 2009 15:55:13 +0200
 Subject: [sup-talk] before-edit hook and accessing the original sender
 Message-ID: <1255614656-sup-7039@midna.zekjur.net>
 
 Hi,
 
 I just configured a before-edit hook which prepends my usual greeting to the
 message and appends my greeting. To personalize the greeting, I access
 header["To"]. However, when replying to emails, this is not always the original
 sender of the message I am replying to (think of mailing lists).
 
 So, the question is, can I somehow access the message to which I am replying
 to when in the before-edit hook called when replying to a message.
 
 Best regards,
 Michael
 
 PS: I am not using the signature hook as I want to edit my signature inside my
 $EDITOR. Also, I need the greeting at the top of the message.
 
 From michael+sup@stapelberg.de  Thu Oct 15 09:59:01 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Thu, 15 Oct 2009 15:59:01 +0200
 Subject: [sup-talk] About faking message IDs
 In-Reply-To: <1255614431-sup-5910@masanjin.net>
 References: <1255603625-sup-2558@midna.zekjur.net>
 	<1255614431-sup-5910@masanjin.net>
 Message-ID: <1255615018-sup-5653@midna.zekjur.net>
 
 Hi William,
 
 Excerpts from William Morgan's message of Thu Oct 15 15:47:36 +0200 2009:
 > Doesn't the header include the date?
 No, in my case it did not. The reason for that is calling "deliver" directly,
 that is without talking SMTP to a mailserver. Thus, no headers are getting
 added. Surely this is a corner case, but I think it will cause headache for
 system administrators running into this one, if they notice it all (overwriting
 messages is quite dangerous).
 
 Best regards,
 Michael
 
 From bgamari.foss@gmail.com  Thu Oct 15 11:03:04 2009
 From: bgamari.foss@gmail.com (Ben Gamari)
 Date: Thu, 15 Oct 2009 11:03:04 -0400
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1255610731-sup-7030@masanjin.net>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net>
 	<1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 	<1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop>
 	<1255610731-sup-7030@masanjin.net>
 Message-ID: <1255618838-sup-1025@ben-laptop>
 
 Excerpts from William Morgan's message of Thu Oct 15 08:46:51 -0400 2009:
 > Reformatted excerpts from Ben Gamari's message of 2009-10-07:
 > > There must be a better way to deal with these invalid ids than
 > > crashing. Is there any reason this needs to be a show-stopping event?
 > 
 > This is probably a symptom of some thread protection issues. You're
 > right, there's no reason this needs to crash Sup. You could apply this:
 > 
 Yep, this fixes it. Thank you so much. Now to sort through my backlog of
 mail. Thanks again,
 
 - Ben
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 11:16:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 08:16:36 -0700
 Subject: [sup-talk] Crash while in thread-view-mode
 In-Reply-To: <1255614287-sup-4683@altis>
 References: <1254844050-sup-4148@ben-laptop> <1254844166-sup-1028@ben-laptop>
 	<1254845543-sup-9458@ben-laptop> <1254896214-sup-5969@zyrg.net>
 	<1e5fdab70910070148s31a8a371u81182a13e72bea4c@mail.gmail.com>
 	<1254945119-sup-3401@ben-laptop> <1254955351-sup-5944@ben-laptop>
 	<1255610731-sup-7030@masanjin.net> <1255614287-sup-4683@altis>
 Message-ID: <1255619752-sup-3707@masanjin.net>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-10-15:
 > (and I love the Python comment, even if I have no effing idea of what
 > the code could mean.)
 
 It refers to the fact that Python programs don't have bugs.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 11:27:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 08:27:44 -0700
 Subject: [sup-talk] curses exception
 In-Reply-To: <ed5557340910150740i4e701044l12be4fd43e2bc072@mail.gmail.com>
 References: <ed5557340910061533w7854510tabe9bb2fc864db09@mail.gmail.com>
 	<1255292940-sup-5558@masanjin.net>
 	<ed5557340910120709u62e97e67id6580f0a8ee6ec64@mail.gmail.com>
 	<1255611057-sup-1320@masanjin.net>
 	<ed5557340910150740i4e701044l12be4fd43e2bc072@mail.gmail.com>
 Message-ID: <1255620005-sup-7616@masanjin.net>
 
 Reformatted excerpts from Dan Falcone's message of 2009-10-15:
 > Hmm... good question.  I regularly use emacs with colors enabled, but
 > I'm not sure if that uses curses.  I tried typespeed and that seemed
 > to work.  According to its man page, it uses curses.
 
 Hm. What version of the ncurses gem do you have? (gem list --local
 should tell you.)
 
 What does this program print?
 
   require 'rubygems'
   require 'ncurses'
 
   x = begin
     Ncurses::initscr();
     Ncurses::has_colors?()
   ensure
     Ncurses::endwin();
   end
 
   puts x
 
 If it prints true, then, if you look in the contents of the gem
 (wherever that is on your system), there should be an examples/
 directory. If you run examples/tlock.rb or examples/rain.rb, (probably
 with ruby -rubygems), do you see color?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 11:29:29 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 08:29:29 -0700
 Subject: [sup-talk] About faking message IDs
 In-Reply-To: <1255615018-sup-5653@midna.zekjur.net>
 References: <1255603625-sup-2558@midna.zekjur.net>
 	<1255614431-sup-5910@masanjin.net>
 	<1255615018-sup-5653@midna.zekjur.net>
 Message-ID: <1255620476-sup-8113@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
 > No, in my case it did not. The reason for that is calling "deliver"
 > directly, that is without talking SMTP to a mailserver. Thus, no
 > headers are getting added. Surely this is a corner case, but I think
 > it will cause headache for system administrators running into this
 > one, if they notice it all (overwriting messages is quite dangerous).
 
 Ok. I think it's fine to generate the message id via another mechanism,
 e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}").
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Oct 15 11:32:54 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Oct 2009 08:32:54 -0700
 Subject: [sup-talk] before-edit hook and accessing the original sender
 In-Reply-To: <1255614656-sup-7039@midna.zekjur.net>
 References: <1255614656-sup-7039@midna.zekjur.net>
 Message-ID: <1255620578-sup-9650@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
 > So, the question is, can I somehow access the message to which I am
 > replying to when in the before-edit hook called when replying to a
 > message.
 
 Not currently. We could wire that through without too much effort, I
 think.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From cworth@cworth.org  Thu Oct 15 13:23:40 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 15 Oct 2009 10:23:40 -0700
 Subject: [sup-talk] Indexing messages without ruby
 Message-ID: <1255623468-sup-2284@yoom.home.cworth.org>
 
 I've gone forward with an experiment I had mentioned I might try:
 trying to create a faster sup-sync by using C rather than ruby.
 
 My approach was to use Xapian to create a sup-compatible index, and to
 use libgmime for the mail parsing. That meant that I only had to write
 a tiny bit of code to glue gmime together with xapian. The code is an
 unholy mess of C and C++, (so there are as many as three different
 string types, sometimes all in one function!), but it seems to be
 working at least.
 
 I wrote a little xapian-dump program to make a textual dump of a
 database, (all data, terms, and values for each document), and I
 verified that my program, notmuch, could create identical[*] terms and
 values when indexing about 150 recent messages from the sup-talk
 mailing list.
 
 I've also verified that notmuch can index my own collection of nearly
 600,000 email messages without any problems.
 
 The big difference in notmuch that makes the resulting index
 incompatible with sup is that it doesn't generate a serialized ruby
 data structure for the document data like sup currently
 expects. Instead it just shoves the mail message's filename into the
 data field. So if anyone wanted to use notmuch with sup, this would
 need to be resolved on one side or the other.[**]
 
 As for performance, things look pretty good, but perhaps not as good
 as I had hoped. From a test of importing about 400,000 messages from
 my mail archive, notmuch starts out between 300 - 400 messages/sec.
 but after about 40,000 messages slows down to about 100
 messages/sec. and stabilizes there.
 
 I haven't tested sup recently, but from my recollection indexing the
 same archive on the same computer, sup started out at about 40
 messages/sec. and slowed down to about 20 messages/sec. (for as long
 as I watched it).
 
 So this is preliminary, but it looks like notmuch gives a 5-10x
 performance improvement over sup, (but likely closer to the 5x end of
 that range unless you've got a very small index---at which point who
 cares how fast/slow things are?).
 
 A quick glance with a profiler shows xapian dominating the notmuch
 profile at 62% and gmime hardly appearing at all (near 2%). As
 contrast, ruby dominates the sup-sync profile with xapian down in the
 8% range. (So there's the 10x target there.) One other advantage is
 that with xapian dominating the profile, notmuch stands to benefit
 from future performance improvements to xapian itself.
 
 If that ruby time is dominated by mail parsing, it's possible that
 much of the advantage of notmuch could be gained by simply switching
 from rmail to a non-ruby-based parser like gmime. But that's just a
 guess as I haven't tried to find where the ruby time is being spent.
 
 If anyone is interested in playing along at home, my code is available
 via git with:
 
 	git clone git://git.cworth.org/git/notmuch
 
 Have fun,
 
 -Carl
 
 [*] Some minor differences exist in the heuristics for reognizing
 signatures, and sup sometimes splits numbers into multiple terms (such
 as "1754" indexed as two terms "17" and "54") which I couldn't explain
 nor replicate. Finally notmuch doesn't attempt to index encrypted
 messages.
 
 [**] Beyond this incompatibility, notmuch is not even close to being a
 functional replacement for sup-sync. It currently only knows how to
 shove new documents into the database and doesn't know how to do any
 updating. Similarly it doesn't have any code to examine mtimes to
 identify new or changed messages to be updated. It also doesn't look
 at maildir filename flags to determine labels, nor does it provide any
 means for the user to request custom labels to be attached to certain
 messages.
 -------------- 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/20091015/25074e86/attachment.bin>
 
 From nicolas.pouillard@gmail.com  Thu Oct 15 15:21:29 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Thu, 15 Oct 2009 21:21:29 +0200
 Subject: [sup-talk] About faking message IDs
 In-Reply-To: <1255620476-sup-8113@masanjin.net>
 References: <1255603625-sup-2558@midna.zekjur.net>
 	<1255614431-sup-5910@masanjin.net>
 	<1255615018-sup-5653@midna.zekjur.net>
 	<1255620476-sup-8113@masanjin.net>
 Message-ID: <1255634425-sup-8445@peray>
 
 Excerpts from William Morgan's message of Thu Oct 15 17:29:29 +0200 2009:
 > Reformatted excerpts from Michael Stapelberg's message of 2009-10-15:
 > > No, in my case it did not. The reason for that is calling "deliver"
 > > directly, that is without talking SMTP to a mailserver. Thus, no
 > > headers are getting added. Surely this is a corner case, but I think
 > > it will cause headache for system administrators running into this
 > > one, if they notice it all (overwriting messages is quite dangerous).
 > 
 > Ok. I think it's fine to generate the message id via another mechanism,
 > e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}").
 
 This way we loose the reproducibility, but I concede that we can't have both.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From cworth@cworth.org  Thu Oct 15 20:14:09 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Thu, 15 Oct 2009 17:14:09 -0700
 Subject: [sup-talk] About faking message IDs
 In-Reply-To: <1255620476-sup-8113@masanjin.net>
 References: <1255603625-sup-2558@midna.zekjur.net>
 	<1255614431-sup-5910@masanjin.net>
 	<1255615018-sup-5653@midna.zekjur.net>
 	<1255620476-sup-8113@masanjin.net>
 Message-ID: <1255651999-sup-9911@yoom.home.cworth.org>
 
 Excerpts from William Morgan's message of Thu Oct 15 08:29:29 -0700 2009:
 > Ok. I think it's fine to generate the message id via another mechanism,
 > e.g. the way we do it in edit-message-mode ("<#{Time.now.to_i}-sup-#{rand
 > 10000}@#{hostname}").
 
 Won't that then make sup insert duplicate documents into the index for
 any run of sup-sync --all over the relevant sources?
 
 -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/20091015/78f02bbd/attachment.bin>
 
 From michael+sup@stapelberg.de  Sat Oct 17 18:32:25 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sun, 18 Oct 2009 00:32:25 +0200
 Subject: [sup-talk] [PATCH] more inline GPG madness
 In-Reply-To: <1255355627-sup-2988@masanjin.net>
 References: <1254348163-sup-6170@midna.zekjur.net>
 	<1254417896-sup-2359@midna.zekjur.net>
 	<1255355627-sup-2988@masanjin.net>
 Message-ID: <1255818685-sup-6010@midna.zekjur.net>
 
 Hi,
 
 Excerpts from William Morgan's message of Mo Okt 12 15:54:06 +0200 2009:
 > Reformatted excerpts from Michael Stapelberg's message of 2009-10-01:
 > > I will instead implement support for "correct" inline GPG.
 See the attached patch. Please consider merging it :).
 
 Best regards,
 Michael
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Implement-inline-GPG.patch
 Type: application/octet-stream
 Size: 5354 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091018/dbd897f2/attachment-0001.obj>
 
 From kirr@landau.phys.spbu.ru  Sun Oct 18 07:50:00 2009
 From: kirr@landau.phys.spbu.ru (Kirill Smelkov)
 Date: Sun, 18 Oct 2009 15:50:00 +0400
 Subject: [sup-talk] BUG: Sup crashes on startup (bisected)
 Message-ID: <20091018114959.GA11630@roro3.zxlink>
 
 Hello up there.
 
 I'm using sup master from git, and after recent upgrade, sup began
 crashing on startup. Here is the backtrace:
 
 --- NoMethodError from thread: main
 undefined method `title' for nil:NilClass
 /home/kirr/src/tools/mail/sup/lib/sup/buffer.rb:772:in `get_status_and_title'
 /home/kirr/src/tools/mail/sup/lib/sup/buffer.rb:305:in `draw_screen'
 /home/kirr/src/tools/mail/sup/lib/sup/buffer.rb:726:in `flash'
 /home/kirr/src/tools/mail/sup/lib/sup/util.rb:520:in `send'
 /home/kirr/src/tools/mail/sup/lib/sup/util.rb:520:in `method_missing'
 /home/kirr/src/tools/mail/sup/lib/sup/colormap.rb:203:in `populate_colormap'
 /home/kirr/src/tools/mail/sup/bin/sup:169
 
 
 Just to give you some help (no ruby knowledge here at the moment, sorry):
 
 Does not crash:     95eaf6
 Crashes at startup: 2dfd37
 Bisected to:        723e22 (rewrite logging to have multiple levels:
                             debug, info, etc)
                             
                             
 Thanks beforehand,
 Kirill
 
 From garoth@gmail.com  Sun Oct 18 11:05:57 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Sun, 18 Oct 2009 11:05:57 -0400
 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9)
 Message-ID: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 
 Hello. Remember me? ;)
 
 Anyway, I've rolled the 0.9 package for Arch Linux in the
 AUR (community repos). It works, but:
  - Ruby 1.9.1 has pretty screwed up dependencies for Sup. Ncurses and ferret in
    particular were broken (at least in Arch.)
  - The package is a big ol' pile of hacks.
  - Ferret index is disabled (sorry for removing it early, but Ruby 1.9.1 is the
    reality for us in Arch.)
  - I've applyed Lloyd's patch for fixing the UTF-8 check.
  - There seem to be a few small bugs.
 
 Anyway, I'd appreciate some suggestions. The package is viewable here:
 http://aur.archlinux.org/packages.php?ID=26439
 
 Some of the sketchier things:
  - I've set Xapian to the default by wrapping all of Sup's binaries with the
    SUP_INDEX variable in a script.
  - q no longer works properly. It prompts you with the regular yes/no option
    as to whether you really want to quit. Neither y nor n seem to have any
    effect; it is still possible to quit with Q.
  - Will that patch get applied? It seems reasonable on a surface level.
 
 Anyway, as some of you can probably tell, I don't have Sup set up at the
 moment. I'm working on it. Regardless, managing mail is a nightmare just now!
 Once I do manage to get it set up, I'll continue testing. I'm not sure,
 but I'm getting the impression that rather little testing has been done
 with the new Ruby as it's not quite mainstream yet.
 
 -Andrei "Garoth" Thorp
 
 From wagnerdm@seas.upenn.edu  Sun Oct 18 21:22:12 2009
 From: wagnerdm@seas.upenn.edu (wagnerdm at seas.upenn.edu)
 Date: Sun, 18 Oct 2009 21:22:12 -0400
 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9)
 In-Reply-To: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 Message-ID: <20091018212212.18607cbsd1pxbds0@webmail.seas.upenn.edu>
 
 Quoting Andrei Thorp <garoth at gmail.com>:
 
 >  - Ferret index is disabled (sorry for removing it early, but Ruby  
 > 1.9.1 is the reality for us in Arch.)
 
 As long as your comfortable with AUR, there are a ruby1.8 and  
 rubygems1.8 packages available.
 ~d
 
 From lists@onerussian.com  Mon Oct 19 13:01:19 2009
 From: lists@onerussian.com (Yaroslav Halchenko)
 Date: Mon, 19 Oct 2009 13:01:19 -0400
 Subject: [sup-talk] as asked -- little bug report
 Message-ID: <20091019170119.GM17964@onerussian.com>
 
 Sup,
 
 thanks for sup!
 
 I have been with (mutt+mairix)-in-screen guy for a while, now I am
 considering sup -- it seems quite nice, although it took days to import
 my inbox (26k messages) without yet touching any lists in the
 other folders (where I am going to assign some tags on import whenever I
 get more familiar with sup).
 
 One of the side-effects was: since I was not "processing" fetched emails
 while they were fetched by sup, inbox listing was growing and growing
 until UI became barely responsive and I guess good chunk of CPU time was
 taken to handle just UI.  So, it might be desirable to have
 automatic way to 'hide' older messages in the listing whenever more and
 more new ones come in?
 
 FWIW some of the issues I hit:
 
 1. At first I was running released version shipped with Debian sid
 (0.8.1-1), and while I was watching a thread and decided to
 archive and jump to next I pressed sequence ",a" and then sup crashed
 entirely with:
 
 --- NoMethodError from thread: main
 undefined method `mark_dirty' for nil:NilClass
 /usr/lib/ruby/1.8/sup/modes/line-cursor-mode.rb:55:in `set_cursor_pos'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:148:in `launch_another_thread'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:131:in `launch_next_thread_after'
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:473:in `dispatch'
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:431:in `archive_and_then'
 /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:418:in `archive_and_next'
 /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:249:in `handle_input'
 /usr/bin/sup-mail:236
 
 2. further I was hit with another one (see below) for which I think I found a fix
 1dbe8fe8b2a57803d697739b4a585e72b1f91885
 which seems relevant
 http://gitorious.org/sup/ehabkost-hacks/commit/1dbe8fe8b2a57803d697739b4a585e72b1f91885
 but it never was absorbed in mainline
 
 
 Here is actual traceback
 
 --- NoMethodError from thread: poll after loading inbox
 undefined method `content_width' for nil:NilClass
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:866:in `from_width'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:792:in `text_for_thread_at'
 /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:791:in `each'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:791:in `each_with_index'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:791:in `text_for_thread_at'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:752:in `regen_text'
 /usr/lib/ruby/1.8/sup/util.rb:354:in `map_with_index'
 /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index'
 /usr/lib/ruby/1.8/sup/util.rb:354:in `each'
 /usr/lib/ruby/1.8/sup/util.rb:354:in `each_with_index'
 /usr/lib/ruby/1.8/sup/util.rb:354:in `map_with_index'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:752:in `regen_text'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:228:in `update'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:696:in `add_or_unhide'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:186:in `handle_added_update'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `send'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `relay'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `each'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `relay'
 /usr/lib/ruby/1.8/sup/util.rb:513:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing'
 /usr/lib/ruby/1.8/sup/poll.rb:162:in `add_messages_from'
 /usr/lib/ruby/1.8/sup/maildir.rb:130:in `each'
 /usr/lib/ruby/1.8/sup/maildir.rb:127:in `upto'
 /usr/lib/ruby/1.8/sup/maildir.rb:127:in `each'
 /usr/lib/ruby/1.8/sup/util.rb:552:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:552:in `__pass'
 /usr/lib/ruby/1.8/sup/util.rb:539:in `method_missing'
 /usr/lib/ruby/1.8/sup/poll.rb:141:in `add_messages_from'
 /usr/lib/ruby/1.8/sup/poll.rb:98:in `do_poll'
 /usr/lib/ruby/1.8/sup/poll.rb:86:in `each'
 /usr/lib/ruby/1.8/sup/poll.rb:86:in `do_poll'
 /usr/lib/ruby/1.8/sup/poll.rb:85:in `synchronize'
 /usr/lib/ruby/1.8/sup/poll.rb:85:in `do_poll'
 /usr/lib/ruby/1.8/sup/util.rb:513:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing'
 /usr/lib/ruby/1.8/sup/modes/poll-mode.rb:17:in `poll'
 /usr/lib/ruby/1.8/sup/poll.rb:53:in `poll'
 /usr/lib/ruby/1.8/sup/util.rb:513:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:513:in `method_missing'
 /usr/bin/sup-mail:204
 
 
 3. btw -- I wonder why git repository has no actual tags but just "like
 converted from svn" off-branches for each release?  is that a feature or
 a bug (like forgotten --tags upon push ;))
 
 4. in general -- should I follow the crash message and complain here or just
 report bugs within Debian using reportbug?
 
 5. Since for me released sup had too many corner stones to run reliably
 I've decided to run from git.  Looking at the git history, it looked like
 I should stick to the 'next' branch. Is that correct?
 
 6. In code from next branch (09e6a71e232d2d3352fe45b13789c3441e3ac937) which I
 run with "ruby -I lib -w bin/sup" (sorry if there is a better way I didn't
 find, this is my first ever experience with Ruby-based project), I hit
 some new issues:
 
  * periodically some warnings are dumped to stderr which obscures current UI
 
   rendering... ie warnings like
    /usr/lib/ruby/1.8/time.rb:180: warning: 2 digits year is used
 
   imho they should go to the same log, shouldn't they?
  
  * some "elderly" crash where I don't remember the context which caused
    it
 
  unknown drawable object: nil in
  #<Redwood::LabelListMode:0x7f9272cadfa8> for line 3
  ./lib/sup/modes/scroll-mode.rb:200:in `draw_line'
  ./lib/sup/modes/line-cursor-mode.rb:52:in `draw_line'
  ./lib/sup/modes/line-cursor-mode.rb:120:in `cursor_up'
  ./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:245
 
 
  * Now that I've fetched big bulk of emails into inbox... I wonder if
    there is a logical way to archive all threads BUT not starred ones?
 
 thanks in advance for any reply ;)
 -- 
 Yaroslav O. Halchenko
 Postdoctoral Fellow,   Department of Psychological and Brain Sciences
 Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
 Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
 WWW:   http://www.linkedin.com/in/yarik        
 
 From yoh@dartmouth.edu  Mon Oct 19 13:07:44 2009
 From: yoh@dartmouth.edu (Yaroslav Halchenko)
 Date: Mon, 19 Oct 2009 13:07:44 -0400
 Subject: [sup-talk] little wishlist: don't confuse 'mark as spam' and
  'search for mails from sender' on the same shortcut
 Message-ID: <20091019170744.GE13747@onerussian.com>
 
 After I've done it about 10 times I figured it out what is going wrong
 with my motor-reflexes-getting-used-to-sup-shortcuts:
 
 in the index-mode:
 S : Mark/unmark thread as spam
 
 in the thread-view-mode:
 S : Search for messages from particular people
 .s : Mark this thread as spam and kill buffer
 
 So, I've got used to use S to check for other emails from this sender so
 I could tag/archive them appropriately while going through inbox, but it
 is working only in thread mode... nevertheless I keep hitting S in index
 box since I see no big reason why it shouldn't work in index mode ;)
 
 would it be possible to unify somehow?
 
 
 -- 
 Yaroslav O. Halchenko
 Postdoctoral Fellow,   Department of Psychological and Brain Sciences
 Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
 Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
 WWW:   http://www.linkedin.com/in/yarik        
 
 From lists@onerussian.com  Mon Oct 19 13:39:01 2009
 From: lists@onerussian.com (Yaroslav Halchenko)
 Date: Mon, 19 Oct 2009 13:39:01 -0400
 Subject: [sup-talk] little wishlist: don't confuse 'mark as spam' and
  'search for mails from sender' on the same shortcut
 Message-ID: <20091019173901.GF13747@onerussian.com>
 
 After I've done it about 10 times I figured it out what is going wrong
 with my motor-reflexes-getting-used-to-sup-shortcuts:
 
 in the index-mode:
 S : Mark/unmark thread as spam
 
 in the thread-view-mode:
 S : Search for messages from particular people
 .s : Mark this thread as spam and kill buffer
 
 So, I've got used to use S to check for other emails from this sender so
 I could tag/archive them appropriately while going through inbox, but it
 is working only in thread mode... nevertheless I keep hitting S in index
 box since I see no big reason why it shouldn't work in index mode ;)
 
 would it be possible to unify somehow?
 
 
 -- 
 Yaroslav O. Halchenko
 Postdoctoral Fellow,   Department of Psychological and Brain Sciences
 Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
 Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
 WWW:   http://www.linkedin.com/in/yarik        
 
 From helgedt@tihlde.org  Mon Oct 19 10:07:26 2009
 From: helgedt@tihlde.org (Helge Titlestad)
 Date: Mon, 19 Oct 2009 16:07:26 +0200
 Subject: [sup-talk] [PATCH] detect and set charset on text/* attachments
 Message-ID: <1255961127-sup-3168@tihlde.org>
 
 I got some feedback from non-suppers that my utf-8 text attachments were
 messed up. When I checked they (the MIME headers) lacked any info on charset,
 which I believe should be set for text/*.
 
 Here's a patch that uses the chardet gem to (try to) detect the appropriate charset
 and sets it in the Content-Type header.
 
 Can't guarantee its robustness - have only tried on a couple of text files and
 one non-text file.
 
 Please tell me if I should use some different way of sending patches... This git
 flow is a bit new to me. (=
 -- 
 alge
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Detect-charset-for-text-file-attachments.patch
 Type: application/octet-stream
 Size: 1927 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091019/474102fe/attachment.obj>
 
 From daveadams@gmail.com  Mon Oct 19 14:46:41 2009
 From: daveadams@gmail.com (David Adams)
 Date: Mon, 19 Oct 2009 14:46:41 -0400
 Subject: [sup-talk] Best practice for customizing keymaps?
 Message-ID: <87af9a490910191146o6b34b81ev4723521d17924ae4@mail.gmail.com>
 
 Hello everyone,
 I'd like to make some customizations to the default keymaps for a few
 modes, and I was wondering what was the safest way to do so. On the
 Hooks wiki page, the entry for startup.rb shows how to add keystrokes,
 but based on trying that example out, it appears to work only for
 adding new keystrokes, not overriding existing ones.
 
 So after poking around at the code a bit, dropping this code into
 startup.rb seems to work to entirely replace a keymap with my
 preferences:
 
 class Redwood::Mode
   @@keymaps[Redwood::ThreadViewMode] = Redwood::Keymap.new do |k|
     # key mappings omitted
   end
 end
 
 So my questions are: Is this unsafe in any way (other than that new
 versions of sup may invalidate the specifics of keymap
 implementation)? And is there a better way?
 
 Thanks!
 
 -dave
 
 From cworth@cworth.org  Tue Oct 20 00:24:21 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Mon, 19 Oct 2009 21:24:21 -0700
 Subject: [sup-talk] Indexing messages without ruby
 In-Reply-To: <1255623468-sup-2284@yoom.home.cworth.org>
 References: <1255623468-sup-2284@yoom.home.cworth.org>
 Message-ID: <1256009934-sup-9323@yoom.home.cworth.org>
 
 Excerpts from Carl Worth's message of Thu Oct 15 10:23:40 -0700 2009:
 > As for performance, things look pretty good, but perhaps not as good
 > as I had hoped.
 
 I know William already said he's not all that concerned with the
 performance of sup-sync since it's not a common operation, but me, I
 can't stop working on the problem.
 
 And I think that's justified, really. For one thing, the giant
 sup-sync is one of the first things a new user has to do. And I think
 that having to wait for an operation that's measured in hours before
 being able to use the program at all can be very off-putting.
 
 I think we could do better to give a good first impression.
 
 > So this is preliminary, but it looks like notmuch gives a 5-10x
 > performance improvement over sup, (but likely closer to the 5x end of
 > that range unless you've got a very small index---at which point who
 > cares how fast/slow things are?).
 
 Those numbers were off. I now believe that my original code gained
 only a 3x improvement by switching from ruby/rmail to C/GMime for mail
 parsing. But I've done a little more coding since. Here are the
 current results:
 
   For a benchmark of ~ 45000 messages, rate in messages/sec.:
 
   Rate    Commit ID       Significant change
   -----   ---------       ------------------
   41                      sup (with xapian, from next)
   120     5fbdbeb33       Switch from ruby to C (with GMime)
   538     9bc4253fa       Index headers only, not body
   1050    371091139       Use custom header parser, not GMime
 
   (Before each run the Linux disk cache was cleared with:
           sync; echo 3 > /proc/sys/vm/drop_caches
   )
 
 So beyond the original 3x improvement, I gained a further 4x
 improvement by simply doing less work. I'm now starting off by only
 indexing message-id and thread-id data. That's obviously "cheating" in
 terms of comparing performance, but I think it really makes sense to
 do this.
 
 The idea is that by just computing the thread-ids and indexing those
 for a collection of email, that initial sup-sync could be performed
 very quickly. Then, later, (as a background thread while sup is
 running), the full-text indexing could be performed.
 
 Finally, I gained a final 2x improvement by not using GMime at all,
 (which constructs a data structure for the entire message, even if I
 only want a few header), and instead just rolling a simple parser for
 email headers. (Did you know you can hide nested parenthesized
 comments all over the place in email headers? I didn't.)
 
 I'm quite happy with the final result that's 25x faster than sup.  I
 can build a cold-cache index from my half-million message archive in
 less than 10 minutes, (rather than 4 hours). And performance is fairly
 IO-bound at this point, (in the 10-minute run, less than 7 minutes of
 CPU are used).
 
 Anyway, there are some ideas to consider for sup.
 
 If anyone wants to play with my code, it's here:
 
 	git clone git://notmuch.org/notmuch
 
 I won't bore the list with further developments in notmuch, if any,
 unless it's on-topic, (such as someone trying to make sup work on top
 of an index built by notmuch). And I'd be delighted to see that kind
 of thing happen.
 
 Happy hacking,
 
 -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/20091019/3839b0cc/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Tue Oct 20 01:34:37 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 19 Oct 2009 22:34:37 -0700
 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with
 	plain monkeypatching
 In-Reply-To: <20091012223449.GB31940@tilus.net>
 References: <20091012223449.GB31940@tilus.net>
 Message-ID: <1256016877-5238-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |   25 +++++++++++++++++++++++++
  1 files changed, 25 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index e1cfe65..c373c17 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -560,7 +560,32 @@ EOS
        raise "Invalid term type #{type}"
      end
    end
 +end
  
  end
  
 +class Xapian::Document
 +  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(Redwood::XapianIndex::STEM_LANGUAGE)
 +    term_generator.document = self
 +    term_generator.index_text text, weight, prefix
 +  end
 +
 +  alias old_add_term add_term
 +  def add_term term
 +    if term.length <= Redwood::XapianIndex::MAX_TERM_LENGTH
 +      old_add_term term
 +    else
 +      warn "dropping excessively long term #{term}"
 +    end
 +  end
  end
 -- 
 1.6.4.2
 
 
 From rlane@club.cc.cmu.edu  Tue Oct 20 02:13:58 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 20 Oct 2009 02:13:58 -0400
 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with
 	plain monkeypatching
 In-Reply-To: <1256016877-5238-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <20091012223449.GB31940@tilus.net>
 	<1256016877-5238-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1256019034-sup-9298@zyrg.net>
 
 Disregard this one. (I thought master had already gotten my
 update-message-state patch)
 
 Excerpts from Rich Lane's message of Tue Oct 20 01:34:37 -0400 2009:
 > ---
 >  lib/sup/xapian_index.rb |   25 +++++++++++++++++++++++++
 >  1 files changed, 25 insertions(+), 0 deletions(-)
 > 
 > diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 > index e1cfe65..c373c17 100644
 > --- a/lib/sup/xapian_index.rb
 > +++ b/lib/sup/xapian_index.rb
 > @@ -560,7 +560,32 @@ EOS
 >        raise "Invalid term type #{type}"
 >      end
 >    end
 > +end
 >  
 >  end
 >  
 > +class Xapian::Document
 > +  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(Redwood::XapianIndex::STEM_LANGUAGE)
 > +    term_generator.document = self
 > +    term_generator.index_text text, weight, prefix
 > +  end
 > +
 > +  alias old_add_term add_term
 > +  def add_term term
 > +    if term.length <= Redwood::XapianIndex::MAX_TERM_LENGTH
 > +      old_add_term term
 > +    else
 > +      warn "dropping excessively long term #{term}"
 > +    end
 > +  end
 >  end
 
 From rlane@club.cc.cmu.edu  Tue Oct 20 02:14:07 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 19 Oct 2009 23:14:07 -0700
 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with
 	plain monkeypatching
 In-Reply-To: <20091012223449.GB31940@tilus.net>
 References: <20091012223449.GB31940@tilus.net>
 Message-ID: <1256019247-6046-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |   47 ++++++++++++++++++++++-------------------------
  1 files changed, 22 insertions(+), 25 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index ad45b0e..34d67d5 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -565,35 +565,32 @@ EOS
        raise "Invalid term type #{type}"
      end
    end
 +end
  
 -  module DocumentMethods
 -    def entry
 -      Marshal.load data
 -    end
 -
 -    def entry=(x)
 -      self.data = Marshal.dump x
 -    end
 +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
 +class Xapian::Document
 +  def entry
 +    Marshal.load data
 +  end
  
 -    def add_term term
 -      if term.length <= MAX_TERM_LENGTH
 -        super term
 -      else
 -        warn "dropping excessively long term #{term}"
 -      end
 -    end
 +  def entry=(x)
 +    self.data = Marshal.dump x
    end
 -end
  
 -end
 +  def index_text text, prefix, weight=1
 +    term_generator = Xapian::TermGenerator.new
 +    term_generator.stemmer = Xapian::Stem.new(Redwood::XapianIndex::STEM_LANGUAGE)
 +    term_generator.document = self
 +    term_generator.index_text text, weight, prefix
 +  end
  
 -class Xapian::Document
 -  include Redwood::XapianIndex::DocumentMethods
 +  alias old_add_term add_term
 +  def add_term term
 +    if term.length <= Redwood::XapianIndex::MAX_TERM_LENGTH
 +      old_add_term term
 +    else
 +      warn "dropping excessively long term #{term}"
 +    end
 +  end
  end
 -- 
 1.6.4.2
 
 
 From mailinglist@flasht.de  Tue Oct 20 08:33:35 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Tue, 20 Oct 2009 14:33:35 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254866136-sup-6974@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1254758256-sup-7400@thinkpad-ubuntu>
 	<1254842820-sup-9099@masanjin.net>
 	<1254861112-sup-590@thinkpad-ubuntu>
 	<1254866136-sup-6974@thinkpad-ubuntu>
 Message-ID: <1256041985-sup-5427@thinkpad-ubuntu>
 
 Just wondering, if anyone is still interested in this, since no one has replied yet.
 -- 
 ================================
 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/20091020/714293fd/attachment.bin>
 
 From cworth@cworth.org  Tue Oct 20 11:35:57 2009
 From: cworth@cworth.org (Carl Worth)
 Date: Tue, 20 Oct 2009 08:35:57 -0700
 Subject: [sup-talk] Indexing messages without ruby
 In-Reply-To: <1256009934-sup-9323@yoom.home.cworth.org>
 References: <1255623468-sup-2284@yoom.home.cworth.org>
 	<1256009934-sup-9323@yoom.home.cworth.org>
 Message-ID: <1256052859-sup-6008@yoom.home.cworth.org>
 
 Excerpts from Carl Worth's message of Mon Oct 19 21:24:21 -0700 2009:
 >     git clone git://notmuch.org/notmuch
 
 That should be:
 
 	git clone git://notmuchmail.org/git/notmuch
 
 Clearly typing without my braing engaged.
 
 -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/20091020/99876743/attachment.bin>
 
 From usul@aruba.it  Wed Oct 21 08:29:59 2009
 From: usul@aruba.it (Fabio Riga)
 Date: Wed, 21 Oct 2009 14:29:59 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1256041985-sup-5427@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1254758256-sup-7400@thinkpad-ubuntu>
 	<1254842820-sup-9099@masanjin.net>
 	<1254861112-sup-590@thinkpad-ubuntu>
 	<1254866136-sup-6974@thinkpad-ubuntu>
 	<1256041985-sup-5427@thinkpad-ubuntu>
 Message-ID: <1256127705-sup-5539@doma>
 
 Excerpts from Christopher Bertels's message of mar ott 20 14:33:35 +0200 2009:
 > Just wondering, if anyone is still interested in this, since no one has replied
 > yet.
 Well, I'm really interested, but I'm just a user. I could only make
 Italian translation, but how? Is it a normal gettext .po file? What I
 have to do?
 
 Cheers,
 Fabio
 
 From guillaume.quintard@gmail.com  Wed Oct 21 12:41:00 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Wed, 21 Oct 2009 18:41:00 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1256127705-sup-5539@doma>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1254758256-sup-7400@thinkpad-ubuntu>
 	<1254842820-sup-9099@masanjin.net>
 	<1254861112-sup-590@thinkpad-ubuntu>
 	<1254866136-sup-6974@thinkpad-ubuntu>
 	<1256041985-sup-5427@thinkpad-ubuntu> <1256127705-sup-5539@doma>
 Message-ID: <1256143200-sup-8858@altis>
 
 > Excerpts from Christopher Bertels's message of mar ott 20 14:33:35 +0200 2009:
 > Well, I'm really interested, but I'm just a user. I could only make
 > Italian translation, but how? Is it a normal gettext .po file? What I
 > have to do?
 
 Same here, with french translation.
 Sorry for the late reply.
 
 -- 
 Guillaume
 
 From mailinglist@flasht.de  Wed Oct 21 14:37:34 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Wed, 21 Oct 2009 20:37:34 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1256127705-sup-5539@doma>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1254758256-sup-7400@thinkpad-ubuntu>
 	<1254842820-sup-9099@masanjin.net>
 	<1254861112-sup-590@thinkpad-ubuntu>
 	<1254866136-sup-6974@thinkpad-ubuntu>
 	<1256041985-sup-5427@thinkpad-ubuntu> <1256127705-sup-5539@doma>
 Message-ID: <1256149858-sup-8291@thinkpad-ubuntu>
 
 Excerpts from Fabio Riga's message of Mi Okt 21 14:29:59 +0200 2009:
 > Well, I'm really interested, but I'm just a user. I could only make
 > Italian translation, but how? Is it a normal gettext .po file? What I
 > have to do?
 
 Get my sup clone git repository at gitorious: 
 
 $ git clone git://gitorious.org/~bakkdoor/sup/bakkdoors-clone.git
 
 Then, checkout the i18n branch.
 
 $ cd bakkdoors-clone
 $ git checkout i18n
 
 Then have a look at the m17n folder. You should find a de.yaml and
 en.yaml file.  They are for german and english translations. You can
 create your own translation files in there. For example, fr.yaml for
 french or it.yaml for italian.  Have a look at en.yaml to see, what
 the original texts are (in english) and come up with your own
 translation. That's basically it. Then, if you have sup set up to run
 from that branch, you can set within your sup config file
 (~/.sup/config.yaml) to use any language, e.g.:
 
 :language: de
 
 for german. Sup will then look into the m17n folder for a file called "de.yaml"
 
 I hope that helped.
 
 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/20091021/8c8dbb43/attachment-0001.bin>
 
 From richard@infoarts.info  Wed Oct 21 22:36:53 2009
 From: richard@infoarts.info (Richard Sandilands)
 Date: Thu, 22 Oct 2009 13:36:53 +1100
 Subject: [sup-talk] Sup crashing upon save changes ($)
 Message-ID: <1256178926-sup-1780@Richard-Sandilandss-MacBook-Pro.local>
 
 I'm tracking next and when I hit $, sup crashes and logs this:
 
 Any clues on how to get things ironed out would be appreciated.
 
 Exception log:
 
 --- Errno::ENOENT from thread: load messages for thread-view-mode
 No such file or directory - /Users/richard/.sup/drafts/18
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/draft.rb:74:in `initialize'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/draft.rb:74:in `open'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/draft.rb:74:in `load_header'
 /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/message.rb:235:in `load_from_source!'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:108:in `select'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/hook.rb:121:in `each_with_index'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:81:in `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:170:in `each_with_stuff'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:168:in `each_with_stuff'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:170:in `each_with_stuff'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:169:in `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:169:in `each_with_stuff'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:78:in `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/thread.rb:75:in `each'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:105:in `each_with_index'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:105:in `select'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/buffer.rb:709:in `say'
 /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/thread-index-mode.rb:104:in `select'
 /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:101:in `select'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/mode.rb:51:in `send'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/mode.rb:51:in `handle_input'
 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/buffer.rb:260:in `handle_input'
 /Users/richard/src/mainline/bin/sup:245
 
 
 -- 
 Richard Sandilands
 
 From mailinglist@flasht.de  Thu Oct 22 04:26:42 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Thu, 22 Oct 2009 10:26:42 +0200
 Subject: [sup-talk] Completion for search queries
 Message-ID: <1256199860-sup-4407@thinkpad-ubuntu>
 
 Hi,
 
 I just came up with an idea (don't know if this has been requested
 yet). What I'd really like to see is some kind of query-completion
 when searching in sup. Often, when I want to search for messages, I
 don't know all the supported query operators (like from:, +label:
 etc.)
 
 It would be super cool if you'd get some kind of completion (or even a
 list of possible completions?) when hitting tab.
 
 Anyone else who would like to have this feature in sup?
 
 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/20091022/91c55c7a/attachment.bin>
 
 From gregor@hoffleit.de  Thu Oct 22 09:10:10 2009
 From: gregor@hoffleit.de (Gregor Hoffleit)
 Date: Thu, 22 Oct 2009 15:10:10 +0200
 Subject: [sup-talk] (Orphaned?) bug tracker at rubyforge.org?
 Message-ID: <1256216959-sup-8012@sam.mediasupervision.de>
 
 The Sup Gitorious homepage (http://gitorious.org/sup) mentions a Ditz
 bugtracker at sup.rubyforge.org, which seems to be orphaned since 2008,
 though. This is in contrast to the Sup homepage, which says to report
 bugs to this mailing list, sup-talk.
 
 If the bug tracker is not to be acticely used any longer, shouldn't it
 be removed from the Sup Gitorious page?
 
 
 Regards,
     Gregor Hoffleit
 
 From tero@tilus.net  Fri Oct 23 02:00:12 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Fri, 23 Oct 2009 09:00:12 +0300
 Subject: [sup-talk] Localized date on mbox From line in sent messages
 Message-ID: <1256276875-sup-5782@tilus.net>
 
 This might be known.  I accidentally used 0.8.1 instead of git next
 once and it screwed up my sent box.  After forwarding a mail sup
 started to blow up (what felt like) after initiall poll.
 
 NoMethodError from thread: poll after loading inbox
 undefined method `[]' for nil:NilClass
 /home/terotil/src/sup/lib/sup/xapian_index.rb:567:in `mkterm'
 /home/terotil/src/sup/lib/sup/xapian_index.rb:338:in `find_docid'
 /home/terotil/src/sup/lib/sup/xapian_index.rb:344:in `find_doc'
 /home/terotil/src/sup/lib/sup/xapian_index.rb:354:in `get_entry'
 /home/terotil/src/sup/lib/sup/xapian_index.rb:73:in `build_message'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /home/terotil/src/sup/lib/sup/xapian_index.rb:363:in `synchronize'
 /home/terotil/src/sup/lib/sup/xapian_index.rb:73:in `build_message'
 /home/terotil/src/sup/lib/sup/util.rb:520:in `send'
 /home/terotil/src/sup/lib/sup/util.rb:520:in `method_missing'
 /home/terotil/src/sup/lib/sup/poll.rb:109:in `do_poll'
 /home/terotil/src/sup/lib/sup/poll.rb:166:in `each_message_from'
 /home/terotil/src/sup/lib/sup/source.rb:104:in `each'
 
 I went to throw in debugger and see what was inside.
 
 /home/terotil/src/sup/lib/sup/poll.rb:109
 old_m = Index.build_message m.id
 (rdb:1) eval m
 #<Redwood::Message:0xb649d5e8 @attachments=[], @have_snippet=false, @source_info=4598, @chunks=[#<Redwood::Chunk::Text:0xb648d328 @lines=["...", "", "***********************************************************************", " An error occurred while loading this message. It is possible that", " the source has changed, or (in the case of remote sources) is down.", " You can check the log for errors, though hopefully an error window", " should have popped up at some point.", "", " The message location was:", " sup://sent#4598", "***********************************************************************", "", "The error message was:", "  mismatch in mbox file offset 4598: \"From tero at tilus.net pe", "loka\\302\\240\\302\\240 16 19:06:58 +0300 2009\\n\"."]>], @dirty=true, @snippet_contains_encrypted_content=false, @source=#<Recoverable:0xb78023cc @error=#<Redwood::OutOfSyncSourceError: mismatch in mbox file offset 4598: "From tero at tilus.net pe loka\302\240\302\240 16 19:06:58 +0300 2
  009\n".>, @mutex=#<Mutex:0xb7802390>, @o=#<Redwood::SentLoader:0xb7809b2c @cur_offset=12856, @dirty=true, @uri="mbox:///home/terotil/.sup/sent.mbox", @archived=true, @path="/home/terotil/.sup/sent.mbox", @filename="/home/terotil/.sup/sent.mbox", @f=#<File:/home/terotil/.sup/sent.mbox>, @mutex=#<Mutex:0xb7809adc>, @labels=#<Set: {}>, @id=nil, @usual=true>>, @encrypted=false, @refs=[], @labels=#<Set: {:sent, :inbox, :unread}>, @snippet=nil>
 
 Okay, it could not load a message from sent box because it thought the
 message wasnt there anymore.  The missmatch was because of the
 starting From line had broken date.  It was a localized version of
 what should have been there, with an added bonus of multibyte chars
 (two nonbreaking spaces after month name, no idea how thats even
 possible).
 
 Fixed it by fixing the mbox.  Dunno how the broken header came to be.
 The file has most certainly been accessed by sup alone.
 
 Full broken headers follow
 
 >From tero at tilus.net pe loka?? 16 19:06:58 +0300 2009
 Subject: Fwd: Neuroscience, Cogmed, and learning disabilities
 From: Tero Tilus <tero at tilus.net>
 To: joonas.kekkonen <joonas.kekkonen at iki.fi>
 Date: Fri, 16 Oct 2009 19:06:58 +0300
 Message-Id: <1255709172-sup-7715 at kuovi.tilus.net>
 User-Agent: Sup/0.8.1
 Content-Transfer-Encoding: 8bit
 Content-Type: multipart/mixed; boundary="=-1255709218-544380-431-3013-1-="
 MIME-Version: 1.0
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Fri Oct 23 02:35:46 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Fri, 23 Oct 2009 09:35:46 +0300
 Subject: [sup-talk] (Orphaned?) bug tracker at rubyforge.org?
 In-Reply-To: <1256216959-sup-8012@sam.mediasupervision.de>
 References: <1256216959-sup-8012@sam.mediasupervision.de>
 Message-ID: <1256279637-sup-3085@tilus.net>
 
 Gregor Hoffleit, 2009-10-22 16:10:
 > If the bug tracker is not to be acticely used any longer, shouldn't
 > it be removed from the Sup Gitorious page?
 
 Definitely should if that is the intention.  Is it?
 
 Why use this list to track bugs in the first place?
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Fri Oct 23 03:00:21 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Fri, 23 Oct 2009 10:00:21 +0300
 Subject: [sup-talk] i18n?
 In-Reply-To: <1254487575-sup-5468@thinkpad-ubuntu>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 Message-ID: <1256280223-sup-736@tilus.net>
 
 Excerpts from 's message of pe loka 02 15:52:47 +0300 2009:
 > Please tell me what you think.
 
 Why not default to the english strings as translation keys and
 fallback to key itself in case of missing translation?  This has imo
 several advantages.  You can go grep the source using what you see in
 sup UI (instead of first greping language yaml).  Adding new strings
 is cumbersome with (mostly unnecessary) key indirection.  Code is more
 readable when messages are inlined.  If you change a string a check of
 translations is forced (there is no translation for the changed
 version).  Most translation workflow tools expect this kind of
 behavior.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From usul@aruba.it  Fri Oct 23 07:23:06 2009
 From: usul@aruba.it (Fabio Riga)
 Date: Fri, 23 Oct 2009 13:23:06 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1256280223-sup-736@tilus.net>
 References: <1254353101-sup-1021@thinkpad-ubuntu>
 	<1254415145-sup-635@masanjin.net>
 	<1254420802-sup-3742@thinkpad-ubuntu>
 	<1254421405-sup-8083@masanjin.net>
 	<1254442420-sup-3771@thinkpad-ubuntu>
 	<1254487575-sup-5468@thinkpad-ubuntu>
 	<1256280223-sup-736@tilus.net>
 Message-ID: <1256295847-sup-9437@viajero>
 
 Excerpts from Tero Tilus's message of ven ott 23 09:00:21 +0200 2009:
 > Excerpts from 's message of pe loka 02 15:52:47 +0300 2009:
 > > Please tell me what you think.
 > 
 > Why not default to the english strings as translation keys and
 > fallback to key itself in case of missing translation?  This has imo
 > several advantages.  You can go grep the source using what you see in
 > sup UI (instead of first greping language yaml).
 
 Well, I finally read the code and I agree with Tero. I also think that the
 use of gettext will be simpler for both developer and translator. In
 this way, every time a developer add a new string he need to write it
 twice, or another developer has to hack it. Instead with gettext the
 developer write his string, surrounded with _() or n_() and he's done
 (tell me, if I'm wrong).
 
 Furthermore people used to .po files (like me) will know what to do and
 are already provided with tools for that purpose (i.e. Vim :-) ).
 
 Can anyone explain me where and why a translated string in the UI should be
 searchable with a regular expression? (Maybe this question is due to the
 fact that I still don't understand sup internals...)
 
 Cheers,
 Fabio
 
 From gregor@hoffleit.de  Fri Oct 23 07:48:31 2009
 From: gregor@hoffleit.de (Gregor Hoffleit)
 Date: Fri, 23 Oct 2009 13:48:31 +0200
 Subject: [sup-talk] A fix for the joining threads bug with Ferret
 Message-ID: <1256297205-sup-683@sam.mediasupervision.de>
 
 I did a little bit research regarding the problem that joining threads
 isn't persistent (as described in [1]-[3]).
 
 I managed to track down the problem until the following line in
 FerretIndex#sync_message in lib/sup/ferret_index.rb.
 
   d = { ...  :refs => (entry[:refs] || (m.refs + m.replytos).uniq.join(" ")) }
 
 I have problems to understand what this line is supposed to do.
 
 For me, it always evaluates to "entry[:refs]" (even if that's an empty
 string!), losing the reference in the modified message m, which was added
 by add_ref. Therefore the manual join is always lost.
 
 With my limited Ruby knowledge, my quick and dirty fix was:
 
     if entry[:refs]!="" then
        d[:refs]=entry[:refs]
     else
        d[:refs]=(m.refs + m.replytos).uniq.join(" ")
     end
 
 Is this what the above code is about?
 
 
 Btw, the code in xapian_index.rb looks much different. Still, I'd like
 to see this fixed for Xapian.
 
 
 Regards,
     Gregor Hoffleit
 
 
 [1] http://sup.rubyforge.org/ditz/issue-4e501973cea5bd1f28739ae4cea98edce8249895.html
 [2] http://rubyforge.org/pipermail/sup-talk/2009-April/002050.html
 [3] http://rubyforge.org/pipermail/sup-talk/2009-April/002060.html
 
 From tero@tilus.net  Fri Oct 23 09:15:50 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Fri, 23 Oct 2009 16:15:50 +0300
 Subject: [sup-talk] A fix for the joining threads bug with Ferret
 In-Reply-To: <1256297205-sup-683@sam.mediasupervision.de>
 References: <1256297205-sup-683@sam.mediasupervision.de>
 Message-ID: <1256302994-sup-9955@tilus.net>
 
 Excerpts from Gregor Hoffleit's message:
 > With my limited Ruby knowledge, my quick and dirty fix was:
 > 
 >     if entry[:refs]!="" then
 >        d[:refs]=entry[:refs]
 >     else
 >        d[:refs]=(m.refs + m.replytos).uniq.join(" ")
 >     end
 > 
 > Is this what the above code is about?
 
 I would expect it to be something alike.  Rails has Object#empty?
 which is true (I think) for nil, false, empty list and empty string.
 I'd go with
 
   entry[:refs].to_s != ""
 
 to handle nil as "no refs" too.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From pioto@pioto.org  Fri Oct 23 17:13:35 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Fri, 23 Oct 2009 17:13:35 -0400
 Subject: [sup-talk] mbox date fail
 Message-ID: <2aeb4e149305569502f106c7e54ae107@localhost>
 
 
 Hi,
 
 I seem to be caught in a bit of a catch-22. I can't reliably use mbox
 because of shortcomings in its format. And, I can't use maildir because
 sup-sync-back doesn't support it.
 
 More specifically, I seem to come across this much more often that I
 should. It's caused by someone starting a line of their message with
 "From". For example:
 
   ...
   X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.0
   Status: 
   X-Keywords:                                                             
        
   Content-Length: 1742
 
   From the ticket he states that 1.2.3.4 is the IP:
 
   ...
 
 That yields this exception:
 
   [Fri Oct 23 17:07:00 -0400 2009] unlocking
 /usr/home/staff/mike/.sup/lock...
   /usr/local/lib/ruby/1.8/time.rb:184:in `local': argument out of range
 (ArgumentError)
         from /usr/local/lib/ruby/1.8/time.rb:184:in `make_time'
         from /usr/local/lib/ruby/1.8/time.rb:243:in `parse'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox.rb:15:in
 `is_break_line?'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox/loader.rb:165:in
 `next'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox/loader.rb:145:in
 `synchronize'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mbox/loader.rb:145:in
 `next'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/source.rb:103:in
 `each'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in
 `send'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:560:in
 `__pass'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:547:in
 `method_missing'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:139:in
 `each_message_from'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in
 `send'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:520:in
 `method_missing'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:146
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141:in
 `each'
         from
 /usr/home/staff/mike/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:141
         from /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup-sync:19:in
 `load'
         from /usr/home/staff/mike/lib/ruby/gems/1.8/bin/sup-sync:19
 
 Is there much of anything that I can do to mitigate this problem, aside
 from manually altering every offending message?
 
 It seems like the messages' Content-Length header should be used to skip
 past the body and ignore the offending Froms? Or, at least, if that sort of
 ArgumentError is thrown, maybe it should be caught and handled better?
 
 I'm running current master (2dfd378b616243d03203e49f5ee29636051d3cbf).
 
 Thanks.
 
 -- 
 Mike Kelly
 
 From sgoldman@tower-research.com  Mon Oct 26 16:15:04 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Mon, 26 Oct 2009 16:15:04 -0400
 Subject: [sup-talk] Can't search without crashing
 Message-ID: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 
 
 Wow, I guess I haven't tried to search in a while... I can't search
 for *anything* without it crashing hard.  Every time.  I'm on master.
 
 Anyone??
 
 
 --- RuntimeError from thread: load threads for thread-index-mode
 invalid source 4
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in `build_message'
 /apps/home/sgoldman/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:256:in `build_message'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in `each_id_by_date'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in `call'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in `load_n_threads'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in `each_id_by_date'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in `each'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in `each_id_by_date'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:328:in `load_n_threads'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:77:in `reporting_thread'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `initialize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `new'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `reporting_thread'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:81:in `initialize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `call'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `each'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in `initialize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in `new'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in `initialize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:54:in `initialize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:6:in `initialize'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30:in `new'
 /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30:in `spawn_from_query'
 bin/sup:275
 -- 
 
 Steve Goldman
 sgoldman at tower-research.com
 
 T: 212.219.6014
 F: 212.219.6007
 
 Tower Research Capital, LLC
 377 Broadway, 11th Fl.
 New York, NY 10013
 
 From sgoldman@tower-research.com  Mon Oct 26 19:30:20 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Mon, 26 Oct 2009 19:30:20 -0400
 Subject: [sup-talk] Can't search without crashing
 In-Reply-To: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 Message-ID: <1256599752-sup-9794@sgoldmanlinux.tower-research.com>
 
 
 It's not every time.
 
 Here's my theory: my mail sits on a server across a network.  When I
 can access that data *quickly*, sup doesn't crash.  When the network
 (or file system or whatever) takes longer, sup crashes.
 
 Can anyone back that up?
 
 Thanks.
 
 
 Excerpts from Steve Goldman's message of Mon Oct 26 16:15:04 -0400 2009:
 > 
 > Wow, I guess I haven't tried to search in a while... I can't search
 > for *anything* without it crashing hard.  Every time.  I'm on master.
 > 
 > Anyone??
 > 
 > 
 > --- RuntimeError from thread: load threads for thread-index-mode
 > invalid source 4
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in
 > `build_message'
 > /apps/home/sgoldman/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:256:in
 > `build_message'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in
 > `each_id_by_date'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in `call'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:332:in
 > `load_n_threads'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:163:in
 > `each_id_by_date'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in `each'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:162:in
 > `each_id_by_date'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/thread.rb:328:in
 > `load_n_threads'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:625:
 > in `__unprotected_load_n_threads'
 > (eval):12:in `load_n_threads'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:609:
 > in `load_n_threads_background'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:77:in `reporting_thread'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `initialize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `new'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup.rb:75:in `reporting_thread'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:608:
 > in `load_n_threads_background'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:679:
 > in `__unprotected_load_threads'
 > (eval):12:in `load_threads'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:81:i
 > n `initialize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in
 >  `call'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in
 >  `initialize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in
 >  `each'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:22:in
 >  `initialize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in
 >  `new'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/line-cursor-mode.rb:19:in
 >  `initialize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/thread-index-mode.rb:54:i
 > n `initialize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:6:
 > in `initialize'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30
 > :in `new'
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/modes/search-results-mode.rb:30
 > :in `spawn_from_query'
 > bin/sup:275
 > -- 
 > 
 > Steve Goldman
 > sgoldman at tower-research.com
 > 
 > T: 212.219.6014
 > F: 212.219.6007
 > 
 > Tower Research Capital, LLC
 > 377 Broadway, 11th Fl.
 > New York, NY 10013
 -- 
 
 Steve Goldman
 sgoldman at tower-research.com
 
 T: 212.219.6014
 F: 212.219.6007
 
 Tower Research Capital, LLC
 377 Broadway, 11th Fl.
 New York, NY 10013
 
 From tero@tilus.net  Tue Oct 27 05:58:47 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 27 Oct 2009 11:58:47 +0200
 Subject: [sup-talk] Can't search without crashing
 In-Reply-To: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 Message-ID: <1256637386-sup-8828@tilus.net>
 
 Steve Goldman, 2009-10-26 22:15:
 > Wow, I guess I haven't tried to search in a while... I can't search
 > for *anything* without it crashing hard.  Every time.  I'm on master.
 > 
 > Anyone??
 > 
 > --- RuntimeError from thread: load threads for thread-index-mode
 > invalid source 4
 > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in
 > `build_message'
 
 http://gitorious.org/sup/mainline/blobs/master/lib/sup/ferret_index.rb#line260
 
 Looks like Sup cant find the source for a message (appearing in
 results?).  Have you altered your sources lately?  Afaik you might
 need to rebuild your index.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From kvrkreddy@gmail.com  Tue Oct 27 07:34:34 2009
 From: kvrkreddy@gmail.com (k.v.ramakrishna reddy)
 Date: Tue, 27 Oct 2009 17:04:34 +0530
 Subject: [sup-talk] Using TLS instead of ssl
 Message-ID: <2b29d9f30910270434k65550eaqf5187d048b604020@mail.gmail.com>
 
 Hi,
    What are the changes that i need to make so that sup uses TLS instead of
 ssl when connecting to my source ? Further more how can i delete a source ?
 
 thanks very much
 karri
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091027/834db656/attachment.html>
 
 From sgoldman@tower-research.com  Tue Oct 27 08:14:50 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Tue, 27 Oct 2009 08:14:50 -0400
 Subject: [sup-talk] Can't search without crashing
 In-Reply-To: <1256637386-sup-8828@tilus.net>
 References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 	<1256637386-sup-8828@tilus.net>
 Message-ID: <1256645659-sup-3884@sgoldmanlinux.tower-research.com>
 
 Excerpts from Tero Tilus's message of Tue Oct 27 05:58:47 -0400 2009:
 > Steve Goldman, 2009-10-26 22:15:
 > > Wow, I guess I haven't tried to search in a while... I can't search
 > > for *anything* without it crashing hard.  Every time.  I'm on master.
 > > 
 > > Anyone??
 > > 
 > > --- RuntimeError from thread: load threads for thread-index-mode
 > > invalid source 4
 > > /apps/infrafs1/sgoldman/sup-src/mainline/lib/sup/ferret_index.rb:260:in
 > > `build_message'
 > 
 > http://gitorious.org/sup/mainline/blobs/master/lib/sup/ferret_index.rb#line260
 > 
 > Looks like Sup cant find the source for a message (appearing in
 > results?).  Have you altered your sources lately?  Afaik you might
 > need to rebuild your index.
 > 
 
 No, it can find it.  But sometimes it takes a long time.
 
 Is there some sort of timeout built into the polling process that
 could cause a crash?
 -- 
 
 Steve Goldman
 sgoldman at tower-research.com
 
 T: 212.219.6014
 F: 212.219.6007
 
 Tower Research Capital, LLC
 377 Broadway, 11th Fl.
 New York, NY 10013
 
 From jdugan@es.net  Wed Oct 28 12:59:20 2009
 From: jdugan@es.net (Jon Dugan)
 Date: Wed, 28 Oct 2009 11:59:20 -0500
 Subject: [sup-talk] exception in mainline
 Message-ID: <1256749083-sup-3681@arrakis.es.net>
 
 i now get this when i start sup.  i'm running mainline.
 
 --- RuntimeError from thread: load threads for thread-index-mode
 wrong id called on nil
 ./lib/sup.rb:17:in `id'
 ./lib/sup/modes/thread-index-mode.rb:225:in `update'
 ./lib/sup/hook.rb:122:in `sort_by'
 ./lib/sup/modes/thread-index-mode.rb:225:in `each'
 ./lib/sup/modes/thread-index-mode.rb:225:in `sort_by'
 ./lib/sup/modes/thread-index-mode.rb:225:in `update'
 ./lib/sup/modes/thread-index-mode.rb:223:in `synchronize'
 ./lib/sup/modes/thread-index-mode.rb:223:in `update'
 ./lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads'
 ./lib/sup/thread.rb:334:in `load_n_threads'
 ./lib/sup/xapian_index.rb:151:in `each_id_by_date'
 ./lib/sup/xapian_index.rb:144:in `each_id'
 ./lib/sup/xapian_index.rb:144:in `each'
 ./lib/sup/xapian_index.rb:144:in `each_id'
 ./lib/sup/xapian_index.rb:151: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'
 bin/sup:199
 
 -- 
 Jon M. Dugan <jdugan at es.net>
 ESnet Network Engineering Group
 Lawrence Berkeley National Laboratory
 
 From jdugan@es.net  Wed Oct 28 13:14:51 2009
 From: jdugan@es.net (Jon Dugan)
 Date: Wed, 28 Oct 2009 12:14:51 -0500
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 Message-ID: <1256749942-sup-4831@arrakis.es.net>
 
 make path to the exception log relative to BASE_DIR
 fix a typo in email address of list.
 
 ---
  bin/sup |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 7641401..a881284 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty?
  ----------------------------------------------------------------
  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
 +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the
 +circumstances to sup-talk at rubyforge dot org so that I might
  address this problem. Thank you!
  
  Sincerely,
 -- 
 1.6.4.4
 
 -- 
 Jon M. Dugan <jdugan at es.net>
 ESnet Network Engineering Group
 Lawrence Berkeley National Laboratory
 
 From nicolas.pouillard@gmail.com  Wed Oct 28 16:05:27 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Wed, 28 Oct 2009 21:05:27 +0100
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1256749942-sup-4831@arrakis.es.net>
 References: <1256749942-sup-4831@arrakis.es.net>
 Message-ID: <1256760295-sup-9873@peray>
 
 Excerpts from Jon Dugan's message of Wed Oct 28 18:14:51 +0100 2009:
 > make path to the exception log relative to BASE_DIR
 > fix a typo in email address of list.
 > 
 > ---
 >  bin/sup |    4 ++--
 >  1 files changed, 2 insertions(+), 2 deletions(-)
 > 
 > diff --git a/bin/sup b/bin/sup
 > index 7641401..a881284 100755
 > --- a/bin/sup
 > +++ b/bin/sup
 > @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty?
 >  ----------------------------------------------------------------
 >  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
 > +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the
 > +circumstances to sup-talk at rubyforge dot org so that I might
 
 I think the *orgs* was on purpose.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From jdugan@es.net  Wed Oct 28 16:22:32 2009
 From: jdugan@es.net (Jon Dugan)
 Date: Wed, 28 Oct 2009 15:22:32 -0500
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1256760295-sup-9873@peray>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 Message-ID: <1256760970-sup-8118@arrakis.es.net>
 
 Excerpts from Nicolas Pouillard's message of Wed Oct 28 15:05:27 -0500 2009:
 > Excerpts from Jon Dugan's message of Wed Oct 28 18:14:51 +0100 2009:
 > > make path to the exception log relative to BASE_DIR
 > > fix a typo in email address of list.
 > > 
 > > ---
 > >  bin/sup |    4 ++--
 > >  1 files changed, 2 insertions(+), 2 deletions(-)
 > > 
 > > diff --git a/bin/sup b/bin/sup
 > > index 7641401..a881284 100755
 > > --- a/bin/sup
 > > +++ b/bin/sup
 > > @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty?
 > >  ----------------------------------------------------------------
 > >  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
 > > +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the
 > > +circumstances to sup-talk at rubyforge dot org so that I might
 > 
 > I think the *orgs* was on purpose.
 
 I was wondering about that.  It seemed odd to me to be obfuscating the email
 address at all in this context since this is an error message not a webpage.
 
 In my mind the usability enhancement of being able to cut and paste the email
 address would increase the likelyhood of people reporting errors.
 
 Obviously not a big deal either way...
 
 Jon
 -- 
 Jon M. Dugan <jdugan at es.net>
 ESnet Network Engineering Group
 Lawrence Berkeley National Laboratory
 
 From Jonah@GoodCoffee.ca  Wed Oct 28 18:06:43 2009
 From: Jonah@GoodCoffee.ca (Jonah)
 Date: Wed, 28 Oct 2009 18:06:43 -0400
 Subject: [sup-talk] [PATCH] change opening attachements on darwin to use
  open instead of run-mailcap
 Message-ID: <4AE8C073.404@GoodCoffee.ca>
 
 Hey everyone,
 
 I've been working on getting sup to work in MacOSX (darwin).  MacOSX has a special command (open) for opening files - there is no support for mailcap.  This patch uses case to run the appropriate command depending on the architecture used.
 
 I still haven't gotten sup to send mail yet,.. so more patches for MacOSX will probably be forthcoming.  :)
 
 I'm loving sup so far, keep up the great work!
 
 Cheers,
 
 Jonah
 
 ---
  lib/sup/message-chunks.rb |    7 ++++++-
  1 files changed, 6 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
 index edc40c4..581b707 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -132,7 +132,12 @@ EOS
      def initial_state; :open end
      def viewable?; @lines.nil? end
      def view_default! path
 -      cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'"
 +      case Config::CONFIG['arch']
 +        when /darwin/
 +          cmd = "open '#{path}'"
 +        else
 +          cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}'"
 +      end
        debug "running: #{cmd.inspect}"
        BufferManager.shell_out(cmd)
        $? == 0
 -- 
 1.6.3.3
 
 From garoth@gmail.com  Wed Oct 28 20:32:00 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Wed, 28 Oct 2009 20:32:00 -0400
 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9)
 In-Reply-To: <20091029000759.GA5109@gmail.com>
 References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 	<20091029000759.GA5109@gmail.com>
 Message-ID: <80055d7c0910281732v60908755kd5b43464aaac30ce@mail.gmail.com>
 
 On Wed, Oct 28, 2009 at 8:07 PM, Sean Escriva <sean.escriva at gmail.com> wrote:
 >
 > On Sun, Oct 18, 2009 at 11:05:57AM -0400, Andrei Thorp wrote:
 >> Hello. Remember me? ;)
 >>
 >> Anyway, I've rolled the 0.9 package for Arch Linux in the
 >> AUR (community repos). It works, but:
 >> ?- Ruby 1.9.1 has pretty screwed up dependencies for Sup. Ncurses and ferret in
 >> ? ?particular were broken (at least in Arch.)
 >> ?- The package is a big ol' pile of hacks.
 >> ?- Ferret index is disabled (sorry for removing it early, but Ruby 1.9.1 is the
 >> ? ?reality for us in Arch.)
 >> ?- I've applyed Lloyd's patch for fixing the UTF-8 check.
 >> ?- There seem to be a few small bugs.
 >>
 >> Anyway, I'd appreciate some suggestions. The package is viewable here:
 >> http://aur.archlinux.org/packages.php?ID=26439
 >
 > I gave the sup package a try today. I had previously put all the new
 > ruby stuff on Hold. It didn't work for me. I post my output on the
 > aur page.
 >
 > Any tips are appreciated, thanks.
 
 Trace on AUR:
 
 >    tried this today and everything installs fine, trying to run sup gives:
 >
 >    /usr/lib/ruby/gems/1.9.1/gems/lockfile-1.4.3/lib/lockfile.rb:475:in `load_lock_id': undefined method `each' for #<String:0x00000002f544d8> (NoMethodError)
 >    from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:26:in `lockinfo_on_disk'
 >    from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/index.rb:40:in `rescue in lock'
 >    from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/index.rb:37:in `lock'
 >    from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing'
 >    from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/interactive-lock.rb:26:in `lock_interactively'
 >    from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:115:in `<top (required)>'
 >    from /usr/bin/supbin/sup-sync:19:in `load'
 >    from /usr/bin/supbin/sup-sync:19:in `<main>'
 
 Delete comment
 
 Hmm... works for me. Could you please give me a few more details:
 - 64 bit or 32 bit? Any other system specs worth noting?
 - This happens immediately on run or do you need to perform some action?
 - Please try running sup while in ~. I've found some bugs occasionally
 if you're in some strange directory.
 - While building my package, does it say that it is rolling lockfile
 for you? It seems your lockfile's a bit screwy rather than Sup. If
 lockfile already exists on the system, my package might not roll a new
 one.
 - That said, try removing the lockfile gem and installing a fresh one
 using the "gem" utility.
 
 The error up there doesn't really make sense. Each not defined on
 buffer strings? Seems unlikely. You could also try running the
 commands in my build step manually and install yourself the sup
 dependencies that I list + the dependencies in the Arch repos and see
 if sup does something then. This would be more serious debugging.
 
 Anyway, for now, I can't reproduce the error on my system, and I'm
 fully up to date with the Arch repos. I don't really know what to say.
 
 Did you remember to switch your indexes to Xapian and so on?
 
 Good luck,
 
 -Andrei Thorp
 
 From nicolas.pouillard@gmail.com  Thu Oct 29 06:29:31 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Thu, 29 Oct 2009 11:29:31 +0100
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1256760970-sup-8118@arrakis.es.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 Message-ID: <1256812101-sup-6316@peray>
 
 Excerpts from Jon Dugan's message of Wed Oct 28 21:22:32 +0100 2009:
 > Excerpts from Nicolas Pouillard's message of Wed Oct 28 15:05:27 -0500 2009:
 > > Excerpts from Jon Dugan's message of Wed Oct 28 18:14:51 +0100 2009:
 > > > make path to the exception log relative to BASE_DIR
 > > > fix a typo in email address of list.
 > > > 
 > > > ---
 > > >  bin/sup |    4 ++--
 > > >  1 files changed, 2 insertions(+), 2 deletions(-)
 > > > 
 > > > diff --git a/bin/sup b/bin/sup
 > > > index 7641401..a881284 100755
 > > > --- a/bin/sup
 > > > +++ b/bin/sup
 > > > @@ -360,8 +360,8 @@ unless Redwood::exceptions.empty?
 > > >  ----------------------------------------------------------------
 > > >  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
 > > > +contents of #{BASE_DIR}/.sup/exception-log.txt and a brief report of the
 > > > +circumstances to sup-talk at rubyforge dot org so that I might
 > > 
 > > I think the *orgs* was on purpose.
 > 
 > I was wondering about that.  It seemed odd to me to be obfuscating the email
 > address at all in this context since this is an error message not a webpage.
 
 Although the error message appears in the source code, and in all emails were
 it has been copied and paste.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From mariano.mara@gmail.com  Thu Oct 29 19:02:46 2009
 From: mariano.mara@gmail.com (Mariano Mara)
 Date: Thu, 29 Oct 2009 20:02:46 -0300
 Subject: [sup-talk] RMail chokes on broken headers
 In-Reply-To: <1255612194-sup-3880@masanjin.net>
 References: <20091012232215.GD31940@tilus.net>
 	<1255612194-sup-3880@masanjin.net>
 Message-ID: <c1d7c48b0910291602t551ee26ek198e558e6e70b7b8@mail.gmail.com>
 
 2009/10/15 William Morgan <wmorgan-sup at masanjin.net>
 
 > Reformatted excerpts from Tero Tilus's message of 2009-10-12:
 > > RMail looks abandoned.  Development is pretty much stalled.  No
 > > functional changes since 2004-04-27.  None of the reported bugs have
 > > been fixed.  Might it be worth to think about switching to another
 > > mail lib?  TMail author's http://github.com/mikel/mail/ looks
 > > promising.
 >
 > Yeah, this is certainly an option. But it seems like a lot of work. And
 > every day our set of rmail workarounds grows more robust. :)
 >
 > Not to say I wouldn't accept a patch that magically did this all for me,
 > of course.
 > --
 
 
 Hi there, I'm facing the same error as reported by Tero. I applied the
 modifications he sent, however it's failing in another place and my total
 ignorance of Ruby prevents me from fixing it. Would anyone be so kind to
 suggest a workaround?
 
 Below is the complete exception recorded.
 
 TIA,
 Mariano
 
 --- NoMethodError from thread: poll after loading inbox
 undefined method `downcase' for nil:NilClass
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:502:in
 `message_to_chunks'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:435:in
 `message_to_chunks'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:435:in `map'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:435:in
 `message_to_chunks'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:239:in
 `load_from_source!'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/message.rb:335:in
 `build_from_source'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:145:in
 `each_message_from'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:160:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:157:in `upto'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:157:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `__pass'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:139:in
 `each_message_from'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:93:in `do_poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `do_poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `synchronize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `do_poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/poll-mode.rb:15:in `poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:48:in `poll'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in
 `call'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in
 `__unprotected_load_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in
 `call'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in
 `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:608:in
 `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:679:in
 `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.9/bin/sup:196
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091029/07b5276c/attachment.html>
 
 From stevenrwalter@gmail.com  Fri Oct 30 13:17:32 2009
 From: stevenrwalter@gmail.com (Steven Walter)
 Date: Fri, 30 Oct 2009 13:17:32 -0400
 Subject: [sup-talk] Recovering a busted ferret db?
 Message-ID: <e06498070910301017g57b156cclec9abb3689bde243@mail.gmail.com>
 
 I think my ferret db is corrupted.  Whenever I do a tag search for a
 specific tag, sup loads 2 messages and then hangs.  Actually, it's
 using 100% CPU, but I have to kill -9 it; ctrl-c doesn't work.  Is
 there any hope of fixing this without losing all my tag information?
 -- 
 -Steven Walter <stevenrwalter at gmail.com>
 
 From wmorgan-sup@masanjin.net  Fri Oct 30 17:48:32 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 30 Oct 2009 14:48:32 -0700
 Subject: [sup-talk] Recovering a busted ferret db?
 In-Reply-To: <e06498070910301017g57b156cclec9abb3689bde243@mail.gmail.com>
 References: <e06498070910301017g57b156cclec9abb3689bde243@mail.gmail.com>
 Message-ID: <1256939095-sup-4201@masanjin.net>
 
 Reformatted excerpts from Steven Walter's message of 2009-10-30:
 > I think my ferret db is corrupted.  Whenever I do a tag search for a
 > specific tag, sup loads 2 messages and then hangs.  Actually, it's
 > using 100% CPU, but I have to kill -9 it; ctrl-c doesn't work.  Is
 > there any hope of fixing this without losing all my tag information?
 
 You can certainly move to the Xapian index without losing all of your
 tags. Sup-dump will output everything precious from your index.
 
 Is it possible you have a very large thread with that label? E.g.
 thousands of messages, all replying to each other, from some script?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Oct 30 17:50:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 30 Oct 2009 14:50:41 -0700
 Subject: [sup-talk] RMail chokes on broken headers
 In-Reply-To: <c1d7c48b0910291602t551ee26ek198e558e6e70b7b8@mail.gmail.com>
 References: <20091012232215.GD31940@tilus.net>
 	<1255612194-sup-3880@masanjin.net>
 	<c1d7c48b0910291602t551ee26ek198e558e6e70b7b8@mail.gmail.com>
 Message-ID: <1256939410-sup-8456@masanjin.net>
 
 Reformatted excerpts from Mariano Mara's message of 2009-10-29:
 > Hi there, I'm facing the same error as reported by Tero. I applied the
 > modifications he sent, however it's failing in another place and my
 > total ignorance of Ruby prevents me from fixing it. Would anyone be so
 > kind to suggest a workaround?
 
 This is fixed in git master. Maybe I should release an 0.9.1.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Oct 30 17:53:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 30 Oct 2009 14:53:08 -0700
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1256760970-sup-8118@arrakis.es.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 Message-ID: <1256939476-sup-2864@masanjin.net>
 
 Reformatted excerpts from Jon Dugan's message of 2009-10-28:
 > I was wondering about that.  It seemed odd to me to be obfuscating the email
 > address at all in this context since this is an error message not a webpage.
 
 Yep, it was intentional. As Nicolas points out, the error message is
 often copied-and-pasted, and the source code is indexable via Gitorious.
 
 The change for BASE_DIR is great though. If you remove the obfuscation I
 will accept the patch.
 
 > In my mind the usability enhancement of being able to cut and paste
 > the email address would increase the likelyhood of people reporting
 > errors.
 
 I hate people reporting errors. I should actually change that whole
 thing to suggest they to send a bugfix patch.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Oct 30 17:56:53 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 30 Oct 2009 14:56:53 -0700
 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9)
 In-Reply-To: <80055d7c0910281732v60908755kd5b43464aaac30ce@mail.gmail.com>
 References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 	<20091029000759.GA5109@gmail.com>
 	<80055d7c0910281732v60908755kd5b43464aaac30ce@mail.gmail.com>
 Message-ID: <1256939734-sup-4021@masanjin.net>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-10-28:
 > On Wed, Oct 28, 2009 at 8:07 PM, Sean Escriva <sean.escriva at gmail.com> wrote:
 > >    tried this today and everything installs fine, trying to run sup gives:
 > >
 > >    /usr/lib/ruby/gems/1.9.1/gems/lockfile-1.4.3/lib/lockfile.rb:475:in `load_lock_id': undefined method `each' for #<String:0x00000002f544d8> (NoMethodError)
 > >    from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:26:in `lockinfo_on_disk'
 [snip]
 
 > Hmm... works for me. Could you please give me a few more details:
 [snip]
 
 > The error up there doesn't really make sense. Each not defined on
 > buffer strings?
 
 It makes sense to me. There's no String#each in Ruby 1.9, so this is
 probably a (trivially fixable) bug in the lockfile gem for 1.9.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Oct 30 18:02:00 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 30 Oct 2009 15:02:00 -0700
 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9)
 In-Reply-To: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 Message-ID: <1256939901-sup-1662@masanjin.net>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-10-18:
 > Anyway, I've rolled the 0.9 package for Arch Linux in the
 > AUR (community repos).
 
 Very cool, thank you! I am very interested in moving to 1.9 so I'm
 doubly happy someone else is doing the work. :)
 
 > - I've set Xapian to the default by wrapping all of Sup's binaries
 > with the SUP_INDEX variable in a script.
 
 Seems fine. Eventually this will be the default.
 
 >  - q no longer works properly. It prompts you with the regular yes/no
 >  option as to whether you really want to quit. Neither y nor n seem to
 >  have any effect; it is still possible to quit with Q.
 
 Now that's weird. Do multi-commands (like ,n in thread-view-mode) work?
 If not, we can insert some debugging code in BufferManager#ask_getch to
 see what's going on?
 
 >  - Will that patch get applied? It seems reasonable on a surface level.
 
 Yes. Sorry, I'm very behind on patches.
 
 > Once I do manage to get it set up, I'll continue testing. I'm not sure,
 > but I'm getting the impression that rather little testing has been done
 > with the new Ruby as it's not quite mainstream yet.
 
 Which makes it perfect a complement to Sup. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Oct 30 18:07:19 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 30 Oct 2009 15:07:19 -0700
 Subject: [sup-talk] [PATCH] change opening attachements on darwin to use
 	open instead of run-mailcap
 In-Reply-To: <4AE8C073.404@GoodCoffee.ca>
 References: <4AE8C073.404@GoodCoffee.ca>
 Message-ID: <1256940409-sup-4411@masanjin.net>
 
 Reformatted excerpts from Jonah's message of 2009-10-28:
 > I've been working on getting sup to work in MacOSX (darwin).  MacOSX has a
 > special command (open) for opening files - there is no support for mailcap. 
 > This patch uses case to run the appropriate command depending on the
 > architecture used.
 
 Branch no-mailcap-on-darwin, merged into next. Thanks!
 
 > I still haven't gotten sup to send mail yet,.. so more patches for
 > MacOSX will probably be forthcoming.  :)
 
 Great, glad to have them.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From stevenrwalter@gmail.com  Fri Oct 30 18:14:32 2009
 From: stevenrwalter@gmail.com (Steven Walter)
 Date: Fri, 30 Oct 2009 18:14:32 -0400
 Subject: [sup-talk] Recovering a busted ferret db?
 In-Reply-To: <1256939095-sup-4201@masanjin.net>
 References: <e06498070910301017g57b156cclec9abb3689bde243@mail.gmail.com>
 	<1256939095-sup-4201@masanjin.net>
 Message-ID: <e06498070910301514ud4efe49ic0fb40d181156fab@mail.gmail.com>
 
 On Fri, Oct 30, 2009 at 5:48 PM, William Morgan
 <wmorgan-sup at masanjin.net> wrote:
 > Reformatted excerpts from Steven Walter's message of 2009-10-30:
 >> I think my ferret db is corrupted. ?Whenever I do a tag search for a
 >> specific tag, sup loads 2 messages and then hangs. ?Actually, it's
 >> using 100% CPU, but I have to kill -9 it; ctrl-c doesn't work. ?Is
 >> there any hope of fixing this without losing all my tag information?
 >
 > You can certainly move to the Xapian index without losing all of your
 > tags. Sup-dump will output everything precious from your index.
 
 Looks like sup-dump hangs, too.
 
 > Is it possible you have a very large thread with that label? E.g.
 > thousands of messages, all replying to each other, from some script?
 
 Not very likely.  I could believe tens, up to a hundred; 200 at the most.
 
 I am able to Ctrl-C sup-dump when it hangs.  Here's the ruby backtrace:
 
 /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:206:in `split': Interrupt
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:206:in
 `split_on_commas'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/person.rb:108:in
 `from_address_list'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/message.rb:104:in
 `parse_header'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:276:in
 `build_message'
         from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:256:in
 `build_message'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/index.rb:150:in
 `each_message'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:319:in
 `each_id'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:319:in `map'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:319:in
 `each_id'
         from /var/lib/gems/1.8/gems/sup-0.9/lib/sup/index.rb:149:in
 `each_message'
         from /var/lib/gems/1.8/gems/sup-0.9/bin/sup-dump:28
 
 -- 
 -Steven Walter <stevenrwalter at gmail.com>
 
 From jdugan@es.net  Fri Oct 30 19:13:39 2009
 From: jdugan@es.net (Jon Dugan)
 Date: Fri, 30 Oct 2009 18:13:39 -0500
 Subject: [sup-talk] [PATCH] change opening attachements on darwin to use
 	open instead of run-mailcap
 In-Reply-To: <4AE8C073.404@GoodCoffee.ca>
 References: <4AE8C073.404@GoodCoffee.ca>
 Message-ID: <1256944116-sup-2844@arrakis.es.net>
 
 Excerpts from Jonah's message of Wed Oct 28 17:06:43 -0500 2009:
 > I still haven't gotten sup to send mail yet,.. so more patches for MacOSX will
 > probably be forthcoming.  :)
 
 I use msmtp via MacPorts to send mail from OS X.  The sup wiki has some
 information on how to use msmtp in the "how mail leaves" section:
 
 http://sup.rubyforge.org/wiki/wiki.pl
 
 And the MacPorts homepage is at:
 
 http://macports.org/
 
 Jon
 -- 
 Jon M. Dugan <jdugan at es.net>
 ESnet Network Engineering Group
 Lawrence Berkeley National Laboratory
 
 From tero@tilus.net  Sat Oct 31 07:28:09 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Sat, 31 Oct 2009 13:28:09 +0200
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1256939476-sup-2864@masanjin.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net>
 Message-ID: <1256987483-sup-338@tilus.net>
 
 William Morgan, 2009-10-30 23:53:
 >> the email address would increase the likelyhood of people reporting
 >> errors.
 > 
 > I hate people reporting errors.
 
 :D
 
 > I should actually change that whole thing to suggest they to send a
 > bugfix patch.
 
 Not all the people who are capable of producing good quality bug
 reports are (practically) capable of producing patches.  Good bug
 reports are usefull.
 
 Do you feel burdened by bugreports sent to you or to this list?  (I
 most definitely would be.)  If so, could we somehow "unburden" you?
 
 How about setting up a loose team which would handle the incoming bug
 reports (for you), track/sort all of them and fix what they feel like
 fixing and maybe upon request/occasionally report somewhere the
 current status (how many minors and majors open).
 
 I could be involved in something like that if it is what you and sup
 community want/need.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From wmorgan-sup@masanjin.net  Sat Oct 31 10:03:35 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 31 Oct 2009 07:03:35 -0700
 Subject: [sup-talk] slowly catching up
 Message-ID: <1256997213-sup-2725@masanjin.net>
 
 Hi all,
 
 Just wanted to let you know that I am slowly catching up with the
 backlog of patches and bug reports. We just had our first baby so it's
 been a busy few weeks.
 
 If you haven't heard back about something in the next week or so, please
 ping me about it.
 
 In the near future I would like to face reality and change the process
 so that I am not the one and only bottleneck to development. (Which is
 entirely a situation I have created myself.) E.g. use a bug tracker (not
 ditz), delegate some responsibility to people who are interested, etc. I
 would like to see the development of Sup continue, but not limited by
 the small amount of time I have for it. Suggestions welcome. (Thanks,
 Tero, for starting on this already.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From mariano.mara@gmail.com  Sat Oct 31 16:18:19 2009
 From: mariano.mara@gmail.com (Mariano Mara)
 Date: Sat, 31 Oct 2009 17:18:19 -0300
 Subject: [sup-talk] RMail chokes on broken headers
 In-Reply-To: <1256939410-sup-8456@masanjin.net>
 References: <20091012232215.GD31940@tilus.net>
 	<1255612194-sup-3880@masanjin.net> 
 	<c1d7c48b0910291602t551ee26ek198e558e6e70b7b8@mail.gmail.com> 
 	<1256939410-sup-8456@masanjin.net>
 Message-ID: <c1d7c48b0910311318g5bbed1al638ffd3cb0815074@mail.gmail.com>
 
 2009/10/30 William Morgan <wmorgan-sup at masanjin.net>
 
 > Reformatted excerpts from Mariano Mara's message of 2009-10-29:
 > > Hi there, I'm facing the same error as reported by Tero. I applied the
 > > modifications he sent, however it's failing in another place and my
 > > total ignorance of Ruby prevents me from fixing it. Would anyone be so
 > > kind to suggest a workaround?
 >
 > This is fixed in git master. Maybe I should release an 0.9.1.
 > --
 > William <wmorgan-sup at masanjin.net>
 >
 
 Thanks a lot! It would be great if you could release 0.9.1
 
 Mariano
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091031/123ef347/attachment.html>