sup

community/pipermail-archives/sup-talk/2009-11.txt (227712B) - raw

 From wmorgan-sup@masanjin.net  Sun Nov  1 09:39:25 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 06:39:25 -0800
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1256987483-sup-338@tilus.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 Message-ID: <1257086191-sup-1136@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-10-31:
 > 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).
 
 As far as I'm concerned, that would be great. I'm open to suggestions
 about how to organize this. At this point I'm pretty convinced I will
 never actually like a bug tracker, and I don't have the energy to write
 another one, so for someone else to take the initiative would be
 awesome.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 09:45:05 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 06:45:05 -0800
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1256940689-sup-888@arrakis.es.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net>
 	<1256940689-sup-888@arrakis.es.net>
 Message-ID: <1257086690-sup-9036@masanjin.net>
 
 [resend to list]
 
 Reformatted excerpts from Jon Dugan's message of 2009-10-30:
 > I've attached a patch that just make the BASE_DIR tweak.  I'll leave
 > changing the instructions to you...
 
 Applied to master. (Had to tweak it to make the path actually correct,
 but no worries.)  Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 09:53:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 06:53:31 -0800
 Subject: [sup-talk] Recovering a busted ferret db?
 In-Reply-To: <e06498070910301514ud4efe49ic0fb40d181156fab@mail.gmail.com>
 References: <e06498070910301017g57b156cclec9abb3689bde243@mail.gmail.com>
 	<1256939095-sup-4201@masanjin.net>
 	<e06498070910301514ud4efe49ic0fb40d181156fab@mail.gmail.com>
 Message-ID: <1257087035-sup-2014@masanjin.net>
 
 Reformatted excerpts from Steven Walter's message of 2009-10-30:
 > 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'
 
 It looks like you have some crazy long recipient email in some list
 that's triggering worst-case behavior in a regexp. Can you try again
 after applying this patch, please? (And I'd be curious how long the
 address list was, if you find out what message is triggering this.)
 
 diff --git a/lib/sup/person.rb b/lib/sup/person.rb
 index 4b1c80b..dbedc79 100644
 --- a/lib/sup/person.rb
 +++ b/lib/sup/person.rb
 @@ -105,6 +105,10 @@ class Person
  
    def self.from_address_list ss
      return [] if ss.nil?
 +    ## #split_on_commas has some bad behavior for long strings. so here we do
 +    ## something nasty and just truncate the string at the nearest comma <= 500
 +    ## characters.
 +    ss = ss[0, ss.rindex(",", 500)] if ss.length > 500
      ss.split_on_commas.map { |s| self.from_address s }
    end
  
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Sun Nov  1 10:24:22 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sun, 01 Nov 2009 16:24:22 +0100
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257086191-sup-1136@masanjin.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net>
 Message-ID: <1257088992-sup-5165@peray>
 
 Excerpts from William Morgan's message of Sun Nov 01 15:39:25 +0100 2009:
 > Reformatted excerpts from Tero Tilus's message of 2009-10-31:
 > > 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).
 > 
 > As far as I'm concerned, that would be great. I'm open to suggestions
 > about how to organize this. At this point I'm pretty convinced I will
 > never actually like a bug tracker, and I don't have the energy to write
 > another one, so for someone else to take the initiative would be
 > awesome.
 
 Have strong points against Ditz or this is also a lake of energy?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 11:19:23 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 08:19:23 -0800
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257088992-sup-5165@peray>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray>
 Message-ID: <1257091305-sup-4606@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01:
 > Have strong points against Ditz or this is also a lake of energy?
 
 Both, really. Ditz was an experiment, and after using it for a while I
 decided it was more trouble than it was worth. I also realized that I
 *did* want a centralized web site after all, and not necessarily a
 complicated distributed thing, both because I want non-technical users
 to be able to submit bug reports, and because development, in reality,
 *is* centralized.
 
 (I had been doing some work on Sheila, which would've provided a web
 frontent that people could use to submit bug reports, but even that
 wouldn't be quite what I wanted.)
 
 Having thought about it for a while, I think what I *really* want for
 Sup is something that tracks bugs/feature requests at the feature branch
 level (i.e. assumes that each feature branch provides a new feature or a
 bugfix), has a web interface for non-technical users to submit bug
 reports and for developers to browse/modify state on bugs, and which
 uses email for discussion, like I did with Whisper. (And I would be fine
 with it being git-specific.)
 
 I am now spending all my energy trying to keep myself from building such 
 a thing.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 11:23:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 08:23:03 -0800
 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: <1257092475-sup-4321@masanjin.net>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-10-18:
 >  - I've applyed Lloyd's patch for fixing the UTF-8 check.
 
 Which patch was this? The only "Lloyd patch" one I'm aware of is:
 http://github.com/lloyd/sup/commit/d07986419b87053b41f7ed4bd7b6d1e537704864
 
 which a) I don't quite understand, and b) isn't about utf8.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 11:32:35 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 08:32:35 -0800
 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: <1257093136-sup-2762@masanjin.net>
 
 Reformatted excerpts from Steve Goldman's message of 2009-10-26:
 > 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.
 
 In ~/.sup/sources.yaml, do you have a source with "id: 4"?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Sun Nov  1 11:48:16 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sun, 01 Nov 2009 17:48:16 +0100
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257091305-sup-4606@masanjin.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray>
 	<1257091305-sup-4606@masanjin.net>
 Message-ID: <1257093429-sup-8020@peray>
 
 Excerpts from William Morgan's message of Sun Nov 01 17:19:23 +0100 2009:
 > Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01:
 > > Have strong points against Ditz or this is also a lake of energy?
 > 
 > Both, really. Ditz was an experiment, and after using it for a while I
 > decided it was more trouble than it was worth. I also realized that I
 > *did* want a centralized web site after all, and not necessarily a
 > complicated distributed thing, both because I want non-technical users
 > to be able to submit bug reports, and because development, in reality,
 > *is* centralized.
 
 I think I see your point, however I think there is no less no more to
 centralize in a bugtracker than in a source code management tool. Indeed
 in most projects using a DVCS, they have a central repository, this
 does not reduce the benefits of distributed tools. Distributed bugtrackers
 does not necessary exclude having a central point.  What I found cool
 about distributed bugtrackers is that the bug-closing action can follow
 the code that fixes the bug. Being in a branch, or being reviewed...
 
 About non-technical users, I think that just a mail (thread) on the
 mailing-list could suffice. Of course some web app can make things clearer.
 
 > (I had been doing some work on Sheila, which would've provided a web
 > frontent that people could use to submit bug reports, but even that
 > wouldn't be quite what I wanted.)
 
 > Having thought about it for a while, I think what I *really* want for
 > Sup is something that tracks bugs/feature requests at the feature branch
 > level (i.e. assumes that each feature branch provides a new feature or a
 > bugfix), has a web interface for non-technical users to submit bug
 > reports and for developers to browse/modify state on bugs, and which
 > uses email for discussion, like I did with Whisper. (And I would be fine
 > with it being git-specific.)
 
 Maybe Ditz is not very far from that.
 
 > I am now spending all my energy trying to keep myself from building such 
 > a thing.
 
 Good luck on this :)
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From sgoldman@tower-research.com  Sun Nov  1 11:48:38 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Sun, 01 Nov 2009 11:48:38 -0500
 Subject: [sup-talk] Can't search without crashing
 In-Reply-To: <1257093136-sup-2762@masanjin.net>
 References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 	<1257093136-sup-2762@masanjin.net>
 Message-ID: <1257094049-sup-1250@sgoldmanlinux.tower-research.com>
 
 Excerpts from William Morgan's message of Sun Nov 01 11:32:35 -0500 2009:
 > Reformatted excerpts from Steve Goldman's message of 2009-10-26:
 > > 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.
 > 
 > In ~/.sup/sources.yaml, do you have a source with "id: 4"?
 
 No.
 
 Although a few weeks ago I cleared out a bunch of sources that I
 thought were defunct from that file.
 
 I'm replacing those sources (at least I backed up the sources.yaml
 file) and will see how that goes.
 
 And now I'm feeling stupid...
 -- 
 
 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  Sun Nov  1 11:49:54 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Sun, 01 Nov 2009 11:49:54 -0500
 Subject: [sup-talk] What happened to the log buffer?
 Message-ID: <1257094144-sup-8318@sgoldmanlinux.tower-research.com>
 
 
 I'm somewhere near the next branch.
 
 Formerly, when I started sup I could cycle through a few buffers with
 'b', two of which were some sort of log buffers.  These are gone now.
 
 Anyone know?
 
 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 wmorgan-sup@masanjin.net  Sun Nov  1 12:15:56 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 09:15:56 -0800
 Subject: [sup-talk] What happened to the log buffer?
 In-Reply-To: <1257094144-sup-8318@sgoldmanlinux.tower-research.com>
 References: <1257094144-sup-8318@sgoldmanlinux.tower-research.com>
 Message-ID: <1257095673-sup-5988@masanjin.net>
 
 Reformatted excerpts from Steve Goldman's message of 2009-11-01:
 > Formerly, when I started sup I could cycle through a few buffers with
 > 'b', two of which were some sort of log buffers.  These are gone now.
 
 'b' now skips over "system" buffers. If you hit ';' you will get the
 full list and you can select it that way. You may want to restart with
 the environment variable SUP_LOG_LEVEL=debug for all the verbiage you
 were used to.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 12:23:49 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 09:23:49 -0800
 Subject: [sup-talk] Can't search without crashing
 In-Reply-To: <1257094049-sup-1250@sgoldmanlinux.tower-research.com>
 References: <1256588053-sup-8922@sgoldmanlinux.tower-research.com>
 	<1257093136-sup-2762@masanjin.net>
 	<1257094049-sup-1250@sgoldmanlinux.tower-research.com>
 Message-ID: <1257095945-sup-1972@masanjin.net>
 
 Reformatted excerpts from Steve Goldman's message of 2009-11-01:
 > I'm replacing those sources (at least I backed up the sources.yaml
 > file) and will see how that goes.
 
 If you're really done with a source, you can remove it from
 sources.yaml, but you also need to remove all messages from the index.
 You should be able do something like:
 
   $ sh devel/console.sh
   >> q = Index.parse_query "source_id:4"
   => # ...
   >> Index.each_id(q) { |id| Index.delete id }
   => nil
   >> Index.save
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 12:30:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 09:30:04 -0800
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257093429-sup-8020@peray>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray>
 	<1257091305-sup-4606@masanjin.net> <1257093429-sup-8020@peray>
 Message-ID: <1257096395-sup-2011@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01:
 > What I found cool about distributed bugtrackers is that the
 > bug-closing action can follow the code that fixes the bug. Being in a
 > branch, or being reviewed...
 > 
 > About non-technical users, I think that just a mail (thread) on the
 > mailing-list could suffice. Of course some web app can make things
 > clearer.
 
 It's funny, the two things that I found irritating do were a) close the
 bug as part of the commit (because I kept forgetting, and also because I
 like reading commits with git log -p and the ditz stuff was additional
 noise), and b) translating a user's bug report email into an issue. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Sun Nov  1 12:49:11 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sun, 01 Nov 2009 18:49:11 +0100
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257096395-sup-2011@masanjin.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net> <1257088992-sup-5165@peray>
 	<1257091305-sup-4606@masanjin.net> <1257093429-sup-8020@peray>
 	<1257096395-sup-2011@masanjin.net>
 Message-ID: <1257097118-sup-8031@peray>
 
 Excerpts from William Morgan's message of Sun Nov 01 18:30:04 +0100 2009:
 > Reformatted excerpts from Nicolas Pouillard's message of 2009-11-01:
 > > What I found cool about distributed bugtrackers is that the
 > > bug-closing action can follow the code that fixes the bug. Being in a
 > > branch, or being reviewed...
 > > 
 > > About non-technical users, I think that just a mail (thread) on the
 > > mailing-list could suffice. Of course some web app can make things
 > > clearer.
 > 
 > It's funny, the two things that I found irritating do were a) close the
 > bug as part of the commit (because I kept forgetting, and also because I
 > like reading commits with git log -p and the ditz stuff was additional
 > noise), and
 
 I think some habits are needed in each model...
 
 > b) translating a user's bug report email into an issue. :)
 
 Yes this translating job can really be boring. In fact I consider every
 bugtracker related task to be boring... And yes the nice part of web
 based bugtracker is to put this burden on the user.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 13:46:33 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 10:46:33 -0800
 Subject: [sup-talk] mbox date fail
 In-Reply-To: <2aeb4e149305569502f106c7e54ae107@localhost>
 References: <2aeb4e149305569502f106c7e54ae107@localhost>
 Message-ID: <1257101109-sup-4117@masanjin.net>
 
 Reformatted excerpts from Mike Kelly's message of 2009-10-23:
 > Is there much of anything that I can do to mitigate this problem,
 > aside from manually altering every offending message?
 
 I've fixed this in master. Can you try again, please?
 
 > It seems like the messages' Content-Length header should be used to
 > skip past the body and ignore the offending Froms?
 
 This is an option, but I'm avoiding it, because Content-Length is not
 guaranteed to be there, and not guaranteed to be correct.
 
 > Or, at least, if that sort of
 > ArgumentError is thrown, maybe it should be caught and handled better?
 
 Yep, that's what I've done. I couldn't get my local system to throw
 ArgumentError, even with your example, but if it's possible, it's
 possible, and should be caught.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rick.tessner@gmail.com  Sun Nov  1 15:30:21 2009
 From: rick.tessner@gmail.com (rick.tessner)
 Date: Sun, 01 Nov 2009 12:30:21 -0800
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257086191-sup-1136@masanjin.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net>
 Message-ID: <1257107371-sup-3361@onnadayr.ca>
 
 Excerpts from William Morgan's message of Sun Nov 01 06:39:25 -0800 2009:
 > Reformatted excerpts from Tero Tilus's message of 2009-10-31:
 > > 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).
 > 
 > As far as I'm concerned, that would be great. I'm open to suggestions
 > about how to organize this. At this point I'm pretty convinced I will
 > never actually like a bug tracker, and I don't have the energy to write
 > another one, so for someone else to take the initiative would be
 > awesome.
 
 Would a move to github be considered since they now have an issue
 tracker.  It provides tagging of issues and voting.
 
 As an example, take a look at
 
     http://github.com/justinfrench/formtastic/
 
 and clicky the Issues tab.  (I chose this project simply because I was
 watching the railscast for it and noticed the Issues tab)
 -- 
 Rick Tessner
 rick.tessner at gmail.com
 
 From nicolas.pouillard@gmail.com  Sun Nov  1 16:52:08 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sun, 01 Nov 2009 22:52:08 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 Message-ID: <1257111816-sup-4397@peray>
 
 Hi,
 
 I would like to discuss more the issue of choosing a bug tracker for sup.
 
 (I've made a new thread for clarity)
 (This is a cross post of a post[1] on my blog)
 
 OK lets forget Ditz[2] as an option.
 
 Note also that I would make no objection to using a traditional bug tracker.
 
 It seems that we do not find a tool we really like.
 
 A simple question I asked me was:
 
   "Do we really need to invent this (big) tool?"
 
 And more and more the answer I see is that we do not need
 yet another big tool.  Especially for a bug tracker we need recipes,
 protocols more than a nice interface.  And generally I think we
 better need thinking on how to split the problem in small issues
 than writing the tool that tackles all of them in one go.
 
 Again the UNIX philosophy can help us to simplify all this mess!
 
 So we need a web interface for non technical users, great.  What
 about a pre-formatted email explained on a single web-page for
 reporting bugs.  This simple web-page will also have a form
 to fill which will send the email for them.  This micro web
 app is really simple and does a very clear job.
 
 So we now have issues as emails. Thus the mailing-list is our
 bug tracker as before. However issues are now in a proper format.
 
 A bot will receive emails on the mailing-list and process those which are in
 the right format.
 
 I think that the bot will not have a lot of information to store:
 
   (correct me if you find something else)
 
   * Issue type, severity, priority, category, person assigned,
     progress status, incriminated version and platform, planned
     milestone/released.
 
   * Issue details, discussion, answers, attachments.
 
 All those of the first category can be easily handled in a very
 flexible way either with labels, or a simple mapping:
   Labels (like the Google bug tracker on code.google.com):
     Type-Defect
     Priority-Critical
     Component-UI
   Mapping:
     type: defect
     priority: critical
     component: UI
 
 This is very flexible because this set of labels/attributes is chosen by the
 project maintainer to match the complexity of the project.
 
 I would store and manage the first category using a simple YAML file.
 
 The bot acknowledges its updates by simply answering to the discussion.
 
 Those of the second category can be managed using a single email discussion.
 
 Since the discussion is central to the issue, tracking the original message-ID
 could be used as the unique identifier.
 
 About the issues identifier I see two options, either we try to allocate
 simple integers like most of the trackers or we just keep the unique (long)
 identifier.
 
 Then, optionally a simple set of HTML pages can be generated using the YAML file.
 
 About storage of the YAML file I would simply store it in the repository.
 If we make the bot accessible, we just have to periodically pull
 from it.
 
 I don't know yet how many issues I've forgotten, and if this design is really
 as simple and lightweight as I claim it to be. I look forward to your answers on
 that.
 
 Best regards,
 
 [1]: http://blog.nicolaspouillard.fr/entries/2009-11-01-bug-tracker-design-issues.html
 [2]: http://ditz.rubyforge.org/
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Sun Nov  1 17:57:44 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 01 Nov 2009 14:57:44 -0800
 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: <1257115167-sup-6013@masanjin.net>
 
 Reformatted excerpts from Gregor Hoffleit's message of 2009-10-23:
 > 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(" ")) }
 
 Great catch. Thank you!
 
 > 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.
 
 Yep, that's the problem. In general all those fields are ||= in order to
 save the work of computing them again when we're updating a message
 (because the way Ferret works is we have to rewrite the entire record
 every time we change the labels, so we want that to be as fast as
 possible). But for certain fields, including refs, we should regenerate
 them because that data can change.
 
 > Btw, the code in xapian_index.rb looks much different. Still, I'd like
 > to see this fixed for Xapian.
 
 I believe that the fix for both is simply to set the entry[:refs] every
 time, and not bother with ||=. (In fact I think the empty string check
 won't work for threads that already have refs set, i.e. joining threads
 of size >1.)
 
 I've put this fix on branch thread-joining-fix and merged into next.
 Check it out.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From pioto@pioto.org  Sun Nov  1 18:30:07 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Sun, 1 Nov 2009 18:30:07 -0500
 Subject: [sup-talk] mbox date fail
 In-Reply-To: <1257101109-sup-4117@masanjin.net>
 References: <2aeb4e149305569502f106c7e54ae107@localhost>
 	<1257101109-sup-4117@masanjin.net>
 Message-ID: <20091101183007.0b90de33@aether.home.pioto.org>
 
 On Sun, 01 Nov 2009 10:46:33 -0800
 William Morgan <wmorgan-sup at masanjin.net> wrote:
 
 > Yep, that's what I've done. I couldn't get my local system to throw
 > ArgumentError, even with your example, but if it's possible, it's
 > possible, and should be caught.
 
 Yep, that seems to help. Thanks! (I altered the example slightly for
 anonymity reasons, that might have invalidated it as a test case).
 
 -- 
 Mike Kelly
 
 
 From rlane@club.cc.cmu.edu  Sun Nov  1 18:42:38 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sun, 01 Nov 2009 18:42:38 -0500
 Subject: [sup-talk] updated xapian experimental branch
 Message-ID: <1257118189-sup-7392@zyrg.net>
 
 I've pushed a few more commits to http://github.com/rlane/sup/tree/experimental
 
 The major feature on this branch is the immediate label updates I've
 mentioned before on the list. The bulk of the actual changes are
 basically consequences of this feature:
 
 Use of Xapian for thread relevance checks
  - Instead of hardcoding the policy into InboxMode
  - New 'z' key to clear irrelevant threads
   - Not strictly necessary, but removing messages in response to index
     events is difficult with the current UI code
   - Saves us from (half of the) adding/removing threads changes cursor_thread problem
  - Relevant messages added to thread-index-modes without reload
 
 Async message state saving
  - Keeps the UI responsive
  - Prepares us for a sup-server future
 
 Fallout from async message saving
  - UpdateManager messages handled in main event loop
   - Avoids many races but can lag UI unless we're careful
 
 New, simpler undo implementation
  - Still needs work at a few use-sites to be completely correct
 
 Let me know what you all think of these changes. I'll need to do a lot
 of rebasing before this branch is clean enough to be merged.
 
 A couple of bugs I know about:
   - Discarding drafts is disabled
   - Occasionally, new messages in an existing undisplayed thread fail to
     get added to the ThreadSet. I haven't been able to come up with a
     test case for this, so if someone wants to give that a shot it would
     be very helpful.
 
 From kevinr@free-dissociation.com  Sun Nov  1 20:17:31 2009
 From: kevinr@free-dissociation.com (Kevin Riggle)
 Date: Sun, 01 Nov 2009 20:17:31 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257111816-sup-4397@peray>
 References: <1257111816-sup-4397@peray>
 Message-ID: <1257124377-sup-199@black-opal.mit.edu>
 
 Excerpts from Nicolas Pouillard's message of Sun Nov 01 16:52:08 -0500 2009:
 (snip)
 (snip)
 > 
 > I would store and manage the first category using a simple YAML file.
 > 
 > The bot acknowledges its updates by simply answering to the discussion.
 > 
 > Those of the second category can be managed using a single email discussion.
 > 
 > Since the discussion is central to the issue, tracking the original message-ID
 > could be used as the unique identifier.
 > 
 > About the issues identifier I see two options, either we try to allocate
 > simple integers like most of the trackers or we just keep the unique (long)
 > identifier.
 > 
 > Then, optionally a simple set of HTML pages can be generated using the YAML
 > file.
 > 
 > About storage of the YAML file I would simply store it in the repository.
 > If we make the bot accessible, we just have to periodically pull
 > from it.
 > 
 This portion of your proposed system sounds to me a lot like SD 
 (http://syncwith.us), against which writing your proposed bot would be fairly
 straightforward.
 
 - Kevin
 -- 
 Kevin Riggle (kevinr at free-dissociation.com) 
 MIT Class of 2010, Course VI-2 (EECS)
 http://free-dissociation.com
 
 From tero@tilus.net  Mon Nov  2 02:01:31 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Mon, 02 Nov 2009 09:01:31 +0200
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257111816-sup-4397@peray>
 References: <1257111816-sup-4397@peray>
 Message-ID: <1257143690-sup-7839@tilus.net>
 
 Requirements collected:
  - Store/track
    - Formal attributes: Issue type, severity, priority, category,
      person assigned, progress status, incriminated version and
      platform, planned milestone/released
    - Informal meta: Issue details, discussion, answers, attachments
  - Web-interface (at least for issue submission, searching and displaying)
  - Issue submission, commenting, attachments and editing attributes by email
  - Notifications by email
 
 Nicolas Pouillard, 2009-11-01 23:52:
 > OK lets forget Ditz[2] as an option.
 
 Why?  (not that i have any reason why not, i've never used diz)
 
 > Note also that I would make no objection to using a traditional bug
 > tracker.
 >
 > It seems that we do not find a tool we really like.
 
 Looks like this is a issue you have discussed in depth before.  Any
 pointers to list archives?
 
 > A simple question I asked me was:
 >   "Do we really need to invent this (big) tool?"
 
 Well... if somebody invented it for us already.  :)
 
 > Especially for a bug tracker we need recipes, protocols more than a
 > nice interface.
 
 Now we are talking!  ...and when trying to choose a tool, we need to
 think about what we need it to do for us.
 
 I tried to pick the requirements you used.
 
 > So we need a web interface for non technical users, great.
 
 OK, this seems reasonable requirement.
 
 > What about a pre-formatted email explained on a single web-page for
 > reporting bugs.
 ...
 > A bot will receive emails on the mailing-list and process those
 > which are in the right format.
 
 Requirement: Bug submission by email?
 I'd say we need that.
 
 > I think that the bot will not have a lot of information to store:
 > 
 >   (correct me if you find something else)
 > 
 >   * Issue type, severity, priority, category, person assigned,
 >     progress status, incriminated version and platform, planned
 >     milestone/released.
 > 
 >   * Issue details, discussion, answers, attachments.
 
 This is pretty traditional.  I'd still want to challenge a bit.  Why
 do we need severity and priority?  What would they be used for?
 
 > I would store and manage the first category using a simple YAML
 > file.  The bot acknowledges its updates by simply answering to the
 > discussion.
 
 Requirement: Email notifications to ticket "subscribers"?
 That's reasonable.
 
 > Those of the second category can be managed using a single email
 > discussion.
 
 Requirement: Issue comments/attachments and status changes by email?
 
 > I don't know yet how many issues I've forgotten
 
 I can't figure out anything really necessary you would have missed.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Mon Nov  2 02:19:58 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Mon, 02 Nov 2009 09:19:58 +0200
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257107371-sup-3361@onnadayr.ca>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net>
 	<1257107371-sup-3361@onnadayr.ca>
 Message-ID: <1257146346-sup-1154@tilus.net>
 
 rick.tessner, 2009-11-01 22:30:
 > Would a move to github be considered since they now have an issue
 > tracker.
 
 I'd be comfortable with github too.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Mon Nov  2 02:25:38 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Mon, 02 Nov 2009 09:25:38 +0200
 Subject: [sup-talk] Sup Issues Task Force (SITF)
 In-Reply-To: <1257086191-sup-1136@masanjin.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net>
 Message-ID: <1257146404-sup-9768@tilus.net>
 
 William Morgan, 2009-11-01 16:39:
 > Reformatted excerpts from Tero Tilus's message of 2009-10-31:
 >> 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).
 > 
 > As far as I'm concerned, that would be great. I'm open to
 > suggestions about how to organize this.
 
 How about SITF responsible of the boring suff
  - First line processing of inbound issues (relevance, duplication, ...)
  - Issue overview
    - Supervise that fixed/handled issues get closed appropriately
    - Draw attention to triaged "bad" bugs
 
 I'm in.  Who else?
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Mon Nov  2 02:29:41 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Mon, 02 Nov 2009 09:29:41 +0200
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <1256997213-sup-2725@masanjin.net>
 References: <1256997213-sup-2725@masanjin.net>
 Message-ID: <1257146774-sup-9810@tilus.net>
 
 William Morgan, 2009-10-31 16:03:
 > We just had our first baby so it's been a busy few weeks.
 
 Congratulations!  Take your time.  Your family needs it now.
 
 I've got two lovely kids, having the first one is a very special
 thing.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From nicolas.pouillard@gmail.com  Mon Nov  2 03:30:03 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 02 Nov 2009 09:30:03 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257124377-sup-199@black-opal.mit.edu>
 References: <1257111816-sup-4397@peray> <1257124377-sup-199@black-opal.mit.edu>
 Message-ID: <1257150469-sup-7051@peray>
 
 Excerpts from Kevin Riggle's message of Mon Nov 02 02:17:31 +0100 2009:
 > Excerpts from Nicolas Pouillard's message of Sun Nov 01 16:52:08 -0500 2009:
 > (snip)
 > (snip)
 > > 
 > > I would store and manage the first category using a simple YAML file.
 > > 
 > > The bot acknowledges its updates by simply answering to the discussion.
 > > 
 > > Those of the second category can be managed using a single email discussion.
 > > 
 > > Since the discussion is central to the issue, tracking the original message-ID
 > > could be used as the unique identifier.
 > > 
 > > About the issues identifier I see two options, either we try to allocate
 > > simple integers like most of the trackers or we just keep the unique (long)
 > > identifier.
 > > 
 > > Then, optionally a simple set of HTML pages can be generated using the YAML
 > > file.
 > > 
 > > About storage of the YAML file I would simply store it in the repository.
 > > If we make the bot accessible, we just have to periodically pull
 > > from it.
 > > 
 > This portion of your proposed system sounds to me a lot like SD 
 > (http://syncwith.us), against which writing your proposed bot would be fairly
 > straightforward.
 
 SD looks indeed really fun, however I think it fails my simplicity goal.
 Indeed the tool expose tons of commands and try to abstract how it is made,
 I'm in favor of better knowing the underlying store (a YAML file), and simply
 storing it with usual DVCS tools.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From nicolas.pouillard@gmail.com  Mon Nov  2 03:46:34 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 02 Nov 2009 09:46:34 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257143690-sup-7839@tilus.net>
 References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net>
 Message-ID: <1257150627-sup-1843@peray>
 
 Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009:
 > Requirements collected:
 >  - Store/track
 >    - Formal attributes: Issue type, severity, priority, category,
 >      person assigned, progress status, incriminated version and
 >      platform, planned milestone/released
 >    - Informal meta: Issue details, discussion, answers, attachments
 >  - Web-interface (at least for issue submission, searching and displaying)
 >  - Issue submission, commenting, attachments and editing attributes by email
 >  - Notifications by email
 
 Nice summary.
 
 > Nicolas Pouillard, 2009-11-01 23:52:
 > > OK lets forget Ditz[2] as an option.
 > 
 > Why?  (not that i have any reason why not, i've never used diz)
 
 At least temporarily, I think it also fails at staying simple. And while
 it is fun to hack that's fine but then it becomes burden and code to maintain.
 
 > > Note also that I would make no objection to using a traditional bug
 > > tracker.
 > >
 > > It seems that we do not find a tool we really like.
 > 
 > Looks like this is a issue you have discussed in depth before.  Any
 > pointers to list archives?
 
 Not really publicly, and I'm open to seeing tools I don't know.
 
 > > A simple question I asked me was:
 > >   "Do we really need to invent this (big) tool?"
 > 
 > Well... if somebody invented it for us already.  :)
 
 Yes but a big tool imply development, extensions, upgrades...
 
 > > Especially for a bug tracker we need recipes, protocols more than a
 > > nice interface.
 > 
 > Now we are talking!  ...and when trying to choose a tool, we need to
 > think about what we need it to do for us.
 
 I would say that we need a collection of small and clear tools.
 
 > I tried to pick the requirements you used.
 > 
 > > So we need a web interface for non technical users, great.
 > 
 > OK, this seems reasonable requirement.
 > 
 > > What about a pre-formatted email explained on a single web-page for
 > > reporting bugs.
 > ...
 > > A bot will receive emails on the mailing-list and process those
 > > which are in the right format.
 > 
 > Requirement: Bug submission by email?
 > I'd say we need that.
 
 Yes some people tend to really dislike web UIs, and while it is not
 my case I prefer to keep a "by email" option anyway.
 
 > > I think that the bot will not have a lot of information to store:
 > > 
 > >   (correct me if you find something else)
 > > 
 > >   * Issue type, severity, priority, category, person assigned,
 > >     progress status, incriminated version and platform, planned
 > >     milestone/released.
 > > 
 > >   * Issue details, discussion, answers, attachments.
 > 
 > This is pretty traditional.  I'd still want to challenge a bit.  Why
 > do we need severity and priority?  What would they be used for?
 
 I don't say that we need all of those, that the flexibility point.
 
 The configuration will be something like:
 
 attributes:
   type: [defect, enhancement, task]
   severity: [critical, ...]
   priority: [high, low, ...]
   category: [UI, index, ...]
   assigned to: [someone, someoneelse, ...]
   progress status: [waiting, open, started, closed]
   ...
 
 This can be tweaked as needed, if we need one more 'type' we add it,
 if we do not need severity we remove it.
 
 > > I would store and manage the first category using a simple YAML
 > > file.  The bot acknowledges its updates by simply answering to the
 > > discussion.
 > 
 > Requirement: Email notifications to ticket "subscribers"?
 > That's reasonable.
 
 I would say that the mailing-list is the only subscriber, people
 choose to follow the discussion or not with their email-client.
 
 This only miss the "vote for this issue" feature, which we can avoid
 in the mean time and delegate to a polling tool afterward.
 
 > > Those of the second category can be managed using a single email
 > > discussion.
 > 
 > Requirement: Issue comments/attachments and status changes by email?
 
 Right.
 
 > > I don't know yet how many issues I've forgotten
 > 
 > I can't figure out anything really necessary you would have missed.
 
 I got some more input via other channels about the need of an UI to
 search, triage, sort issues. I would say that all of this can easily be
 done by playing with the YAML file.  The only tool I see would be one
 to fetch the email discussion given a Message-ID, but this is a matter
 of another separated tool.
 
 Thanks for your input!
 
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From isra@herraiz.org  Mon Nov  2 04:14:52 2009
 From: isra@herraiz.org (Israel Herraiz)
 Date: Mon, 02 Nov 2009 10:14:52 +0100
 Subject: [sup-talk] Sup Issues Task Force (SITF)
 In-Reply-To: <1257146404-sup-9768@tilus.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net> <1257146404-sup-9768@tilus.net>
 Message-ID: <1257153269-sup-1434@elly>
 
 Excerpts from Tero Tilus's message of Mon Nov 02 08:25:38 +0100 2009:
 > How about SITF responsible of the boring suff
 >  - First line processing of inbound issues (relevance, duplication, ...)
 >  - Issue overview
 >    - Supervise that fixed/handled issues get closed appropriately
 >    - Draw attention to triaged "bad" bugs
 > 
 > I'm in.  Who else?
 
 Me too.
 
 From tero@tilus.net  Mon Nov  2 04:50:07 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Mon, 02 Nov 2009 11:50:07 +0200
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257150627-sup-1843@peray>
 References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net>
 	<1257150627-sup-1843@peray>
 Message-ID: <1257154664-sup-90@tilus.net>
 
 Nicolas Pouillard, 2009-11-02 10:46:
 > Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009:
 >>>   "Do we really need to invent this (big) tool?"
 >> 
 >> Well... if somebody invented it for us already.  :)
 > 
 > Yes but a big tool imply development, extensions, upgrades...
 
 Unless you take service, not the bare tool.  We are already using
 gitorius and rubyforge (at least to some extent).  I'd go for a issue
 tracking service that suits our needs.
 
 >> Requirement: Email notifications to ticket "subscribers"?
 >> That's reasonable.
 > 
 > I would say that the mailing-list is the only subscriber, people
 > choose to follow the discussion or not with their email-client.
 
 Thats exactly why there were quotes around the word subscribers.  ;)
 
 What I was thinking was that you could be a first class citized no
 matter the client.  You could choose to comment and follow the
 discussion on issues using your mua or web interface.  Kinda like what
 Alue[1] does for discussions in general.
 
 [1] http://antti-juhani.kaijanaho.fi/newblog/archives/572
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 06:53:39 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 03:53:39 -0800
 Subject: [sup-talk] Recovering a busted ferret db?
 In-Reply-To: <e06498070911011203s66ece542mac80378442073369@mail.gmail.com>
 References: <e06498070910301017g57b156cclec9abb3689bde243@mail.gmail.com>
 	<1256939095-sup-4201@masanjin.net>
 	<e06498070910301514ud4efe49ic0fb40d181156fab@mail.gmail.com>
 	<1257087035-sup-2014@masanjin.net>
 	<e06498070911011203s66ece542mac80378442073369@mail.gmail.com>
 Message-ID: <1257162594-sup-7077@masanjin.net>
 
 [cc'ing list]
 
 Reformatted excerpts from Steven Walter's message of 2009-11-01:
 > Hooray, that worked.  There is an email with an exceptionally long
 > recipient list with the tag in question, and I received it around the
 > time I first noticed the bad behavior in sup.  The Cc: field is 6878
 > bytes long, containing 281 email addresses.
 
 Weird, because I can call split_on_commas on a string that's that size,
 with that many commas, in a few milliseconds. Must be something strange
 about that particular string that's causing the worst-case behavior.
 
 I'm going to apply the patch, but with a bigger limit.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From gregor@hoffleit.de  Mon Nov  2 07:06:36 2009
 From: gregor@hoffleit.de (Gregor Hoffleit)
 Date: Mon, 02 Nov 2009 13:06:36 +0100
 Subject: [sup-talk] Patch for ncursesw branch (use panelw and formw)
 Message-ID: <1257162838-sup-737@sam.mediasupervision.de>
 
 I noticed that the ncursesw branch implements only the first part of the
 wide-char fixes suggested in the extconf patch in
 http://rubyforge.org/pipermail/sup-talk/2007-October/000297.html.
 
 Entering UTF-8 characters in the textfields ('To', 'Subject', 'Alias')
 still doesn't work.
 
 It worked fine, though, applied the second part of the patch as well.
 This is the diff against ncursesw:
 
 diff --git a/ncurses-0.9.1/extconf.rb b/ncurses-0.9.1/extconf.rb
 index a559385..7c4d2c2 100644
 --- a/ncurses-0.9.1/extconf.rb
 +++ b/ncurses-0.9.1/extconf.rb
 @@ -118,11 +118,11 @@ have_func("attr_get")
  
  puts "checking for the panel library..."
  if have_header("panel.h")
 -  have_library("panel", "panel_hidden")
 +  have_library("panelw", "panel_hidden")
  end
  puts "checking for the form library..."
  if have_header("form.h")
 -  have_library("form", "new_form")
 +  have_library("formw", "new_form")
  end
  
  create_makefile('ncurses')
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 07:08:09 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 04:08:09 -0800
 Subject: [sup-talk] updated xapian experimental branch
 In-Reply-To: <1257118189-sup-7392@zyrg.net>
 References: <1257118189-sup-7392@zyrg.net>
 Message-ID: <1257163403-sup-9032@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-11-01:
 > The major feature on this branch is the immediate label updates I've
 > mentioned before on the list.
 
 Awesome, really awesome.
 
 > Use of Xapian for thread relevance checks
 >  - Instead of hardcoding the policy into InboxMode
 
 Awesome.
 
 >  - New 'z' key to clear irrelevant threads
 >   - Not strictly necessary, but removing messages in response to index
 >     events is difficult with the current UI code
 
 Can you describe this a bit?
 
 > Fallout from async message saving
 >  - UpdateManager messages handled in main event loop
 >   - Avoids many races but can lag UI unless we're careful
 
 I think this is a great idea.
 
 Thanks for all of this, Rich.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 07:12:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 04:12:41 -0800
 Subject: [sup-talk] i18n?
 In-Reply-To: <1256295847-sup-9437@viajero>
 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> <1256295847-sup-9437@viajero>
 Message-ID: <1257163780-sup-1357@masanjin.net>
 
 Reformatted excerpts from Fabio Riga's message of 2009-10-23:
 > 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).
 
 Tero's comment wasn't about gettext, as far as I understand it. There
 are Ruby gettext bindings but they look like a pain in the ass to use,
 and it's pretty trivial to replace it a language like Ruby.
 
 > 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 :-) ).
 
 That is a downside, definitely.
 
 > 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...)
 
 I believe he was thinking about something like git grep. You see a weird
 message displayed by Sup, you want to find the code that's generating
 it, you can git grep the source for the message directly.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 07:13:01 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 04:13:01 -0800
 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: <1257163967-sup-5554@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-10-23:
 > Why not default to the english strings as translation keys and
 > fallback to key itself in case of missing translation?
 
 Christopher, what do you think?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 07:16:04 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 04:16:04 -0800
 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: <1257164155-sup-371@masanjin.net>
 
 Reformatted excerpts from Gregor Hoffleit's message of 2009-10-22:
 > If the bug tracker is not to be acticely used any longer, shouldn't it
 > be removed from the Sup Gitorious page?
 
 Removed, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 07:23:16 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 04:23:16 -0800
 Subject: [sup-talk] Localized date on mbox From line in sent messages
 In-Reply-To: <1256276875-sup-5782@tilus.net>
 References: <1256276875-sup-5782@tilus.net>
 Message-ID: <1257164552-sup-2382@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-10-22:
 > 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.
 
 This was fixed in bfe40c05dc6dc2656a4dde11948ff617f2fa00d6, released in
 0.9.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 07:35:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 04:35:21 -0800
 Subject: [sup-talk] Recovering a busted ferret db?
 In-Reply-To: <1257162594-sup-7077@masanjin.net>
 References: <e06498070910301017g57b156cclec9abb3689bde243@mail.gmail.com>
 	<1256939095-sup-4201@masanjin.net>
 	<e06498070910301514ud4efe49ic0fb40d181156fab@mail.gmail.com>
 	<1257087035-sup-2014@masanjin.net>
 	<e06498070911011203s66ece542mac80378442073369@mail.gmail.com>
 	<1257162594-sup-7077@masanjin.net>
 Message-ID: <1257165314-sup-679@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-11-02:
 > I'm going to apply the patch, but with a bigger limit.
 
 Actually, strike that. The patch would mean we effectively limit the
 number of recipients in a to, cc, or bcc field, which seems crazy. It
 would be better to reimplement the regexp as a little state machine, as
 irritating as that might be.
 
 Steven, can you privately send me the header that's causing this? You
 can obscure it somewhat if you want, just leave the quotes and commas
 alone.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From tero@tilus.net  Mon Nov  2 08:58:09 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Mon, 02 Nov 2009 15:58:09 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257163780-sup-1357@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>
 	<1256280223-sup-736@tilus.net> <1256295847-sup-9437@viajero>
 	<1257163780-sup-1357@masanjin.net>
 Message-ID: <1257169884-sup-2615@tilus.net>
 
 William Morgan, 2009-11-02 14:12:
 > Reformatted excerpts from Fabio Riga's message of 2009-10-23:
 >> 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.
 > 
 > Tero's comment wasn't about gettext, as far as I understand it.
 
 You had me right.  I was talking about the approach to i18n in general.
 
 > There are Ruby gettext bindings but they look like a pain in the ass
 > to use, and it's pretty trivial to replace it a language like Ruby.
 
 Also they are pretty trivial to wrap behind nice interface in a
 language like Ruby.  "Been there, done that!".t  :)
 
 >> Can anyone explain me where and why a translated string in the UI
 >> should be searchable with a regular expression?
 >
 > I believe he was thinking about something like git grep. You see a
 > weird message displayed by Sup, you want to find the code that's
 > generating it, you can git grep the source for the message directly.
 
 That was exactly what I was thinking.
 
 Having weird keys in code imo also slows down development.  If I want
 to (write code to) display a simple message to user, with "original
 language as key" approac i just write "my message".t (or whatever the
 l10n interface is) instead of modifying some yaml file somewhere and
 then copy-pasting the key from there to code. I just plain code and
 let somebody else figure out the translation later or.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 09:50:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 06:50:08 -0800
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257111816-sup-4397@peray>
 References: <1257111816-sup-4397@peray>
 Message-ID: <1257169654-sup-6224@masanjin.net>
 
 Nice writeup. Just brainstorming, here are the features I personally
 find vital for an issue tracker that would make me happy:
 
 1. Web submission. The burden of creating a record should be on the
 submitter---it's not too much to ask, and it saves developer time. This
 also encourages reporters to provide relevant information like version,
 platform, Ruby version, etc. upfront, since they can be prompted for
 those data explicitly.
 
 2. Developer discussion via email. This is vital. There's no way I would
 want to have a technical discussion using text boxes on a website. And
 this discussion should be attached to the issue, of course.
 
 3. Canonicality. I want one name for a bug, and I want one URL that I
 can point people to when referring to it. That URL should have the
 entire history, including developer discussion, of the issue.
 
 4. Browseability. There should be some public way of getting a view of
 all the open issues, at a minimum. (Web seems natural.) Other stuff like
 sorting by priority, attachign to releases, etc. are icing on the cake,
 but if people are going to be chipping in on development effort, or
 searching to see if other people have had this bug, they have to be able
 to browse what's out there.
 
 > About the issues identifier I see two options, either we try to
 > allocate simple integers like most of the trackers or we just keep the
 > unique (long) identifier.
 
 I want a simple one. I can remember JIRA-style "ABC-123" names and
 that's really handy sometimes.
 
 Just my two cents.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 09:53:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 06:53:08 -0800
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257143690-sup-7839@tilus.net>
 References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net>
 Message-ID: <1257173444-sup-295@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-11-01:
 > Requirement: Bug submission by email?
 > I'd say we need that.
 
 That's what we have now, basically, and what we had when we were using
 ditz, and I didn't like having to do the extra work of making an issue.
 
 > This is pretty traditional.  I'd still want to challenge a bit.  Why
 > do we need severity and priority?  What would they be used for?
 
 At least one type of ordering would be nice. There are a large class of
 feature requests where my basic feeling is "sure, that would be nice,
 but I've got a million other things more important to do", which I would
 like to keep around as food for later thought, if nothing else, but
 would like to basically ignore in the near term.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 09:58:18 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 06:58:18 -0800
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257154664-sup-90@tilus.net>
 References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net>
 	<1257150627-sup-1843@peray> <1257154664-sup-90@tilus.net>
 Message-ID: <1257173616-sup-9298@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-11-02:
 > Unless you take service, not the bare tool.  We are already using
 > gitorius and rubyforge (at least to some extent).  I'd go for a issue
 > tracking service that suits our needs.
 
 I'm not dead-set against a hosted solution, but I am wary of making too
 much of the development cycle reliant on third parties. E.g. I see
 people who can't get any work done when Github is down. Well, that's not
 Github's fault, per se, but they've integrated it into their process to
 such an extent that they're now reliant on it.
 
 Not to say that that would happen with just an issue tracker. But still,
 our use of Gitorious and Rubyforge is pretty minimal right now, and I
 feel good about that.
 
 (And honestly I find Gitorious merge requests a little irritating,
 because they're invariably not rebased properly against master and I
 have to have the same discussion every time.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 09:59:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 06:59:48 -0800
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257169884-sup-2615@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> <1256295847-sup-9437@viajero>
 	<1257163780-sup-1357@masanjin.net> <1257169884-sup-2615@tilus.net>
 Message-ID: <1257173950-sup-4883@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-11-02:
 > Having weird keys in code imo also slows down development.  If I want
 > to (write code to) display a simple message to user, with "original
 > language as key" approac i just write "my message".t (or whatever the
 > l10n interface is) instead of modifying some yaml file somewhere and
 > then copy-pasting the key from there to code. I just plain code and
 > let somebody else figure out the translation later or.
 
 I tend to agree.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 10:07:31 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 07:07:31 -0800
 Subject: [sup-talk] [PATCH] minor nits in exception apology message
 In-Reply-To: <1257107371-sup-3361@onnadayr.ca>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net>
 	<1257107371-sup-3361@onnadayr.ca>
 Message-ID: <1257174251-sup-3662@masanjin.net>
 
 Reformatted excerpts from rick.tessner's message of 2009-11-01:
 > Would a move to github be considered since they now have an issue
 > tracker.  It provides tagging of issues and voting.
 
 I will move development discussion to a flat sequence of web textareas
 the day you pry Sup from my cold dead hands.
 
 Well, ok. I will at least take a look at it.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 10:08:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 07:08:48 -0800
 Subject: [sup-talk] Sup Issues Task Force (SITF)
 In-Reply-To: <1257146404-sup-9768@tilus.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net> <1257146404-sup-9768@tilus.net>
 Message-ID: <1257174456-sup-5631@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-11-01:
 > How about SITF responsible of the boring suff
 >  - First line processing of inbound issues (relevance, duplication, ...)
 >  - Issue overview
 >    - Supervise that fixed/handled issues get closed appropriately
 >    - Draw attention to triaged "bad" bugs
 > 
 > I'm in.  Who else?
 
 That sounds great. I think it needs to be combined with some kind of
 formal issue tracker though.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 10:57:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 07:57:50 -0800
 Subject: [sup-talk] Using TLS instead of ssl
 In-Reply-To: <2b29d9f30910270434k65550eaqf5187d048b604020@mail.gmail.com>
 References: <2b29d9f30910270434k65550eaqf5187d048b604020@mail.gmail.com>
 Message-ID: <1257177347-sup-2023@masanjin.net>
 
 Reformatted excerpts from k.v.ramakrishna reddy's message of 2009-10-27:
 > What are the changes that i need to make so that sup uses TLS instead
 > of ssl when connecting to my source ?
 
 Honestly I'm not sure. I'm not that familiar with IMAP. Is that
 something that's negotiated during setting up a connection?
 
 > Further more how can i delete a source ?
 
 There's not a great way right now. You can remove it from
 ~/.sup/sources.yaml manually, and then you can remove the messages from
 the index with something like this:
 
   $ sh devel/console.sh
   >> q = Index.parse_query "source_id:4"
   => # ...
   >> Index.each_id(q) { |id| Index.delete id }
   => nil
   >> Index.save
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 10:58:45 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 07:58:45 -0800
 Subject: [sup-talk] Completion for search queries
 In-Reply-To: <1256199860-sup-4407@thinkpad-ubuntu>
 References: <1256199860-sup-4407@thinkpad-ubuntu>
 Message-ID: <1257177490-sup-4126@masanjin.net>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-10-22:
 > Anyone else who would like to have this feature in sup?
 
 Sounds good to me. Probably wouldn't be too hard since we have a fairly
 general tab-completion mechanism in place already.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 11:03:41 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 08:03:41 -0800
 Subject: [sup-talk] exception in mainline
 In-Reply-To: <1256749083-sup-3681@arrakis.es.net>
 References: <1256749083-sup-3681@arrakis.es.net>
 Message-ID: <1257177587-sup-5889@masanjin.net>
 
 Hi Jon,
 
 Reformatted excerpts from Jon Dugan's message of 2009-10-28:
 > 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'
 
 I posted this workaround patch earlier. I'm working on a better solution in the
 meanwhile.
 
 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
 
 > ./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
 > 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From stevenrwalter@gmail.com  Mon Nov  2 11:47:51 2009
 From: stevenrwalter@gmail.com (Steven Walter)
 Date: Mon, 2 Nov 2009 11:47:51 -0500
 Subject: [sup-talk] "Force tags to be joined" doesn't save
 Message-ID: <e06498070911020847v6e91024am4af1d4901dee7ef6@mail.gmail.com>
 
 If I select two threads and combine them with #, sup seems to combine
 them, and the current view becomes "modified."  If I save ($) and
 reload (@), the threads show up separately again.  Is this expected
 behavior?
 -- 
 -Steven Walter <stevenrwalter at gmail.com>
 
 From nicolas.pouillard@gmail.com  Mon Nov  2 12:38:54 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 02 Nov 2009 18:38:54 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257173444-sup-295@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257143690-sup-7839@tilus.net>
 	<1257173444-sup-295@masanjin.net>
 Message-ID: <1257183478-sup-7820@peray>
 
 Excerpts from William Morgan's message of Mon Nov 02 15:53:08 +0100 2009:
 > Reformatted excerpts from Tero Tilus's message of 2009-11-01:
 > > Requirement: Bug submission by email?
 > > I'd say we need that.
 > 
 > That's what we have now, basically, and what we had when we were using
 > ditz, and I didn't like having to do the extra work of making an issue.
 
 Right, but in this setup only well formatted bug reports are accepted, so
 no extra burden on devs.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From nicolas.pouillard@gmail.com  Mon Nov  2 12:47:19 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 02 Nov 2009 18:47:19 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257169654-sup-6224@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 Message-ID: <1257183536-sup-1174@peray>
 
 Excerpts from William Morgan's message of Mon Nov 02 15:50:08 +0100 2009:
 > Nice writeup. Just brainstorming, here are the features I personally
 > find vital for an issue tracker that would make me happy:
 > 
 > 1. Web submission. The burden of creating a record should be on the
 > submitter---it's not too much to ask, and it saves developer time. This
 > also encourages reporters to provide relevant information like version,
 > platform, Ruby version, etc. upfront, since they can be prompted for
 > those data explicitly.
 
 > 2. Developer discussion via email. This is vital. There's no way I would
 > want to have a technical discussion using text boxes on a website. And
 > this discussion should be attached to the issue, of course.
 
 1,2: Same for me.
 
 > 3. Canonicality. I want one name for a bug, and I want one URL that I
 > can point people to when referring to it. That URL should have the
 > entire history, including developer discussion, of the issue.
 
 > 4. Browseability. There should be some public way of getting a view of
 > all the open issues, at a minimum. (Web seems natural.) Other stuff like
 > sorting by priority, attachign to releases, etc. are icing on the cake,
 > but if people are going to be chipping in on development effort, or
 > searching to see if other people have had this bug, they have to be able
 > to browse what's out there.
 
 3,4:
 
 Right, I think this is part of the web-page generation tool. Which
 given the YAML file will produce web-pages. The only unclear point to
 me is: "how to find the archive URL for a discussion given the message-ID?"
 
 > > About the issues identifier I see two options, either we try to
 > > allocate simple integers like most of the trackers or we just keep the
 > > unique (long) identifier.
 > 
 > I want a simple one. I can remember JIRA-style "ABC-123" names and
 > that's really handy sometimes.
 
 Right, we want short issue numbers. I'm would still be a bit sad of completely
 loosing the distributed property. Maybe a solution would be to allow issues
 to have an optional short name. In practice it will be just temporarily,
 the time the issue makes its way to the central repository, or being just a
 local issue.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 14:20:32 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 11:20:32 -0800
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257183536-sup-1174@peray>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<1257183536-sup-1174@peray>
 Message-ID: <1257189278-sup-7991@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-11-02:
 > Right, we want short issue numbers. I'm would still be a bit sad of
 > completely loosing the distributed property. Maybe a solution would be
 > to allow issues to have an optional short name. In practice it will be
 > just temporarily, the time the issue makes its way to the central
 > repository, or being just a local issue.
 
 I just think it would be really useful to say stuff like "this is a
 duplicate of #154" or "fixing this depends on index-48" or whatever, and
 have everyone be able to find that easily, e.g. by going to
 http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was
 irritating.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 14:22:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 11:22:48 -0800
 Subject: [sup-talk] "Force tags to be joined" doesn't save
 In-Reply-To: <e06498070911020847v6e91024am4af1d4901dee7ef6@mail.gmail.com>
 References: <e06498070911020847v6e91024am4af1d4901dee7ef6@mail.gmail.com>
 Message-ID: <1257189701-sup-8211@masanjin.net>
 
 Reformatted excerpts from Steven Walter's message of 2009-11-02:
 > If I select two threads and combine them with #, sup seems to combine
 > them, and the current view becomes "modified."  If I save ($) and
 > reload (@), the threads show up separately again.  Is this expected
 > behavior?
 
 I pushed a fix for this to master yesterday. Do you still have this with
 a recent git? (I.e. one with cc2359bf87bd982501e57f703fbf4368b7f9cb5f).
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 14:28:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 11:28:03 -0800
 Subject: [sup-talk] [PATCH] xapian: replace DocumentMethods module with
 	plain monkeypatching
 In-Reply-To: <1256019247-6046-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <20091012223449.GB31940@tilus.net>
 	<1256019247-6046-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1257190065-sup-2886@masanjin.net>
 
 Branch xapian-bugfix, merged into next. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 14:31:38 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 11:31:38 -0800
 Subject: [sup-talk] releasing 0.9.1 in the next day or so
 Message-ID: <1257190099-sup-9880@masanjin.net>
 
 Hi all,
 
 I'm going to release an 0.9.1 based off the current master in the next
 day or so. This is just a heads-up.
 
 There are a couple bugfixes that are still cooking in next, but I want
 to keep this as stable as possible. Changes since 0.9 will be:
 
 $ git log release-0.9..master --pretty=oneline
 84d9313bfd73e86c8fea95fabc8ff8544f70b1f0 make doc/NewUserGuide.txt markdown
 269cd03b183669c86df1f7336ade8fff5c566ebd fix mbox date parsing: catch ArgumentError
 409ddd9c5668b5cdf67dbebea761c476a317c53a give exception log relative to BASE_DIR in exception message
 2dfd378b616243d03203e49f5ee29636051d3cbf fix bug in which custom-search substitutions are not used
 4a32776f523039cdcbb6165d58e24bd9753b256b increase numbers in contact-list-mode
 d19eda45643dff558324c6c2f34aa0148f9d65d0 don't downcase a nil content-type
 a8b5c6db0587fe4383758dc3400aaab85ad22d8b fix --compose option, and add a --subject option
 c924164c22a7bdb3fb66f9ce4ca5ac8b19dfcccf include hook filename in error messages
 93b5552730c10e2a352bd33f5ee98800bcd8679e more release-script updates
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  2 14:32:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 02 Nov 2009 11:32:36 -0800
 Subject: [sup-talk] "Force tags to be joined" doesn't save
 In-Reply-To: <1257189701-sup-8211@masanjin.net>
 References: <e06498070911020847v6e91024am4af1d4901dee7ef6@mail.gmail.com>
 	<1257189701-sup-8211@masanjin.net>
 Message-ID: <1257190312-sup-7892@masanjin.net>
 
 Reformatted excerpts from William Morgan's message of 2009-11-02:
 > I pushed a fix for this to master yesterday. Do you still have this
 > with a recent git? (I.e. one with
 > cc2359bf87bd982501e57f703fbf4368b7f9cb5f).
 
 Sorry, this is in next only for the moment.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Mon Nov  2 15:23:58 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 02 Nov 2009 21:23:58 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257189278-sup-7991@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<1257183536-sup-1174@peray> <1257189278-sup-7991@masanjin.net>
 Message-ID: <1257193412-sup-5939@peray>
 
 Excerpts from William Morgan's message of Mon Nov 02 20:20:32 +0100 2009:
 > Reformatted excerpts from Nicolas Pouillard's message of 2009-11-02:
 > > Right, we want short issue numbers. I'm would still be a bit sad of
 > > completely loosing the distributed property. Maybe a solution would be
 > > to allow issues to have an optional short name. In practice it will be
 > > just temporarily, the time the issue makes its way to the central
 > > repository, or being just a local issue.
 > 
 > I just think it would be really useful to say stuff like "this is a
 > duplicate of #154" or "fixing this depends on index-48" or whatever, and
 > have everyone be able to find that easily, e.g. by going to
 > http://sup.com/bugs/index-48. Having to refer to the hashes in Ditz was
 > irritating.
 
 I agree, that's way I proposed it.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From joe@talkhouse.com  Mon Nov  2 15:40:21 2009
 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=)
 Date: Mon, 02 Nov 2009 15:40:21 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257169654-sup-6224@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 Message-ID: <1257193345-sup-3174@maui.local>
 
 Excerpts from William Morgan's message of Mon Nov 02 09:50:08 -0500 2009:
 > 1. Web submission. The burden of creating a record should be on the
 > submitter---it's not too much to ask, and it saves developer time. This
 > also encourages reporters to provide relevant information like version,
 > platform, Ruby version, etc. upfront, since they can be prompted for
 > those data explicitly.
 > 
 > 2. Developer discussion via email. This is vital. There's no way I would
 > want to have a technical discussion using text boxes on a website. And
 > this discussion should be attached to the issue, of course.
 
 Please ignore this suggestion if you feel it is stupid, but couldn't an
 internal sup-based bug submission perform prompting and validation tasks just
 as easily as a web form? Also, wouldn't it be better for automatically
 including or verifying operating system info, version info, libraries, etc?  
 
 It seems like this might make for a more natural transition to email-based
 developer discussion, reduce the need for centralized infrastructure, make it
 easier for users to figure out how and where to submit a bug, and possibly make
 critical system and library information more accurate and detailed.
 
 Cheers,
 Joe
 
 From nicolas.pouillard@gmail.com  Mon Nov  2 16:49:39 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 02 Nov 2009 22:49:39 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257193345-sup-3174@maui.local>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<1257193345-sup-3174@maui.local>
 Message-ID: <1257198369-sup-9036@peray>
 
 Excerpts from Joe W?lfel's message of Mon Nov 02 21:40:21 +0100 2009:
 > Excerpts from William Morgan's message of Mon Nov 02 09:50:08 -0500 2009:
 > > 1. Web submission. The burden of creating a record should be on the
 > > submitter---it's not too much to ask, and it saves developer time. This
 > > also encourages reporters to provide relevant information like version,
 > > platform, Ruby version, etc. upfront, since they can be prompted for
 > > those data explicitly.
 > > 
 > > 2. Developer discussion via email. This is vital. There's no way I would
 > > want to have a technical discussion using text boxes on a website. And
 > > this discussion should be attached to the issue, of course.
 > 
 > Please ignore this suggestion if you feel it is stupid, but couldn't an
 > internal sup-based bug submission perform prompting and validation tasks just
 > as easily as a web form? Also, wouldn't it be better for automatically
 > including or verifying operating system info, version info, libraries, etc?  
 > 
 > It seems like this might make for a more natural transition to email-based
 > developer discussion, reduce the need for centralized infrastructure, make it
 > easier for users to figure out how and where to submit a bug, and possibly make
 > critical system and library information more accurate and detailed.
 
 This is indeed a nice option. Add to sup a way to send a bug report. It could
 simply be an email in the chosen format for bug reporting. And indeed the
 bonus is more precise information.
 
 However in the long run this only complementary with other way to report bugs.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From david.pflug@hostdime.com  Mon Nov  2 16:53:52 2009
 From: david.pflug@hostdime.com (David Pflug)
 Date: Mon, 02 Nov 2009 16:53:52 -0500
 Subject: [sup-talk] Exception during message polling
 Message-ID: <1257198730-sup-5007@dpflug-desktop>
 
 I don't know what mail it's dying on, but this is sup 0.9 using Xapian.
 
 --- ArgumentError from thread: poll after loading inbox
 invalid byte sequence in US-ASCII
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:284:in `gsub'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:284:in `normalize_whitespace'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:511:in `message_to_chunks'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:435:in `block in message_to_chunks'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:435:in `map'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:435:in `message_to_chunks'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:239:in `load_from_source!'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/message.rb:335:in `build_from_source'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:145:in `block in each_message_from'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/imap.rb:197:in `block in each'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/imap.rb:185:in `upto'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/imap.rb:185:in `each'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:139:in `each_message_from'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:93:in `block (2 levels) in do_poll'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:81:in `each'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:81:in `block in do_poll'
 <internal:prelude>:8:in `synchronize'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:80:in `do_poll'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/modes/poll-mode.rb:15:in `poll'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:48:in `poll'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup:196:in `block (2 levels) in <module:Redwood>'
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup.rb:77:in `block in reporting_thread'
 
 -- 
 David Pflug
 System Technician
 Hostdime.com, Inc.
 
 From usul@aruba.it  Mon Nov  2 19:01:08 2009
 From: usul@aruba.it (Fabio Riga)
 Date: Tue, 03 Nov 2009 01:01:08 +0100
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257169884-sup-2615@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> <1256295847-sup-9437@viajero>
 	<1257163780-sup-1357@masanjin.net> <1257169884-sup-2615@tilus.net>
 Message-ID: <1257202138-sup-5711@viajero>
 
 Excerpts from Tero Tilus's message of lun nov 02 14:58:09 +0100 2009:
 > William Morgan, 2009-11-02 14:12:
 > > Tero's comment wasn't about gettext, as far as I understand it.
 > 
 > You had me right.  I was talking about the approach to i18n in general.
 
 Sorry, I think the problem here is my English. I understood Tero's
 comment wasn't about gettext, I was the one suggesting: "everybody's
 using gettext, why don't we?"
 
 > > There are Ruby gettext bindings but they look like a pain in the ass
 > > to use, and it's pretty trivial to replace it a language like Ruby.
 > 
 > Also they are pretty trivial to wrap behind nice interface in a
 > language like Ruby.  "Been there, done that!".t  :)
 
 And you both answered that question... I'm just a hobbyist ruby
 programmer, never used gettext. I transleted a program that use it (my
 previous mail client :D) so I can read a .po file (I don't understand
 why this is a problem, though). I thought it was an easy, ready-made
 thing to implement, if I'm wrong, no problem, there is always a better
 solution.
 
 > > I believe he was thinking about something like git grep. You see a
 > > weird message displayed by Sup, you want to find the code that's
 > > generating it, you can git grep the source for the message directly.
 > 
 > That was exactly what I was thinking.
 > 
 > Having weird keys in code imo also slows down development.  If I want
 > to (write code to) display a simple message to user, with "original
 > language as key" approac i just write "my message".t (or whatever the
 > l10n interface is) instead of modifying some yaml file somewhere and
 > then copy-pasting the key from there to code. I just plain code and
 > let somebody else figure out the translation later or.
 > 
 Sorry, I don't understand what you mean. The idea is to (1) have a branch
 for every language? Translators directly write in the code? Or (2)  "original
 language as key" means a way to substitute "on the fly" the original
 string with another one in the current locale? In this way you always need a
 yaml file, or a ruby hash, or a .po file (you can implement it in another
 way, but is the gettext approach...).
 
 So, I played a little with irb... do you mean something like:
 
 class String
   def t
     l10n_hash[self] || self
   end
 end
 
 Sounds good to me...
 
 "bye bye".t
 => "ciao ciao"
 
 From tero@tilus.net  Mon Nov  2 20:22:44 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 03 Nov 2009 03:22:44 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257202138-sup-5711@viajero>
 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> <1256295847-sup-9437@viajero>
 	<1257163780-sup-1357@masanjin.net>
 	<1257169884-sup-2615@tilus.net> <1257202138-sup-5711@viajero>
 Message-ID: <1257210858-sup-5218@tilus.net>
 
 Fabio Riga, 2009-11-03 02:01:
 > Sorry, I don't understand what you mean. The idea is to (1) have a
 > branch for every language? Translators directly write in the code?
 > Or (2) "original language as key" means a way to substitute "on the
 > fly" the original string with another one in the current locale?
 
 The second one, yes.  God save us from the first!
 
 > So, I played a little with irb... do you mean something like:
 > 
 > class String
 >   def t
 >     l10n_hash[self] || self
 >   end
 > end
 
 Exactly.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Mon Nov  2 20:45:24 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 03 Nov 2009 03:45:24 +0200
 Subject: [sup-talk] Sup Issues Task Force (SITF)
 In-Reply-To: <1257174456-sup-5631@masanjin.net>
 References: <1256749942-sup-4831@arrakis.es.net> <1256760295-sup-9873@peray>
 	<1256760970-sup-8118@arrakis.es.net>
 	<1256939476-sup-2864@masanjin.net> <1256987483-sup-338@tilus.net>
 	<1257086191-sup-1136@masanjin.net> <1257146404-sup-9768@tilus.net>
 	<1257174456-sup-5631@masanjin.net>
 Message-ID: <1257212675-sup-1610@tilus.net>
 
 William Morgan, 2009-11-02 17:08:
 > I think it needs to be combined with some kind of formal issue
 > tracker though.
 
 Most definitely yes.  Let's see where the tracker discussion goes.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From rlane@club.cc.cmu.edu  Mon Nov  2 22:48:10 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 02 Nov 2009 22:48:10 -0500
 Subject: [sup-talk] updated xapian experimental branch
 In-Reply-To: <1257163403-sup-9032@masanjin.net>
 References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net>
 Message-ID: <1257196293-sup-6882@zyrg.net>
 
 Excerpts from William Morgan's message of Mon Nov 02 07:08:09 -0500 2009:
 > >  - New 'z' key to clear irrelevant threads
 > >   - Not strictly necessary, but removing messages in response to index
 > >     events is difficult with the current UI code
 > 
 > Can you describe this a bit?
 
 In general, we can only determine thread relevance by querying xapian.
 The actual write to the db is done async, so it will happen a little
 after you (for example) remove a label. The index fires a message event
 when the new state hits the db, and the UI then checks if the thread is
 still relevant to the query. So, the UI would only know to hide a newly
 irrelevant thread after the user has potentially gone on and done other
 actions. Having threads randomly disappear would be unfriendly, so
 instead the UI displays a red X. 'z' will drop these irrelevant threads.
 
 For 'simple' queries we can determine relevance without xapian, so we
 could synchronously remove irrelevant threads in that case. However,
 this would lead to unintuitive situations where queries that appear
 similar have different irrelevance behaviors. The option that I will
 probably implement is choosing the behavior per-mode, so that inbox-mode
 could keep it's old behavior. That's the most important one anyway.
 
 From nicolas.pouillard@gmail.com  Tue Nov  3 03:39:48 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 03 Nov 2009 09:39:48 +0100
 Subject: [sup-talk] updated xapian experimental branch
 In-Reply-To: <1257196293-sup-6882@zyrg.net>
 References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net>
 	<1257196293-sup-6882@zyrg.net>
 Message-ID: <1257237468-sup-5663@peray>
 
 Excerpts from Rich Lane's message of Tue Nov 03 04:48:10 +0100 2009:
 > Excerpts from William Morgan's message of Mon Nov 02 07:08:09 -0500 2009:
 > > >  - New 'z' key to clear irrelevant threads
 > > >   - Not strictly necessary, but removing messages in response to index
 > > >     events is difficult with the current UI code
 > > 
 > > Can you describe this a bit?
 > 
 > In general, we can only determine thread relevance by querying xapian.
 > The actual write to the db is done async, so it will happen a little
 > after you (for example) remove a label. The index fires a message event
 > when the new state hits the db, and the UI then checks if the thread is
 > still relevant to the query. So, the UI would only know to hide a newly
 > irrelevant thread after the user has potentially gone on and done other
 > actions. Having threads randomly disappear would be unfriendly, so
 > instead the UI displays a red X. 'z' will drop these irrelevant threads.
 > 
 > For 'simple' queries we can determine relevance without xapian, so we
 > could synchronously remove irrelevant threads in that case. However,
 > this would lead to unintuitive situations where queries that appear
 > similar have different irrelevance behaviors. The option that I will
 > probably implement is choosing the behavior per-mode, so that inbox-mode
 > could keep it's old behavior. That's the most important one anyway.
 
 What are non simple queries which would cause 'red X's to appear? My guess
 is that since we cannot change other attributes than the labels, we can
 statically know if the thread is still relevant without the label. No?
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 08:43:25 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 05:43:25 -0800
 Subject: [sup-talk] Sup crashing upon save changes ($)
 In-Reply-To: <1256178926-sup-1780@Richard-Sandilandss-MacBook-Pro.local>
 References: <1256178926-sup-1780@Richard-Sandilandss-MacBook-Pro.local>
 Message-ID: <1257255713-sup-617@masanjin.net>
 
 Reformatted excerpts from Richard Sandilands's message of 2009-10-21:
 > 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
 
 It looks like Sup's expecting a draft message that disappeared from disk
 somehow. You should be able to fix this by reindexing the drafts folder:
 
   sup-sync --all -v sup://drafts
 
 But you may want to find out why that file disappeared.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From mailinglist@flasht.de  Tue Nov  3 09:05:01 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Tue, 03 Nov 2009 15:05:01 +0100
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257163967-sup-5554@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>
 	<1256280223-sup-736@tilus.net> <1257163967-sup-5554@masanjin.net>
 Message-ID: <1257256976-sup-1266@thinkpad-ubuntu>
 
 Excerpts from William Morgan's message of Mo Nov 02 13:13:01 +0100 2009:
 > Reformatted excerpts from Tero Tilus's message of 2009-10-23:
 > > Why not default to the english strings as translation keys and
 > > fallback to key itself in case of missing translation?
 > 
 > Christopher, what do you think?
 
 Sounds OK to me. Should we use gettext then or rely on .yaml files for
 any additional translations then? I haven't used gettext yet and from
 what I remember it lookes weird, at least the ruby binding did.
 Maybe it's very easy though.
 -- 
 ================================
 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/20091103/7be8d5b7/attachment.bin>
 
 From pioto@pioto.org  Tue Nov  3 09:50:55 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Tue, 03 Nov 2009 09:50:55 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257169654-sup-6224@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 Message-ID: <02055f053011496a2dcb9085b7e7535f@localhost>
 
 
 On Mon, 02 Nov 2009 06:50:08 -0800, William Morgan
 <wmorgan-sup at masanjin.net> wrote:
 > Nice writeup. Just brainstorming, here are the features I personally
 > find vital for an issue tracker that would make me happy:
 > 
 > 1. Web submission. 
 > 
 > 2. Developer discussion via email.
 > 
 > 3. Canonicality.
 > 
 > 4. Browseability.
 > 
 > I want a simple one. I can remember JIRA-style "ABC-123" names and
 > that's really handy sometimes.
 
 As much as I hate to suggest it... RT[1] should have all of these
 qualities. It's used by CPAN, among other things. And, a sample ticket of
 mine[2].
 
 [1] http://bestpractical.com/rt
 [2] https://rt.cpan.org/Public/Bug/Display.html?id=45040
 
 -- 
 Mike Kelly
 
 From tero@tilus.net  Tue Nov  3 10:08:00 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 03 Nov 2009 17:08:00 +0200
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257256976-sup-1266@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>
 	<1256280223-sup-736@tilus.net> <1257163967-sup-5554@masanjin.net>
 	<1257256976-sup-1266@thinkpad-ubuntu>
 Message-ID: <1257260315-sup-830@tilus.net>
 
 Christopher Bertels, 2009-11-03 16:05:
 > Should we use gettext then or rely on .yaml files for any additional
 > translations then? I haven't used gettext yet and from what I
 > remember it lookes weird, at least the ruby binding did.  Maybe it's
 > very easy though.
 
 The l10n backend is an implementation detail.  If we really need to we
 can change backend later down the road if it is decoupled enough from
 the i18n of sup itself.  IMO you get to choose what we start with.
 And William gets to choose if he accepts the patches or not.  ;)
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 10:13:10 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 07:13:10 -0800
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257260315-sup-830@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> <1257163967-sup-5554@masanjin.net>
 	<1257256976-sup-1266@thinkpad-ubuntu>
 	<1257260315-sup-830@tilus.net>
 Message-ID: <1257261122-sup-5192@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-11-03:
 > IMO you get to choose what we start with.
 
 Yeah, Christopher has a working implementation of this already using
 yaml, and I'm happy to merge it if he changes the keys to strings as
 discussed.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 10:16:15 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 07:16:15 -0800
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <02055f053011496a2dcb9085b7e7535f@localhost>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 Message-ID: <1257261315-sup-977@masanjin.net>
 
 Reformatted excerpts from Mike Kelly's message of 2009-11-03:
 > As much as I hate to suggest it... RT should have all of these
 > qualities.
 
 Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
 (I've heard people complain about it before, but I don't remember any of
 the details.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From pioto@pioto.org  Tue Nov  3 10:34:24 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Tue, 03 Nov 2009 10:34:24 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257261315-sup-977@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 	<1257261315-sup-977@masanjin.net>
 Message-ID: <afd0a1d89ddee05080dcaf20f03bdefa@localhost>
 
 
 On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
 <wmorgan-sup at masanjin.net> wrote:
 > Reformatted excerpts from Mike Kelly's message of 2009-11-03:
 >> As much as I hate to suggest it... RT should have all of these
 >> qualities.
 > 
 > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
 > (I've heard people complain about it before, but I don't remember any of
 > the details.)
 
 Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one
 of those things which requires half of CPAN to work. So, it was annoying
 when I made an attempt to package it for a distro, but if you're just
 installing it following their directions, it's probably not that bad.
 
 But, someone is able to get away with charging $3250 a month for a
 "platinum" managed install of it. (Then again, some enterprises will pay
 anything for hosting...)
 
 Let me try a test install real quick, and I'll get back to you.
 
 -- 
 Mike Kelly
 
 From reid.thompson@ateb.com  Tue Nov  3 11:49:53 2009
 From: reid.thompson@ateb.com (Reid Thompson)
 Date: Tue, 3 Nov 2009 11:49:53 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <afd0a1d89ddee05080dcaf20f03bdefa@localhost>
 Message-ID: <20091103164953.GA20359@ateb.com>
 
 On Tue, Nov 03, 2009 at 10:34:24AM -0500, Mike Kelly wrote:
 > 
 > On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
 > <wmorgan-sup at masanjin.net> wrote:
 > > Reformatted excerpts from Mike Kelly's message of 2009-11-03:
 > >> As much as I hate to suggest it... RT should have all of these
 > >> qualities.
 > > 
 > > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
 > > (I've heard people complain about it before, but I don't remember any of
 > > the details.)
 > 
 > Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one
 > of those things which requires half of CPAN to work. So, it was annoying
 > when I made an attempt to package it for a distro, but if you're just
 > installing it following their directions, it's probably not that bad.
 > 
 > But, someone is able to get away with charging $3250 a month for a
 > "platinum" managed install of it. (Then again, some enterprises will pay
 > anything for hosting...)
 > 
 > Let me try a test install real quick, and I'll get back to you.
 
 I just started looking at it, so not sure if it fits all needs but
 fossil has a built in bugtracker
 
 http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
 
 
 
 From reid.thompson@ateb.com  Tue Nov  3 12:03:38 2009
 From: reid.thompson@ateb.com (Reid Thompson)
 Date: Tue, 3 Nov 2009 12:03:38 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <20091103164953.GA20359@ateb.com>
 References: <afd0a1d89ddee05080dcaf20f03bdefa@localhost>
 	<20091103164953.GA20359@ateb.com>
 Message-ID: <20091103170338.GC20359@ateb.com>
 
 On Tue, Nov 03, 2009 at 11:49:53AM -0500, Reid Thompson wrote:
 > On Tue, Nov 03, 2009 at 10:34:24AM -0500, Mike Kelly wrote:
 > > 
 > > On Tue, 03 Nov 2009 07:16:15 -0800, William Morgan
 > > <wmorgan-sup at masanjin.net> wrote:
 > > > Reformatted excerpts from Mike Kelly's message of 2009-11-03:
 > > >> As much as I hate to suggest it... RT should have all of these
 > > >> qualities.
 > > > 
 > > > Rrrrrrrrreally. Is it a pain to set up? Why do you hate to suggest it?
 > > > (I've heard people complain about it before, but I don't remember any of
 > > > the details.)
 > > 
 > > Yes, somewhat, IIRC. But, I haven't really ever had to set it up. It's one
 > > of those things which requires half of CPAN to work. So, it was annoying
 > > when I made an attempt to package it for a distro, but if you're just
 > > installing it following their directions, it's probably not that bad.
 > > 
 > > But, someone is able to get away with charging $3250 a month for a
 > > "platinum" managed install of it. (Then again, some enterprises will pay
 > > anything for hosting...)
 > > 
 > > Let me try a test install real quick, and I'll get back to you.
 > 
 > I just started looking at it, so not sure if it fits all needs but
 > fossil has a built in bugtracker
 > 
 > http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
 > 
 forgot to mention, it's developed by the same person as sqlite 
 
 From rlane@club.cc.cmu.edu  Tue Nov  3 11:12:11 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 03 Nov 2009 11:12:11 -0500
 Subject: [sup-talk] updated xapian experimental branch
 In-Reply-To: <1257237468-sup-5663@peray>
 References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net>
 	<1257196293-sup-6882@zyrg.net> <1257237468-sup-5663@peray>
 Message-ID: <1257263951-sup-6837@zyrg.net>
 
 Excerpts from Nicolas Pouillard's message of Tue Nov 03 03:39:48 -0500 2009:
 > What are non simple queries which would cause 'red X's to appear? My guess
 > is that since we cannot change other attributes than the labels, we can
 > statically know if the thread is still relevant without the label. No?
 
 is:inbox OR foo
 
 We have to use xapian to check relevance here because of the fulltext
 term 'foo'.
 
 From nicolas.pouillard@gmail.com  Tue Nov  3 11:15:23 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Tue, 03 Nov 2009 17:15:23 +0100
 Subject: [sup-talk] updated xapian experimental branch
 In-Reply-To: <1257263951-sup-6837@zyrg.net>
 References: <1257118189-sup-7392@zyrg.net> <1257163403-sup-9032@masanjin.net>
 	<1257196293-sup-6882@zyrg.net> <1257237468-sup-5663@peray>
 	<1257263951-sup-6837@zyrg.net>
 Message-ID: <1257264825-sup-7924@peray>
 
 Excerpts from Rich Lane's message of Tue Nov 03 17:12:11 +0100 2009:
 > Excerpts from Nicolas Pouillard's message of Tue Nov 03 03:39:48 -0500 2009:
 > > What are non simple queries which would cause 'red X's to appear? My guess
 > > is that since we cannot change other attributes than the labels, we can
 > > statically know if the thread is still relevant without the label. No?
 > 
 > is:inbox OR foo
 > 
 > We have to use xapian to check relevance here because of the fulltext
 > term 'foo'.
 
 Hum... Right. This is because we don't want to look into the fulltext of
 the threads we have... this does makes sense.
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From seschwar@googlemail.com  Tue Nov  3 11:20:47 2009
 From: seschwar@googlemail.com (Sebastian Schwarz)
 Date: Tue, 3 Nov 2009 17:20:47 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257261315-sup-977@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 	<1257261315-sup-977@masanjin.net>
 Message-ID: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 
 On 2009-11-03 at 07:16 -0800, William Morgan wrote:
 > Is it a pain to set up?
 
 I have never installed, administered or used RT before, but curiously
 digging around its homepage I found this:
 
 http://bestpractical.com/rt/features.html praises it as "Easy to
 install".  However on http://wiki.bestpractical.com/view/HomePage
 it says:
 
 > RT doesn't come with a formal, formatted users or administrators
 > guide, but it's likely most of what you need to know to use and run it
 > is contained somewhere within this wiki, so look around a little, be
 > patient... and try not to install RT on a Sunday night when you need
 > to run it in production on Monday: it's big, and learning how to set
 > it up can take some time.
 
 Can anyone with more experience with RT comment on this?
 
 Moreover I'd like to advertise/suggest [Roundup][1].  Apart form a slim
 web interface -- [here][2] Python's issue tracker as an example -- it
 also offers a fully functional [email interface][3], which allows --
 from what I understand -- creating, discussing and setting properties
 like status and labels of issues.
 
 As a note on the ease of installation: Roundup's [documentation on
 installation][4] begins with: "Set aside 15-30 minutes."  But again
 I have no personal experience to back this claim up.  Can anyone
 comment on this or Roundup in general?
 
 [1]: http://roundup.sourceforge.net/
 [2]: http://bugs.python.org/
 [3]: http://roundup.sourceforge.net/docs/user_guide.html#e-mail-gateway
 [4]: http://www.roundup-tracker.org/docs/installation.html#installation
 
 From mailinglist@flasht.de  Tue Nov  3 10:23:52 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Tue, 03 Nov 2009 16:23:52 +0100
 Subject: [sup-talk] i18n?
 In-Reply-To: <1257261122-sup-5192@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>
 	<1256280223-sup-736@tilus.net> <1257163967-sup-5554@masanjin.net>
 	<1257256976-sup-1266@thinkpad-ubuntu>
 	<1257260315-sup-830@tilus.net> <1257261122-sup-5192@masanjin.net>
 Message-ID: <1257261780-sup-4231@thinkpad-ubuntu>
 
 Excerpts from William Morgan's message of Di Nov 03 16:13:10 +0100 2009:
 > Reformatted excerpts from Tero Tilus's message of 2009-11-03:
 > > IMO you get to choose what we start with.
 > 
 > Yeah, Christopher has a working implementation of this already using
 > yaml, and I'm happy to merge it if he changes the keys to strings as
 > discussed.
 
 Alright, I'll change that then and tell you here when I'm done.
 -- 
 ================================
 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/20091103/9af3a0f4/attachment.bin>
 
 From mailinglist@flasht.de  Tue Nov  3 11:31:25 2009
 From: mailinglist@flasht.de (Christopher Bertels)
 Date: Tue, 03 Nov 2009 17:31:25 +0100
 Subject: [sup-talk] Completion for search queries
 In-Reply-To: <1257177490-sup-4126@masanjin.net>
 References: <1256199860-sup-4407@thinkpad-ubuntu>
 	<1257177490-sup-4126@masanjin.net>
 Message-ID: <1257265840-sup-9752@thinkpad-ubuntu>
 
 Excerpts from William Morgan's message of Mo Nov 02 16:58:45 +0100 2009:
 > Reformatted excerpts from Christopher Bertels's message of 2009-10-22:
 > > Anyone else who would like to have this feature in sup?
 > 
 > Sounds good to me. Probably wouldn't be too hard since we have a fairly
 > general tab-completion mechanism in place already.
 
 Cool, anyone who knows how & wants to implement this? ;)
 -- 
 ================================
 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/20091103/012a1929/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 12:16:32 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 09:16:32 -0800
 Subject: [sup-talk] [PATCH] detect and set charset on text/* attachments
 In-Reply-To: <1255961127-sup-3168@tihlde.org>
 References: <1255961127-sup-3168@tihlde.org>
 Message-ID: <1257264198-sup-8152@masanjin.net>
 
 Reformatted excerpts from Helge Titlestad's message of 2009-10-19:
 > 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/*.
 
 After reviewing the RFCs, yeah, I think you're basically right. The
 charset parameter is not required to be set for text/* mime types, but
 if it's unset, the part is assumed to be us-ascii.
 
 > Here's a patch that uses the chardet gem to (try to) detect the
 > appropriate charset and sets it in the Content-Type header.
 
 Although I don't relish adding yet another gem dependency, I think this
 is the right approach.
 
 It looks like the chardet gem is unmaintained. But someone decided to
 make their own special version called rchardet which is completely
 equivalent version but *is* maintained. (What is it with these goddamn
 ruby people.)
 
 I suggest we use rchardet instead of chardet. Would you like to change
 the patch? If not, I will get to it at some point.
 
 > Please tell me if I should use some different way of sending
 > patches... This git flow is a bit new to me. (=
 
 Nope, this is perfect. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 12:25:29 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 09:25:29 -0800
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 	<1257261315-sup-977@masanjin.net>
 	<20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 Message-ID: <1257268977-sup-4810@masanjin.net>
 
 Reformatted excerpts from Sebastian Schwarz's message of 2009-11-03:
 > Moreover I'd like to advertise/suggest [Roundup][1].  Apart form a slim
 > web interface -- [here][2] Python's issue tracker as an example -- it
 > also offers a fully functional [email interface][3], which allows --
 > from what I understand -- creating, discussing and setting properties
 > like status and labels of issues.
 
 Nicolas suggested this too. I tried installing it locally (late on a
 Sunday night, with a screaming infant in my ear) and couldn't get it to
 behave. But, bugs.python.org looks great, and it looks like they're using
 email to discuss and change issue state, which is awesome. I'll give it
 another shot.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 12:35:34 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 09:35:34 -0800
 Subject: [sup-talk] Completion for search queries
 In-Reply-To: <1257265840-sup-9752@thinkpad-ubuntu>
 References: <1256199860-sup-4407@thinkpad-ubuntu>
 	<1257177490-sup-4126@masanjin.net>
 	<1257265840-sup-9752@thinkpad-ubuntu>
 Message-ID: <1257269366-sup-159@masanjin.net>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-11-03:
 > Cool, anyone who knows how & wants to implement this? ;)
 
 If anyone is interested, I would suggest this approach: have each index
 (Ferret and Xapian) have a method that returns a list of query terms,
 and then look at how BufferManager#ask_many_emails_with_completions
 works, and implement something similar called ask_for_search_query or
 the like. Then have bin/sup circa line 275 call that instead of #ask.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From danfalcone@gmail.com  Tue Nov  3 12:37:22 2009
 From: danfalcone@gmail.com (Dan Falcone)
 Date: Tue, 3 Nov 2009 13:37:22 -0400
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257268977-sup-4810@masanjin.net>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 	<1257261315-sup-977@masanjin.net>
 	<20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 	<1257268977-sup-4810@masanjin.net>
 Message-ID: <ed5557340911030937u7f36b4e7p21415f532aac395d@mail.gmail.com>
 
 Hi all,
 
 Thought I'd chime in regarding RT.  I've never configured it, but we use it
 internally where I work, so I can comment on it from a user perspective.  I
 mainly use the email interface, which is very finicky.  If you include
 attachments that are too large, RT will ignore your message and will not
 attach it to an existing ticket or open a new ticket.  Our instance is well
 known to modify attachments (changing the md5sums), which causes all kinds
 of problems for us.  Maybe this part is user error, but it also sends 2
 copies of every message and doesn't always CC everyone on the ticket when it
 is supposed to.  So you either get 2 copies of each email, or zero.  Either
 way it sucks. We have lots of processes in place to work around the issues
 RT creates for us.  Basically the only reason we use it is for archival
 purposes.
 
 Again, I did not install and do not administer this instance, so there could
 be configuration issues or possibly newer versions that address these
 shortcomings.  However, given my past experience, I wouldn't recommend it.
 
 -Dan
 
 On Tue, Nov 3, 2009 at 1:25 PM, William Morgan <wmorgan-sup at masanjin.net>wrote:
 
 > Reformatted excerpts from Sebastian Schwarz's message of 2009-11-03:
 > > Moreover I'd like to advertise/suggest [Roundup][1].  Apart form a slim
 > > web interface -- [here][2] Python's issue tracker as an example -- it
 > > also offers a fully functional [email interface][3], which allows --
 > > from what I understand -- creating, discussing and setting properties
 > > like status and labels of issues.
 >
 > Nicolas suggested this too. I tried installing it locally (late on a
 > Sunday night, with a screaming infant in my ear) and couldn't get it to
 > behave. But, bugs.python.org looks great, and it looks like they're using
 > email to discuss and change issue state, which is awesome. I'll give it
 > another shot.
 > --
 > William <wmorgan-sup at masanjin.net>
 > _______________________________________________
 > sup-talk mailing list
 > sup-talk at rubyforge.org
 > http://rubyforge.org/mailman/listinfo/sup-talk
 >
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091103/2c2cb645/attachment.html>
 
 From daemianmack@gmail.com  Tue Nov  3 12:03:38 2009
 From: daemianmack@gmail.com (Daemian Mack)
 Date: Tue, 03 Nov 2009 12:03:38 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 	<1257261315-sup-977@masanjin.net>
 	<20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 Message-ID: <1257266599-sup-1535@lenin>
 
 Excerpts from Sebastian Schwarz's message of Tue Nov 03 11:20:47 -0500 2009:
 > > RT doesn't come with a formal, formatted users or administrators
 > > guide, but it's likely most of what you need to know to use and run it
 > > is contained somewhere within this wiki, so look around a little, be
 > > patient... and try not to install RT on a Sunday night when you need
 > > to run it in production on Monday: it's big, and learning how to set
 > > it up can take some time.
 > 
 > Can anyone with more experience with RT comment on this?
 
 Having evaluated RT3 for fairly-intense production use at a prior
 job, I can't really say I'd recommend it for our use here. As an
 'enterprise-ready' solution, it's a bit ungainly out of the box, and
 the bulk of its feature-set would probably be overkill for sup's
 needs. It makes heavy use of the 'departmental queue' model whereby
 many departments, consisting each of many employees, have some
 permission set for many queues. Customization was a bit opaque (though
 perhaps less so if you're very familiar with Perl), and though there's
 an O'Reilly book for RT, I found it often fell short of my needs.
 
 I'd suspect, with the glut of ticket-tracker software available,
 there's something a good deal better-suited for sup out there. I'll
 chime in again if I manage to find something that seems helpful.
 -- 
 http://daemianmack.com/
 
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 13:04:26 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 10:04:26 -0800
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <20091103164953.GA20359@ateb.com>
 References: <afd0a1d89ddee05080dcaf20f03bdefa@localhost>
 	<20091103164953.GA20359@ateb.com>
 Message-ID: <1257271383-sup-3116@masanjin.net>
 
 Reformatted excerpts from Reid Thompson's message of 2009-11-03:
 > I just started looking at it, so not sure if it fits all needs but
 > fossil has a built in bugtracker
 > 
 > http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki
 
 Is it possible to use the bug tracker without keeping all the code in
 Fossil itself? My impression is no.  I'm very happy with git and
 changing development to a brand new SCM is extremely unlikely to happen
 at this point.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From pioto@pioto.org  Tue Nov  3 13:06:52 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Tue, 03 Nov 2009 13:06:52 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257266599-sup-1535@lenin>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 	<1257261315-sup-977@masanjin.net>
 	<20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 	<1257266599-sup-1535@lenin>
 Message-ID: <3e1dd7cf334013e45e4e161e3ff512a4@localhost>
 
 
 On Tue, 03 Nov 2009 12:03:38 -0500, Daemian Mack <daemianmack at gmail.com>
 wrote:
 > Having evaluated RT3 for fairly-intense production use at a prior
 > job, I can't really say I'd recommend it for our use here.
 > 
 > I'd suspect, with the glut of ticket-tracker software available,
 > there's something a good deal better-suited for sup out there. I'll
 > chime in again if I manage to find something that seems helpful.
 
 Yes, feel free to ignore me. It's a pain in the butt to get going. :p
 
 On the hopefully-less-sucky front, there's Bugzilla. There is apparently a
 plugin for it that lets you reply to tickets by email, but I haven't set it
 up myself.
 
 But, I'm a perl guy, so I'm likely highly biased... :)
 
 -- 
 Mike Kelly
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 13:14:37 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 10:14:37 -0800
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <1257146774-sup-9810@tilus.net>
 References: <1256997213-sup-2725@masanjin.net> <1257146774-sup-9810@tilus.net>
 Message-ID: <1257272059-sup-9800@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-11-01:
 > Congratulations!  Take your time.  Your family needs it now.
 > 
 > I've got two lovely kids, having the first one is a very special
 > thing.
 
 Thanks guys. It's been great so far.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From tero@tilus.net  Tue Nov  3 13:33:04 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Tue, 03 Nov 2009 20:33:04 +0200
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 References: <1257111816-sup-4397@peray> <1257169654-sup-6224@masanjin.net>
 	<02055f053011496a2dcb9085b7e7535f@localhost>
 	<1257261315-sup-977@masanjin.net>
 	<20091103162047.GD2963@pineapple.q.wohnheim-jahnplatz.de>
 Message-ID: <1257272880-sup-941@tilus.net>
 
 Sebastian Schwarz, 2009-11-03 18:20:
 > Moreover I'd like to advertise/suggest [Roundup][1].
 
 Now that you mention it, I've used it in couple of projects and liked
 very much.
 
 > As a note on the ease of installation: Roundup's [documentation on
 > installation][4] begins with: "Set aside 15-30 minutes."  But again
 > I have no personal experience to back this claim up.  Can anyone
 > comment on this or Roundup in general?
 
 I've set it up once long time ago and I don't remember anything about
 it really.  Installation was fluent I guess.  ;)
 
 Another one I like is Redmine, but its whole a lot different kind of
 tool, nice and fluent tho.  It also might do pretty much what we want,
 but I'd guess Roundup does it with less tuning and pluginnig.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From wmorgan-sup@masanjin.net  Tue Nov  3 14:00:39 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 03 Nov 2009 11:00:39 -0800
 Subject: [sup-talk] new list: sup-devel
 Message-ID: <1257272092-sup-9031@masanjin.net>
 
 Hi all,
 
 I've created a new list for Sup developer discussion. This has been
 requested a couple times, and I finally think the traffic level warrants
 it.
 
 If you're interested, please subscribe here:
 
   http://rubyforge.org/mailman/listinfo/sup-devel
 
 I'm not going to be too strict about it, and we can finish up the bug
 tracker conversation here, but I would like sup-talk to eventually be a
 place for user questions and discussions, and for future conversations
 about code, bugs, bug trackers, etc to talk place over there.
 
 I'm going to change the bug report email address in 0.9.1 to sup-devel
 as well. (And hopefully to a URL in 0.10.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From helgedt@tihlde.org  Tue Nov  3 14:23:28 2009
 From: helgedt@tihlde.org (Helge Titlestad)
 Date: Tue, 03 Nov 2009 20:23:28 +0100
 Subject: [sup-talk] [PATCH] detect and set charset on text/* attachments
 In-Reply-To: <1257264198-sup-8152@masanjin.net>
 References: <1255961127-sup-3168@tihlde.org> <1257264198-sup-8152@masanjin.net>
 Message-ID: <1257275607-sup-583@tihlde.org>
 
 Excerpts from William Morgan's message of Tue Nov 03 18:16:32 +0100 2009:
 > It looks like the chardet gem is unmaintained. But someone decided to
 > make their own special version called rchardet which is completely
 > equivalent version but *is* maintained. 
 > 
 > I suggest we use rchardet instead of chardet. Would you like to change
 > the patch? If not, I will get to it at some point.
 
 Here you go!
 
 One thing I noticed when trying it out: It will set charset 'ascii' for ascii
 text, which is allowed by the RFC but "US-ASCII" is preferred. I think I prefer
 to not create a special case in the code to change it to US-ASCII or remove the
 charset for ascii text, but other people might disagree.
 -- 
 alge
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Detect-charset-for-text-file-attachments.patch
 Type: application/octet-stream
 Size: 1919 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091103/bcbaa6d8/attachment.obj>
 
 From reid.thompson@ateb.com  Tue Nov  3 14:30:23 2009
 From: reid.thompson@ateb.com (Reid Thompson)
 Date: Tue, 03 Nov 2009 14:30:23 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257271383-sup-3116@masanjin.net>
 References: <afd0a1d89ddee05080dcaf20f03bdefa@localhost>
 	<20091103164953.GA20359@ateb.com>  <1257271383-sup-3116@masanjin.net>
 Message-ID: <1257276623.6780.4.camel@raker.ateb.com>
 
 On Tue, 2009-11-03 at 10:04 -0800, William Morgan wrote:
 > Is it possible to use the bug tracker without keeping all the code in
 > Fossil itself? 
 
 I just created an empty repository.  Contains no source code files.
 
 $ fossil new bugtracker-only
 $ fossil open bugtracker-only
 $ ls -rlt /tmp/bugtracker-only 
 -rw-r--r-- 1 rthompso staff 50176 2009-11-03 14:23 /tmp/bugtracker-only
 
 $ fossil ui
 
 did minimal admin/config -> http://localhost:8080/setup_config
 then added tickets etc, looks like the data entry is free-form, so not
 tied to a source version existing etc.
 
 attached png.
 
 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: TestBugTrackerOnly.png
 Type: image/png
 Size: 127986 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091103/fc6d6f50/attachment-0001.png>
 
 From jim@gonzul.net  Tue Nov  3 18:11:31 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Wed, 4 Nov 2009 12:11:31 +1300
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257111816-sup-4397@peray>
 References: <1257111816-sup-4397@peray>
 Message-ID: <f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 
 On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard
 <nicolas.pouillard at gmail.com> wrote:
 > I would like to discuss more the issue of choosing a bug tracker for sup.
 
 Having had a quick read of this thread, I think that trac
 (http://trac.edgewall.com) would meet your goals.
 
 It's a simple single-project combination of wiki, ticketing engine and
 repository browser. Tickets can be received by email, ticket updates
 can be emailed to a set of interested subscribers, and checkins to the
 repository can close tickets (via simple hooks). The wiki markup
 provides simple access to changes, tickets & files.
 
 -jim
 
 From pioto@pioto.org  Tue Nov  3 19:07:24 2009
 From: pioto@pioto.org (Mike Kelly)
 Date: Tue, 3 Nov 2009 19:07:24 -0500
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 References: <1257111816-sup-4397@peray>
 	<f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 Message-ID: <20091103190724.1dd5d891@aether.home.pioto.org>
 
 On Wed, 4 Nov 2009 12:11:31 +1300
 Jim Cheetham <jim at gonzul.net> wrote:
 
 > On Mon, Nov 2, 2009 at 10:52 AM, Nicolas Pouillard
 > <nicolas.pouillard at gmail.com> wrote:
 > > I would like to discuss more the issue of choosing a bug tracker
 > > for sup.
 > 
 > Having had a quick read of this thread, I think that trac
 > (http://trac.edgewall.com) would meet your goals.
 > 
 > It's a simple single-project combination of wiki, ticketing engine and
 > repository browser. Tickets can be received by email, ticket updates
 > can be emailed to a set of interested subscribers, and checkins to the
 > repository can close tickets (via simple hooks). The wiki markup
 > provides simple access to changes, tickets & files.
 
 Trac doesn't really allow you to reply to tickets by email. At least,
 not with any plugin that I've used.
 
 Also, I've used trac for years for another project, and I wouldn't
 recommend it. (It's been a memory hog, among other things).
 
 -- 
 Mike Kelly
 
 From pi+sup@pihost.us  Tue Nov  3 22:05:19 2009
 From: pi+sup@pihost.us (Anthony Martinez)
 Date: Tue,  3 Nov 2009 20:05:19 -0700
 Subject: [sup-talk] [PATCH] If we have a COLUMNS environment variable,
 	wrap to that instead of 80.
 Message-ID: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 
 From: Anthony Martinez <pi at pihost.us>
 
 I find that this provides a much smoother terminal experience,
 especially with dumped HTML output. At least on Linux+zsh, this
 environment variable is automatically updated, and if it doesn't exist,
 sup will continue to happily default to 80.
 ---
  lib/sup/message-chunks.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
 index 581b707..881ac4b 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -41,7 +41,7 @@ end
  
  module Redwood
  module Chunk
 -  WRAP_LEN = 80 # wrap messages and text attachments at this width
 +  WRAP_LEN = ENV["COLUMNS"] || 80 # wrap messages and text attachments at this width
  
    class Attachment
      HookManager.register "mime-decode", <<EOS
 -- 
 1.6.5
 
 
 From pi+sup@pihost.us  Tue Nov  3 22:22:24 2009
 From: pi+sup@pihost.us (Anthony Martinez)
 Date: Tue, 03 Nov 2009 20:22:24 -0700
 Subject: [sup-talk] [PATCH] If we have a COLUMNS environment variable,
 	wrap to that instead of 80.
 In-Reply-To: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 Message-ID: <1257304795-sup-5302@home.mrtheplague.net>
 
 Excerpts from Anthony Martinez's message of Tue Nov 03 20:05:19 -0700 2009:
 > I find that this provides a much smoother terminal experience,
 Or it would if I tested it. Sorry about the bad patch, seems today isn't my day.
 :)
 
 Either way, I'd like to see something like this. Discussion?
 
 From pi+sup@pihost.us  Tue Nov  3 22:51:46 2009
 From: pi+sup@pihost.us (Anthony Martinez)
 Date: Tue, 03 Nov 2009 20:51:46 -0700
 Subject: [sup-talk] [CORRECTED PATCH] If we can get the terminal width,
 	use that for WRAP_LEN.
 In-Reply-To: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 Message-ID: <1257306460-sup-1506@home.mrtheplague.net>
 
 I find that this provides a much smoother terminal experience,
 especially with elinks configured to dump to the same size in hook
 scripts.
 
 At least on Linux, "stty size"'s second numerical output is the number
 of columns, and if that fails somehow, sup will continue to happily
 default to 80.
 ---
  lib/sup/message-chunks.rb |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
 index 581b707..56ddf1e 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -41,7 +41,8 @@ end
 
  module Redwood
  module Chunk
 -  WRAP_LEN = 80 # wrap messages and text attachments at this width
 +  TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails.
 +  WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width
 
    class Attachment
      HookManager.register "mime-decode", <<EOS
 
 From tero@tilus.net  Wed Nov  4 00:48:51 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Wed, 04 Nov 2009 07:48:51 +0200
 Subject: [sup-talk] [PATCH] If we have a COLUMNS environment variable,
 	wrap to that instead of 80.
 In-Reply-To: <1257304795-sup-5302@home.mrtheplague.net>
 References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 	<1257304795-sup-5302@home.mrtheplague.net>
 Message-ID: <1257313462-sup-7125@tilus.net>
 
 Anthony Martinez, 2009-11-04 05:22:
 > Either way, I'd like to see something like this. Discussion?
 
 Dunno why, but I myself rarely use terms wider (or narrower) than 80
 chars.  This could be nice for people who do.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From michael+sup@stapelberg.de  Wed Nov  4 04:38:20 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Wed, 04 Nov 2009 10:38:20 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <20091103190724.1dd5d891@aether.home.pioto.org>
 References: <1257111816-sup-4397@peray>
 	<f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 	<20091103190724.1dd5d891@aether.home.pioto.org>
 Message-ID: <1257327410-sup-3421@midna.zekjur.net>
 
 Hi,
 
 Excerpts from Mike Kelly's message of Mi Nov 04 01:07:24 +0100 2009:
 > Also, I've used trac for years for another project, and I wouldn't
 > recommend it. (It's been a memory hog, among other things).
 I?ve also used trac for quite some time now and I don?t recommend it
 either. As soon as the spammers find your website, problems start. trac
 has no built-in possibility to delete a comment/ticket, nor do any of
 the anti-spam plugins work as they should (either they don?t recognize
 spam, they have false-positives or they are totally cumbersome for the
 user).
 
 Best regards,
 Michael
 
 From isra@herraiz.org  Wed Nov  4 04:44:02 2009
 From: isra@herraiz.org (Israel Herraiz)
 Date: Wed, 04 Nov 2009 10:44:02 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257327410-sup-3421@midna.zekjur.net>
 References: <1257111816-sup-4397@peray>
 	<f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 	<20091103190724.1dd5d891@aether.home.pioto.org>
 	<1257327410-sup-3421@midna.zekjur.net>
 Message-ID: <1257327692-sup-7174@elly>
 
 Excerpts from Michael Stapelberg's message of Wed Nov 04 10:38:20 +0100 2009:
 > I?ve also used trac for quite some time now and I don?t recommend it
 > either. As soon as the spammers find your website, problems start. trac
 > has no built-in possibility to delete a comment/ticket, nor do any of
 > the anti-spam plugins work as they should (either they don?t recognize
 > spam, they have false-positives or they are totally cumbersome for the
 > user).
 
 I am not going to recommend Trac, because it does not fulfill the
 requirements listed by William, but that thing you say is simply not
 true.
 
 I have been using Trac since a couple of years now, and it is sensible
 to spam, ok, but you can always delete comments, tickets, or anything
 in general, and force people to register to post comments or tickets,
 to fight against spam.
 
 Cheers,
 Israel
 
 From michael+sup@stapelberg.de  Wed Nov  4 05:00:43 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Wed, 04 Nov 2009 11:00:43 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257327692-sup-7174@elly>
 References: <1257111816-sup-4397@peray>
 	<f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 	<20091103190724.1dd5d891@aether.home.pioto.org>
 	<1257327410-sup-3421@midna.zekjur.net> <1257327692-sup-7174@elly>
 Message-ID: <1257328487-sup-8593@midna.zekjur.net>
 
 Hi,
 
 Excerpts from Israel Herraiz's message of Mi Nov 04 10:44:02 +0100 2009:
 > I have been using Trac since a couple of years now, and it is sensible
 > to spam, ok, but you can always delete comments, tickets, or anything
 I am referring to trac 0.11.5, which does not have a possibility to delete
 comments or tickets without installing a third-party plugin (which is
 hard to use because you have to use ticket IDs). If I am wrong, please tell me
 where they hid the possibility, so I don?t need the plugin anymore.
 
 > in general, and force people to register to post comments or tickets,
 > to fight against spam.
 I consider forcing people to register to post comments/tickets as the end of
 bug reports for my project. I personally would only register at a bugtracker if
 the bug was *really* important and there would be *no* other possibility to
 contact the author of the software. However, I want to get every bugreport for
 my software and thus lower the requirements for users to actually help me
 improve my software by submitting bugreports.
 
 Best regards,
 Michael
 
 From isra@herraiz.org  Wed Nov  4 05:05:45 2009
 From: isra@herraiz.org (Israel Herraiz)
 Date: Wed, 04 Nov 2009 11:05:45 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257328487-sup-8593@midna.zekjur.net>
 References: <1257111816-sup-4397@peray>
 	<f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 	<20091103190724.1dd5d891@aether.home.pioto.org>
 	<1257327410-sup-3421@midna.zekjur.net> <1257327692-sup-7174@elly>
 	<1257328487-sup-8593@midna.zekjur.net>
 Message-ID: <1257328897-sup-4720@elly>
 
 Excerpts from Michael Stapelberg's message of Wed Nov 04 11:00:43 +0100 2009:
 > I am referring to trac 0.11.5, which does not have a possibility to delete
 > comments or tickets without installing a third-party plugin (which is
 > hard to use because you have to use ticket IDs). If I am wrong, please tell me
 > where they hid the possibility, so I don?t need the plugin anymore.
 
 Check the *_ADMIN permissions. Any user with say TICKET_ADMIN
 permission can remove tickets. Same applies to WIKI_ADMIN (remove wiki
 pages), etc.
 
 > I consider forcing people to register to post comments/tickets as the end of
 > bug reports for my project. I personally would only register at a bugtracker if
 > the bug was *really* important and there would be *no* other possibility to
 > contact the author of the software. However, I want to get every bugreport for
 > my software and thus lower the requirements for users to actually help me
 > improve my software by submitting bugreports.
 
 Right. It is not the best elegant solution at all.
 
 Cheers,
 Israel
 
 From marka@pobox.com  Wed Nov  4 14:06:01 2009
 From: marka@pobox.com (Mark Alexander)
 Date: Wed, 04 Nov 2009 14:06:01 -0500
 Subject: [sup-talk] [PATCH] If we have a COLUMNS environment variable,
 	wrap to that instead of 80.
 In-Reply-To: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us>
 Message-ID: <1257361498-sup-7950@r50p>
 
 Excerpts from Anthony Martinez's message of Tue Nov 03 22:05:19 -0500 2009:
 > +  WRAP_LEN = ENV["COLUMNS"] || 80 # wrap messages and text attachments at this width
 
 How about using Ncurses.cols?  That's what I did in a similar patch on
 my copy of sup.
 
 From isra@herraiz.org  Wed Nov  4 18:40:22 2009
 From: isra@herraiz.org (Israel Herraiz)
 Date: Thu, 05 Nov 2009 00:40:22 +0100
 Subject: [sup-talk] Choosing a bug tracker for Sup
 In-Reply-To: <1257328897-sup-4720@elly>
 References: <1257111816-sup-4397@peray>
 	<f4cc59760911031511m7f99a4bck4d9b31f4aa7704e2@mail.gmail.com>
 	<20091103190724.1dd5d891@aether.home.pioto.org>
 	<1257327410-sup-3421@midna.zekjur.net> <1257327692-sup-7174@elly>
 	<1257328487-sup-8593@midna.zekjur.net> <1257328897-sup-4720@elly>
 Message-ID: <1257377988-sup-7526@elly>
 
 Excerpts from Israel Herraiz's message of Wed Nov 04 11:05:45 +0100 2009:
 > Check the *_ADMIN permissions. Any user with say TICKET_ADMIN
 > permission can remove tickets. Same applies to WIKI_ADMIN (remove wiki
 > pages), etc.
 
 I am afraid I am wrong with this. Tickets can only be deleted by
 manipulating the database. So Michael was right.
 
 Sorry for the noise.
 
 Israel
 
 From rlane@club.cc.cmu.edu  Thu Nov  5 00:45:18 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed,  4 Nov 2009 21:45:18 -0800
 Subject: [sup-talk] [PATCH 1/4] factor saving out of thread/message classes
 Message-ID: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/index.rb                   |    7 +++++++
  lib/sup/message.rb                 |    5 +----
  lib/sup/modes/thread-index-mode.rb |    2 +-
  lib/sup/thread.rb                  |    2 +-
  4 files changed, 10 insertions(+), 6 deletions(-)
 
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index ff03f19..5d8d714 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -172,6 +172,13 @@ class BaseIndex
    def parse_query s
      unimplemented
    end
 +
 +  def save_thread t
 +    t.each_dirty_message do |m|
 +      update_message_state m 
 +      m.clear_dirty
 +    end
 +  end
  end
  
  index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index a147c42..95ae050 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -182,11 +182,8 @@ class Message
    ## don't tempt me.
    def sanitize_message_id mid; mid.gsub(/(\s|[^\000-\177])+/, "")[0..254] end
  
 -  def save_state index
 -    return unless @dirty
 -    index.update_message_state self
 +  def clear_dirty
      @dirty = false
 -    true
    end
  
    def has_label? t; @labels.member? t; end
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index 12a76f9..370903a 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -477,7 +477,7 @@ EOS
        BufferManager.say("Saving threads...") do |say_id|
          dirty_threads.each_with_index do |t, i|
            BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id
 -          t.save_state Index
 +          Index.save_thread t
          end
        end
      end
 diff --git a/lib/sup/thread.rb b/lib/sup/thread.rb
 index 2300305..3fdf1f6 100644
 --- a/lib/sup/thread.rb
 +++ b/lib/sup/thread.rb
 @@ -112,7 +112,7 @@ class Thread
  
    def set_labels l; each { |m, *o| m && m.labels = l }; end
    def has_label? t; any? { |m, *o| m && m.has_label?(t) }; end
 -  def save_state index; each { |m, *o| m && m.save_state(index) }; end
 +  def each_dirty_message; each { |m, *o| m && m.dirty? && yield(m) }; end
  
    def direct_participants
      map { |m, *o| [m.from] + m.to if m }.flatten.compact.uniq
 -- 
 1.6.4.2
 
 
 From rlane@club.cc.cmu.edu  Thu Nov  5 00:45:19 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed,  4 Nov 2009 21:45:19 -0800
 Subject: [sup-talk] [PATCH 2/4] async thread indexing
 In-Reply-To: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup                            |    2 ++
  lib/sup/index.rb                   |   26 +++++++++++++++++++++++++-
  lib/sup/modes/thread-index-mode.rb |    2 +-
  3 files changed, 28 insertions(+), 2 deletions(-)
 
 diff --git a/bin/sup b/bin/sup
 index 78c396a..910ff12 100755
 --- a/bin/sup
 +++ b/bin/sup
 @@ -142,6 +142,7 @@ Index.lock_interactively or exit
  begin
    Redwood::start
    Index.load
 +  Index.start_sync_worker unless $opts[:no_threads]
  
    $die = false
    trap("TERM") { |x| $die = true }
 @@ -335,6 +336,7 @@ ensure
  
    HookManager.run "shutdown"
  
 +  Index.stop_sync_worker
    Redwood::finish
    stop_cursing
    Redwood::Logger.remove_all_sinks!
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 5d8d714..1131ec7 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -28,6 +28,8 @@ class BaseIndex
    def initialize dir=BASE_DIR
      @dir = dir
      @lock = Lockfile.new lockfile, :retries => 0, :max_age => nil
 +    @sync_worker = nil
 +    @sync_queue = Queue.new
    end
  
    def lockfile; File.join @dir, "lock" end
 @@ -175,10 +177,32 @@ class BaseIndex
  
    def save_thread t
      t.each_dirty_message do |m|
 -      update_message_state m 
 +      if @sync_worker
 +        @sync_queue << m
 +      else
 +        update_message_state m
 +      end
        m.clear_dirty
      end
    end
 +
 +  def start_sync_worker
 +    @sync_worker = Redwood::reporting_thread('index sync') { run_sync_worker }
 +  end
 +
 +  def stop_sync_worker
 +    return unless worker = @sync_worker
 +    @sync_worker = nil
 +    @sync_queue << :die
 +    worker.join
 +  end
 +
 +  def run_sync_worker
 +    while m = @sync_queue.deq
 +      return if m == :die
 +      update_message_state m
 +    end
 +  end
  end
  
  index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index 370903a..d2b1651 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -477,7 +477,7 @@ EOS
        BufferManager.say("Saving threads...") do |say_id|
          dirty_threads.each_with_index do |t, i|
            BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id
 -          Index.save_thread t
 +          Index.save_thread_async t
          end
        end
      end
 -- 
 1.6.4.2
 
 
 From rlane@club.cc.cmu.edu  Thu Nov  5 00:45:20 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed,  4 Nov 2009 21:45:20 -0800
 Subject: [sup-talk] [PATCH 3/4] immediate thread indexing
 In-Reply-To: <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu>
 References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1257399921-26813-3-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/modes/inbox-mode.rb        |    4 +++
  lib/sup/modes/thread-index-mode.rb |   40 +++++++++++++----------------------
  lib/sup/modes/thread-view-mode.rb  |    7 ++++++
  3 files changed, 26 insertions(+), 25 deletions(-)
 
 diff --git a/lib/sup/modes/inbox-mode.rb b/lib/sup/modes/inbox-mode.rb
 index 6c2244a..ad3a864 100644
 --- a/lib/sup/modes/inbox-mode.rb
 +++ b/lib/sup/modes/inbox-mode.rb
 @@ -42,6 +42,7 @@ class InboxMode < ThreadIndexMode
      cursor_thread.remove_label :inbox
      hide_thread cursor_thread
      regen_text
 +    Index.save_thread thread
    end
  
    def multi_archive threads
 @@ -58,6 +59,7 @@ class InboxMode < ThreadIndexMode
        hide_thread t
      end
      regen_text
 +    threads.each { |t| Index.save_thread t }
    end
  
    def read_and_archive
 @@ -74,6 +76,7 @@ class InboxMode < ThreadIndexMode
      cursor_thread.remove_label :inbox
      hide_thread cursor_thread
      regen_text
 +    Index.save_thread thread
    end
  
    def multi_read_and_archive threads
 @@ -94,6 +97,7 @@ class InboxMode < ThreadIndexMode
        regen_text
      end
  
 +    threads.each { |t| Index.save_thread t }
    end
  
    def handle_unarchived_update sender, m
 diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 index d2b1651..bf3f646 100644
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -37,7 +37,6 @@ EOS
      k.add :toggle_spam, "Mark/unmark thread as spam", 'S'
      k.add :toggle_deleted, "Delete/undelete thread", 'd'
      k.add :kill, "Kill thread (never to be seen in inbox again)", '&'
 -    k.add :save, "Save changes now", '$'
      k.add :jump_to_next_new, "Jump to next new thread", :tab
      k.add :reply, "Reply to latest message in a thread", 'r'
      k.add :reply_all, "Reply to all participants of the latest message in a thread", 'G'
 @@ -269,12 +268,14 @@ EOS
      UndoManager.register "toggling thread starred status", undo
      update_text_for_line curpos
      cursor_down
 +    Index.save_thread t
    end
  
    def multi_toggle_starred threads
      UndoManager.register "toggling #{threads.size.pluralize 'thread'} starred status",
        threads.map { |t| actually_toggle_starred t }
      regen_text
 +    threads.each { |t| Index.save_thread t }
    end
  
    ## returns an undo lambda
 @@ -352,12 +353,14 @@ EOS
      undo = actually_toggle_archived t
      UndoManager.register "deleting/undeleting thread #{t.first.id}", undo, lambda { update_text_for_line curpos }
      update_text_for_line curpos
 +    Index.save_thread t
    end
  
    def multi_toggle_archived threads
      undos = threads.map { |t| actually_toggle_archived t }
      UndoManager.register "deleting/undeleting #{threads.size.pluralize 'thread'}", undos, lambda { regen_text }
      regen_text
 +    threads.each { |t| Index.save_thread t }
    end
  
    def toggle_new
 @@ -365,11 +368,13 @@ EOS
      t.toggle_label :unread
      update_text_for_line curpos
      cursor_down
 +    Index.save_thread t
    end
  
    def multi_toggle_new threads
      threads.each { |t| t.toggle_label :unread }
      regen_text
 +    threads.each { |t| Index.save_thread t }
    end
  
    def multi_toggle_tagged threads
 @@ -385,6 +390,7 @@ EOS
  
    def multi_join_threads threads
      @ts.join_threads threads or return
 +    threads.each { |t| Index.save_thread t }
      @tags.drop_all_tags # otherwise we have tag pointers to invalid threads!
      update
    end
 @@ -421,6 +427,7 @@ EOS
      UndoManager.register "marking/unmarking  #{threads.size.pluralize 'thread'} as spam",
                           undos, lambda { regen_text }
      regen_text
 +    threads.each { Index.save_thread async t }
    end
  
    def toggle_deleted
 @@ -434,6 +441,7 @@ EOS
      UndoManager.register "deleting/undeleting #{threads.size.pluralize 'thread'}",
                           undos, lambda { regen_text }
      regen_text
 +    threads.each { Index.save_thread async t }
    end
  
    def kill
 @@ -458,29 +466,7 @@ EOS
  
      regen_text
      BufferManager.flash "#{threads.size.pluralize 'thread'} killed."
 -  end
 -
 -  def save background=true
 -    if background
 -      Redwood::reporting_thread("saving thread") { actually_save }
 -    else
 -      actually_save
 -    end
 -  end
 -
 -  def actually_save
 -    @save_thread_mutex.synchronize do
 -      BufferManager.say("Saving contacts...") { ContactManager.instance.save }
 -      dirty_threads = @mutex.synchronize { (@threads + @hidden_threads.keys).select { |t| t.dirty? } }
 -      next if dirty_threads.empty?
 -
 -      BufferManager.say("Saving threads...") do |say_id|
 -        dirty_threads.each_with_index do |t, i|
 -          BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id
 -          Index.save_thread_async t
 -        end
 -      end
 -    end
 +    threads.each { |t| Index.save_thread async t }
    end
  
    def cleanup
 @@ -492,7 +478,8 @@ EOS
        sleep 0.1 # TODO: necessary?
        BufferManager.erase_flash
      end
 -    save false
 +    dirty_threads = @mutex.synchronize { (@threads + @hidden_threads.keys).select { |t| t.dirty? } }
 +    fail "dirty threads remain" unless dirty_threads.empty?
      super
    end
  
 @@ -546,6 +533,7 @@ EOS
      end
  
      UpdateManager.relay self, :labeled, thread.first
 +    Index.save_thread thread
    end
  
    def multi_edit_labels threads
 @@ -582,6 +570,8 @@ EOS
        end
        regen_text
      end
 +    
 +    threads.each { |t| Index.save_thread t }
    end
  
    def reply type_arg=nil
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 2da0555..e59112e 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -132,6 +132,7 @@ EOS
      @layout[earliest].state = :detailed if earliest.has_label?(:unread) || @thread.size == 1
  
      @thread.remove_label :unread
 +    Index.save_thread @thread
      regen_text
    end
  
 @@ -263,6 +264,7 @@ EOS
      new_labels.each { |l| LabelManager << l }
      update
      UpdateManager.relay self, :labeled, @thread.first
 +    Index.save_thread @thread
    end
  
    def toggle_starred
 @@ -285,6 +287,7 @@ EOS
      ## star to the display
      update
      UpdateManager.relay self, :single_message_labeled, m
 +    Index.save_thread @thread
    end
  
    ## called when someone presses enter when the cursor is highlighting
 @@ -503,6 +506,7 @@ EOS
      dispatch op do
        @thread.remove_label :inbox
        UpdateManager.relay self, :archived, @thread.first
 +      Index.save_thread @thread
      end
    end
  
 @@ -510,6 +514,7 @@ EOS
      dispatch op do
        @thread.apply_label :spam
        UpdateManager.relay self, :spammed, @thread.first
 +      Index.save_thread @thread
      end
    end
  
 @@ -517,6 +522,7 @@ EOS
      dispatch op do
        @thread.apply_label :deleted
        UpdateManager.relay self, :deleted, @thread.first
 +      Index.save_thread @thread
      end
    end
  
 @@ -524,6 +530,7 @@ EOS
      dispatch op do
        @thread.apply_label :unread
        UpdateManager.relay self, :unread, @thread.first
 +      Index.save_thread @thread
      end
    end
  
 -- 
 1.6.4.2
 
 
 From rlane@club.cc.cmu.edu  Thu Nov  5 00:45:21 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed,  4 Nov 2009 21:45:21 -0800
 Subject: [sup-talk] [PATCH 4/4] force the index sync thread to give up the
 	cpu
 In-Reply-To: <1257399921-26813-3-git-send-email-rlane@club.cc.cmu.edu>
 References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu>
 	<1257399921-26813-3-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1257399921-26813-4-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/index.rb |    2 ++
  1 files changed, 2 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 1131ec7..4f491d6 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -201,6 +201,8 @@ class BaseIndex
      while m = @sync_queue.deq
        return if m == :die
        update_message_state m
 +      # Necessary to keep Xapian calls from lagging the UI too much.
 +      sleep 0.03
      end
    end
  end
 -- 
 1.6.4.2
 
 
 From matthias.guedemann@ovgu.de  Thu Nov  5 03:27:25 2009
 From: matthias.guedemann@ovgu.de (Matthias Guedemann)
 Date: Thu, 05 Nov 2009 09:27:25 +0100
 Subject: [sup-talk] Problems with undo archive and thread focus
 Message-ID: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de>
 
 
 Hi,
 
 while using sup for a while now I came across surprising behavior in the
 following situations.
 
 One is, if you hit 'a' in thread view mode, the thread is archived but undo does
 not work. If you go back to index view and hit 'u' the just archived thread does
 not appear, but the one before.
 
 The second is, if I respond to a thread and send the mail, I normally want to
 either archive that mail directly or label and archive it. But the thread is put
 to the front and the focus is on the last place of the thread. Therefore I
 sometimes archive the wrong thread (but undo comes in handy)
 
 
 The first seems to be a bug, the second may be a problem only for me.
 
 best regards,
 
 Matthias
 -- 
 __________________________________________________________
                                             ___  __    __
 Dipl. Inf. Matthias Guedemann              / __\/ _\  /__\
 Computer Systems in Engineering           / /   \ \  /_\
 Otto-von-Guericke Universitaet Magdeburg / /___ _\ \//__
 Tel.: 0391 / 67-19359                    \____/ \__/\__/
 __________________________________________________________
 
 From markr.anderson@amd.com  Thu Nov  5 15:29:23 2009
 From: markr.anderson@amd.com (Mark Anderson)
 Date: Thu, 5 Nov 2009 13:29:23 -0700
 Subject: [sup-talk] Sup-sync exception
 Message-ID: <1257452860-sup-7983@testarossa>
 
 
 I have an offlineimap synced IMAP Maildir area, and for some reason I get an error when I try to run sup-sync.
 
 Any ideas?
 
 -Mark
 
 144> sup-sync
 /home/manderso/src/sup-git/mainline/lib/sup/util.rb:9: warning: method redefined; discarding old gen_lock_id
 /home/manderso/src/sup-git/mainline/lib/sup/util.rb:20: warning: method redefined; discarding old dump_lock_id
 [Thu Nov 05 13:25:38 -0700 2009] WARNING: can't find character set by using locale, defaulting to utf-8
 /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname
 /home/manderso/src/sup-git/mainline/lib/sup/imap.rb:119: warning: ambiguous first argument; put parentheses or even spaces
 [Thu Nov 05 13:25:39 -0700 2009] using index Redwood::FerretIndex
 /home/manderso/src/sup-git/mainline/bin/sup-sync:11: warning: method redefined; discarding old to_s
 [Thu Nov 05 13:25:40 -0700 2009] crypto: detected gpg binary in /usr/bin/gpg
 [Thu Nov 05 13:25:40 -0700 2009] locking /home/manderso/.sup/lock...
 [Thu Nov 05 13:25:40 -0700 2009] loading index...
 [Thu Nov 05 13:25:40 -0700 2009] loaded index of 3830 messages
 [Thu Nov 05 13:25:40 -0700 2009] scanning maildir /home/manderso/MailExchange/INBOX...
 [Thu Nov 05 13:25:42 -0700 2009] done scanning maildir
 Scanning maildir:/home/manderso/MailExchange/INBOX...
 [Thu Nov 05 13:25:42 -0700 2009] unlocking /home/manderso/.sup/lock...
 /home/manderso/src/sup-git/mainline/lib/sup/buffer.rb:15:in `cols': undefined local variable or method `stdscr' for Ncurses:Module (NameError)
         from /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:165:in `initialize'
         from /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:165:in `map'
         from /home/manderso/src/sup-git/mainline/lib/sup/message-chunks.rb:165:in `initialize'
         from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:591:in `new'
         from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:591:in `text_to_chunks'
         from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:511:in `message_to_chunks'
         from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:239:in `load_from_source!'
         from /home/manderso/src/sup-git/mainline/lib/sup/message.rb:335:in `build_from_source'
         from /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:145:in `each_message_from'
         from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:160:in `each'
         from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `upto'
         from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `each'
         from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `send'
         from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `__pass'
         from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:547:in `method_missing'
         from /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:139:in `each_message_from'
         from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `send'
         from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `method_missing'
         from /home/manderso/src/sup-git/mainline/bin/sup-sync:146
         from /home/manderso/src/sup-git/mainline/bin/sup-sync:141:in `each'
         from /home/manderso/src/sup-git/mainline/bin/sup-sync:141
 
 
 From garoth@gmail.com  Thu Nov  5 20:58:27 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Thu, 5 Nov 2009 20:58:27 -0500
 Subject: [sup-talk] Arch Linux Sup Package (Ruby 1.9.1 + Sup 0.9)
 In-Reply-To: <1257092475-sup-4321@masanjin.net>
 References: <80055d7c0910180805v5da8a9a0o57851093ee17813e@mail.gmail.com>
 	<1257092475-sup-4321@masanjin.net>
 Message-ID: <80055d7c0911051758p815b66eu722ebb15993b7f0d@mail.gmail.com>
 
 Sorry, William. I've been busy and haven't monitered the list. I'll
 probably set up a proper mail system tonight so I don't screw this up
 again.
 
 > Reformatted excerpts from Andrei Thorp's message of 2009-10-18:
 >> ?- I've applyed Lloyd's patch for fixing the UTF-8 check.
 >
 > Which patch was this? The only "Lloyd patch" one I'm aware of is:
 > http://github.com/lloyd/sup/commit/d07986419b87053b41f7ed4bd7b6d1e537704864
 
 No, that's not it... the patch that I applied is
 http://aur.archlinux.org/packages/sup/sup/fix-utf8-hack.patch. At
 least' that's my copy of it that I uploaded to the AUR. I'm assuming
 that Lloyd still has this in his repos somewhere. I'm not sure this
 patch is strictly necessary, but at the time I was under the
 impression that it seemed reasonable. Admittedly, I'm not a great Ruby
 programmer.
 
 Ah, here it is.
 http://github.com/lloyd/sup/commit/e32c48c4abfb921c60d337354634cd905f7e9149
 
 >> 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.
 
 I'm still not sure why this bug doesn't happen for me. Oh wait!
 Discovery! Sean left a comment on my AUR page stating, "It was just a
 stale lock file. removed ~/.sup/lock and it started up nicely." So
 never mind that, lockfile's fine in 1.9.
 
 As for trying things like ,n, I'll give it a whirl tonight. I need to
 set up my mail... I've been busy/putting it off :).
 
 Cheers!
 
 -Andrei Thorp
 
 From garoth@gmail.com  Thu Nov  5 21:34:31 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Thu, 5 Nov 2009 21:34:31 -0500
 Subject: [sup-talk] [Ruby 1.9] sup-sync error
 Message-ID: <80055d7c0911051834u4c08786aiecc37fcdb77d75b5@mail.gmail.com>
 
 Looks like another one of those simple to fix but annoying sup errors:
 
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?':
 undefined method `>=' for true:TrueClass (NoMethodError)
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in
 `method_missing'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in
 `each_message_from'
 	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/bin/sup-sync:146:in `block
 in <top (required)>'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `<top
 (required)>'
 	from /usr/bin/supbin/sup-sync:19:in `load'
 	from /usr/bin/supbin/sup-sync:19:in `<main>'
 
 This occurs when attempting to import mail from Maildirs
 
 From garoth@gmail.com  Thu Nov  5 21:38:26 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Thu, 5 Nov 2009 21:38:26 -0500
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <1256997213-sup-2725@masanjin.net>
 References: <1256997213-sup-2725@masanjin.net>
 Message-ID: <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com>
 
 On Sat, Oct 31, 2009 at 9:03 AM, William Morgan
 <wmorgan-sup at masanjin.net> wrote:
 > Suggestions welcome.
 
 I propose promoting Rich Lane to commiter if he's up for it and
 doesn't have access yet. From what I can tell, he's done a terrific
 job thus far, and has a lot of experience with Sup.
 
 -AT
 
 From rlane@club.cc.cmu.edu  Thu Nov  5 23:13:05 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 05 Nov 2009 23:13:05 -0500
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com>
 References: <1256997213-sup-2725@masanjin.net>
 	<80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com>
 Message-ID: <1257476207-sup-3459@zyrg.net>
 
 Excerpts from Andrei Thorp's message of Thu Nov 05 21:38:26 -0500 2009:
 > On Sat, Oct 31, 2009 at 9:03 AM, William Morgan
 > <wmorgan-sup at masanjin.net> wrote:
 > > Suggestions welcome.
 > 
 > I propose promoting Rich Lane to commiter if he's up for it and
 > doesn't have access yet. From what I can tell, he's done a terrific
 > job thus far, and has a lot of experience with Sup.
 
 Thanks! If William doesn't have the free time, I would be glad to help
 out. Rather than committing directly to mainline, I'd rather keep a
 public repo that I apply incoming patches to and that William can pull
 from. This way I could do a lot of the first-line work and he could get
 a more stable flow of patches to make releases from.
 
 For my own process suggestion:
 
 I can imagine that a lot of William's work caused by being the central
 repository is reviewing the patches that get sent in. I'd like for
 anyone who feels interested to read through incoming patches and comment
 on them. I don't want any strict processes just yet, but I'd like to see
 a couple of positive reviews (depending on the complexity of the patch,
 etc) before things get merged.
 
 Distributing the workload and ensuring code quality are only a couple of
 my motives here. I know I feel more comfortable sending out a patch if
 I'm sure someone will catch my mistakes before it's merged. Also, it's a
 great way for people who aren't yet familiar with the codebase to start
 contributing.
 
 If anyone's interested and wants to get started right away, definitely
 take a look at the immediate-updates patches I sent in yesterday.
 
 From wmorgan-sup@masanjin.net  Fri Nov  6 08:47:51 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 06 Nov 2009 05:47:51 -0800
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <1257476207-sup-3459@zyrg.net>
 References: <1256997213-sup-2725@masanjin.net>
 	<80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com>
 	<1257476207-sup-3459@zyrg.net>
 Message-ID: <1257509523-sup-3428@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-11-05:
 > Rather than committing directly to mainline, I'd rather keep a public
 > repo that I apply incoming patches to and that William can pull from.
 > This way I could do a lot of the first-line work and he could get a
 > more stable flow of patches to make releases from.
 
 That sounds good to me. I'm happy to add you to the gitorious repo, of
 course, but this is definitely more in line with the git lifestyle.
 
 We have a couple options on how to organize this, but I think the best
 would be for you to maintain one or more branches that I treat as
 integration branches, and periodically merge into master whenever you
 tell me they're ready. That's a very minimal amount of work for me. I
 can just merge it and forget it.
 
 The only things to be careful about in such a setup are not merging next
 into your branch (merging master in is fine and good to keep up with
 other stable changes), and not rebasing. And we will have to coordinate
 on releases, if nothing else so that I can make reasonable changelogs
 and release notes.
 
 How does that sound?
 
 > I can imagine that a lot of William's work caused by being the central
 > repository is reviewing the patches that get sent in. I'd like for
 > anyone who feels interested to read through incoming patches and comment
 > on them. I don't want any strict processes just yet, but I'd like to see
 > a couple of positive reviews (depending on the complexity of the patch,
 > etc) before things get merged.
 
 That would be great. Or heck, even an "I applied it and it works for
 me" is useful.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rick.tessner@gmail.com  Fri Nov  6 10:13:19 2009
 From: rick.tessner@gmail.com (rick.tessner)
 Date: Fri, 06 Nov 2009 07:13:19 -0800
 Subject: [sup-talk] Sup-sync exception
 In-Reply-To: <1257452860-sup-7983@testarossa>
 References: <1257452860-sup-7983@testarossa>
 Message-ID: <1257520288-sup-8595@onnadayr.ca>
 
 Hi,
 
 Excerpts from Mark Anderson's message of Thu Nov 05 12:29:23 -0800 2009:
 > 
 > I have an offlineimap synced IMAP Maildir area, and for some reason I get an error when I try to run
 > sup-sync.
 
 I had that exact same thing.  If you applied a patch that used
 Ncurses.cols rather than WRAP_LEN to determine screen width, you'll have
 that problem in the non-curses based sup applications.
 
 The patch came from an email with the subject
 
     [PATCH] Use terminal width instead of hardcoded 80 as the wrap length.
 
 I initially didn't have any problems whatsoever with that patch until I ran
 sup-sync. I fixed it with the attached commit.
 
 This patch just does a rescue on that call.  The patch is only
 applicable if you had applied a patch that came through previously on
 this list for using Ncurses.cols rather than WRAP_LEN in
 lib/sup/message-chunks.rb
 -- 
 Rick Tessner
 rick.tessner at gmail.com
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 0001-Corrects-Use-terminal-width-instead-of-hardcoded-80-.patch
 Type: application/octet-stream
 Size: 1637 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091106/d2c16dff/attachment.obj>
 
 From wmorgan-sup@masanjin.net  Fri Nov  6 11:33:03 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 06 Nov 2009 08:33:03 -0800
 Subject: [sup-talk] sup bug tracker
 Message-ID: <1257524700-sup-9112@masanjin.net>
 
 Hi all,
 
 I've put a slightly modified Roundup installation here for tracking Sup
 bugs:
 
   http://masanjin.net/sup-bugs/
 
 Please use this to submit your bug reports and feature requests. If you
 have existing bug reports or feature requests and you don't want to rely
 on my faulty memory any more, feel free to resubmit them here.
 
 You should be able to create new issues without having to register.
 However, if you want to receive email about an issue when updates
 happen, you will have to register. Sorry! On the plus side, registration
 is super quick because I've disabled the email confirmation step.
 
 If anyone has written Roundup detectors in the past, let me know. There
 are a couple things I'd like to tweak.
 
 I'm going to point the 0.9.1 crash message there too.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From markr.anderson@amd.com  Fri Nov  6 15:06:17 2009
 From: markr.anderson@amd.com (Mark Anderson)
 Date: Fri, 6 Nov 2009 13:06:17 -0700
 Subject: [sup-talk] Sup-sync exception
 In-Reply-To: <1257520288-sup-8595@onnadayr.ca>
 References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca>
 Message-ID: <1257537789-sup-1961@testarossa>
 
 Excerpts from rick.tessner's message of Fri Nov 06 08:13:19 -0700 2009:
 > I had that exact same thing.  If you applied a patch that used
 > Ncurses.cols rather than WRAP_LEN to determine screen width, you'll have
 > that problem in the non-curses based sup applications.
 > 
 > The patch came from an email with the subject
 > 
 >     [PATCH] Use terminal width instead of hardcoded 80 as the wrap length.
 
 I had applied that previous patch, as you guessed.
 
 There was another patch that is complementary in getting the console to recognize the width of the terminal, I forget the tname, but here's what I have in my message-chunks.rb:
 
   TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails
   WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width
 
 I don't know why that patch preferred `stty` to ENV["COLUMNS"], since that one had worked for me.
 
 > I initially didn't have any problems whatsoever with that patch until I ran
 > sup-sync. I fixed it with the attached commit.
 > 
 > This patch just does a rescue on that call.  The patch is only
 > applicable if you had applied a patch that came through previously on
 > this list for using Ncurses.cols rather than WRAP_LEN in
 > lib/sup/message-chunks.rb
 
 Thanks, it is much happier now.
 
 -Mark
 
 
 From pi+sup@pihost.us  Fri Nov  6 21:16:42 2009
 From: pi+sup@pihost.us (Anthony Martinez)
 Date: Fri, 06 Nov 2009 19:16:42 -0700
 Subject: [sup-talk] Sup-sync exception
 In-Reply-To: <1257537789-sup-1961@testarossa>
 References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca>
 	<1257537789-sup-1961@testarossa>
 Message-ID: <1257556260-sup-1272@home.mrtheplague.net>
 
 Excerpts from Mark Anderson's message of Fri Nov 06 13:06:17 -0700 2009:
 > There was another patch that is complementary in getting the console to
 > recognize the width of the terminal, I forget the tname, but here's what I
 > have in my message-chunks.rb:
 > 
 >   TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails
 >   WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width
 > 
 > I don't know why that patch preferred `stty` to ENV["COLUMNS"], since that one
 > had worked for me.
 
 That'd be my patch. I used stty because ENV["COLUMNS"] doesn't consistently work
 for me:
 
 $ echo $COLUMNS
 132
 $ perl -wE 'say $ENV{COLUMNS}'
 Use of uninitialized value in say at -e line 1.
 
 $ ruby -e 'puts ENV["COLUMNS"]'
 nil
 $ irb
 irb(main):001:0> ENV["COLUMNS"]
 => "132"
 
 In Sup's console mode, ENV["COLUMNS"] is set, but when I tried
   WRAP_LEN = ENV["COLUMNS"]
 in message-chunks.rb, it gets nil. It appears to have something to do with
 readline:
 
 $ irb --noreadline
 irb(main):001:0> ENV["COLUMNS"]
 => nil
 
 I also tried Ncurses.cols, as suggested on sup-devel, and got a similar
 exception to yours. `stty`, albeit cheesy, works well enough for right now (even
 though I'm not quite happy with it, since, in addition to its reliance on the
 output of an external command, it also won't react to window size changes)
 
 Perhaps this should be a configuration option -- give it a number to wrap to
 that width, :auto to wrap to the terminal size (in some fashion that will allow
 it to resize when the terminal does), and in the absence of any configuration,
 80.
 
 -- 
 Every program has at least one bug and can be shortened by at least one
 instruction -- from which, by induction, one can deduce that every
 program can be reduced to one instruction which doesn't work.
 
 From garoth@gmail.com  Fri Nov  6 22:22:28 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 6 Nov 2009 22:22:28 -0500
 Subject: [sup-talk]  Ruby 1.9: encodings
 Message-ID: <80055d7c0911061922w64ef7cb0qf0c7bed008cc728c@mail.gmail.com>
 
 Eh, bad news.
 
 So I've been testing Sup in an 1.9 environment further, and I have
 found that there are a great deal of problems with regards to
 encodings. "invalid byte sequence in US-ASCII" is something you'll see
 frequently. This seems to be when parsing messages that have non-ascii
 chararacters.
 
 Ouch :(
 
 Has this already been taken care of in the git somewhere?
 
 -AT
 
 From marka@pobox.com  Fri Nov  6 23:10:33 2009
 From: marka@pobox.com (Mark Alexander)
 Date: Fri, 06 Nov 2009 23:10:33 -0500
 Subject: [sup-talk] Sup-sync exception
 In-Reply-To: <1257556260-sup-1272@home.mrtheplague.net>
 References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca>
 	<1257537789-sup-1961@testarossa>
 	<1257556260-sup-1272@home.mrtheplague.net>
 Message-ID: <1257566953-sup-306@r50p>
 
 Excerpts from Anthony Martinez's message of Fri Nov 06 21:16:42 -0500 2009:
 > That'd be my patch. I used stty because ENV["COLUMNS"] doesn't consistently work
 > for me:
 > 
 > $ echo $COLUMNS
 > 132
 > $ perl -wE 'say $ENV{COLUMNS}'
 > Use of uninitialized value in say at -e line 1.
 
 It sounds like you didn't do this:
 
 export COLUMNS
 
 From rlane@club.cc.cmu.edu  Sat Nov  7 02:09:36 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 07 Nov 2009 02:09:36 -0500
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <1257509523-sup-3428@masanjin.net>
 References: <1256997213-sup-2725@masanjin.net>
 	<80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com>
 	<1257476207-sup-3459@zyrg.net> <1257509523-sup-3428@masanjin.net>
 Message-ID: <1257562722-sup-9854@zyrg.net>
 
 Excerpts from William Morgan's message of Fri Nov 06 08:47:51 -0500 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-11-05:
 > > Rather than committing directly to mainline, I'd rather keep a public
 > > repo that I apply incoming patches to and that William can pull from.
 > > This way I could do a lot of the first-line work and he could get a
 > > more stable flow of patches to make releases from.
 > 
 > That sounds good to me. I'm happy to add you to the gitorious repo, of
 > course, but this is definitely more in line with the git lifestyle.
 > 
 > We have a couple options on how to organize this, but I think the best
 > would be for you to maintain one or more branches that I treat as
 > integration branches, and periodically merge into master whenever you
 > tell me they're ready. That's a very minimal amount of work for me. I
 > can just merge it and forget it.
 > 
 > The only things to be careful about in such a setup are not merging next
 > into your branch (merging master in is fine and good to keep up with
 > other stable changes), and not rebasing. And we will have to coordinate
 > on releases, if nothing else so that I can make reasonable changelogs
 > and release notes.
 > 
 > How does that sound?
 
 Sounds good. I'll keep using my clone at http://github.com/rlane/sup/tree/master
 unless people would prefer I move it to gitorious. 
 
 When I see a new patchset I'll create a branch for it, like William has
 been doing. One difference is that I'll hold off on merging to my master
 (where new patches cook before being sent upstream) until I see some
 positive feedback on the list. Initially this might just come from me,
 but like I said before I'm hoping others will join in too. My intention
 in creating the branch quickly after the patch is mailed is to make it
 trivial for people tracking my repo to try out the newest patches.
 
 As for getting changes to William, I'll occasionally (weekly?) apply the
 patches I deem stable on top of his master branch and send mail to
 the list. This way it should be a fast-forward when he pulls and we
 won't have to worry about resolving merges differently.
 
 As a side note, I just created a Wishlist wiki page for feature requests:
 http://sup.rubyforge.org/wiki/wiki.pl?Wishlist
 
 From tero@tilus.net  Sat Nov  7 04:34:38 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Sat, 07 Nov 2009 11:34:38 +0200
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <1257562722-sup-9854@zyrg.net>
 References: <1256997213-sup-2725@masanjin.net>
 	<80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com>
 	<1257476207-sup-3459@zyrg.net> <1257509523-sup-3428@masanjin.net>
 	<1257562722-sup-9854@zyrg.net>
 Message-ID: <1257585999-sup-5436@tilus.net>
 
 Rich Lane, 2009-11-07 09:09:
 > Sounds good. I'll keep using my clone at
 > http://github.com/rlane/sup/tree/master unless people would prefer I
 > move it to gitorious.
 
 Does it really make that big difference?  I don't think.
 
 > As a side note, I just created a Wishlist wiki page for feature
 > requests: http://sup.rubyforge.org/wiki/wiki.pl?Wishlist
 
 Why not use tracker for feature requests too?  If I don't hear any
 reasons why, I'll go put the wishlist items there too.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From tero@tilus.net  Sat Nov  7 06:15:56 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Sat, 07 Nov 2009 13:15:56 +0200
 Subject: [sup-talk] sup bug tracker
 In-Reply-To: <1257524700-sup-9112@masanjin.net>
 References: <1257524700-sup-9112@masanjin.net>
 Message-ID: <1257591624-sup-8158@tilus.net>
 
 William Morgan, 2009-11-06 18:33:
 > If you have existing bug reports or feature requests and you don't
 > want to rely on my faulty memory any more, feel free to resubmit
 > them here.
 
 What should be the policy with issues are reported/discussed on irc or
 mailinglist but are not reported to tracker?  Should The Sup Issues
 Task Force(TM) ;) report them to tracker or try to push the original
 reporter to do it?
 
 Should we (The SITF) skim mailinglist archives and transfer reported
 unfixed bugs (with links to archives) to tracker?
 
 > I'm going to point the 0.9.1 crash message there too.
 
 Sup home http://sup.rubyforge.org/ is not yet pointing there.
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From wmorgan-sup@masanjin.net  Sat Nov  7 11:32:08 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 07 Nov 2009 08:32:08 -0800
 Subject: [sup-talk] sup bug tracker
 In-Reply-To: <1257591624-sup-8158@tilus.net>
 References: <1257524700-sup-9112@masanjin.net> <1257591624-sup-8158@tilus.net>
 Message-ID: <1257610340-sup-9345@masanjin.net>
 
 Reformatted excerpts from Tero Tilus's message of 2009-11-07:
 > What should be the policy with issues are reported/discussed on irc or
 > mailinglist but are not reported to tracker?  Should The Sup Issues
 > Task Force(TM) ;) report them to tracker or try to push the original
 > reporter to do it?
 
 I would like all new issues to go on the tracker, and I think it's
 completely reasonable to tell people who report things to the mailing
 list or IRC to instead use the issue tracker instead.
 
 > Should we (The SITF) skim mailinglist archives and transfer reported
 > unfixed bugs (with links to archives) to tracker?
 
 If the SITF wants to creating issues for existing bug reports, that
 would be very helpful. But please don't do it to the point that you get
 sick of it.
 
 > Sup home http://sup.rubyforge.org/ is not yet pointing there.
 
 Fixed, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov  7 11:56:10 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 07 Nov 2009 08:56:10 -0800
 Subject: [sup-talk] slowly catching up
 In-Reply-To: <1257562722-sup-9854@zyrg.net>
 References: <1256997213-sup-2725@masanjin.net>
 	<80055d7c0911051838m855262bi93d149549de2da8c@mail.gmail.com>
 	<1257476207-sup-3459@zyrg.net> <1257509523-sup-3428@masanjin.net>
 	<1257562722-sup-9854@zyrg.net>
 Message-ID: <1257612219-sup-7066@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-11-06:
 > As for getting changes to William, I'll occasionally (weekly?) apply
 > the patches I deem stable on top of his master branch and send mail to
 > the list. This way it should be a fast-forward when he pulls and we
 > won't have to worry about resolving merges differently.
 
 Sounds good to me. I'm not even that concerned about fastforward vs
 merge.
 
 > As a side note, I just created a Wishlist wiki page for feature requests:
 > http://sup.rubyforge.org/wiki/wiki.pl?Wishlist
 
 I agree that these would be great to have on the issue tracker.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From macwright@gmail.com  Sat Nov  7 12:01:31 2009
 From: macwright@gmail.com (tom)
 Date: Sat, 7 Nov 2009 09:01:31 -0800 (PST)
 Subject: [sup-talk] Apple Address Book integration for Sup?
 Message-ID: <cbbc2289-94b5-4217-82fd-5b2dcf28466b@a31g2000yqn.googlegroups.com>
 
 Hey,
 
 Could anyone point me towards where I should start hacking or looking
 to get my address book contacts as options in Sup? I'm up for the task
 if the contact list is pluggable, but obviously documentation is
 somewhat minimal here.
 
 Thanks!
 
 Tom
 
 From rlane@club.cc.cmu.edu  Sat Nov  7 12:18:51 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 07 Nov 2009 12:18:51 -0500
 Subject: [sup-talk] Apple Address Book integration for Sup?
 In-Reply-To: <cbbc2289-94b5-4217-82fd-5b2dcf28466b@a31g2000yqn.googlegroups.com>
 References: <cbbc2289-94b5-4217-82fd-5b2dcf28466b@a31g2000yqn.googlegroups.com>
 Message-ID: <1257613929-sup-2902@zyrg.net>
 
 Excerpts from tom's message of Sat Nov 07 12:01:31 -0500 2009:
 > Hey,
 > 
 > Could anyone point me towards where I should start hacking or looking
 > to get my address book contacts as options in Sup? I'm up for the task
 > if the contact list is pluggable, but obviously documentation is
 > somewhat minimal here.
 > 
 > Thanks!
 > 
 > Tom
 
 Hi Tom,
 
 If you're just looking to get tab-completion for these contacts you can
 create a extra-contact-addresses hook script that imports them.
 
 - Rich
 
 From eugeneiiim@gmail.com  Mon Nov  9 01:02:07 2009
 From: eugeneiiim@gmail.com (Eugene Marinelli)
 Date: Sun, 8 Nov 2009 22:02:07 -0800
 Subject: [sup-talk] [PATCH 2/4] async thread indexing
 In-Reply-To: <1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu>
 References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <69d60e3a0911082202t31561f18mf5e24dda7a108b58@mail.gmail.com>
 
 > -          Index.save_thread t
 > +          Index.save_thread_async t
 Where is the "save_thread_async" function?
 
 In patch 3/4, this looks like a syntax error:
 > -    end
 > +    threads.each { |t| Index.save_thread async t }
 >   end
 
 - Eugene Marinelli
 
 On Wed, Nov 4, 2009 at 9:45 PM, Rich Lane <rlane at club.cc.cmu.edu> wrote:
 > ---
 > ?bin/sup ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ?2 ++
 > ?lib/sup/index.rb ? ? ? ? ? ? ? ? ? | ? 26 +++++++++++++++++++++++++-
 > ?lib/sup/modes/thread-index-mode.rb | ? ?2 +-
 > ?3 files changed, 28 insertions(+), 2 deletions(-)
 >
 > diff --git a/bin/sup b/bin/sup
 > index 78c396a..910ff12 100755
 > --- a/bin/sup
 > +++ b/bin/sup
 > @@ -142,6 +142,7 @@ Index.lock_interactively or exit
 > ?begin
 > ? Redwood::start
 > ? Index.load
 > + ?Index.start_sync_worker unless $opts[:no_threads]
 >
 > ? $die = false
 > ? trap("TERM") { |x| $die = true }
 > @@ -335,6 +336,7 @@ ensure
 >
 > ? HookManager.run "shutdown"
 >
 > + ?Index.stop_sync_worker
 > ? Redwood::finish
 > ? stop_cursing
 > ? Redwood::Logger.remove_all_sinks!
 > diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 > index 5d8d714..1131ec7 100644
 > --- a/lib/sup/index.rb
 > +++ b/lib/sup/index.rb
 > @@ -28,6 +28,8 @@ class BaseIndex
 > ? def initialize dir=BASE_DIR
 > ? ? @dir = dir
 > ? ? @lock = Lockfile.new lockfile, :retries => 0, :max_age => nil
 > + ? ?@sync_worker = nil
 > + ? ?@sync_queue = Queue.new
 > ? end
 >
 > ? def lockfile; File.join @dir, "lock" end
 > @@ -175,10 +177,32 @@ class BaseIndex
 >
 > ? def save_thread t
 > ? ? t.each_dirty_message do |m|
 > - ? ? ?update_message_state m
 > + ? ? ?if @sync_worker
 > + ? ? ? ?@sync_queue << m
 > + ? ? ?else
 > + ? ? ? ?update_message_state m
 > + ? ? ?end
 > ? ? ? m.clear_dirty
 > ? ? end
 > ? end
 > +
 > + ?def start_sync_worker
 > + ? ?@sync_worker = Redwood::reporting_thread('index sync') { run_sync_worker }
 > + ?end
 > +
 > + ?def stop_sync_worker
 > + ? ?return unless worker = @sync_worker
 > + ? ?@sync_worker = nil
 > + ? ?@sync_queue << :die
 > + ? ?worker.join
 > + ?end
 > +
 > + ?def run_sync_worker
 > + ? ?while m = @sync_queue.deq
 > + ? ? ?return if m == :die
 > + ? ? ?update_message_state m
 > + ? ?end
 > + ?end
 > ?end
 >
 > ?index_name = ENV['SUP_INDEX'] || $config[:index] || DEFAULT_INDEX
 > diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb
 > index 370903a..d2b1651 100644
 > --- a/lib/sup/modes/thread-index-mode.rb
 > +++ b/lib/sup/modes/thread-index-mode.rb
 > @@ -477,7 +477,7 @@ EOS
 > ? ? ? BufferManager.say("Saving threads...") do |say_id|
 > ? ? ? ? dirty_threads.each_with_index do |t, i|
 > ? ? ? ? ? BufferManager.say "Saving modified thread #{i + 1} of #{dirty_threads.length}...", say_id
 > - ? ? ? ? ?Index.save_thread t
 > + ? ? ? ? ?Index.save_thread_async t
 > ? ? ? ? end
 > ? ? ? end
 > ? ? end
 > --
 > 1.6.4.2
 >
 > _______________________________________________
 > sup-talk mailing list
 > sup-talk at rubyforge.org
 > http://rubyforge.org/mailman/listinfo/sup-talk
 >
 
 From rlane@club.cc.cmu.edu  Mon Nov  9 01:22:03 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 09 Nov 2009 01:22:03 -0500
 Subject: [sup-talk] [PATCH 2/4] async thread indexing
 In-Reply-To: <69d60e3a0911082202t31561f18mf5e24dda7a108b58@mail.gmail.com>
 References: <1257399921-26813-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1257399921-26813-2-git-send-email-rlane@club.cc.cmu.edu>
 	<69d60e3a0911082202t31561f18mf5e24dda7a108b58@mail.gmail.com>
 Message-ID: <1257747131-sup-7562@zyrg.net>
 
 Excerpts from Eugene Marinelli's message of Mon Nov 09 01:02:07 -0500 2009:
 > > -          Index.save_thread t
 > > +          Index.save_thread_async t
 > Where is the "save_thread_async" function?
 > 
 > In patch 3/4, this looks like a syntax error:
 > > -    end
 > > +    threads.each { |t| Index.save_thread async t }
 > >   end
 
 Nice catch. I'd originally named the method save_thread_async and it
 looks like my search-and-replace wasn't complete. I've fixed this on the
 immediate-updates branch. Thanks for the review!
 
 From kvrkreddy@gmail.com  Tue Nov 10 04:23:22 2009
 From: kvrkreddy@gmail.com (k.v.ramakrishna reddy)
 Date: Tue, 10 Nov 2009 14:53:22 +0530
 Subject: [sup-talk] Error upon starting sup
 Message-ID: <2b29d9f30911100123j4b14f3dr721329306b93b5cb@mail.gmail.com>
 
 --- RuntimeError from thread: load threads for thread-index-mode
 invalid source 3
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:260:in
 `build_message'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:256:in
 `build_message'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:163:in
 `each_id_by_date'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/thread.rb:332:in `call'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/thread.rb:332:in
 `load_n_threads'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:163:in
 `each_id_by_date'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:162:in `each'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:162:in
 `each_id_by_date'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/thread.rb:328:in
 `load_n_threads'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:625:in
 `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:609:in
 `load_n_threads_background'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:75:in `new'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:608:in
 `load_n_threads_background'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:679:in
 `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /home/karri/.gem/ruby/1.8/gems/sup-0.9/bin/sup:196
 /home/karri/.gem/ruby/1.8/bin/sup:19:in `load'
 /home/karri/.gem/ruby/1.8/bin/sup:19
 thanks
 karri
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091110/2486ba5d/attachment-0001.html>
 
 From rlane@club.cc.cmu.edu  Tue Nov 10 12:10:42 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 10 Nov 2009 12:10:42 -0500
 Subject: [sup-talk] Error upon starting sup
 In-Reply-To: <2b29d9f30911100123j4b14f3dr721329306b93b5cb@mail.gmail.com>
 References: <2b29d9f30911100123j4b14f3dr721329306b93b5cb@mail.gmail.com>
 Message-ID: <1257872765-sup-828@zyrg.net>
 
 Excerpts from k.v.ramakrishna reddy's message of Tue Nov 10 04:23:22 -0500 2009:
 > --- RuntimeError from thread: load threads for thread-index-mode
 > invalid source 3
 
 It looks like you removed a source. If you remember what it was, you can
 just re-add it (and tweak the id in sources.yaml). Otherwise, a
 sup-dump, deleting the ferret db, and sup-sync -a --restore will solve
 the problem.
 
 From micah@riseup.net  Tue Nov 10 18:47:18 2009
 From: micah@riseup.net (Micah Anderson)
 Date: Tue, 10 Nov 2009 18:47:18 -0500
 Subject: [sup-talk] Getting gpg to work
 References: <87k5462s8q.fsf@pond.riseup.net> <1243441483-sup-2270@entry>
 	<8763fkwng3.fsf@pond.riseup.net> <1243730754-sup-8672@entry>
 Message-ID: <87fx8mkkmx.fsf@pond.riseup.net>
 
 William Morgan <wmorgan-sup at masanjin.net> writes:
 
 > Reformatted excerpts from Micah Anderson's message of 2009-05-28:
 >> [Fri May 29 00:17:42 -0400 2009] crypto: detected gpg binary in /usr/bin/gpg
 >
 > Any other obvious messages in the log about multipart/encrypted?
 
 I failed to respond to this message, partly because I think I decided to
 give up on sup at the time. But I am back now, because sup is so
 alluring, and I'm trying harder to switch this time :)
 
 This time, gpg works fine... although it is using the wrong gpg keyid
 when I try to send. I did manage to find and set the gpgkey configurable
 in the .sup/config.yaml:
 
 :accounts: 
   :default: 
     :signature: /home/micah/.signature
     :email: micah at riseup.net
     :sendmail: /usr/sbin/sendmail -oem -ti
     :name: micah anderson
     :gpgkey: 0xDEADBEEF
 
 but still, that key does not get used, and instead the first key in my
 keyring for my email at address gets used instead. I do not want that,
 because that key is set to expire in about a week.
 
 micah
 
 
 From micah@riseup.net  Tue Nov 10 23:08:22 2009
 From: micah@riseup.net (Micah Anderson)
 Date: Tue, 10 Nov 2009 23:08:22 -0500
 Subject: [sup-talk] mark-as-spam.rb and writing hooks
 Message-ID: <87bpj9ln49.fsf@pond.riseup.net>
 
 
 Howdy folks,
 
 Normally, spam is automatically put into my imap Spam folder, but
 something gets through, then I move it to the Mistakes folder, and send
 it back to the imap server. Anything put in the Mistakes folder gets
 processed for Spam/Ham scenarios (conversely, if I move something from
 the Spam folder that is actually not spam and put it in the Mistakes
 folder, then spamassassin trains bayes to learn that is actually Ham,
 not Spam). This is a pretty common Bayes training
 setup. 
 
 Sadly, this is something that Sup doesn't do, so I am stuck getting all
 of this spam in my inbox. so I think what I need to do is use the
 mark-as-spam hook to copy the message to another location. I'm using
 offlineimap, so I can just do a file copy of the actual file to the
 right spot and let sup do the rest. This seems like the most logical
 place to look, use this hook to make a copy of the mail to my Mistakes
 maildir folder when I press 'S', and then the offlineimap process will
 go and put it back on the IMAP server for processing.
 
 It seems like a hook could do this fairly easily, but because I dont
 know ruby its a lot harder for me, also I couldn't find much information
 about how to use hooks. I read the hooks.txt file in the debian package,
 but it wans't so useful.
 
 Spent some time today trying to figure out how hooks work. Couldn't find
 much information out there, but eventually figured out that there are a
 handful of hooks available, which you can list via 'sup -l', for
 example:
 
 mark-as-spam
 ------------
 File: /home/micah/.sup/hooks/mark-as-spam.rb
 This hook is run when a thread is marked as spam
 Variables: thread: The message thread being marked as spam.
 
 basically what this means is that if you put a file in
 .sup/hooks/mark-as-spam.rb with ruby code it will be executed when you
 hit the S key, and the "thread" variable is available to this hook.
 
 The above took me quite some time to determine, not being a ruby person
 and all, now that I got that, I want to use it!
 
 So what is that thread variable? I only really found it in thread.rb, so
 I looked at that for a while, I find that a thread is a bunch of
 messages, so I figure I need to enumerate the array. Then I taught
 myself some ruby looping and variable interpolation, and came up with
 this:
 
 log "Marking thread #{thread.to_s} of size #{thread.size} as spam..."
 thread.each { |message| system 'cp', message, '/home/me/Maildir/Personal/INBOX.Mistakes/cur' }
 
 and hey, it almost works, just incorrectly, my sup log gets:
 
 hook[mark-as-spam]: Marking thread <thread containing: <20091110072526.5236749428B at waldenburg.org>> of size 1 as spam...
 
 But... I dont know how to get the thread array to tell me where the
 actual file is. I spent some more quality time with the source, and I am
 pretty sure that a @thread is an array of Containers which contain the
 different Messages, which are accessed via Store... but i dont know if I
 can access any of that, there is a Thread class, Container class,
 Message class and finally a Source class, and I think the problem is
 that thread.each isn't an actual file its more of a thread object of
 some sort, and if I knew how to get at the actual file, I could just
 use a simple system call to copy it where I need to.
 
 There has to be some way to have sup actually move a message, isn't
 there?
 
 thanks for any help!
 micah
 
 
 From rlane@club.cc.cmu.edu  Wed Nov 11 23:30:56 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Wed, 11 Nov 2009 23:30:56 -0500
 Subject: [sup-talk] [PATCH] moved deriving the cmd for bouncing to
 	Account and fixed a bug in it
 In-Reply-To: <1255159160-sup-8754@tilus.net>
 References: <1255159160-sup-8754@tilus.net>
 Message-ID: <1258000130-sup-4084@zyrg.net>
 
 Excerpts from Tero Tilus's message of Sat Oct 10 03:21:33 -0400 2009:
 > 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(-)
 
 Looks good to me. Pushed to branch fix-bounce-cmd in my repo* and merged
 to master.
 
 * git://github.com/rlane/sup
 
 From rlane@club.cc.cmu.edu  Thu Nov 12 01:40:14 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 12 Nov 2009 01:40:14 -0500
 Subject: [sup-talk] mark-as-spam.rb and writing hooks
 In-Reply-To: <87bpj9ln49.fsf@pond.riseup.net>
 References: <87bpj9ln49.fsf@pond.riseup.net>
 Message-ID: <1258006050-sup-2926@zyrg.net>
 
 Hi Micah,
 
 Something like the following could work:
 
 spam = thread.labels.member? :spam
 what = spam ? 'spam' : 'ham'
 source_uri = "maildir:///tmp/mistakes" 
 source = SourceManager.source_for(source_uri) or fail "source not found"
 thread.each do |m,a,b|
   next if !m or m == :fake_root
   info "marking message #{m.id} as #{what}"
   source.store_message m.date, m.from.email do |f|
     m.each_raw_message_line { |l| f.puts l }
   end
 end
 
 This code assumes a maildir (/tmp/mistakes) and that you've added it as
 a sup "source" with "sup-add -u maildir:///tmp/mistakes". When you mark
 a thread as spam/ham, it will store the messages into that maildir. One
 problem with the above code is that it does store the entire thread, so
 if only one message was miscategorized you'll end up confusing your spam
 filter. Depending on your exact mail setup you can probably do something
 smarter here.
 
 Excerpts from Micah Anderson's message of Tue Nov 10 23:08:22 -0500 2009:
 > There has to be some way to have sup actually move a message, isn't
 > there?
 
 Sup really doesn't like it when messages are deleted from a source.
 Best to just keep it a copy.
 
 For other sup developers: it shouldn't take this much hook code to do
 this. I suggest renaming Source#store_message to Source#store_raw. A new
 Source#store_message should take a Message as the first argument and let
 the mbox From header address and date be optional with reasonable
 defaults. We should also have a Thread#each_message which ignores any
 result of Thread#each that isn't a Message. These two changes would make
 the hook above a lot less magical. What other API changes could we do
 to make writing hooks easier?
 
 From andrew@pimlott.net  Thu Nov 12 12:30:01 2009
 From: andrew@pimlott.net (Andrew Pimlott)
 Date: Thu, 12 Nov 2009 09:30:01 -0800
 Subject: [sup-talk] Problems with undo archive and thread focus
 In-Reply-To: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de>
 References: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de>
 Message-ID: <1258045702-sup-9760@pimlott.net>
 
 Excerpts from Matthias Guedemann's message of Thu Nov 05 00:27:25 -0800 2009:
 > One is, if you hit 'a' in thread view mode, the thread is archived but undo does
 > not work. If you go back to index view and hit 'u' the just archived thread does
 > not appear, but the one before.
 
 I was annoyed by this too and found that undo is minimally implemented.
 I added undo to thread view, at least for the cases that I care about or
 were easy.  I have to say I was discouraged that this was necessary: the
 code to archive a thread should all be in one place, and the undo
 record should be created there.  There's a lot of code duplication, and
 I can't tell if it's because the model and view are too coupled, or
 because nobody has bothered to factor it out.
 
 The patch is appended.  (This is the first time I've done this with git.)
 
 > The second is, if I respond to a thread and send the mail, I normally want to
 > either archive that mail directly or label and archive it. But the thread is put
 > to the front and the focus is on the last place of the thread. Therefore I
 > sometimes archive the wrong thread (but undo comes in handy)
 
 That's the next most annying thing for me.  Hope to get a chance to work
 on it.
 
 Andrew
 
 Subject: [PATCH] create undo records in thread view
 
 ---
  lib/sup/modes/thread-view-mode.rb |   19 ++++++++++++++++++-
  1 files changed, 18 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 81197c2..2f2d564 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -254,7 +254,8 @@ EOS
    end    
  
    def edit_labels
 -    reserved_labels = @thread.labels.select { |l| LabelManager::RESERVED_LABELS.include? l }
 +    old_labels = @thread.labels
 +    reserved_labels = old_labels.select { |l| LabelManager::RESERVED_LABELS.include? l }
      new_labels = BufferManager.ask_for_labels :label, "Labels for thread: ", @thread.labels
  
      return unless new_labels
 @@ -262,6 +263,10 @@ EOS
      new_labels.each { |l| LabelManager << l }
      update
      UpdateManager.relay self, :labeled, @thread.first
 +    UndoManager.register "labeling thread" do
 +      @thread.labels = old_labels
 +      UpdateManager.relay self, :labeled, @thread.first
 +    end
    end
  
    def toggle_starred
 @@ -476,6 +481,10 @@ EOS
      dispatch op do
        @thread.remove_label :inbox
        UpdateManager.relay self, :archived, @thread.first
 +      UndoManager.register "archiving 1 thread" do
 +        @thread.apply_label :inbox
 +        UpdateManager.relay self, :unarchived, @thread.first
 +      end
      end
    end
  
 @@ -483,6 +492,10 @@ EOS
      dispatch op do
        @thread.apply_label :spam
        UpdateManager.relay self, :spammed, @thread.first
 +      UndoManager.register "marking 1 thread as spam" do
 +        @thread.remove_label :spam
 +        UpdateManager.relay self, :unspammed, @thread.first
 +      end
      end
    end
  
 @@ -490,6 +503,10 @@ EOS
      dispatch op do
        @thread.apply_label :deleted
        UpdateManager.relay self, :deleted, @thread.first
 +      UndoManager.register "deleting 1 thread" do
 +        @thread.remove_label :deleted
 +        UpdateManager.relay self, :undeleted, @thread.first
 +      end
      end
    end
  
 -- 
 1.5.6.5
 
 -- 
 I've decided to go back to school.  Kindergarden.
 
 From rlane@club.cc.cmu.edu  Thu Nov 12 13:50:54 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 12 Nov 2009 13:50:54 -0500
 Subject: [sup-talk] mark-as-spam.rb and writing hooks
 In-Reply-To: <1258040153-sup-741@pond.riseup.net>
 References: <87bpj9ln49.fsf@pond.riseup.net> <1258006050-sup-2926@zyrg.net>
 	<1258040153-sup-741@pond.riseup.net>
 Message-ID: <1258046671-sup-7062@zyrg.net>
 
 Excerpts from micah anderson's message of Thu Nov 12 10:35:59 -0500 2009:
 > > spam = thread.labels.member? :spam
 > > what = spam ? 'spam' : 'ham'
 > 
 > I'm curious about this 'what' piece. It seems like it is a way to
 > specify the message as 'spam' or 'ham', which is the second half of the
 > puzzle: go into my Spam source and review the messages there, if there
 > is a incorrectly categorized as spam message, I would typically stuff
 > that into Mistakes as well. It seems like you *have* built this into
 > this hook, but I don't understand how it is able to determine one from
 > the other? There is the 'S' mark-as-spam key, but there is no 'H'
 > mark-as-ham :)
 
 There's only 'S' and the mark-as-spam hook, but you can tell whether the
 user has marked the thread as spam or ham by checking the labels. If the
 thread is labelled 'spam', it's spam.
 
 > Yeah, I had realized this thread problem when I saw that the thread
 > variable was available for this hook. I think that this is mostly ok, I
 > think getting threaded spam is somewhat unusual... but I will pay
 > attention to see how frequently this happens. In the case that it
 > happens, i'll probably fire up mutt, categorize it as Spam, and then
 > re-index my sup index, which is what I was doing before.
 
 If you can configure your spam filter so it reads from two folders,
 'spam' and 'ham', then you can safely store extra messages in them
 (assuming you don't have true-spam threaded with true-ham). My own setup
 is slightly different - I write the raw message to a tempfile and run
 sa-learn on it with --spam or --ham.
 
 > > We should also have a Thread#each_message which ignores any
 > > result of Thread#each that isn't a Message. These two changes would make
 > > the hook above a lot less magical. What other API changes could we do
 > > to make writing hooks easier?
 > 
 > Would that make it so the above thread problem would go away?
 
 Nope, it would just mean easier iteration over the messages in a thread.
 
 From carlosgc@gnome.org  Fri Nov 13 04:11:38 2009
 From: carlosgc@gnome.org (Carlos Garcia Campos)
 Date: Fri, 13 Nov 2009 10:11:38 +0100
 Subject: [sup-talk] Sup not working anymore after abrupt reboot
 Message-ID: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com>
 
 Hi all,
 
 my laptop ran out of battery while sup was polling new mail and now sup
 always fails to start.
 I don't know whether my ferret index is corrupt, this is the exception  I
 get:
 
 ----------------------------------------------------------------
 --- IOError from thread: main
 IO Error occured at <except.c>:93 in xraise
 Error occured in index.c:901 - sis_find_segments_file
 Error reading the segment infos. Store listing was
 
 
 /usr/lib/ruby/1.8/ferret/index.rb:736:in `initialize'
 /usr/lib/ruby/1.8/ferret/index.rb:736:in `new'
 /usr/lib/ruby/1.8/ferret/index.rb:736:in `ensure_reader_open'
 /usr/lib/ruby/1.8/ferret/index.rb:591:in `size'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /usr/lib/ruby/1.8/ferret/index.rb:590:in `size'
 ./lib/sup/ferret_index.rb:31:in `load_index'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 ./lib/sup/ferret_index.rb:29:in `load_index'
 ./lib/sup/index.rb:67:in `load'
 ./lib/sup/util.rb:520:in `send'
 ./lib/sup/util.rb:520:in `method_missing'
 bin/sup:144
 
 is there any way to recover it? (if possible without losing mi index . . . )
 
 Thanks in advance.
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20091113/59536d70/attachment.html>
 
 From tero@tilus.net  Fri Nov 13 06:10:17 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Fri, 13 Nov 2009 13:10:17 +0200
 Subject: [sup-talk] Sup not working anymore after abrupt reboot
 In-Reply-To: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com>
 References: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com>
 Message-ID: <1258109288-sup-5579@tilus.net>
 
 Carlos Garcia Campos, 2009-11-13 11:11:
 > I don't know whether my ferret index is corrupt, this is the exception  I
 > get:
 > 
 > ----------------------------------------------------------------
 > Error occured in index.c:901 - sis_find_segments_file
 > Error reading the segment infos.
 
 I'm not familiar with the internals of ferret, but the error looks
 pretty bad.  It might have lost part of index data files.  Do you
 happen to have index or dump backups or find deleted files under
 ferret/ with using undelete tools?
 
 Lessons learned...
 
 Always have regular (automatic, if possible) backups of your index
 dump, ALWAYS!  I have sup-dump in my backup2l before-hook.
 
 Hum.  I think for people who don't do cron backups it wouldn't be a
 bad idea to create (optional) rotating sup-dumps on every start. (and
 stop?)
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From eg@gaute.vetsj.com  Fri Nov 13 06:57:05 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Fri, 13 Nov 2009 12:57:05 +0100
 Subject: [sup-talk] Sup not working anymore after abrupt reboot
 In-Reply-To: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com>
 References: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com>
 Message-ID: <1258113332-sup-7090@dolk>
 
 Excerpts from Carlos Garcia Campos's message of fr. nov. 13 10:11:38 +0100 2009:
 > Hi all,
 > 
 > my laptop ran out of battery while sup was polling new mail and now sup
 > always fails to start.
 > I don't know whether my ferret index is corrupt, this is the exception  I
 > get:
 > 
 > ----------------------------------------------------------------
 > --- IOError from thread: main
 > IO Error occured at <except.c>:93 in xraise
 > Error occured in index.c:901 - sis_find_segments_file
 > Error reading the segment infos. Store listing was
 > 
 > 
 > /usr/lib/ruby/1.8/ferret/index.rb:736:in `initialize'
 > /usr/lib/ruby/1.8/ferret/index.rb:736:in `new'
 > /usr/lib/ruby/1.8/ferret/index.rb:736:in `ensure_reader_open'
 > /usr/lib/ruby/1.8/ferret/index.rb:591:in `size'
 > /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 > /usr/lib/ruby/1.8/ferret/index.rb:590:in `size'
 > ./lib/sup/ferret_index.rb:31:in `load_index'
 > /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 > ./lib/sup/ferret_index.rb:29:in `load_index'
 > ./lib/sup/index.rb:67:in `load'
 > ./lib/sup/util.rb:520:in `send'
 > ./lib/sup/util.rb:520:in `method_missing'
 > bin/sup:144
 
 Also, the xapian backend works better (doesn't help you now thou, im
 afraid).
 
 - gaute
 
 From micah@riseup.net  Fri Nov 13 10:53:15 2009
 From: micah@riseup.net (Micah Anderson)
 Date: Fri, 13 Nov 2009 10:53:15 -0500
 Subject: [sup-talk] offlineimap before-poll.rb undefined method
 	'usual_sources'
 Message-ID: <877htul8us.fsf@pond.riseup.net>
 
 
 The before-poll.rb wiki example[0] seems to be what I am interested in,
 however it doesn't work and provides a traceback. It reads as follows:
 
 def offlineimap(*folders)
   cmd = "offlineimap -q -u Noninteractive.Basic"
   cmd << " -f #{folders * ','}" unless folders.compact.empty?
   `#{cmd}`
 end
 
 def folder_names(sources)
   sources.map { |s| s.uri.split('/').last }
 end
 
 def inbox_sources(sources = Index.usual_sources)
   sources.find_all { |s| !s.archived? }.sort_by {|s| s.id }
 end
 
 if (@last_fetch || Time.at(0)) < Time.now - 120
   say "Running offlineimap..."
   # only check non-auto-archived sources on the first run
   log offlineimap(@last_fetch ? nil : folder_names(inbox_sources))
   say "Finished offlineimap run."
 end
 @last_fetch = Time.now
 
 When I use this hook, i get this traceback in my sup log:
 
 [Fri Nov 13 10:51:28 -0500 2009] hook: error running hook: undefined method `usual_sources' for #<Redwood::FerretIndex:0xb7520a64>
 [Fri Nov 13 10:51:28 -0500 2009] hook: /usr/lib/ruby/1.8/sup/util.rb:520:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing'
 /home/micah/.sup/hooks/before-poll.rb:11:in `inbox_sources'
 /home/micah/.sup/hooks/before-poll.rb:18:in `__run'
 /usr/lib/ruby/1.8/sup/hook.rb:42:in `__run'
 /usr/lib/ruby/1.8/sup/hook.rb:82:in `run'
 /usr/lib/ruby/1.8/sup/util.rb:520:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing'
 /usr/lib/ruby/1.8/sup/poll.rb:45:in `poll'
 /usr/lib/ruby/1.8/sup/util.rb:520:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing'
 /usr/bin/sup-mail:195
 /usr/lib/ruby/1.8/sup.rb:76:in `reporting_thread'
 /usr/lib/ruby/1.8/sup.rb:74:in `initialize'
 /usr/lib/ruby/1.8/sup.rb:74:in `new'
 /usr/lib/ruby/1.8/sup.rb:74:in `reporting_thread'
 /usr/bin/sup-mail:195
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:669:in `call'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:610:in `call'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background'
 /usr/lib/ruby/1.8/sup.rb:76:in `reporting_thread'
 /usr/lib/ruby/1.8/sup.rb:74:in `initialize'
 /usr/lib/ruby/1.8/sup.rb:74:in `new'
 /usr/lib/ruby/1.8/sup.rb:74:in `reporting_thread'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /usr/bin/sup-mail:195
 
 Thanks,
 micah
 
 
 0. http://sup.rubyforge.org/wiki/wiki.pl?Hooks
 
 
 From eg@gaute.vetsj.com  Fri Nov 13 19:12:04 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Sat, 14 Nov 2009 01:12:04 +0100
 Subject: [sup-talk] offlineimap before-poll.rb undefined method
 	'usual_sources'
 In-Reply-To: <877htul8us.fsf@pond.riseup.net>
 References: <877htul8us.fsf@pond.riseup.net>
 Message-ID: <1258157447-sup-5782@dolk>
 
 Excerpts from Micah Anderson's message of fr. nov. 13 16:53:15 +0100 2009:
 > 
 > The before-poll.rb wiki example[0] seems to be what I am interested in,
 > however it doesn't work and provides a traceback. It reads as follows:
 > 
 > def offlineimap(*folders)
 >   cmd = "offlineimap -q -u Noninteractive.Basic"
 >   cmd << " -f #{folders * ','}" unless folders.compact.empty?
 >   `#{cmd}`
 > end
 > 
 > def folder_names(sources)
 >   sources.map { |s| s.uri.split('/').last }
 > end
 > 
 > def inbox_sources(sources = Index.usual_sources)
 >   sources.find_all { |s| !s.archived? }.sort_by {|s| s.id }
 > end
 > 
 > if (@last_fetch || Time.at(0)) < Time.now - 120
 >   say "Running offlineimap..."
 >   # only check non-auto-archived sources on the first run
 >   log offlineimap(@last_fetch ? nil : folder_names(inbox_sources))
 >   say "Finished offlineimap run."
 > end
 > @last_fetch = Time.now
 
 Im using this modified version; and I filter the folders in
 offlineimaprc.
 
 
 def offlineimap(*folders)
   cmd = "offlineimap -u Noninteractive.Basic 2>&1"
   #cmd << " -f #{folders * ','}" unless folders.compact.empty?
   `#{cmd}`
 end
 
 def folder_names(sources)
   sources.map { |s| s.uri.split('/').last }
 end
 
 def inbox_sources(sources = SourceManager.sources)
   sources.find_all { |s| !s.archived? }.sort_by {|s| s.id }
 end
 
 if (@last_fetch || Time.at(0)) < Time.now - 20
   say "Running offlineimap..."
   # only check non-auto-archived sources on the first run
   log offlineimap(@last_fetch ? nil : folder_names(inbox_sources))
   say "Finished offlineimap."
 end
 @last_fetch = Time.now
 
 - 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/20091114/359a15f2/attachment.bin>
 
 From carlosgc@gnome.org  Sat Nov 14 08:22:50 2009
 From: carlosgc@gnome.org (Carlos Garcia Campos)
 Date: Sat, 14 Nov 2009 14:22:50 +0100
 Subject: [sup-talk] Sup not working anymore after abrupt reboot
 In-Reply-To: <1258109288-sup-5579@tilus.net>
 References: <21063fcb0911130111h234098b5oabe77bfdd14a0dab@mail.gmail.com>
 	<1258109288-sup-5579@tilus.net>
 Message-ID: <1258204741-sup-4254@charmaleon>
 
 Excerpts from Tero Tilus's message of vie nov 13 12:10:17 +0100 2009:
 > Carlos Garcia Campos, 2009-11-13 11:11:
 > > I don't know whether my ferret index is corrupt, this is the exception  I
 > > get:
 > > 
 > > ----------------------------------------------------------------
 > > Error occured in index.c:901 - sis_find_segments_file
 > > Error reading the segment infos.
 > 
 > I'm not familiar with the internals of ferret, but the error looks
 > pretty bad.  It might have lost part of index data files.
 
 indeed, I have had to build a new index scratch. 
 
 > Do you
 > happen to have index or dump backups or find deleted files under
 > ferret/ with using undelete tools?
 
 No :-/
 
 > Lessons learned...
 > 
 > Always have regular (automatic, if possible) backups of your index
 > dump, ALWAYS!  I have sup-dump in my backup2l before-hook.
 
 Yes, I have a daily cron script for it now. 
 
 > Hum.  I think for people who don't do cron backups it wouldn't be a
 > bad idea to create (optional) rotating sup-dumps on every start. (and
 > stop?)
 > 
 
 Thank you very much. 
 -- 
 Carlos Garcia Campos
 PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462
 -------------- 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/20091114/e7a99505/attachment.bin>
 
 From matthias.guedemann@ovgu.de  Mon Nov 16 04:42:18 2009
 From: matthias.guedemann@ovgu.de (Matthias Guedemann)
 Date: Mon, 16 Nov 2009 10:42:18 +0100
 Subject: [sup-talk] Problems with undo archive and thread focus
 In-Reply-To: <1258045702-sup-9760@pimlott.net>
 References: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de>
 	<1258045702-sup-9760@pimlott.net>
 Message-ID: <1258363822-sup-5470@pc44es141.cs.uni-magdeburg.de>
 
 
 Hi Andrew,
 
 > The patch is appended.  (This is the first time I've done this with git.)
 
 thanks, works perfectly.
 
 > That's the next most annying thing for me.  Hope to get a chance to work
 > on it.
 
 I had a look at the code and it should not be too hard, basically when a reply
 buffer is spawned (e.g. thread-view-mode line 168), a hook to call set_sursor_pos
 0 (as ThreadViewMode is a subclass of LineCursorMode) after successful sending of
 the reply should do the job. 
 
 But unfortunately I don't know too much about the inner workings of sup (can the
 HookManager be used for this? or should the hook be supplied as attribute to the
 reply-buffer?), or even Ruby, to do it at the moment.
 
 best regards
 
 Matthias
 
 
 -- 
 __________________________________________________________
                                             ___  __    __
 Dipl. Inf. Matthias Guedemann              / __\/ _\  /__\
 Computer Systems in Engineering           / /   \ \  /_\
 Otto-von-Guericke Universitaet Magdeburg / /___ _\ \//__
 Tel.: 0391 / 67-19359                    \____/ \__/\__/
 __________________________________________________________
 
 From dhaval.giani@gmail.com  Tue Nov 17 14:04:27 2009
 From: dhaval.giani@gmail.com (Dhaval Giani)
 Date: Wed, 18 Nov 2009 00:34:27 +0530
 Subject: [sup-talk] Bug report, importing emails into sup
 Message-ID: <8aa016e10911171104t7fd3e913y96e85e039c53ce98@mail.gmail.com>
 
 Hi,
 
 Attached an exception log.
 
 Failure occured when trying to import mails from mbox after setting up
 using sup-config whicch failed and i tried to run sup after that
 
 [dhaval at gondor sup]$ sup --version
 sup v0.9
 [dhaval at gondor sup]$
 
 
 Thanks,
 Dhaval
 -- 
 
 Joan Crawford  - "I, Joan Crawford, I believe in the dollar.
 Everything I earn, I spend." -
 http://www.brainyquote.com/quotes/authors/j/joan_crawford.html
 -------------- next part --------------
 --- 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: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/source.rb:104: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
 
 From tero@tilus.net  Wed Nov 18 07:38:25 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Wed, 18 Nov 2009 14:38:25 +0200
 Subject: [sup-talk] Bug report, importing emails into sup
 In-Reply-To: <8aa016e10911171104t7fd3e913y96e85e039c53ce98@mail.gmail.com>
 References: <8aa016e10911171104t7fd3e913y96e85e039c53ce98@mail.gmail.com>
 Message-ID: <1258547658-sup-5136@tilus.net>
 
 Dhaval Giani, 2009-11-17 21:04:
 > Failure occured when trying to import mails from mbox after setting up
 > using sup-config whicch failed and i tried to run sup after that
 
 The trace is from sup, but you say it happened "when trying to import
 mails", which is usually done with sup-sync.  What was your procedure?
 How did sup-config fail?
 
 btw, we now have a brand new tracker <http://masanjin.net/sup-bugs/>
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From rlane@club.cc.cmu.edu  Thu Nov 19 23:51:22 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Thu, 19 Nov 2009 23:51:22 -0500
 Subject: [sup-talk] Problems with undo archive and thread focus
 In-Reply-To: <1258045702-sup-9760@pimlott.net>
 References: <1257409101-sup-7780@pc44es141.cs.uni-magdeburg.de>
 	<1258045702-sup-9760@pimlott.net>
 Message-ID: <1258692213-sup-2324@zyrg.net>
 
 Excerpts from Andrew Pimlott's message of Thu Nov 12 12:30:01 -0500 2009:
 > Excerpts from Matthias Guedemann's message of Thu Nov 05 00:27:25 -0800 2009:
 > > One is, if you hit 'a' in thread view mode, the thread is archived but undo does
 > > not work. If you go back to index view and hit 'u' the just archived thread does
 > > not appear, but the one before.
 > 
 > I was annoyed by this too and found that undo is minimally implemented.
 > I added undo to thread view, at least for the cases that I care about or
 > were easy.  I have to say I was discouraged that this was necessary: the
 > code to archive a thread should all be in one place, and the undo
 > record should be created there.  There's a lot of code duplication, and
 > I can't tell if it's because the model and view are too coupled, or
 > because nobody has bothered to factor it out.
 > 
 > The patch is appended.  (This is the first time I've done this with git.)
 
 Branch thread-view-mode-undo, merged to master at
 git://github.com/rlane/sup
 
 From edwardludd@gmail.com  Fri Nov 20 10:50:47 2009
 From: edwardludd@gmail.com (Ned Ludd)
 Date: Fri, 20 Nov 2009 10:50:47 -0500
 Subject: [sup-talk] Sup-sync exception
 Message-ID: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com>
 
 There was a message about this a week or so ago.  Did anyone ever find a fix?
 
 When I run "sup-sync", regardless or the source (I tried IMAP and
 Maildir), I get this error:
 
 $ sup-sync
 Scanning maildir:/home/nedludd/.mail/INBOX...
 /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?':
 undefined method `>=' for true:TrueClass (NoMethodError)
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in
 `method_missing'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in
 `each_message_from'
 	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/bin/sup-sync:146:in `block
 in <top (required)>'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each'
 	from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `<top
 (required)>'
 	from /usr/bin/supbin/sup-sync:19:in `load'
 	from /usr/bin/supbin/sup-sync:19:in `<main>'
 
 
 [I'm on Arch with sup 0.9 and Ruby 1.9.1]
 
 -----
 Ned Ludd
 
 From garoth@gmail.com  Sat Nov 21 00:18:28 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Sat, 21 Nov 2009 00:18:28 -0500
 Subject: [sup-talk] Sup-sync exception
 In-Reply-To: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com>
 References: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com>
 Message-ID: <80055d7c0911202118v4360f880n373676a90a92d3a3@mail.gmail.com>
 
 You can solve this particular problem (I have), but then it uncovers
 quite a few other probems with sup and Ruby 1.9. As the maintainer of
 the sup package in the AUR, I pretty much recommend using ruby 1.8
 until the dev team can beat sup into working.
 
 Sorry,
 
 -AT
 
 On Fri, Nov 20, 2009 at 10:50 AM, Ned Ludd <edwardludd at gmail.com> wrote:
 > There was a message about this a week or so ago. ?Did anyone ever find a fix?
 >
 > When I run "sup-sync", regardless or the source (I tried IMAP and
 > Maildir), I get this error:
 >
 > $ sup-sync
 > Scanning maildir:/home/nedludd/.mail/INBOX...
 > /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?':
 > undefined method `>=' for true:TrueClass (NoMethodError)
 > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass'
 > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in
 > `method_missing'
 > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in
 > `each_message_from'
 > ? ? ? ?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/bin/sup-sync:146:in `block
 > in <top (required)>'
 > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each'
 > ? ? ? ?from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `<top
 > (required)>'
 > ? ? ? ?from /usr/bin/supbin/sup-sync:19:in `load'
 > ? ? ? ?from /usr/bin/supbin/sup-sync:19:in `<main>'
 >
 >
 > [I'm on Arch with sup 0.9 and Ruby 1.9.1]
 >
 > -----
 > Ned Ludd
 > _______________________________________________
 > sup-talk mailing list
 > sup-talk at rubyforge.org
 > http://rubyforge.org/mailman/listinfo/sup-talk
 >
 
 From rlane@club.cc.cmu.edu  Mon Nov 23 18:33:06 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 23 Nov 2009 18:33:06 -0500
 Subject: [sup-talk] Sup-sync exception
 In-Reply-To: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com>
 References: <65a36ed50911200750q53cda26h5c5d374c6228a5a@mail.gmail.com>
 Message-ID: <1259018950-sup-9876@zyrg.net>
 
 Excerpts from Ned Ludd's message of Fri Nov 20 10:50:47 -0500 2009:
 > There was a message about this a week or so ago.  Did anyone ever find a fix?
 > 
 > When I run "sup-sync", regardless or the source (I tried IMAP and
 > Maildir), I get this error:
 > 
 > $ sup-sync
 > Scanning maildir:/home/nedludd/.mail/INBOX...
 > /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?':
 > undefined method `>=' for true:TrueClass (NoMethodError)
 >     from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass'
 >     from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in
 > `method_missing'
 >     from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in
 > `each_message_from'
 >     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/bin/sup-sync:146:in `block
 > in <top (required)>'
 >     from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each'
 >     from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `<top
 > (required)>'
 >     from /usr/bin/supbin/sup-sync:19:in `load'
 >     from /usr/bin/supbin/sup-sync:19:in `<main>'
 > 
 > 
 > [I'm on Arch with sup 0.9 and Ruby 1.9.1]
 
 Is there a cur_offset key for every source in sources.yaml? If not (or
 if it is nil/blank) see if setting cur_offset to 0 fixes it.
 
 From eg@gaute.vetsj.com  Wed Nov 25 12:27:53 2009
 From: eg@gaute.vetsj.com (Gaute Hope)
 Date: Wed, 25 Nov 2009 18:27:53 +0100
 Subject: [sup-talk] browser filter / attachment ideas
 Message-ID: <1259170070-sup-7628@dolk>
 
 Greetings,
 
 Is there already a way to put a filter on the file browser? 
 i.e: exclude anything that start with a '.' ? is there a hook for this?
 
 I know there is a way of saving all attachments to a folder, but is
 there a way to save a single attachment to a folder, now when I want to
 save it I have to remove the file name to get tab-completion, and then
 type the file name again when I want to save it.
 
 And sup doesn't understand attachment names with inline encoding:
 i.e.: =?ISO-8859-1?Q?framside_sm=E5_stader_STORE_VYER.jpg?= 
 which should be displayed as: framside_sm?_stader_STORE_VYER.jpg
 
 (see issue 24)
 
 - gaute
 
 From tero@tilus.net  Thu Nov 26 07:13:18 2009
 From: tero@tilus.net (Tero Tilus)
 Date: Thu, 26 Nov 2009 14:13:18 +0200
 Subject: [sup-talk] browser filter / attachment ideas
 In-Reply-To: <1259170070-sup-7628@dolk>
 References: <1259170070-sup-7628@dolk>
 Message-ID: <1259237544-sup-7216@tilus.net>
 
 Gaute Hope, 2009-11-25 19:27:
 > And sup doesn't understand attachment names with inline encoding:
 > i.e.: =?ISO-8859-1?Q?framside_sm=E5_stader_STORE_VYER.jpg?= 
 > which should be displayed as: framside_sm?_stader_STORE_VYER.jpg
 
 I think I have this fixed, but haven committed/pushed it.  Shame on
 me.  Should try to find time to do that...
 
 -- 
 Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
 
 From guillaume.quintard@gmail.com  Sun Nov 29 08:39:56 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sun, 29 Nov 2009 14:39:56 +0100
 Subject: [sup-talk] sup-add won't work.
 Message-ID: <1e5fdab70911290539j75355e9ds23468c866abae66b@mail.gmail.com>
 
 Here, I have a somewhat clean install of sup (gems + next branch), and
 here's what I get at the end of sup-config :
 
 Ok, trying to run "bin/sup-add mbox:/home/shivan/.gmail.mbox"...
 /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in
 `gem_original_require': no such file to load -- sup (LoadError)
 	from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
 	from bin/sup-add:7
 
 Something changed?
 
 -- 
 Guillaume