sup

community/pipermail-archives/sup-talk/2009-07.txt (248372B) - raw

 From jim@gonzul.net  Wed Jul  1 01:20:10 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Wed, 1 Jul 2009 17:20:10 +1200
 Subject: [sup-talk] Character encoding when displaying quoted-printable
 	messages
 In-Reply-To: <f4cc59760906171439q1b8983adw2008843b1ec02990@mail.gmail.com>
 References: <f4cc59760906171439q1b8983adw2008843b1ec02990@mail.gmail.com>
 Message-ID: <f4cc59760906302220v1595b4a8xf600a96747d2c408@mail.gmail.com>
 
 On Thu, Jun 18, 2009 at 9:39 AM, Jim Cheetham<jim at gonzul.net> wrote:
 > However, I'm coming across some character decoding issues with
 > quoted-printable that are making some messages hard to read. Any
 > advice on how to improve things would be welcome ... In the example
 > below, a NBSP entity is showing up as the characters "M-BM-"
 
 Nicely fixed by using the hack ncursesw branch, by the way.
 http://sup.rubyforge.org/wiki/wiki.pl?UTF8
 
 -jim
 
 From ingmar@exherbo.org  Wed Jul  1 04:38:36 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Wed, 01 Jul 2009 10:38:36 +0200
 Subject: [sup-talk]  ncurses-ruby-1.2.3 + ncursesw hack breaks search
 In-Reply-To: <f4cc59760906302220v1595b4a8xf600a96747d2c408@mail.gmail.com>
 References: <f4cc59760906171439q1b8983adw2008843b1ec02990@mail.gmail.com>
 	<f4cc59760906302220v1595b4a8xf600a96747d2c408@mail.gmail.com>
 Message-ID: <1246437271-sup-7636@cannonball>
 
 Excerpts from Jim Cheetham's message of Wed Jul 01 07:20:10 +0200 2009:
 > Nicely fixed by using the hack ncursesw branch, by the way.
 > http://sup.rubyforge.org/wiki/wiki.pl?UTF8
 
 Has anyone noticed that newer versions of ncurses-ruby plus that
 ncursesw hack [1] (to link to ncurses with widechar support) breaks search?
 
 When I search for 'foo', sup launches a search for a bunch of weird
 characters, not for 'foo', which obviously returns nothing useful.
 
 I can trigger this with ncurses-ruby 1.2.2, 1.2.3. Version 1.1 seems to
 be unaffected.
 
 [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52
 -- 
 Exherbo KDE, X.org maintainer
 
 From helgedt@tihlde.org  Wed Jul  1 05:20:05 2009
 From: helgedt@tihlde.org (Helge Titlestad)
 Date: Wed, 01 Jul 2009 11:20:05 +0200
 Subject: [sup-talk] Sup crash when adding CC to forwarded message
 Message-ID: <1246439829-sup-6907@colargol.tihlde.org>
 
 Hi,
 sup 0.8 just crashed on me. What I did was:
 * From thread-view, hit "f" to forward. 
 * Enter address to forward to.
 * Just hit "enter" when asked for CC.
 * Save message (unedited). 
 * Hit "c" to edit CC
 -> crash
 
 This is reproducible (only tried on one message, though.)
 
 bt: 
 --- NoMethodError from thread: main
 undefined method `join' for "":String
 /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/modes/edit-message-mode.rb:414:in `edit_field'
 /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/modes/edit-message-mode.rb:119:in `edit_cc'
 /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/mode.rb:50:in `send'
 /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/mode.rb:50:in `handle_input'
 /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/buffer.rb:249:in `handle_input'
 /home/xhs/helgedt/gems/gems/sup-0.8/bin/sup:238
 /home/xhs/helgedt/gems/bin/sup:19:in `load'
 /home/xhs/helgedt/gems/bin/sup:19
 -- 
 alge
 
 From jim@gonzul.net  Wed Jul  1 05:48:30 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Wed, 1 Jul 2009 21:48:30 +1200
 Subject: [sup-talk] sent_source - singular or per-account?
 Message-ID: <f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com>
 
 It looks like there is only one place that outbound mail can be stored
 -- sent_source in config.yaml specifies it globally.
 
 I'd like to be able to save outgoing email into the mailstore for the
 matching account; can anyone suggest some way to do this? Hacking code
 is an option, although I'd appreciate some pointers ...
 
 From wmorgan-sup@masanjin.net  Wed Jul  1 11:28:46 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 01 Jul 2009 08:28:46 -0700
 Subject: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks search
 In-Reply-To: <1246437271-sup-7636@cannonball>
 References: <f4cc59760906171439q1b8983adw2008843b1ec02990@mail.gmail.com>
 	<f4cc59760906302220v1595b4a8xf600a96747d2c408@mail.gmail.com>
 	<1246437271-sup-7636@cannonball>
 Message-ID: <1246461233-sup-208@entry>
 
 Reformatted excerpts from Ingmar Vanhassel's message of 2009-07-01:
 > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52
 
 Interesting thread. I disagree with the conclusion that a separate
 libncursesw-ruby package should be created. Maybe I'll respond.
 
 The analysis of Sup is wrong. He says: "Looking at the source code of
 the mailer I'd say that it is not really suited for UTF-8 encoded
 strings yet, as it still assumes that the length of a string in bytes is
 equal to the number of characters in the string." This is not really
 true. What Sup assumes is that String#length gives the length of the
 string in characters. This is obviously false in Ruby 1.8 (without
 monkeypatching), but it is true in Ruby 1.9.
 
 What *does* need to happen for Sup to really, actually, correctly
 display non-ASCII characters, besides having a ncurses library that's
 linked against ncursesw, is to be able to call the 'wcwidth' and
 'wcswidth' functions. The current #display_length function is a hack
 that's broken for e.g. Chinese characters.
 
 One way to do this would be to use dl/import like we do for setlocale().
 I've played around with this but haven't really gotten it to work. If
 someone can get any further than the below, please let me know:
 
   require 'dl/import'
   module LibC
     extend DL.const_defined?(:Importer) ? DL::Importer : DL::Importable
     dlload "libc.so.6"
     extern "void setlocale(int, const char *)"
     extern "int wcwidth(int)"
     extern "int wcswidth(const int*, int)"
   end
 
 That "works", as in doesn't throw any exceptions, but then calling
 LibC.wcswidth doesn't return the right thing, presumably because the
 Ruby string isn't being converted into an array of ints, or something. I
 don't really know how this works.
 
 > Has anyone noticed that newer versions of ncurses-ruby plus that
 > ncursesw hack [1] (to link to ncurses with widechar support) breaks
 > search?
 
 I don't have these newer versions available on my system yet (Ubuntu).
 
 > When I search for 'foo', sup launches a search for a bunch of weird
 > characters, not for 'foo', which obviously returns nothing useful.
 
 Disturbing.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bachjh@googlemail.com  Wed Jul  1 11:42:04 2009
 From: bachjh@googlemail.com (Jörg-Hendrik Bach)
 Date: Wed, 01 Jul 2009 17:42:04 +0200
 Subject: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks search
 In-Reply-To: <1246437271-sup-7636@cannonball>
 References: <f4cc59760906171439q1b8983adw2008843b1ec02990@mail.gmail.com>
 	<f4cc59760906302220v1595b4a8xf600a96747d2c408@mail.gmail.com>
 	<1246437271-sup-7636@cannonball>
 Message-ID: <1246462442-sup-1884@BlackMesa>
 
 Ingmar Vanhassel, Wed Jul 01 10:38:36 +0200 2009:
  
 > Has anyone noticed that newer versions of ncurses-ruby plus that
 > ncursesw hack [1] (to link to ncurses with widechar support) breaks search?
 
 I can confirm the behaviour.
 
 > When I search for 'foo', sup launches a search for a bunch of weird
 > characters, not for 'foo', which obviously returns nothing useful.
 
 True. However, with the following workaround, you can get proper search results:
 - search for foo -> garbled search, no proper results
 - hit 'x' to destroy the result buffer
 - hit '\' to search again.
 - hit uparrow to go to previous search. backspace all the garbled characters there.
 - repeat the uparrow + remove until it shows your last working search (or until there's no more previous search to go to)
 - type foo again, hit enter: works.
 
 Not that this is the type of thing you'd want to do for a simple search. Guess we'll have to wait for ruby 1.9?
 
 cheers,
 - J?rg-Hendrik
 
 
 > 
 > I can trigger this with ncurses-ruby 1.2.2, 1.2.3. Version 1.1 seems to
 > be unaffected.
 > 
 > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52
 
 From ingmar@exherbo.org  Wed Jul  1 11:29:22 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Wed, 01 Jul 2009 17:29:22 +0200
 Subject: [sup-talk] Sup on Ruby-1.9
 Message-ID: <1246461780-sup-5146@cannonball>
 
 Has anyone been keeping a TODO list for running sup on ruby-1.9?
 
 I haven't had the time to try it myself, but I'd like to have a rough
 idea of what I'm looking at.
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From wmorgan-sup@masanjin.net  Wed Jul  1 14:11:37 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 01 Jul 2009 11:11:37 -0700
 Subject: [sup-talk] Sup on Ruby-1.9
 In-Reply-To: <1246461780-sup-5146@cannonball>
 References: <1246461780-sup-5146@cannonball>
 Message-ID: <1246471261-sup-3755@entry>
 
 Reformatted excerpts from Ingmar Vanhassel's message of 2009-07-01:
 > Has anyone been keeping a TODO list for running sup on ruby-1.9?
 
 The major blocker for a while was the Ferret gem. With the advent of the
 Xapian branch, I have been toying around with getting Sup + Xapian to
 work on 1.9.1. So far all the gem dependencies seem to compile except
 ncurses, which needs some minor code tweaks.
 
 The latest Xapian has Ruby 1.9.1-compatible bindings, but unfortunately
 the API seems to have shifted since Rich's patches. I get:
 
   lib/sup/xapian_index.rb:24:in `initialize': Wrong arguments for overloaded method 'WritableDatabase.new'. (ArgumentError)
   Possible C/C++ prototypes are:
       WritableDatabase.new()
       WritableDatabase.new(std::string const &path, int action)
       WritableDatabase.new(Xapian::WritableDatabase const &other)
     from lib/sup/xapian_index.rb:24:in `new'
     from lib/sup/xapian_index.rb:24:in `initialize'
     from bin/sup:132:in `new'
     from bin/sup:132:in `<module:Redwood>'
     from bin/sup:62:in `<main>'
 
 Moving to 1.9 is highly desirable. It would be a major win for non-ASCII
 display issues and for speed in general. I would also like to try moving
 some of the display code from threads to fibers, since there are still
 weird threading bugs in there that occasionally crop up, and I think it
 would simplify the implementation.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jul  1 14:19:27 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 01 Jul 2009 11:19:27 -0700
 Subject: [sup-talk] Sup crash when adding CC to forwarded message
 In-Reply-To: <1246439829-sup-6907@colargol.tihlde.org>
 References: <1246439829-sup-6907@colargol.tihlde.org>
 Message-ID: <1246472248-sup-591@entry>
 
 Hi Helge,
 
 Reformatted excerpts from Helge Titlestad's message of 2009-07-01:
 > sup 0.8 just crashed on me. What I did was:
 > * From thread-view, hit "f" to forward. 
 > * Enter address to forward to.
 > * Just hit "enter" when asked for CC.
 > * Save message (unedited). 
 > * Hit "c" to edit CC
 > -> crash
 > 
 > This is reproducible (only tried on one message, though.)
 
 I can't reproduce this. Does it happen on all messages, or just on that
 one? Does it happen if you specify someting for the cc: header?
 
 Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jul  1 14:23:09 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 01 Jul 2009 11:23:09 -0700
 Subject: [sup-talk] Delete single message in thread-view?
 In-Reply-To: <1245415127-sup-2107@thinkpad-ubuntu>
 References: <1245415127-sup-2107@thinkpad-ubuntu>
 Message-ID: <1246472570-sup-6752@entry>
 
 Reformatted excerpts from Christopher Bertels's message of 2009-06-19:
 > Is it possible to delete a single message from a thread?  I haven't
 > found a way to do this, but maybe I'm just blind.
 
 Not currently. Sorry! It's all or nothing for now.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From helgedt@tihlde.org  Wed Jul  1 14:54:20 2009
 From: helgedt@tihlde.org (Helge Titlestad)
 Date: Wed, 01 Jul 2009 20:54:20 +0200
 Subject: [sup-talk] Sup crash when adding CC to forwarded message
 In-Reply-To: <1246472248-sup-591@entry>
 References: <1246439829-sup-6907@colargol.tihlde.org>
 	<1246472248-sup-591@entry>
 Message-ID: <1246474215-sup-7272@colargol.tihlde.org>
 
 Excerpts from William Morgan's message of Wed Jul 01 20:19:27 +0200 2009:
 >> [Adding CC crash procedure]
 > 
 > I can't reproduce this. Does it happen on all messages, or just on that
 > one? Does it happen if you specify someting for the cc: header?
 
 It's stopped being reproducible now. \:
 
 For the record, there was one "?" in the subject field. Probably shouldn't
 be related, but you never know with these utf-8 woes. (:
 -- 
 alge
 
 From wmorgan-sup@masanjin.net  Wed Jul  1 14:57:55 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 01 Jul 2009 11:57:55 -0700
 Subject: [sup-talk] Sup crash when adding CC to forwarded message
 In-Reply-To: <1246474215-sup-7272@colargol.tihlde.org>
 References: <1246439829-sup-6907@colargol.tihlde.org>
 	<1246472248-sup-591@entry>
 	<1246474215-sup-7272@colargol.tihlde.org>
 Message-ID: <1246474654-sup-137@entry>
 
 Reformatted excerpts from Helge Titlestad's message of 2009-07-01:
 > For the record, there was one "?" in the subject field. Probably
 > shouldn't be related, but you never know with these utf-8 woes. (:
 
 I'd be surprised... but yeah, who knows!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Jul  1 15:15:45 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 01 Jul 2009 12:15:45 -0700
 Subject: [sup-talk] Sup on Ruby-1.9
 In-Reply-To: <1246471261-sup-3755@entry>
 References: <1246461780-sup-5146@cannonball> <1246471261-sup-3755@entry>
 Message-ID: <1246475697-sup-7574@entry>
 
 Reformatted excerpts from William Morgan's message of 2009-07-01:
 > The latest Xapian has Ruby 1.9.1-compatible bindings, but unfortunately
 > the API seems to have shifted since Rich's patches.
 
 Hm, AFAIK that isn't an API change. Maybe I compiled my Xapian bindings
 wrong somehow. Or something.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Wed Jul  1 15:39:57 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 01 Jul 2009 15:39:57 -0400
 Subject: [sup-talk] sent_source - singular or per-account?
 In-Reply-To: <f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com>
 References: <f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com>
 Message-ID: <1246476925-sup-5046@ntdws12.chass.utoronto.ca>
 
 Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
 > I'd like to be able to save outgoing email into the mailstore for the
 > matching account; can anyone suggest some way to do this? Hacking code
 > is an option, although I'd appreciate some pointers ...
 
 This is an interesting idea.  I think the best way to do it might be
 to implement a sent_source hook that can override the global default.
 It would be wise to either a) not use mbox or b) have dedicated mboxes
 for this purpose...until I finally get around to finishing the lock
 manager to make shared access safe.
 
 The other gotcha with a hook to pick the source for message storage is
 that not all sources are capable of storing mail presently (mbox,
 maildir and imap are the only supported types, which admittedly should
 cover most people).
 
 I think this would be quite simple to add.
 
 I've also toyed around with the idea of 'patterned' sources so that
 you could specify a source as maildir:///u/bwalton/Maildir/inbox-%Y%m
 and have new sources picked up automatically as they're created
 (possibly by procmail doing autofiling, or something).
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090701/64c4a100/attachment.bin>
 
 From andrea.fazzi@alcacoop.it  Wed Jul  1 16:07:22 2009
 From: andrea.fazzi@alcacoop.it (Andrea Fazzi)
 Date: Wed, 01 Jul 2009 22:07:22 +0200
 Subject: [sup-talk] Reconnect command
 Message-ID: <1246478645-sup-1505@ganimoide>
 
 Hi all,
 
 finally I found the mail client I was searching for :) So, thanks for this 
 great software.
 
 Sometime, it happens that I lost my internet connection (e.g. after a 
 suspend/resume). Occasionally I noticed that, after the connection is 
 restored, sup can't polling for new messages anymore. At the moment, I 
 "fix" the issue restarting sup. In fact, it seems that doing a new login to 
 the imap server solves the problem and I can fetch the new messages. I know 
 I should investigate deeper and I'll do. But now I wonder if a "reconnect" 
 command can be an useful feature. Thoughts?
 
 Cheers,
 Andrea
 -- 
 Andrea Fazzi @ Alca Societ? Cooperativa
 Follow me on http://twitter.com/remogatto
 
 From jim@gonzul.net  Wed Jul  1 22:30:25 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Thu, 2 Jul 2009 14:30:25 +1200
 Subject: [sup-talk] sent_source - singular or per-account?
 In-Reply-To: <1246476925-sup-5046@ntdws12.chass.utoronto.ca>
 References: <f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com> 
 	<1246476925-sup-5046@ntdws12.chass.utoronto.ca>
 Message-ID: <f4cc59760907011930x4678e623j33a777ef03b7da55@mail.gmail.com>
 
 On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton<bwalton at artsci.utoronto.ca> wrote:
 > Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
 >> I'd like to be able to save outgoing email into the mailstore for the
 >> matching account; can anyone suggest some way to do this? Hacking code
 >> is an option, although I'd appreciate some pointers ...
 >
 > This is an interesting idea. ?I think the best way to do it might be
 > to implement a sent_source hook that can override the global default.
 
 'best' or 'simplest'?
 
 There already exists logic for determining which account a given
 outgoing message belongs to, because that's how the :sendmail: target
 is being used.
 
 If you are arguing that having a different sent_source per (outgoing)
 message is useful, then perhaps a hook makes sense; but the simpler
 case probably doesn't need it.
 
 > It would be wise to either a) not use mbox or b) have dedicated mboxes
 > for this purpose...until I finally get around to finishing the lock
 > manager to make shared access safe.
 
 Certainly the sent_source mbox shouldn't be subject to something
 inconvenient like delivery of new mail while we're updating it :-) but
 I'm not sure that mbox people would be unhappy having sent mail in a
 separate file ... ?
 
 -jim
 
 From bwalton@artsci.utoronto.ca  Wed Jul  1 23:17:57 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Wed, 01 Jul 2009 23:17:57 -0400
 Subject: [sup-talk] sent_source - singular or per-account?
 In-Reply-To: <f4cc59760907011930x4678e623j33a777ef03b7da55@mail.gmail.com>
 References: <f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com>
 	<1246476925-sup-5046@ntdws12.chass.utoronto.ca>
 	<f4cc59760907011930x4678e623j33a777ef03b7da55@mail.gmail.com>
 Message-ID: <1246502666-sup-1295@ntdws12.chass.utoronto.ca>
 
 Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009:
 > On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton<bwalton at artsci.utoronto.ca> wrote:
 > > Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
 > >> I'd like to be able to save outgoing email into the mailstore for the
 > >> matching account; can anyone suggest some way to do this? Hacking code
 > >> is an option, although I'd appreciate some pointers ...
 > >
 > > This is an interesting idea. ?I think the best way to do it might be
 > > to implement a sent_source hook that can override the global default.
 >
 > 'best' or 'simplest'?
 
 Both?
 
 > There already exists logic for determining which account a given
 > outgoing message belongs to, because that's how the :sendmail:
 > target is being used.
 >
 > If you are arguing that having a different sent_source per (outgoing)
 > message is useful, then perhaps a hook makes sense; but the simpler
 > case probably doesn't need it.
 
 I'm not arguing anything, and perhaps using sent_source as the
 (hypothetical) hook name was a bad choice...
 
 If I'm understanding you correctly, you want to write to a different
 source depending on which address is used in the From.  You'd either
 need to make a separate config entry in each account that gets setup
 (similar to the sendmail that you note) or provide the ability for the
 user to select the sent box in some other way.
 
 In the 'simpler' case where the decision is made based on account
 used, you've got a chunk of static code making the choice and
 defaulting as it would now.  The hook would simply take the place of
 the static decision maker.  The decision has to be made per message
 regardless of how it's implemented, so doing it in a hook is a better
 option, imo.  The Hook route would be slightly slower, since there are
 extra activation records on the stack for the function calls, but it
 should be negligible.
 
 The other advantage to a Hook is that the decision could be made based
 on more than simply the From:.  Maybe other users would prefer to
 store mail based on who it was sent To...or a combo of From/To?
 
 I'm interested in William's thoughts on this.  It's not a feature I'd
 use, but I do think it's a good feature to have.
 
 I hope this explains my thinking more clearly.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090701/eb941c06/attachment.bin>
 
 From jim@gonzul.net  Thu Jul  2 06:14:23 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Thu, 2 Jul 2009 22:14:23 +1200
 Subject: [sup-talk] sent_source - singular or per-account?
 In-Reply-To: <1246502666-sup-1295@ntdws12.chass.utoronto.ca>
 References: <f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com> 
 	<1246476925-sup-5046@ntdws12.chass.utoronto.ca>
 	<f4cc59760907011930x4678e623j33a777ef03b7da55@mail.gmail.com> 
 	<1246502666-sup-1295@ntdws12.chass.utoronto.ca>
 Message-ID: <f4cc59760907020314o60100e01r1a1f8af4d354030a@mail.gmail.com>
 
 On Thu, Jul 2, 2009 at 3:17 PM, Ben Walton<bwalton at artsci.utoronto.ca> wrote:
 > Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009:
 > If I'm understanding you correctly, you want to write to a different
 > source depending on which address is used in the From.
 
 Almost; what I (could have) said was that I wanted to write to a
 different source depending on which account is in use for the current
 message; I wasn't fixating on the From address itself, although with a
 better understanding of the code you might declare that they are
 effectively the same anyway :-)
 
 
 > ?You'd either
 > need to make a separate config entry in each account that gets setup
 > (similar to the sendmail that you note) or provide the ability for the
 > user to select the sent box in some other way.
 
 Yes; and in either case I think we can't just override the current
 global sent_source, because this is being used to read messages from,
 in order to include them in the threads.
 
 > In the 'simpler' case where the decision is made based on account
 > used, you've got a chunk of static code making the choice and
 > defaulting as it would now. ?The hook would simply take the place of
 > the static decision maker. ?The decision has to be made per message
 > regardless of how it's implemented, so doing it in a hook is a better
 > option, imo. ?The Hook route would be slightly slower, since there are
 > extra activation records on the stack for the function calls, but it
 > should be negligible.
 
 Mmm, I think the hook route would expose you to a lot of change,
 because whenever a 'new' source (i.e. one not known about as load
 time) is declared in the hook, you'll have to remember it so it can be
 included in the index, and be available next time sup starts too.
 
 Whereas requiring sent_sources to be declared at load time only means
 they can be added as sources just like the current singular one is.
 
 I've been browsing the source this evening, I don't have a very good
 grasp of Ruby idiom but I do find it to be very readable in general
 :-) However, I've come to a halt in SentManager.write_sent_message,
 because I haven't figured out how @source.store_message relates to my
 store URI, and therefore the relevant store_message function. I mean,
 if :sent_store: is configured, how does @source get created from
 @source_uri?
 
 If we have multiple sent_sources, that contradicts the singleton
 SentManager, unless @source becomes a hash keyed off from_email ... at
 which point I'm pushing my Ruby skills too far for the evening.
 
 Any comments or specific code pointers welcomed! I'd be happy to
 attempt a patch for this, but I may need a little help ...
 
 -jim
 
 From bwalton@artsci.utoronto.ca  Thu Jul  2 10:02:56 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Thu, 02 Jul 2009 10:02:56 -0400
 Subject: [sup-talk] sent_source - singular or per-account?
 In-Reply-To: <f4cc59760907020314o60100e01r1a1f8af4d354030a@mail.gmail.com>
 References: <f4cc59760907010248r5598eb50sf29b3ae8f500e5f8@mail.gmail.com>
 	<1246476925-sup-5046@ntdws12.chass.utoronto.ca>
 	<f4cc59760907011930x4678e623j33a777ef03b7da55@mail.gmail.com>
 	<1246502666-sup-1295@ntdws12.chass.utoronto.ca>
 	<f4cc59760907020314o60100e01r1a1f8af4d354030a@mail.gmail.com>
 Message-ID: <1246542975-sup-7239@ntdws12.chass.utoronto.ca>
 
 Excerpts from Jim Cheetham's message of Thu Jul 02 06:14:23 -0400 2009:
 
 > Almost; what I (could have) said was that I wanted to write to a
 > different source depending on which account is in use for the
 > current message; I wasn't fixating on the From address itself,
 > although with a better understanding of the code you might declare
 > that they are effectively the same anyway :-)
 
 Ok.  I _think_ that difference would come out in the wash, unless I'm
 overlooking a subtlety.  Thanks for clarifying your needs/wants
 though.
 
 > > ?You'd either need to make a separate config entry in each account
 > > that gets setup (similar to the sendmail that you note) or provide
 > > the ability for the user to select the sent box in some other way.
 >
 > Yes; and in either case I think we can't just override the current
 > global sent_source, because this is being used to read messages from,
 > in order to include them in the threads.
 
 As long as sup is configured with all sources that might be returned
 from the hook, including the default source, it should be ok.  It'll
 still poll all sources and thread messages appropriately.
 
 > Mmm, I think the hook route would expose you to a lot of change,
 > because whenever a 'new' source (i.e. one not known about as load
 > time) is declared in the hook, you'll have to remember it so it can be
 > included in the index, and be available next time sup starts too.
 
 My take on this is that the hook would be constrained to return only
 existing sources.  On the other hand, aside from an initial import of
 any existing mail in a new folder, I'm not sure that adding new
 sources on the fly would be that bad.
 
 > Whereas requiring sent_sources to be declared at load time only means
 > they can be added as sources just like the current singular one is.
 
 I was picturing the hook return value to be a uri suitable for passing
 to Index.source_for.  If that method call failed, the default would be
 used.  There are of course other (maybe better) ways to do this, but
 that's what I was thinking last night.  Using this technique, you're
 limited to existing sources and you also have an easy way to back out
 of a 'hook gone wild.'
 
 > I've been browsing the source this evening, I don't have a very good
 > grasp of Ruby idiom but I do find it to be very readable in general
 > :-) However, I've come to a halt in SentManager.write_sent_message,
 
 It is a beautiful, expressive language! :)
 
 > because I haven't figured out how @source.store_message relates to my
 > store URI, and therefore the relevant store_message function. I mean,
 > if :sent_store: is configured, how does @source get created from
 > @source_uri?
 
 At startup, SentManager is initialized with a URI.  This is either the
 value of :sent_source: from config.yaml or the default (special) value
 sup://sent.  A little later on, after the Index has been initialized,
 it is asked for the source that corresponds to the URI value passed to
 SentManager.  If this source is found in the Index, it is assigned to
 the @source value.  Otherwise, the SentManager.default_source method
 is triggered.
 
 So, when one of the message modes calls write_sent_message, it has
 either a specific source or the default ready to go.  Sources usable
 by SentManager are constrained such that they must respond to
 store_message.  This excludes ssh+mbox URI's from being a valid sent
 mail source.
 
 > If we have multiple sent_sources, that contradicts the singleton
 > SentManager, unless @source becomes a hash keyed off from_email ... at
 > which point I'm pushing my Ruby skills too far for the evening.
 
 I don't think it precludes it from being a singleton, but it would
 require some heavy reworking of the initialization logic for it.
 
 I just popped into sent.rb and was all set to knock out a patch to add
 the hook and I discovered that my memory of this wasn't what I
 thought.  SentManager doesn't ever _see_ the message.  It simply
 facilitates calling the store_message method of whatever source is
 configured and that source object in turn provides an object that acts
 like an IO object to the edit-message-mode call site.  This
 complicates either approach discussed here since the determination of
 which source to use can't be constrained to SentManager...presently,
 it would end up in edit-message-mode, which wouldn't be the right spot
 for the logic, I don't think.
 
 More thinking required, I believe.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090702/9f959f68/attachment.bin>
 
 From ezyang@MIT.EDU  Thu Jul  2 13:16:17 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 02 Jul 2009 13:16:17 -0400
 Subject: [sup-talk] Sup doesn't respect Reply-To header
 Message-ID: <1246554940-sup-138@javelin>
 
 It doesn't look like Sup respects Reply-To headers. Is this
 intentional? It breaks some mailing list agents.
 
 Cheers,
 Edward
 
 From bachjh@googlemail.com  Fri Jul  3 12:05:23 2009
 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=)
 Date: Fri, 3 Jul 2009 18:05:23 +0200
 Subject: [sup-talk] colour customisation
 Message-ID: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com>
 
 Hello list,
 
 is there any documentation on which parts of the display can be changed via the
 .sup/colors.yaml? From the wiki entry[1] it is possible to figure out some of
 the variables, but I haven't got all.
 
 cheers,
 - J?rg-Hendrik
 
 [1] http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
 
 From garoth@gmail.com  Fri Jul  3 13:13:29 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 03 Jul 2009 13:13:29 -0400
 Subject: [sup-talk] colour customisation
 In-Reply-To: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com>
 References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com>
 Message-ID: <1246641077-sup-9945@Longbow>
 
 Excerpts from J?rg-Hendrik Bach's message of Fri Jul 03 12:05:23 -0400 2009:
 > Hello list,
 > 
 > is there any documentation on which parts of the display can be changed via the
 > .sup/colors.yaml? From the wiki entry[1] it is possible to figure out some of
 > the variables, but I haven't got all.
 
 I don't really know, but from browsing the source briefly, I've
 found (formatted as quote):
 
 >  DEFAULT_COLORS = {
 >    :status => { :fg => "white", :bg => "blue", :attrs => ["bold"] },
 >    :index_old => { :fg => "white", :bg => "default" },
 >    :index_new => { :fg => "white", :bg => "default", :attrs => ["bold"] },
 >    :index_starred => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
 >    :index_draft => { :fg => "red", :bg => "default", :attrs => ["bold"] },
 >    :labellist_old => { :fg => "white", :bg => "default" },
 >    :labellist_new => { :fg => "white", :bg => "default", :attrs => ["bold"] },
 >    :twiddle => { :fg => "blue", :bg => "default" },
 >    :label => { :fg => "yellow", :bg => "default" },
 >    :message_patina => { :fg => "black", :bg => "green" },
 >    :alternate_patina => { :fg => "black", :bg => "blue" },
 >    :missing_message => { :fg => "black", :bg => "red" },
 >    :attachment => { :fg => "cyan", :bg => "default" },
 >    :cryptosig_valid => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
 >    :cryptosig_unknown => { :fg => "cyan", :bg => "default" },
 >    :cryptosig_invalid => { :fg => "yellow", :bg => "red", :attrs => ["bold"] },
 >    :generic_notice_patina => { :fg => "cyan", :bg => "default" },
 >    :quote_patina => { :fg => "yellow", :bg => "default" },
 >    :sig_patina => { :fg => "yellow", :bg => "default" },
 >    :quote => { :fg => "yellow", :bg => "default" },
 >    :sig => { :fg => "yellow", :bg => "default" },
 >    :to_me => { :fg => "green", :bg => "default" },
 >    :starred => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
 >    :starred_patina => { :fg => "yellow", :bg => "green", :attrs => ["bold"] },
 >    :alternate_starred_patina => { :fg => "yellow", :bg => "blue", :attrs => ["bold"] },
 >    :snippet => { :fg => "cyan", :bg => "default" },
 >    :option => { :fg => "white", :bg => "default" },
 >    :tagged => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
 >    :draft_notification => { :fg => "red", :bg => "default", :attrs => ["bold"] },
 >    :completion_character => { :fg => "white", :bg => "default", :attrs => ["bold"] },
 >    :horizontal_selector_selected => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
 >    :horizontal_selector_unselected => { :fg => "cyan", :bg => "default" },
 >    :search_highlight => { :fg => "black", :bg => "yellow", :attrs => ["bold"] },
 >    :system_buf => { :fg => "blue", :bg => "default" },
 >    :regular_buf => { :fg => "white", :bg => "default" },
 >    :modified_buffer => { :fg => "yellow", :bg => "default", :attrs => ["bold"] },
 >  }
 
 You can probably extrapolate how to do colouring based on this? If you
 have the energy, please update the wiki to maybe mention this list, etc.
 Last I saw, the page was fairly out of date.
 
 Hope this helps,
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From wmorgan-sup@masanjin.net  Fri Jul  3 14:37:46 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 03 Jul 2009 11:37:46 -0700
 Subject: [sup-talk] sup
 In-Reply-To: <20090703173353.GA4117@gmx.de>
 References: <20090703173353.GA4117@gmx.de>
 Message-ID: <1246645330-sup-1433@entry>
 
 [cc'ing sup-talk]
 
 Hi Marc,
 
 Reformatted excerpts from Marc Weber's message of 2009-07-03:
 > I finally managed to package sup on nix. (nixos.org) and I'm ready to
 > give sup a try.
 
 Great!
 
 > a) if ferret does save the whole messages you don't really need the
 >     original sources (maildir, mbox files), right?
 
 That's basically correct, but:
 
 a) Ferret doesn't store the entire message as represented in the
    mailstore (e.g. it only keeps a subset of the headers).
 b) Ferret has had corruption problems in the past, which I believe have
    now been fixed, but I wouldn't bet my mailstore on it.
 c) It's easy to turn that feature off, i.e., Ferret can index email for
    search without directly storing the email. The only reason I have
    Ferret store the email is because it makes changing the message
    labels quicker. If the Ferret index is too large, you can disable
    this feature at the expense of some speed.
 
 > b) [redacted] on irc told me that ferret has been abandoned in favour of
 >   Xapian ? So are there any plans in replacing Ferret by Xapian as well?
 
 It hasn't happened quite yet (the Xapian backend is very recent and
 experimental), but that's the goal. I'm currently thinking about having
 the next release of Sup use Xapian as the default index, but still
 support Ferret, and the release after that not support Ferret at all.
 But we shall see. I'm also working on a sup server, which will act as
 yet another index type.
 
 > c) I've got about 280MB of mails from the haskelcafe mailinglist or
 >   such. I missed telling sup to mark those old mails as read as well
 >   as adding a "haskell-cafe" tag. It's not a big problem because all
 >   mails contain [haskell-cafe] in the subject. However finding all
 >   threads (using !!) takes ages (more than 20min or so?) so I didn't
 >   wait until it finished.  Opening the same maildir in mutt takes less
 >   than a minute.
 
 The Xapian backend will speed this up dramatically, because the thread
 structures are cached, and that's what's expensive in this case. But the
 best solution is to use sup-tweak-labels, which is an offline tool built
 for exactly this purpose.
 
 > I've seen that ferret does save mails but displays threads.
 > Would it make sense to index the threads instead of mails?
 > Then displaying them and querying them could be even faster?
 
 See above.
 
 Welcome to Sup!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jul  3 14:54:46 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 03 Jul 2009 11:54:46 -0700
 Subject: [sup-talk] colour customisation
 In-Reply-To: <1246641077-sup-9945@Longbow>
 References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com>
 	<1246641077-sup-9945@Longbow>
 Message-ID: <1246646592-sup-3461@entry>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-07-03:
 > I don't really know, but from browsing the source briefly, I've
 > found (formatted as quote):
 
 This is correct. That is the list of parts of the display that can be
 changed, and their default colors. The possible colors for both
 foreground and background are the curses palette: black, red, green,
 yellow, blue, magenta, cyan, white, and "default". The possible
 attributes are the curses attributes: normal, standout, underline,
 reverse, blink, dim, bold, protect, invis. (I have no idea what many
 of those actually do.)
 
 Any of those settings can be overwritten by making a ~/.sup/colors.yaml
 file, which should be a YAML hash of the exact same format as
 DEFAULT_COLORS.
 
 A good way to get started it to do this:
 
   ruby -rubygems -rsup -e 'print Redwood::Colormap::DEFAULT_COLORS.to_yaml' > ~/.sup/colors.yaml
 
 and then edit the result.
 
 A gold star to whoever updates the wiki.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From j.bach@uni-oldenburg.de  Sat Jul  4 08:01:25 2009
 From: j.bach@uni-oldenburg.de (=?utf-8?q?J=C3=B6rg-Hendrik_Bach?=)
 Date: Sat, 04 Jul 2009 14:01:25 +0200
 Subject: [sup-talk] colour customisation
 In-Reply-To: <1246646592-sup-3461@entry>
 References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com>
 	<1246641077-sup-9945@Longbow> <1246646592-sup-3461@entry>
 Message-ID: <1246708626-sup-8076@lambda>
 
 I started updating the wiki page on customized colours,
 http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
 
 I added explanations for the obvious entries, and a few that I found by
 trial and error. However, a large part of the description is still
 missing, I didn't have enough time to find all the colours; but at least
 it's a start.
 
 From garoth@gmail.com  Mon Jul  6 09:47:42 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Mon, 06 Jul 2009 09:47:42 -0400
 Subject: [sup-talk] colour customisation
 In-Reply-To: <1246708626-sup-8076@lambda>
 References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com>
 	<1246641077-sup-9945@Longbow> <1246646592-sup-3461@entry>
 	<1246708626-sup-8076@lambda>
 Message-ID: <1246887804-sup-6728@Longbow>
 
 Excerpts from J?rg-Hendrik Bach's message of Sat Jul 04 08:01:25 -0400 2009:
 > I started updating the wiki page on customized colours,
 > http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors
 > 
 > I added explanations for the obvious entries, and a few that I found by
 > trial and error. However, a large part of the description is still
 > missing, I didn't have enough time to find all the colours; but at least
 > it's a start.
 
 Daaamn. Fine work you've done there. I'm really impressed with the
 graphics :)
 
 Just from reading over the names of the list and not consulting the
 source:
  - index_draft is obviously what colour drafts in the inbox are
  - cryptosig variables probably have to do with what colours the stuff
    for signed messages are.
  - search_highlight is probably the colour for when you search in a
    buffer and some stuff is highlighted (yellow)
 
 Anyway, thanks for all your work.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From jof@thejof.com  Tue Jul  7 04:20:51 2009
 From: jof@thejof.com (Jonathan Lassoff)
 Date: Tue, 07 Jul 2009 01:20:51 -0700
 Subject: [sup-talk] sup 0.8.1 crash
 Message-ID: <1246954373-sup-4550@sfo.thejof.com>
 
 Yikes! I found a way to crash my sup!
 
 I'm running sup 0.8.1 (sourced from whatever's current on rubygems.org, not a git branch), and can get sup to crash on specific searches.
 
 I took a little time to poke around in the sup source to try and get an idea what was going on. I'm led to believe this is because I added a source in the past that I later deleted -- but all of the mesages are still in the index. So, when certain searches turn up results that are in that deleted source, the sup index fails to reference the message source in Redwood::Index. Is there a way to delete a source without having to re-index everything?
 
 So, I figured I might find a way to search the index for any documents whose source id is the same as the deleted one and remove them from the index, but am having a hard time finding a way to iterate over all documents in the index (no search query). Is there a simple way to iterate over all messages?
 
 Here's some example crash output:
 
 --- RuntimeError from thread: load threads for thread-index-mode
 invalid source 1
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:403:in `build_message'
 /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:399:in `build_message'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in `each_id_by_date'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `call'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `load_n_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in `each_id_by_date'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each_id_by_date'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:326:in `load_n_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:620:in `__unprotected_load_n_threads'
 (eval):12:in `load_n_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:604:in `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/search-results-mode.rb:34:in `spawn_from_query'
 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:270
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 Thanks,
 jonathan
 
 From marco-oweber@gmx.de  Tue Jul  7 09:08:44 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Tue, 7 Jul 2009 15:08:44 +0200
 Subject: [sup-talk] Backups ?
 Message-ID: <20090707130844.GA23073@gmx.de>
 
 Hi, I'd like to setup an automatic backup system cause I don't want to
 tag my mails twice and I don't want to loose the information about
 archived mails etc.
 
 What do you think about something like this?
 Is it enough to keep 4 dumps?
 What about moving this code into sup shutdown?
 I think everyone wants to have this feature?
 
 run_sup(){
   # untested draft
   local dump_dir="/var"
   sup
   sup-dump | bzip2 > "$dump_dir/sup-dumps-`date`"
   ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
 }
 
 Marc Weber
 
 From wagnerdm@seas.upenn.edu  Tue Jul  7 11:26:35 2009
 From: wagnerdm@seas.upenn.edu (wagnerdm at seas.upenn.edu)
 Date: Tue, 07 Jul 2009 11:26:35 -0400
 Subject: [sup-talk] Backups ?
 In-Reply-To: <20090707130844.GA23073@gmx.de>
 References: <20090707130844.GA23073@gmx.de>
 Message-ID: <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu>
 
 Quoting Marc Weber <marco-oweber at gmx.de>:
 
 >   ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
 
 "{ read; read; read; read; cat }" could probably better be done as  
 "tail +5"; makes it easier to adjust to people's choice of backup  
 count, too. ;-)
 - Daniel "Bikeshedder" Wagner
 
 From bwalton@artsci.utoronto.ca  Tue Jul  7 12:10:42 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 07 Jul 2009 12:10:42 -0400
 Subject: [sup-talk] Backups ?
 In-Reply-To: <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu>
 References: <20090707130844.GA23073@gmx.de>
 	<20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu>
 Message-ID: <1246982848-sup-5820@ntdws12.chass.utoronto.ca>
 
 Excerpts from wagnerdm's message of Tue Jul 07 11:26:35 -0400 2009:
 > >   ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
 > 
 > "{ read; read; read; read; cat }" could probably better be done as  
 > "tail +5"; makes it easier to adjust to people's choice of backup  
 
 
 Or:
 
 DAYS=5
 find $dump_dir -mtime +${DAYS} -name "*sup-dumps-*" -print0 | xargs -0 --no-run-if-empty rm
 
 (adjust xargs options to suit your environment...I don't think
 --no-run-if-empty is all that portable.)
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090707/e4d9cdb7/attachment.bin>
 
 From ingmar@exherbo.org  Tue Jul  7 12:19:14 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Tue, 07 Jul 2009 18:19:14 +0200
 Subject: [sup-talk] Backups ?
 In-Reply-To: <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu>
 References: <20090707130844.GA23073@gmx.de>
 	<20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu>
 Message-ID: <1246983494-sup-6924@cannonball>
 
 Excerpts from wagnerdm's message of Tue Jul 07 17:26:35 +0200 2009:
 > Quoting Marc Weber <marco-oweber at gmx.de>:
 > 
 > >   ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm
 > 
 > "{ read; read; read; read; cat }" could probably better be done as  
 > "tail +5"; makes it easier to adjust to people's choice of backup  
 > count, too. ;-)
 > - Daniel "Bikeshedder" Wagner
 
 "tail -n+5", which is POSIX compatible
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From rhomunuq+ml_sup@gmail.com  Tue Jul  7 13:44:18 2009
 From: rhomunuq+ml_sup@gmail.com (Iain)
 Date: Tue, 07 Jul 2009 18:44:18 +0100
 Subject: [sup-talk] Exception Log
 Message-ID: <1246988396-sup-8372@leda>
 
 I'm using Sup 0.8.1 on Ubuntu 8.10 -- from the .deb kindly put together
 by Decklin Foster, <http://apt.rupamsunyata.org/sup/>.
 
 A few minutes ago, sup crashed on me. ~/.sup/exception-log.txt :
 
 --- NoMethodError from thread: main
 undefined method `title' for nil:NilClass
 /usr/lib/ruby/1.8/sup/buffer.rb:747:in `get_status_and_title'
 /usr/lib/ruby/1.8/sup/buffer.rb:281:in `draw_screen'
 /usr/bin/sup-mail:306
 
 The crash may have something to do with receiving a new message (from an
 automatic poll of a Maildir) at the same time as having just read and
 archived the prior first message in the inbox, using: ".a".
 
 From dato@net.com.org.es  Thu Jul  9 15:55:17 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=)
 Date: Thu,  9 Jul 2009 21:55:17 +0200
 Subject: [sup-talk] [PATCH] Use /etc/mailname if present to determine the
 	hostname for Message-Id
 Message-ID: <e23a0f3ed1ae4e2007d0f8144207e0e2fe3d8c11.1247169308.git.dato@net.com.org.es>
 
 Signed-off-by: Adeodato Sim? <dato at net.com.org.es>
 ---
 Hello,
 
 on many systems (notably Debian-based systems), the /etc/mailname file 
 can be created to specify the public mail name for a host. If that file
 exists, it'd be good to use its contents for generating the Message-Id 
 header.
                                                      
 I'd be grateful if you'd consider applying this patch.
 
  lib/sup/modes/edit-message-mode.rb |    9 ++++++++-
  1 files changed, 8 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb
 index f956d65..a48930a 100644
 --- a/lib/sup/modes/edit-message-mode.rb
 +++ b/lib/sup/modes/edit-message-mode.rb
 @@ -73,7 +73,14 @@ EOS
        @attachment_names = []
      end
  
 -    @message_id = "<#{Time.now.to_i}-sup-#{rand 10000}@#{Socket.gethostname}>"
 +    begin
 +      hostname = File.open("/etc/mailname", "r").gets.chomp
 +    rescue
 +        nil
 +    end
 +    hostname = Socket.gethostname if hostname.nil? or hostname.empty?
 +
 +    @message_id = "<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}>"
      @edited = false
      @selectors = []
      @selector_label_width = 0
 -- 
 1.6.3.3
 
 
 From michael@stapelberg.de  Thu Jul  9 20:34:21 2009
 From: michael@stapelberg.de (Michael Stapelberg)
 Date: Fri, 10 Jul 2009 02:34:21 +0200
 Subject: [sup-talk] sup opens multiple connections to the same imap-server
 Message-ID: <1247185833-sup-8539@x200>
 
 Hi,
 
 for some reason my cyrus-imapd does not handle multiple connections so well.
 There are 27 processes on my server which are all caused by sup. Probably sup
 opens one imap connection for each source I configured, which are 28. In my
 opinion, one connection to the server should be enough. Especially because
 sup hangs for ages until it manages to talk to my imap server correctly.
 
 Is there an easy way to make sup use only one connection? If not, I?ll see
 if this problem still arises after I re-install my server (probably with
 dovecot instead of cyrus this time).
 
 Best regards,
 Michael
 
 From michael@stapelberg.de  Thu Jul  9 20:38:25 2009
 From: michael@stapelberg.de (Michael Stapelberg)
 Date: Fri, 10 Jul 2009 02:38:25 +0200
 Subject: [sup-talk] Using sup on multiple computers?
 Message-ID: <1247186181-sup-1712@x200>
 
 Hi,
 
 I?d like to use sup on my notebook and on my workstation. Is there any
 simple/recommended way to synchronize the index? I figured using multiple
 clients in parallel is one of the big advantages of IMAP and I?d love to keep
 it that way while using sup.
 
 Best regards,
 Michael
 
 From ezyang@MIT.EDU  Thu Jul  9 22:57:14 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Thu, 09 Jul 2009 22:57:14 -0400
 Subject: [sup-talk] Using sup on multiple computers?
 In-Reply-To: <1247186181-sup-1712@x200>
 References: <1247186181-sup-1712@x200>
 Message-ID: <1247194599-sup-5843@javelin>
 
 Excerpts from Michael Stapelberg's message of Thu Jul 09 20:38:25 -0400 2009:
 > I?d like to use sup on my notebook and on my workstation. Is there any
 > simple/recommended way to synchronize the index? I figured using multiple
 > clients in parallel is one of the big advantages of IMAP and I?d love to keep
 > it that way while using sup.
 
 The easiest way is to not; since Sup is a command line application, it's trivial
 to spin it up on a server you have access to and simply SSH in to check your
 mail.
 
 Cheers,
 Edward
 
 From jof@thejof.com  Thu Jul  9 23:03:22 2009
 From: jof@thejof.com (Jonathan Lassoff)
 Date: Thu, 09 Jul 2009 20:03:22 -0700
 Subject: [sup-talk] Using sup on multiple computers?
 In-Reply-To: <1247186181-sup-1712@x200>
 References: <1247186181-sup-1712@x200>
 Message-ID: <1247194844-sup-6153@sfo.thejof.com>
 
 Excerpts from Michael Stapelberg's message of Thu Jul 09 17:38:25 -0700 2009:
 > Hi,
 > 
 > I'd like to use sup on my notebook and on my workstation. Is there any
 > simple/recommended way to synchronize the index?
 
 As far as I know, this isn't supported in sup yet.
 
 One way I work around this to use sup on two machines is that I know my
 access is mutually exclusive i.e. I don't use more than one host at
 once.
 
 So, when I switch from one host to another, I quit sup and rsync my ~/.sup to the
 machine I'm moving to and rysnc it back again when I return.
 Hacky, but functional enough.
 
 Cheers,
 jonathan
 
 From michael+sup@stapelberg.de  Fri Jul 10 06:59:42 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Fri, 10 Jul 2009 12:59:42 +0200
 Subject: [sup-talk] Using sup on multiple computers?
 In-Reply-To: <1247194599-sup-5843@javelin>
 References: <1247186181-sup-1712@x200> <1247194599-sup-5843@javelin>
 Message-ID: <1247223427-sup-4016@x200>
 
 Hi,
 
 Excerpts from Edward Z. Yang's message of Fr Jul 10 04:57:14 +0200 2009:
 > The easiest way is to not; since Sup is a command line application, it's trivial
 > to spin it up on a server you have access to and simply SSH in to check your
 > mail.
 I?ve been using mutt like this for about a year or so but I generally
 don?t want to continue with this approach. It has the disadvantage of
 having the need to copy attachments to your computer before being able
 to display them (think of PDFs) and of not scaling well when on a slow
 internet connection (IMAP traffic is less than a whole user interface).
 
 Best regards,
 Michael
 
 From garoth@gmail.com  Fri Jul 10 10:30:40 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 10 Jul 2009 10:30:40 -0400
 Subject: [sup-talk] Using sup on multiple computers?
 In-Reply-To: <1247194844-sup-6153@sfo.thejof.com>
 References: <1247186181-sup-1712@x200> <1247194844-sup-6153@sfo.thejof.com>
 Message-ID: <1247236046-sup-9543@Longbow>
 
 Excerpts from Jonathan Lassoff's message of Thu Jul 09 23:03:22 -0400 2009:
 > Excerpts from Michael Stapelberg's message of Thu Jul 09 17:38:25 -0700 2009:
 > > Hi,
 > > 
 > > I'd like to use sup on my notebook and on my workstation. Is there any
 > > simple/recommended way to synchronize the index?
 > 
 > As far as I know, this isn't supported in sup yet.
 > 
 > One way I work around this to use sup on two machines is that I know my
 > access is mutually exclusive i.e. I don't use more than one host at
 > once.
 
 The smarter way of doing this is to keep your .sup on a remote server as
 a share and mount it onto the right place in your home when you log in.
 This still has the disadvantage of only being able to use one sup at a
 time, but at least sup will lock the index using its lockfile, so you
 can't accidentally run two at once and screw something up.
 
 It also prevents you from having to manually rsync stuff.
 
 The nicest way to do this would to probably use sshfs. This way, the
 index is shared, you only need ssh (no NFS nastiness), it can mount
 automatically, and since sup is actually running on your local machine,
 it can save attachments just fine.
 
 One note: You need to either have _identical_ imap folders on your
 computers in the identical filesystem paths, or you need to have your
 mail delivered to the server and share that too.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From dato@net.com.org.es  Fri Jul 10 11:00:29 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=)
 Date: Fri, 10 Jul 2009 17:00:29 +0200
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable
 	with the attachment charset
 Message-ID: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 
 This is useful, for example, for HTML attachments which are sent in a
 charset different from the default for the system (eg., ISO-8859-1 on an
 UTF-8 system), so that the converter program can be told what charset it
 should be converting from.
 
 Signed-off-by: Adeodato Sim? <dato at net.com.org.es>
 ---
  lib/sup/message-chunks.rb |    4 +++-
  1 files changed, 3 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb
 index 0d742d9..ea04ed7 100644
 --- a/lib/sup/message-chunks.rb
 +++ b/lib/sup/message-chunks.rb
 @@ -50,7 +50,8 @@ directly in Sup. For attachments that you wish to use a separate program
  to view (e.g. images), you should use the mime-view hook instead.
  
  Variables:
 -   content_type: the content-type of the message
 +   content_type: the content-type of the attachment
 +        charset: the charset of the attachment, if applicable
         filename: the filename of the attachment as saved to disk
    sibling_types: if this attachment is part of a multipart MIME attachment,
                   an array of content-types for all attachments. Otherwise,
 @@ -103,6 +104,7 @@ EOS
          else
            HookManager.run "mime-decode", :content_type => content_type,
                            :filename => lambda { write_to_disk },
 +                          :charset => encoded_content.charset,
                            :sibling_types => sibling_types
          end
  
 -- 
 1.6.3.3
 
 
 From michael+sup@stapelberg.de  Fri Jul 10 16:19:14 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Fri, 10 Jul 2009 22:19:14 +0200
 Subject: [sup-talk] Validating GPG keys in parallel and in background
 Message-ID: <1247256988-sup-2799@x200>
 
 Hi,
 
 it seems like sup is blocking during the validation of GPG signed/encrypted
 mails. While for encryption it makes some sense to block, for signed mails
 it would be better to just display the message and add the information about
 the signature status later. The same approach could be used for encrypted
 messages: Display "decrypting..." and update it when done.
 
 This is especially important for big mailing lists (like debian-devel) which
 contain many signed mails.
 
 Best regards,
 Michael
 
 From dato@net.com.org.es  Sat Jul 11 07:57:55 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=)
 Date: Sat, 11 Jul 2009 13:57:55 +0200
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing
 	an nonexistent variable)
 Message-ID: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 
 Signed-off-by: Adeodato Sim? <dato at net.com.org.es>
 ---
  lib/sup/modes/thread-view-mode.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb
 index 759191e..737f6f1 100644
 --- a/lib/sup/modes/thread-view-mode.rb
 +++ b/lib/sup/modes/thread-view-mode.rb
 @@ -204,7 +204,7 @@ EOS
        end
      end
  
 -    cmd = case HookManager.run "bounce-command", :from => m.from, :to => to
 +    cmd = case (hookcmd = HookManager.run "bounce-command", :from => m.from, :to => to)
            when nil, /^$/ then defcmd
            else hookcmd
            end + ' ' + to.map { |t| t.email }.join(' ')
 -- 
 1.6.3.3
 
 
 From bwalton@artsci.utoronto.ca  Sat Jul 11 10:12:17 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 11 Jul 2009 10:12:17 -0400
 Subject: [sup-talk] sup opens multiple connections to the same
 	imap-server
 In-Reply-To: <1247185833-sup-8539@x200>
 References: <1247185833-sup-8539@x200>
 Message-ID: <1247321064-sup-4795@ntdws12.chass.utoronto.ca>
 
 Excerpts from Michael Stapelberg's message of Thu Jul 09 20:34:21 -0400 2009:
 > Is there an easy way to make sup use only one connection? If not, I?ll see
 > if this problem still arises after I re-install my server (probably with
 > dovecot instead of cyrus this time).
 
 I don't believe there is a way to do this currently.  It would require
 some refactoring of the code.
 
 Roughly:
 
 The IMAP source would refer to an IMAPManager for a connection.  The
 IMAP manager would handle creating new connections when required or
 passing a reference to an existing connection if it had already
 created.  A tuple of (imap server, username, password) could be used
 to determine the uniqueness of the request.
 
 The unsafe_connect method of the IMAP source could move to the
 IMAPManager and calls to unsafe_connect could be rerouted to
 IMAPManager.connection_for(server, user, password) or some such...
 
 It shouldn't be a bad addition to add if you're interested.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090711/4edae96c/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Sat Jul 11 10:28:58 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Sat, 11 Jul 2009 10:28:58 -0400
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
 	referencing an nonexistent variable)
 In-Reply-To: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 References: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 Message-ID: <1247322405-sup-1564@ntdws12.chass.utoronto.ca>
 
 Excerpts from Adeodato Sim?'s message of Sat Jul 11 07:57:55 -0400 2009:
 
 > Signed-off-by: Adeodato Sim? <dato at net.com.org.es>
 > ---
 >  lib/sup/modes/thread-view-mode.rb |    2 +-
 >  1 files changed, 1 insertions(+), 1 deletions(-)
 
 +1 for this.  Not sure how I managed to submit the original patch like
 this, since I did test various forms of results returned from the
 bounce-command hook...anyway, I've applied this and verified it.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090711/3b5d572f/attachment.bin>
 
 From michael+sup@stapelberg.de  Sat Jul 11 11:36:23 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sat, 11 Jul 2009 17:36:23 +0200
 Subject: [sup-talk] sup opens multiple connections to the same
 	imap-server
 In-Reply-To: <1247321064-sup-4795@ntdws12.chass.utoronto.ca>
 References: <1247185833-sup-8539@x200>
 	<1247321064-sup-4795@ntdws12.chass.utoronto.ca>
 Message-ID: <1247326506-sup-1002@x200>
 
 Hi Ben,
 
 Excerpts from Ben Walton's message of Sa Jul 11 16:12:17 +0200 2009:
 > It shouldn't be a bad addition to add if you're interested.
 Thanks for pointing out how it could be done. Unfortunately, I?ve never
 done any ruby code. I?ll have a look at sup?s source in a few weeks and
 I can try to implement it. Don?t count on it, though (meaning: if you
 can do it better/faster, go for it).
 
 Best regards,
 Michael
 
 From michael+sup@stapelberg.de  Sat Jul 11 12:53:35 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Sat, 11 Jul 2009 18:53:35 +0200
 Subject: [sup-talk] Adding/saving multiple attachments?
 Message-ID: <1247331130-sup-4923@x200>
 
 Hi,
 
 I?ve had the same problem with mutt: Isn?t there a way to add or save
 multiple attachments? Why can?t I add ~/work/foo/* when pressing 'a'?
 Why doesn?t the file browser save the last directory I?ve been in?
 Can we please get a binding to save all attachments of a message into
 a folder?
 
 Best regards,
 Michael
 
 From nico-sup@schottelius.org  Mon Jul 13 05:01:10 2009
 From: nico-sup@schottelius.org (Nico Schottelius)
 Date: Mon, 13 Jul 2009 11:01:10 +0200
 Subject: [sup-talk] Invalid character on import
 Message-ID: <20090713090110.GA20996@ikn.schottelius.org>
 
 Hello!
 
 I'm trying to import my current maildir into sup, but
 it fails with the following error:
 
 --------------------------------------------------------------------------------
 [Mon Jul 13 09:33:17 +0200 2009] scanning maildir /home/spieler/Maildir/INBOX...
 [Mon Jul 13 09:33:17 +0200 2009] no poll on cur.  mtime on indicates no new messages.
 [Mon Jul 13 09:33:17 +0200 2009] no poll on new.  mtime on indicates no new messages.
 [Mon Jul 13 09:33:18 +0200 2009] done scanning maildir
 ## read 13228m (about 84%) @ 6.1m/s. 0:36:04 elapsed, about 0:06:49 remaining
 ## read 13306m (about 84%) @ 6.1m/s. 0:36:19 elapsed, about 0:06:48 remaining
 [Mon Jul 13 09:33:34 +0200 2009] unlocking /home/spieler/.sup/lock...
 /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:647:in `iconv': " " (Iconv::InvalidCharacter)
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:647:in `easy_decode'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/message.rb:430:in `message_to_chunks'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/message.rb:209:in `load_from_source!'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/poll.rb:151:in `add_messages_from'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:130:in `each'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:127:in `upto'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:127:in `each'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:140
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:135:in `each'
 	from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:135
 	from /home/spieler/.gem/ruby/1.8/bin/sup-sync:19:in `load'
 	from /home/spieler/.gem/ruby/1.8/bin/sup-sync:19
 --------------------------------------------------------------------------------
 
 Any idea what's wrong here? sup's installed via gem install.
 
 Nico
 
 From nico-sup@schottelius.org  Mon Jul 13 05:15:16 2009
 From: nico-sup@schottelius.org (Nico Schottelius)
 Date: Mon, 13 Jul 2009 11:15:16 +0200
 Subject: [sup-talk] Slow import of messages
 Message-ID: <20090713091516.GA21214@ikn.schottelius.org>
 
 Hello!
 
 I'm looking at sup as a replacement for mutt.
 Following the idea of sup, I took a snapshot of
 my Mails from 2008-2009 (~56k mails) and run
 
    sup-sync --all-sources
 
 Now the problem is that sup gets about 3 mails per
 second into its index. That means it takes about
 
 	56k/3 ~= 15k; 15000/60 = 250 minutes
 
 That import is already from a local Maildir (synced with
 offlineimap).
 
 For me, this is incredibly slow. Using mutt it's way faster,
 not even comparing the fact the speed improvement you get
 when dividing into folders.
 
 What's your impression? Am I totally wrong or is sup just
 the wrong tool for handling a lot of messages?
 
 Sincerly,
 
 Nico
 
 From michael+sup@stapelberg.de  Mon Jul 13 05:26:14 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Mon, 13 Jul 2009 11:26:14 +0200
 Subject: [sup-talk] Slow import of messages
 In-Reply-To: <20090713091516.GA21214@ikn.schottelius.org>
 References: <20090713091516.GA21214@ikn.schottelius.org>
 Message-ID: <1247477044-sup-6433@midna>
 
 Hi Nico,
 
 Excerpts from Nico Schottelius's message of Mo Jul 13 11:15:16 +0200 2009:
 > I'm looking at sup as a replacement for mutt.
 > Following the idea of sup, I took a snapshot of
 > my Mails from 2008-2009 (~56k mails) and run
 I have about 33k emails on my IMAP server in my LAN.
 
 > Now the problem is that sup gets about 3 mails per
 > second into its index. That means it takes about
 I got around 10 MB/s performance using sup-sync. Maybe
 your mails are all very large, I don?t know. Maybe maildir is
 just a lot slower than IMAP in sup-sync.
 
 > What's your impression? Am I totally wrong or is sup just
 > the wrong tool for handling a lot of messages?
 My impression is that sup-sync can definitely be improved regarding
 its speed. I?m not sure if it is actually doable or if it is some ruby
 library (Ferret?) which is the limiting factor here. However, it was
 not as bad for me as it is for you ;-).
 
 Best regards,
 Michael
 
 From nicolas.pouillard@gmail.com  Mon Jul 13 16:17:26 2009
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 13 Jul 2009 22:17:26 +0200
 Subject: [sup-talk] Invalid character on import
 In-Reply-To: <20090713090110.GA20996@ikn.schottelius.org>
 References: <20090713090110.GA20996@ikn.schottelius.org>
 Message-ID: <1247516120-sup-3116@ausone.local>
 
 Excerpts from Nico Schottelius's message of Mon Jul 13 11:01:10 +0200 2009:
 > Hello!
 Hello,
 
 > I'm trying to import my current maildir into sup, but
 > it fails with the following error:
 
 The fix is trivial, I've submitted a merge request for exactly this:
 
 http://gitorious.org/~ertai/sup/clone-by-ertai
 
 -- 
 Nicolas Pouillard
 http://nicolaspouillard.fr
 
 From jim@gonzul.net  Mon Jul 13 17:22:04 2009
 From: jim@gonzul.net (Jim Cheetham)
 Date: Tue, 14 Jul 2009 09:22:04 +1200
 Subject: [sup-talk] Slow import of messages
 In-Reply-To: <20090713091516.GA21214@ikn.schottelius.org>
 References: <20090713091516.GA21214@ikn.schottelius.org>
 Message-ID: <f4cc59760907131422p3dd1d429ka9d334e509b992d7@mail.gmail.com>
 
 On Mon, Jul 13, 2009 at 9:15 PM, Nico
 Schottelius<nico-sup at schottelius.org> wrote:
 > What's your impression? Am I totally wrong or is sup just
 > the wrong tool for handling a lot of messages?
 
 No, it's just slow to index for the first time. Unless you receive
 1000s of messages per hour, you should be OK ...
 
 -jim
 
 From lcanas@libresoft.es  Mon Jul 13 17:20:22 2009
 From: lcanas@libresoft.es (Luis =?ISO-8859-1?Q?Ca=F1as_D=EDaz?=)
 Date: Mon, 13 Jul 2009 23:20:22 +0200
 Subject: [sup-talk] problems with Maildir and IMAP offline
 Message-ID: <20090713232022.fe1d4839.lcanas@libresoft.es>
 
 Hi guys,
 first things first. Your mail client looks promising, I've been testing many of them (most of them from the kde/gnome world) and yours seems to be perfect to be running in my dear mac mini ;)
 
 This afternoon I've been trying to set up a gmail account with offlineimap and I'm having the same problem reported by this guy[1]. I run offlineimap and it creates a Maildir directory with 4hundred read mails and 2hundred unread mails (yes, I should pay more attention to my gmail account;). The problem is that sup sees all of the messages as unread which is not true according to the Maildir structure:
 
    [luis at gongbu INBOX]$ ls new/|wc -l;ls cur/|wc -l
    210
    412
 
 After applying changes with sup, the state is the same. When using sup I "delete" messages and mark them as read.
 
 The sup version is: 
 
    [luis at gongbu ~]$ sup -v
    [Mon Jul 13 23:14:25 +0200 2009] using character set encoding "UTF-8"
    sup v0.8.1
 
 Last thing, I haven't seen it written by I guess it's a good idea having the files locally to use the search engine. Am I right?
 
 Thanks for your help! :)
 
 [1] http://osdir.com/ml/mail.sup.general/2008-08/msg00029.html
 
 -- 
 Luis Ca?as D?az          | GSyC/LibreSoft Research Lab
 http://libresoft.es      | Grupo de Sistemas y Comunicaciones
 Tel: (+34) 91 488 85 23  | Universidad Rey Juan Carlos
 
 From garoth@gmail.com  Tue Jul 14 09:24:32 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 14 Jul 2009 09:24:32 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <20090713232022.fe1d4839.lcanas@libresoft.es>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 Message-ID: <1247577490-sup-7098@Longbow>
 
 Excerpts from Luis Ca?as D?az's message of Mon Jul 13 17:20:22 -0400 2009:
 > After applying changes with sup, the state is the same. When using sup I
 > "delete" messages and mark them as read.
 I'm somewhat unhappy about this too. It seems to me that sup just plain
 does not support the read features of maildirs.
  a) It doesn't import them as read
  b) sup-sync-back does not mark them as read.
 
 The best I could find is manually marking things as read and deleting
 them, and then using sup-sync-back with the deleted options which it
 does understand.
 
 On the other hand, sup provides hooks to make calling offlineimap and
 sup-sync-back completely transparent and well-timed. You can call
 sup-sync-back followed by offlineimap on each sup poll, so that's pretty
 sweet.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From garoth@gmail.com  Tue Jul 14 10:02:11 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 14 Jul 2009 10:02:11 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 Message-ID: <1247580020-sup-9946@Longbow>
 
 Excerpts from Tim Gray's message of Tue Jul 14 09:45:44 -0400 2009:
 > On Tue 14, Jul'09 at  9:24 AM -0400, Andrei Thorp wrote:
 > 
 > > a) It doesn't import them as read
 > > b) sup-sync-back does not mark them as read.
 
 I'm forwarding a summary of your message with my replies to the mailing
 list. It seems like you replied to me only by accident?
 
 >   From my playing around with sup and from what I've read, sup just doesn't 
 > play nicely with other mail clients.  Sup will read from your sources, but 
 > the sources never get modified.
 
 Again, see sup-sync-back -- it does indeed have _some_ ability to write
 its state back to the source.
 
 > I know sup is slowly moving in the direction of a more locked in design.  I 
 > just wish sup added automatic sync back capabilities.
 
 Put this in a hook and it's automatic. That's the beauty of the
 hook/multiple binary design.
 
 > As far as OfflineIMAP goes, I didn't think I would do this, but I've been 
 > running it in it's full curses mode with an auto refresh set.
 
 I'm not entirely sure why you want this. If you're worried about
 failures, do they really happen? If you want to see the log, aren't you
 already piping it? If you want notifications, you could hook them up to
 happen in your sup hook (the one I described before) rather trivially
 via notify-send.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From lists+sup@protozoic.com  Tue Jul 14 11:00:34 2009
 From: lists+sup@protozoic.com (Tim Gray)
 Date: Tue, 14 Jul 2009 11:00:34 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <1247580020-sup-9946@Longbow>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 	<1247580020-sup-9946@Longbow>
 Message-ID: <20090714150034.GA393@d228.scdc1.swarthmore.edu>
 
 On Tue 14, Jul'09 at 10:02 AM -0400, Andrei Thorp wrote:
 
 > I'm forwarding a summary of your message with my replies to the mailing
 > list. It seems like you replied to me only by accident?
 
 Whoops.  I didn't realize this list didn't have reply-to set.  Thanks.
 
 > Again, see sup-sync-back -- it does indeed have _some_ ability to write
 > its state back to the source.
 
 To me, this is a vital feature of any mail client.  I'll look into it, but I 
 would really like this to be fully integrated into my mail client.  And from 
 I've read, this isn't something that's going to happen.
 
 Sometimes I need to use mutt/pine.  Sometimes webmail.  Most importantly, I 
 want all my mail in a form that is easy to backup, human readable, and can 
 be manipulated with standard utilities.  Maildir fits the bill.
 
 I think it'd be fantastic if there was a mail client that allowed you to 
 sort by folders, but also provided a sup-like view that laid on top if/when 
 you needed.
 
 > Put this in a hook and it's automatic. That's the beauty of the
 > hook/multiple binary design.
 
 Honestly, if it's that easy, shouldn't it be configured like that out of the 
 box?
 
 > I'm not entirely sure why you want this. If you're worried about
 > failures, do they really happen? If you want to see the log, aren't you
 > already piping it? If you want notifications, you could hook them up to
 > happen in your sup hook (the one I described before) rather trivially
 > via notify-send.
 
 For use with other mail clients for one.  It's kind of nice having my IMAP 
 syncing separate from the mail client.  I'm sure I could run it 
 automatically via cron, but then you'd have to give up the quick refresh 
 capability (minor) and the IDLE mode.  Sure, I could pipe the output 
 somewhere else, but wouldn't that accomplish the same thing as just looking 
 at the output already provided, either curses or one of the other ones? 
 Again, it's running in screen so I don't even have it open on any windows.
 
 Of course, that doesn't mean this is the best route to go, but it's been 
 working for me for so far - I am new to it though.  It's a nice pretty 
 colored interface too :)
 
 Tim
 
 From bwalton@artsci.utoronto.ca  Tue Jul 14 11:07:46 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 14 Jul 2009 11:07:46 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <20090714150034.GA393@d228.scdc1.swarthmore.edu>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 	<1247580020-sup-9946@Longbow>
 	<20090714150034.GA393@d228.scdc1.swarthmore.edu>
 Message-ID: <1247584002-sup-504@ntdws12.chass.utoronto.ca>
 
 Excerpts from Tim Gray's message of Tue Jul 14 11:00:34 -0400 2009:
 > > Again, see sup-sync-back -- it does indeed have _some_ ability to write
 > > its state back to the source.
 > 
 > To me, this is a vital feature of any mail client.  I'll look into it, but I 
 > would really like this to be fully integrated into my mail client.  And from 
 > I've read, this isn't something that's going to happen.
 
 There was some talk a while back about modifying the behaviour of
 Maildir sources.  The issue was that there is an odd scanning bug with
 Maildir that sometimes sees messages get skipped.  A proposed solution
 was to have sup start 'playing nice' with Maildir so that when new
 messages were found in new/, they'd be indexed and recorded with a
 filename in cur/, presumably with the S (seen) flag appended properly.
 
 I _think_ William was looking at that, but I'm not sure.  It's
 something I'd like too (not to play nice with other clients, but
 because it's "just better").  I haven't had much time lately, but if
 William confirms he's not working on it, I'd be interested in
 implementing it.
 
 Thanks
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090714/e30a5b14/attachment.bin>
 
 From garoth@gmail.com  Tue Jul 14 11:14:50 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 14 Jul 2009 11:14:50 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <20090714150034.GA393@d228.scdc1.swarthmore.edu>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 	<1247580020-sup-9946@Longbow>
 	<20090714150034.GA393@d228.scdc1.swarthmore.edu>
 Message-ID: <1247584404-sup-7126@Longbow>
 
 Excerpts from Tim Gray's message of Tue Jul 14 11:00:34 -0400 2009:
 > On Tue 14, Jul'09 at 10:02 AM -0400, Andrei Thorp wrote:
 > > Put this in a hook and it's automatic. That's the beauty of the
 > > hook/multiple binary design.
 > 
 > Honestly, if it's that easy, shouldn't it be configured like that out of the 
 > box?
 
 People perhaps don't want this. It's slower, and a lot of folks probably
 do no syncing back since all they use is sup anyway.
 
 > > I'm not entirely sure why you want this. If you're worried about
 > > failures, do they really happen? If you want to see the log, aren't you
 > > already piping it? If you want notifications, you could hook them up to
 > > happen in your sup hook (the one I described before) rather trivially
 > > via notify-send.
 > 
 > For use with other mail clients for one.
 
 Understood. Makes sense in your use case. I don't really understand why
 you'd want to use pine/mutt when you've already got sup though ;)
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From lists+sup@protozoic.com  Tue Jul 14 11:28:06 2009
 From: lists+sup@protozoic.com (Tim Gray)
 Date: Tue, 14 Jul 2009 11:28:06 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <1247584002-sup-504@ntdws12.chass.utoronto.ca>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 	<1247580020-sup-9946@Longbow>
 	<20090714150034.GA393@d228.scdc1.swarthmore.edu>
 	<1247584002-sup-504@ntdws12.chass.utoronto.ca>
 Message-ID: <20090714152806.GC393@d228.scdc1.swarthmore.edu>
 
 On Tue 14, Jul'09 at 11:07 AM -0400, Ben Walton wrote:
 > It's something I'd like too (not to play nice with other clients, but
 > because it's "just better").
 
 This sound like a good thing.  In my experience, 'just better' usually 
 equals 'playing nice', since 'playing nice' usually equals following the 
 standards.  That's how Maildirs are supposed to work - if everybody followed 
 the spec, we'd be set.
 
 Though I don't program for a living, nor do I know any Ruby, it seems like a 
 doable thing.  Is there something fundamental blocking per-message sync-back 
 of status as you read/delete/otherwise modify your mail?  I would assume 
 there a reference to the original message location in a message's database 
 entry.  If a message gets read, write an S at the end of the filename and 
 move it to /cur.  If it gets deleted, delete it.  Operations on a message 
 should affect the database and the mail store at the same time.  Why is 
 something like sup-sync-back even necessary?
 
 Anyway, these are just the musings of someone who doesn't have the tools to 
 write something like sup, so I'll be quiet now before I embarrass myself any 
 further.
 
 From garoth@gmail.com  Tue Jul 14 11:39:09 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Tue, 14 Jul 2009 11:39:09 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <20090714152806.GC393@d228.scdc1.swarthmore.edu>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 	<1247580020-sup-9946@Longbow>
 	<20090714150034.GA393@d228.scdc1.swarthmore.edu>
 	<1247584002-sup-504@ntdws12.chass.utoronto.ca>
 	<20090714152806.GC393@d228.scdc1.swarthmore.edu>
 Message-ID: <1247585761-sup-5167@Longbow>
 
 Excerpts from Tim Gray's message of Tue Jul 14 11:28:06 -0400 2009:
 > On Tue 14, Jul'09 at 11:07 AM -0400, Ben Walton wrote:
 > > It's something I'd like too (not to play nice with other clients, but
 > > because it's "just better").
 > 
 > This sound like a good thing.  In my experience, 'just better' usually 
 > equals 'playing nice', since 'playing nice' usually equals following the 
 > standards.  That's how Maildirs are supposed to work - if everybody followed 
 > the spec, we'd be set.
 
 I'd just like to mention that the reason we tend not to sync back in
 general isn't because we hate standards and want people to get hurt :)
 
 It's roughly because of the extra features in sup:
  - It keeps a database so it can search for stuff quickly
  - It implements its own tagging regardless of source (unlike stuff like
    mutt that just rely on "physical" folders)
  - It merges sources
 
 So while it's possible to do some merging back, it's sometimes awkward
 because sup's tags do not have to map 1:1 to IMAP folders or anything
 else. It's otherwise also a bit awkward because we might have mail from
 many sources in one place, so writing back isn't as simple as just
 editing files. You also have to _not_ edit files.
 
 Anyway, that all said, it's clearly possible and would be very nice to
 have.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From lists+sup@protozoic.com  Tue Jul 14 11:45:07 2009
 From: lists+sup@protozoic.com (Tim Gray)
 Date: Tue, 14 Jul 2009 11:45:07 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <1247584404-sup-7126@Longbow>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 	<1247580020-sup-9946@Longbow>
 	<20090714150034.GA393@d228.scdc1.swarthmore.edu>
 	<1247584404-sup-7126@Longbow>
 Message-ID: <20090714154507.GD393@d228.scdc1.swarthmore.edu>
 
 On Tue 14, Jul'09 at 11:14 AM -0400, Andrei Thorp wrote:
 > People perhaps don't want this. It's slower, and a lot of folks probably
 > do no syncing back since all they use is sup anyway.
 
 I would hope in this day in age we can change a database entry and move a 
 file at the same time without too much of a performance hit.  I would think 
 it only gets unbearable when you don't update as you go and you have to do a 
 large batch of messages.  But you are right, maybe people don't want that.
 
 Personally, and this is a side note, if I was involved in the project, I'd 
 push for canning the built in IMAP capabilities all together.  Just run 
 offlineimap or one of the other IMAP syncing utilities.  Add to that beefing 
 up the Maildir handling.  Just worry about better and more transparent 
 sync-back-to-Maildir capabilities and let offlineimap worry about the server 
 side of the equation.
 
 > Understood. Makes sense in your use case. I don't really understand why
 > you'd want to use pine/mutt when you've already got sup though ;)
 
 As you can tell, I'm not quite sold on sup yet.  I've switched mail clients 
 enough over the past few years that switching in and of itself is a giant 
 pain.  I've settled on Maildir as my 'client' for now.  I can serve it via 
 IMAP if I need, I can read it with a couple mail clients, and I can easily 
 convert it to mbox however I want to with some simple Python code.
 
 If I switch to sup full time, I would be comforted by the fact that if I 
 choose to change in 2 years, all of my mail is marked read, deleted mail is 
 actually deleted, and even though I was using sup labels for my 
 organization, things are still organized in some fashion by appropriate 
 folders on the file system.  The last part could be achievable by some 
 combination of offlineimap + gmail/sieve filtering and fetchmail/getmail + 
 procmail.  It'd still be nice to be able to move physical messages around in 
 sup though.  Maybe I'm just nuts though.
 
 From lists+sup@protozoic.com  Tue Jul 14 11:59:16 2009
 From: lists+sup@protozoic.com (Tim Gray)
 Date: Tue, 14 Jul 2009 11:59:16 -0400
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <1247585761-sup-5167@Longbow>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 	<1247577490-sup-7098@Longbow>
 	<20090714134544.GD90157@d228.scdc1.swarthmore.edu>
 	<1247580020-sup-9946@Longbow>
 	<20090714150034.GA393@d228.scdc1.swarthmore.edu>
 	<1247584002-sup-504@ntdws12.chass.utoronto.ca>
 	<20090714152806.GC393@d228.scdc1.swarthmore.edu>
 	<1247585761-sup-5167@Longbow>
 Message-ID: <20090714155916.GE393@d228.scdc1.swarthmore.edu>
 
 On Tue 14, Jul'09 at 11:39 AM -0400, Andrei Thorp wrote:
 > I'd just like to mention that the reason we tend not to sync back in
 > general isn't because we hate standards and want people to get hurt :)
 
 Haha.  Of course.
 
 > It's roughly because of the extra features in sup:
 
 I got you.  Still, I envisage a mail client that has an underlying structure 
 built on folders.  On top of that a database/virtual folder interface is 
 built.  Of course, you'd have the ability to access the folder based 
 structure when needed.  So you could move a message or a conversation to a 
 given folder if you want.
 
 For example, I have work emails for a certain project with a given label. 
 It's wonderful that in sup, those currently in my physical inbox and those 
 currently in an archive folder somewhere show up under the same label in 
 sup.  But there's no mechanism to moving those in my physical inbox to the 
 archive folder.  Some might say who cares, but I can't leave all my email in 
 my physical inbox forever, which is synced by offlineimap, because people 
 associated with this project have a nasty habit of sending 10-20 mb 
 attachments and I don't want to clutter up my IMAP boxes with hundreds of 
 megs of attachments forever.  Heck, I can't do that unless I have an IMAP 
 service with 25 gigs of storage.*  Sometimes they just need to be collected 
 in a totally offline box, but somewhere that is still accessible by 
 searching if I need access to it.
 
 Sup is pretty close to this already, minus the access to the underlying 
 structure.
 
 ---
 
 [*] Obviously for those of you using Gmail, this isn't an issue.  Who cares 
 about deleting messages?
 
 From isra@herraiz.org  Tue Jul 14 12:21:45 2009
 From: isra@herraiz.org (Israel Herraiz)
 Date: Tue, 14 Jul 2009 18:21:45 +0200
 Subject: [sup-talk] problems with Maildir and IMAP offline
 In-Reply-To: <20090713232022.fe1d4839.lcanas@libresoft.es>
 References: <20090713232022.fe1d4839.lcanas@libresoft.es>
 Message-ID: <1247587742-sup-5619@elly>
 
 Excerpts from Luis's message on Jul 13, 2009 about 11 PM:
 > This afternoon I've been trying to set up a gmail account with offlineimap and
 > I'm having the same problem reported by this guy[1]. I run offlineimap and it
 > creates a Maildir directory with 4hundred read mails and 2hundred unread mails
 > (yes, I should pay more attention to my gmail account;).
 
 I have not used IMAP with Sup, but AFAIK, Sup does not touch the
 original sources of email. For instance, it does not read nor modify
 messages using IMAP, it just read them using that protocol (or maildir
 or whatever).
 
 Therefore, the only way to get those messages marked as read is using
 sup-sync with the --read option. That will mark the messages as read
 in Sup.
 
 However there are two problems. If all the messages (unread or read)
 are in the same source, there is no way to indicate which messages are
 going to be marked as read and which are not.
 
 Moreover, if you read a message in Sup, it still will appear in Gmail
 as unread.
 
 I also use Gmail with Sup, but using POP. I use the web interface of
 Gmail when I cannnot access my laptop. I use IMAP from my mobile
 phone. And I download all my email to my laptop using POP.
 
 If I get a message in my laptop, it is marked as archived and read in
 GMail, so it does not appear as unread in the web nor in my phone.
 
 However, if I read the message in the phone or the web, it will appear
 as unread in Sup.
 
 Still it is a good solution if you have a "central" node where you
 store your mail, and do your main work (my laptop), and a couple of
 "external" agents (phone, web) to be able of reading your email if you
 do not have your laptop at hand.
 
 Another advantage is that you keep a copy of your mail in your
 laptop. GMail is not going to last forever (of course, it still has a
 long live) and with this you ensure that you will not loose your
 old-email in GMail is closed some day, and it is also very handy to
 make backups of all your email (just copy the mbox file to another
 location).
 
 To get the email I use getmail [1], and msmtp [2] with these scripts
 [3] (see last section) as a lightweight replacement for sendmail. I
 can provide you my config scripts if you want.
 
 It is not a good solution though if you read your email from several
 different computers.
 
 Cheers,
 Israel
 
 [1] http://pyropus.ca/software/getmail/
 [2] http://msmtp.sourceforge.net/
 [3] http://wiki.archlinux.org/index.php/Msmtp
 
 From johnbent@lanl.gov  Tue Jul 14 11:43:01 2009
 From: johnbent@lanl.gov (John Bent)
 Date: Tue, 14 Jul 2009 09:43:01 -0600
 Subject: [sup-talk] Using sup on multiple computers?
 In-Reply-To: <1247186181-sup-1712@x200>
 References: <1247186181-sup-1712@x200>
 Message-ID: <1247585908-sup-4190@tangerine.lanl.gov>
 
 Excerpts from Michael Stapelberg's message of Thu Jul 09 18:38:25 -0600
 2009:
 > Hi,
 > 
 > I?d like to use sup on my notebook and on my workstation. Is there any
 > simple/recommended way to synchronize the index? I figured using
 > multiple clients in parallel is one of the big advantages of IMAP and
 > I?d love to keep it that way while using sup.
 > 
 This won't really answer your exact question but I also use sup on a
 workstation and a notebook.  What I do is run sup in a screen session on
 the workstation and then connect to it from the laptop.  The window size
 is different on the workstation and the laptop so whenever I switch, I
 have to do:
 
 <ctr-a>F : to get screen to resize
 @        : to get sup to redraw itself
 
 Hope that helps,
 
 John
 > Best regards,
 > Michael
 
 From bwalton@artsci.utoronto.ca  Tue Jul 14 15:33:36 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 14 Jul 2009 15:33:36 -0400
 Subject: [sup-talk] Using sup on multiple computers?
 In-Reply-To: <1247585908-sup-4190@tangerine.lanl.gov>
 References: <1247186181-sup-1712@x200> <1247585908-sup-4190@tangerine.lanl.gov>
 Message-ID: <1247599899-sup-811@ntdws12.chass.utoronto.ca>
 
 Excerpts from John Bent's message of Tue Jul 14 11:43:01 -0400 2009:
 > @        : to get sup to redraw itself
 
 Try Ctrl+L for the redraw.  Saves having sup do any work at all.  This
 is also good for when the display gets corrupted in screen.  It's a
 pretty standard sequence too, so you may find it applicable elsewhere
 (eg: it'll clear your terminal for you, redraw and centre a buffer in
 emacs, etc).
 
 HTH.
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090714/143b6aca/attachment.bin>
 
 From michael+sup@stapelberg.de  Tue Jul 14 15:35:12 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Tue, 14 Jul 2009 21:35:12 +0200
 Subject: [sup-talk] Using sup on multiple computers?
 In-Reply-To: <1247585908-sup-4190@tangerine.lanl.gov>
 References: <1247186181-sup-1712@x200> <1247585908-sup-4190@tangerine.lanl.gov>
 Message-ID: <1247600011-sup-635@midna>
 
 Hi John,
 
 Excerpts from John Bent's message of Di Jul 14 17:43:01 +0200 2009:
 > <ctr-a>F : to get screen to resize
 > @        : to get sup to redraw itself
 > Hope that helps,
 Thanks, that?s at least a good start to get where I was with mutt. However,
 it does not solve the other problems (GUI traffic/latency vs. IMAP,
 opening/adding attachments).
 
 Best regards,
 Michael
 
 From rgh@roughage.com.au  Fri Jul 17 19:42:07 2009
 From: rgh@roughage.com.au (Richard Heycock)
 Date: Sat, 18 Jul 2009 09:42:07 +1000
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1246022094-sup-3336@entry>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry>
 Message-ID: <1247873980-sup-8574@wrasse>
 
 Excerpts from William Morgan's message of Fri Jun 26 23:49:40 +1000 2009:
 > Reformatted excerpts from Olly Betts's message of 2009-06-25:
 > > I'll make sure this fix makes it into the next Xapian release (which
 > > will be 1.0.14).
 > 
 > Awesome, thanks!
 > 
 > Though even with SWIG fixed there will still be some tweaking necessary
 > in Sup because the logistic function used for generating Xapian docids
 > still has trouble with extreme dates.
 > 
 > BTW, more kudos to Rich for somehow finding a way to use a logistic
 > function in an email client.
 
 I've been meaning to respond to this the day this was posted. Rich Lane
 thank you, thank you. Ferret was one of by biggest gripes of using sup.
 I've used it elsewhere and it's a shocker; I eventually migrated it all
 to Xapian which has worked flawlessly since. I used to rebuild by ferret
 index almost on a weekly basis (I'm running debian unstable, which at
 the moment is really living up to it's name) at one stage something I
 haven't had to do once since migrating to Xapian.
 
 I got it work with 1.9 once but there are some problems that I just
 haven't had the time to look into but I will do and post any problems to
 the list.
 
 rgh
 
 From lee@yun.yagibdah.de  Sat Jul 18 03:41:51 2009
 From: lee@yun.yagibdah.de (lee)
 Date: Sat, 18 Jul 2009 01:41:51 -0600
 Subject: [sup-talk] trying out sup ...
 Message-ID: <20090718074151.GF30748@cat.rubenette.is-a-geek.com>
 
 Hi,
 
 I've started trying out sup on Debian Testing amd64. Searching didn't
 work, so I installed a replacement library[1] after finding a bug
 report[2].
 
 Now the search would work, but when I'm trying to enter something to
 search for or only press enter to see a list of labels I used, no
 matches are found, and the status line shows some garbage characters
 as string that has been searched for. This happens when sup is running
 in an xterm or in rxvt; it doesn't happen when I switch to the console
 and run sup there.
 
 So I had sup running on the console and tried out to search for
 something while sup was looking for new messages in a maildir. But
 then it crashed and told me I should send a bug report[3].
 
 Maybe I have created some incompatibilities by installing the
 replacement library. But is it currently possible to run sup on Debian
 Testing without too much difficulty? If so, what do I need to do?
 
 
 [1]:
 http://apt.rupamsunyata.org/sup/libncurses-ruby1.8_1.2.3-0.2_amd64.deb
 [2]:
 http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/d79896cacc28e0e8/7a76dece1e5ef6a3?lnk=raot
 [3]: ~/.sup/exception-log.txt:
 
 --- NoMethodError from thread: poll after loading inbox
 undefined method `content_width' for nil:NilClass
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:747:in `from_width'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:672:in `text_for_thread_at'
 /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `each'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `each_with_index'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `text_for_thread_at'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:632:in `regen_text'
 /usr/lib/ruby/1.8/sup/util.rb:344:in `map_with_index'
 /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index'
 /usr/lib/ruby/1.8/sup/util.rb:344:in `each'
 /usr/lib/ruby/1.8/sup/util.rb:344:in `each_with_index'
 /usr/lib/ruby/1.8/sup/util.rb:344:in `map_with_index'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:632:in `regen_text'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:219:in `update'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:576:in `add_or_unhide'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:181:in `handle_added_update'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `send'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `relay'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `each'
 /usr/lib/ruby/1.8/sup/update.rb:27:in `relay'
 /usr/lib/ruby/1.8/sup/util.rb:499:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing'
 /usr/lib/ruby/1.8/sup/poll.rb:161:in `add_messages_from'
 /usr/lib/ruby/1.8/sup/maildir.rb:130:in `each'
 /usr/lib/ruby/1.8/sup/maildir.rb:127:in `upto'
 /usr/lib/ruby/1.8/sup/maildir.rb:127:in `each'
 /usr/lib/ruby/1.8/sup/util.rb:538:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:538:in `__pass'
 /usr/lib/ruby/1.8/sup/util.rb:525:in `method_missing'
 /usr/lib/ruby/1.8/sup/poll.rb:141:in `add_messages_from'
 /usr/lib/ruby/1.8/sup/poll.rb:98:in `do_poll'
 /usr/lib/ruby/1.8/sup/poll.rb:86:in `each'
 /usr/lib/ruby/1.8/sup/poll.rb:86:in `do_poll'
 /usr/lib/ruby/1.8/sup/poll.rb:85:in `synchronize'
 /usr/lib/ruby/1.8/sup/poll.rb:85:in `do_poll'
 /usr/lib/ruby/1.8/sup/util.rb:499:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing'
 /usr/lib/ruby/1.8/sup/modes/poll-mode.rb:17:in `poll'
 /usr/lib/ruby/1.8/sup/poll.rb:53:in `poll'
 /usr/lib/ruby/1.8/sup/util.rb:499:in `send'
 /usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing'
 /usr/bin/sup-mail:173
 /usr/lib/ruby/1.8/sup.rb:84:in `reporting_thread'
 /usr/lib/ruby/1.8/sup.rb:82:in `initialize'
 /usr/lib/ruby/1.8/sup.rb:82:in `new'
 /usr/lib/ruby/1.8/sup.rb:82:in `reporting_thread'
 /usr/bin/sup-mail:173
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:543:in `call'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:543:in `__unprotected_load_threads'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:485:in `call'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:485:in `load_n_threads_background'
 /usr/lib/ruby/1.8/sup.rb:84:in `reporting_thread'
 /usr/lib/ruby/1.8/sup.rb:82:in `initialize'
 /usr/lib/ruby/1.8/sup.rb:82:in `new'
 /usr/lib/ruby/1.8/sup.rb:82:in `reporting_thread'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:483:in `load_n_threads_background'
 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:553:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /usr/bin/sup-mail:173
 
 From michael+sup@stapelberg.de  Mon Jul 20 08:34:56 2009
 From: michael+sup@stapelberg.de (Michael Stapelberg)
 Date: Mon, 20 Jul 2009 14:34:56 +0200
 Subject: [sup-talk] [PATCH] GSSAPI support for net/imap.rb and sup
 Message-ID: <1248092732-sup-9960@midna>
 
 Hi,
 
 since I installed my new mailserver with Kerberos auth only, I needed to
 implement GSSAPI support for Net::IMAP and sup.
 
 I found the C bindings called ruby-gss at:
 http://devel.it.su.se/pub/jsp/polopoly.jsp?d=1047&a=3790
 
 Using them (and adding the wrap/unwrap methods for a context, see
 03-ruby-gss.patch), it was relatively easy to implement GSSAPIAuthenticator
 (see 02-net_imap-gssapi.patch). The addition of the authenticator to sup is
 trivial (see 01-sup_gssapi.patch).
 
 Here comes the catch:
 As I?m not very much involved in the ruby community (in fact, this is my first
 piece of ruby code), I need someone to help me get things upstream (for
 Net::IMAP in the first place, but someone maintaining ruby-gss would be great).
 As for the sup patch, I think this already is the right place to post it ;-).
 
 Short installation instructions for those not so familiar with ruby:
 $ cd ruby-gss
 $ ruby extconf.rb
 $ make
 $ sudo make install
 # patch /usr/lib/ruby/1.8/net/imap.rb
 # patch /usr/lib/ruby/1.8/sup/imap.rb
 
 Best regards,
 Michael
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 01-sup_gssapi.patch
 Type: application/octet-stream
 Size: 1936 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090720/9d9a88ec/attachment.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 02-net_imap_gssapi.patch
 Type: application/octet-stream
 Size: 2373 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090720/9d9a88ec/attachment-0001.obj>
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: 03-ruby-gss.patch
 Type: application/octet-stream
 Size: 2891 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090720/9d9a88ec/attachment-0002.obj>
 
 From sgoldman@tower-research.com  Wed Jul 22 21:10:41 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Wed, 22 Jul 2009 21:10:41 -0400
 Subject: [sup-talk] Choose "From:" address based on message content?
 Message-ID: <1248311332-sup-1053@sgoldmanlinux.tower-research.com>
 
 
 Here's what I want:
 
 After I compose an email (new or a reply), I want sup to grep the
 entire message (recipients, subject, body, etc.) for a single word and
 choose address A if that word is there and address B otherwise.
 
 Can sup do it?
 
 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 sgoldman@tower-research.com  Wed Jul 22 22:51:54 2009
 From: sgoldman@tower-research.com (Steve Goldman)
 Date: Wed, 22 Jul 2009 22:51:54 -0400
 Subject: [sup-talk] Choose "From:" address based on message content?
 In-Reply-To: <1248311332-sup-1053@sgoldmanlinux.tower-research.com>
 References: <1248311332-sup-1053@sgoldmanlinux.tower-research.com>
 Message-ID: <1248317360-sup-4094@sgoldmanlinux.tower-research.com>
 
 Excerpts from Steve Goldman's message of Wed Jul 22 21:10:41 -0400 2009:
 > 
 > Here's what I want:
 > 
 > After I compose an email (new or a reply), I want sup to grep the
 > entire message (recipients, subject, body, etc.) for a single word and
 > choose address A if that word is there and address B otherwise.
 > 
 > Can sup do it?
 > 
 > Thanks.
 > 
 
 I think I answered my own question.
 
 I added an "after-edit" hook call in edit-message-mode.rb and wrote a
 hook that looks like this:
 
 
 require 'eregex'
 
 r = Regexp.new('word', Regexp::IGNORECASE);
 if header.to_s.grep(r).size > 0 or body.to_s.grep(r).size > 0
   header["From"] = "Steve Goldman <sgoldman at other-address.com>"
 end
 -- 
 
 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 dato@net.com.org.es  Thu Jul 23 05:35:43 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Thu, 23 Jul 2009 11:35:43 +0200
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
 	variable with	the attachment charset
 In-Reply-To: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 Message-ID: <20090723093543.GA2265@chistera.yi.org>
 
 + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
 
 > +                          :charset => encoded_content.charset,
 
 Hm, so apparently encoded_content doesn't always have a charset
 member...
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From dato@net.com.org.es  Thu Jul 23 06:23:25 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Thu, 23 Jul 2009 12:23:25 +0200
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1247873980-sup-8574@wrasse>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 Message-ID: <20090723102325.GA4291@chistera.yi.org>
 
 + Richard Heycock (Sat, 18 Jul 2009 09:42:07 +1000):
 
 > I've been meaning to respond to this the day this was posted. Rich Lane
 > thank you, thank you. Ferret was one of by biggest gripes of using sup.
 > I've used it elsewhere and it's a shocker; I eventually migrated it all
 > to Xapian which has worked flawlessly since. I used to rebuild by ferret
 > index almost on a weekly basis (I'm running debian unstable, which at
 > the moment is really living up to it's name) at one stage something I
 > haven't had to do once since migrating to Xapian.
 
 Yeah, thanks Rich! However, there seems to be something wrong with the
 parsing of contacts. After reindexing with Xapian, my contact list has
 entries like:
 
   <dato                                        <dato at net.com.org.esadeodato
   <other                                       <other at foo.ua.esfoo
   dato at net.com.org.esAdeodato Simo             other2 at domain.netother2 surname2
 
 Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
 inspection of the code, it doesn't look to me as random negated labels
 are being parsed.
 
 Any hints?
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From dato@net.com.org.es  Thu Jul 23 13:12:58 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=)
 Date: Thu, 23 Jul 2009 19:12:58 +0200
 Subject: [sup-talk] [RFC] Fix parsing of encrypted messages that contain
 	further multipart elements
 Message-ID: <ff7df0405d003a8f4e88f0dd191d8bf4875f73f3.1248368899.git.dato@net.com.org.es>
 
 ---
 Hello,
 
 this is just a RFC, because I can't think of any elegant way to address
 the issue, given the shortcomings of the RMail API. Please read the
 lengthy comment in the patch, and let me know if anybody has any ideas
 about this issue.
 
 P.S.: I've created a "sup-dato" repository in Gitorious, in case that's
 helpful. Should I be creating merge requests?
 
  lib/sup/crypto.rb |   19 ++++++++++++++++++-
  1 files changed, 18 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
 index 8ec277b..6ef0c0e 100644
 --- a/lib/sup/crypto.rb
 +++ b/lib/sup/crypto.rb
 @@ -132,8 +132,25 @@ class CryptoManager
            end
          end
  
 +      # This is gross. The decrypted payload could very well be a multipart
 +      # element itself, as opposed to a simple payload; for example, a
 +      # multipart/signed element, like Mutt does when encrypting and signing a
 +      # message (instead of clearsigning it). Supposedly, decrypted_payload
 +      # being a multipart element ought to work out nicely because in
 +      # Message::multipart_encrypted_to_chunks() the decrypted message is run
 +      # though message_to_chunks() again to get any children. However, it does
 +      # not work as intended because this inner payload need not carry a
 +      # MIME-Version header, yet they are fed to RMail as a top-level message,
 +      # for which the MIME-Version header is required, which causes for the
 +      # part not to be detected as multipart. If we detect this is happening,
 +      # force the payload to be interpreted as MIME.
 +      msg = RMail::Parser.read(decrypted_payload)
 +      if msg.header.content_type =~ %r{^multipart/} and not msg.multipart?
 +        decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload
 +        msg = RMail::Parser.read(decrypted_payload)
 +      end
        notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display"
 -      [RMail::Parser.read(decrypted_payload), sig, notice]
 +      [msg, sig, notice]
      else
        notice = Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n")
        [nil, nil, notice]
 -- 
 1.6.3.3
 
 
 From dato@net.com.org.es  Thu Jul 23 13:19:51 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=)
 Date: Thu, 23 Jul 2009 19:19:51 +0200
 Subject: [sup-talk] [PATCH] Fix parsing of encrypted messages that contain
 	further multipart elements
 In-Reply-To: <ff7df0405d003a8f4e88f0dd191d8bf4875f73f3.1248368899.git.dato@net.com.org.es>
 References: <ff7df0405d003a8f4e88f0dd191d8bf4875f73f3.1248368899.git.dato@net.com.org.es>
 Message-ID: <6fd87965a2e243b190678edb6c4b9cefbde9ae66.1248369563.git.dato@net.com.org.es>
 
 ---
 Amended patch follows, with a better wording that I had seemingly not
 committed. Sorry for the noise.
 
  lib/sup/crypto.rb |   20 +++++++++++++++++++-
  1 files changed, 19 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb
 index 8ec277b..acbc1d8 100644
 --- a/lib/sup/crypto.rb
 +++ b/lib/sup/crypto.rb
 @@ -132,8 +132,26 @@ class CryptoManager
            end
          end
  
 +      # This is gross. This decrypted payload could very well be a multipart
 +      # element itself, as opposed to a simple payload. For example, a
 +      # multipart/signed element, like those generated by Mutt when encrypting
 +      # and signing a message (instead of just clearsigning the body).
 +      # Supposedly, decrypted_payload being a multipart element ought to work
 +      # out nicely because Message::multipart_encrypted_to_chunks() runs the
 +      # decrypted message through message_to_chunks() again to get any
 +      # children. However, it does not work as intended because these inner
 +      # payloads need not carry a MIME-Version header, yet they are fed to
 +      # RMail as a top-level message, for which the MIME-Version header is
 +      # required. This causes for the part not to be detected as multipart,
 +      # hence being shown as an attachment. If we detect this is happening,
 +      # we force the decrypted payload to be interpreted as MIME.
 +      msg = RMail::Parser.read(decrypted_payload)
 +      if msg.header.content_type =~ %r{^multipart/} and not msg.multipart?
 +        decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload
 +        msg = RMail::Parser.read(decrypted_payload)
 +      end
        notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display"
 -      [RMail::Parser.read(decrypted_payload), sig, notice]
 +      [msg, sig, notice]
      else
        notice = Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n")
        [nil, nil, notice]
 -- 
 1.6.3.3
 
 
 From marco-oweber@gmx.de  Fri Jul 24 12:35:15 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Fri, 24 Jul 2009 18:35:15 +0200
 Subject: [sup-talk] Exception
 Message-ID: <1248453259-sup-3604@nixos>
 
 Hi, when either running sup-sync or sup (without -n) I get this
 exception:
 
 --- NoMethodError from thread: poll after loading inbox
 undefined method `to_indexable_s' for nil:NilClass
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/index.rb:244:in `sync_message'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:161:in `add_messages_from'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/source.rb:100:in `each'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:98:in `do_poll'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:86:in `each'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:86:in `do_poll'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:85:in `synchronize'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:85:in `do_poll'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/poll-mode.rb:17:in `poll'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:53:in `poll'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
 /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `new'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
 /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:663:in `call'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:663:in `__unprotected_load_threads'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:605:in `call'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:605:in `load_n_threads_background'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `initialize'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `new'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads'
 (eval):12:in `load_threads'
 /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-wrapped:19:in `load'
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-wrapped:19
 
 Do you see what's happening here or shall I start debugging?
 
 The sup-sync exception trace looks like this:
 
 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/index.rb:244:in `sync_message': undefined method `to_indexable_s' for nil:NilClass (NoMethodError)
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:161:in `add_messages_from'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/source.rb:100:in `each'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `send'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing'
         from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:140
         from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:135:in `each'
         from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:135
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-sync-wrapped:19:in `load'
         from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-sync-wrapped:19
 
 
 
 Marc Weber
 
 From rlane@club.cc.cmu.edu  Fri Jul 24 22:50:54 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 24 Jul 2009 19:50:54 -0700
 Subject: [sup-talk] [PATCH] xapian: initialize sources in sup-dump
 Message-ID: <1248490254-31895-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup-dump |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/bin/sup-dump b/bin/sup-dump
 index 9b0892e..c18a767 100755
 --- a/bin/sup-dump
 +++ b/bin/sup-dump
 @@ -22,6 +22,7 @@ EOS
  end
  
  index = Redwood::Index.new
 +Redwood::SourceManager.new
  index.load
  
  index.each_message do |m|
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Fri Jul 24 23:25:09 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 24 Jul 2009 20:25:09 -0700
 Subject: [sup-talk] [PATCH] xapian: fix mk_addrs args in build_message
 Message-ID: <1248492309-1980-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |    6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index d064ffc..23af431 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -68,9 +68,9 @@ class XapianIndex < BaseIndex
        'date' => Time.at(entry[:date]),
        'subject' => entry[:subject],
        'from' => mk_addrs[[entry[:from]]],
 -      'to' => mk_addrs[[entry[:to]]],
 -      'cc' => mk_addrs[[entry[:cc]]],
 -      'bcc' => mk_addrs[[entry[:bcc]]],
 +      'to' => mk_addrs[entry[:to]],
 +      'cc' => mk_addrs[entry[:cc]],
 +      'bcc' => mk_addrs[entry[:bcc]],
        'reply-tos' => mk_refs[entry[:replytos]],
        'references' => mk_refs[entry[:refs]],
       }
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jul 25 00:53:07 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 25 Jul 2009 00:53:07 -0400
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <20090723102325.GA4291@chistera.yi.org>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 Message-ID: <1248497184-sup-939@pion.club.cc.cmu.edu>
 
 > Yeah, thanks Rich! However, there seems to be something wrong with the
 > parsing of contacts. After reindexing with Xapian, my contact list has
 > entries like:
 > 
 >   <dato                                        <dato at net.com.org.esadeodato
 >   <other                                       <other at foo.ua.esfoo
 >   dato at net.com.org.esAdeodato Simo             other2 at domain.netother2 surname2
 
 Thanks for the bug report, I've posted a patch (fix-mk_addrs-args) to
 fix this. You shouldn't need to reindex after applying the patch.
 
 > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
 > inspection of the code, it doesn't look to me as random negated labels
 > are being parsed.
 > 
 > Any hints?
 
 You need to specify a non-negated term in the query.
 "type:mail -label:inbox" should work.
 
 From dato@net.com.org.es  Sat Jul 25 05:21:16 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato_Sim=C3=B3?=)
 Date: Sat, 25 Jul 2009 11:21:16 +0200
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248497184-sup-939@pion.club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 Message-ID: <1248513425-sup-2484@chistera.yi.org>
 
 + Rich Lane (Sat, 25 Jul 2009 06:53:07 +0200):
 
 > Thanks for the bug report, I've posted a patch (fix-mk_addrs-args) to
 > fix this. You shouldn't need to reindex after applying the patch.
 
 Great, thanks. The patch indeed fixes the issue.
 
 > > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
 > > inspection of the code, it doesn't look to me as random negated labels
 > > are being parsed.
 
 > > Any hints?
 
 > You need to specify a non-negated term in the query.
 > "type:mail -label:inbox" should work.
 
 Oh, I see. Yes, that works, thanks.
 
 One extra issue I just noticed: after dumping with ferret, reloading
 into Xapian, and doing a dump again (with Xapian this time), all the
 messages tagged "deleted" or "spam" do not appear in the dump at all.
 Any ideas?
 
 -- 
 - Are you sure we're good?
 - Always.
         -- Rory and Lorelai
 
 
 From ezyang@MIT.EDU  Sat Jul 25 14:10:54 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 25 Jul 2009 14:10:54 -0400
 Subject: [sup-talk] Reply calculation
 Message-ID: <1248545266-sup-6886@javelin>
 
 I think sup's "To" address calculation algorithm is wrong, and
 messes up in some important edge-cases.  The two edge
 cases I have in mind are:
 
 * When a mailing list sends an unsubscribe/subscribe notification
 
 * When someone posts to a mailing list with an explicit Reply-to
   header.
 
 In both of these cases, the mail will commonly have an explicit
 Reply-to header.  However, Sup will by default disregard this
 header in favor for List-id, which is *wrong*.
 
 You can guess, this has bitten me several times.
 
 I think the correct behavior is to only use List-id when Reply-to
 is not explicitly set, since List-id is "magical" whereas Reply-to
 is commonly explicit.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Sat Jul 25 14:24:15 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 25 Jul 2009 14:24:15 -0400
 Subject: [sup-talk] Reply calculation
 In-Reply-To: <1248545266-sup-6886@javelin>
 References: <1248545266-sup-6886@javelin>
 Message-ID: <1248546228-sup-9505@javelin>
 
 Here is a patch that changes the behavior:
 
 >From 58a8d325286703f9057dd5d07094d0c6a061377c Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <ezyang at mit.edu>
 Date: Sat, 25 Jul 2009 14:17:08 -0400
 Subject: [PATCH] Use Reply-to if it is explicitly set.
 
 Previously, Sup would ignore an explicit Reply-to
 in favor of List-id.  This is the wrong behavior for
 the following cases:
 
 * List subscribe and unsubscribe messages will commonly
   have List-id set, but set Reply-to for their own
   nefarious purposes (the "you should be able to reply
   to this email and have it work")
 
 * People will sometimes send mail to a list with an
   explicit Reply-to header to get responses offlist.
 
 This brings Sup's behavior more inline with traditional
 mail clients.  Since most lists already set Reply-to
 (and most mail clients don't respect List-id), there will
 probably be no breakage.
 
 Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
 ---
  lib/sup/modes/reply-mode.rb |    8 +++-----
  1 files changed, 3 insertions(+), 5 deletions(-)
 
 diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb
 index c79c5db..ca423c1 100644
 --- a/lib/sup/modes/reply-mode.rb
 +++ b/lib/sup/modes/reply-mode.rb
 @@ -81,10 +81,8 @@ EOS
        AccountManager.default_account
      end
  
 -    ## now, determine to: and cc: addressess. we ignore reply-to for list
 -    ## messages because it's typically set to the list address, which we
 -    ## explicitly treat with reply type :list
 -    to = @m.is_list_message? ? @m.from : (@m.replyto || @m.from)
 +    ## if someone overrode reply-to, it was for a good reason
 +    to = (@m.replyto || @m.from)
  
      ## next, cc:
      cc = (@m.to + @m.cc - [from, to]).uniq
 @@ -115,7 +113,7 @@ EOS
      } unless not_me_ccs.empty?
  
      @headers[:list] = {
 -      "To" => [@m.list_address.full_address],
 +      "To" => [@m.replyto.full_address || @m.list_address.full_address],
      } if @m.is_list_message?
  
      refs = gen_references
 -- 
 1.6.3.3
 
 From ezyang@MIT.EDU  Sat Jul 25 15:03:31 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 25 Jul 2009 15:03:31 -0400
 Subject: [sup-talk] Reply calculation
 In-Reply-To: <1248546228-sup-9505@javelin>
 References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin>
 Message-ID: <1248548497-sup-1158@javelin>
 
 Excerpts from Edward Z. Yang's message of Sat Jul 25 14:24:15 -0400 2009:
 > Here is a patch that changes the behavior:
 
 Actually, the patch is not quite correct.  Let me think about this
 some more.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Sat Jul 25 15:15:59 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Sat, 25 Jul 2009 15:15:59 -0400
 Subject: [sup-talk] Reply calculation
 In-Reply-To: <1248548497-sup-1158@javelin>
 References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin>
 	<1248548497-sup-1158@javelin>
 Message-ID: <1248549271-sup-3371@javelin>
 
 After thinking about this some, I think that the only way
 to reasonably handle all corner cases is to explicitly ask
 the user for a choice in corner cases.  Having the default
 subtly change based on some non-obvious attributes of an
 email is a great way to break muscle memory.
 
 Myself, I have :user in my reply-to.rb hook for now.
 
 Cheers,
 Edward
 
 From rlane@club.cc.cmu.edu  Sat Jul 25 15:27:08 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 25 Jul 2009 12:27:08 -0700
 Subject: [sup-talk] [PATCH] xapian: dont exclude spam/etc in some internal
 	searches
 Message-ID: <1248550028-9703-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  bin/sup-dump         |    2 +-
  bin/sup-sync         |    2 +-
  bin/sup-sync-back    |    2 +-
  bin/sup-tweak-labels |    1 +
  4 files changed, 4 insertions(+), 3 deletions(-)
 
 diff --git a/bin/sup-dump b/bin/sup-dump
 index c18a767..ba36b21 100755
 --- a/bin/sup-dump
 +++ b/bin/sup-dump
 @@ -25,6 +25,6 @@ index = Redwood::Index.new
  Redwood::SourceManager.new
  index.load
  
 -index.each_message do |m|
 +index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m|
    puts "#{m.id} (#{m.labels * ' '})"
  end
 diff --git a/bin/sup-sync b/bin/sup-sync
 index 270524a..8e37c74 100755
 --- a/bin/sup-sync
 +++ b/bin/sup-sync
 @@ -213,7 +213,7 @@ begin
      num_del, num_scanned = 0, 0
      sources.each do |source|
        raise "no source id for #{source}" unless source.id
 -      index.each_message :source_id => source.id do |m|
 +      index.each_message :source_id => source.id, :load_spam => true, :load_deleted => true, :load_killed => true do |m|
          num_scanned += 1
          unless seen[m.id]
            next unless m.source_info >= opts[:start_at] if opts[:start_at]
 diff --git a/bin/sup-sync-back b/bin/sup-sync-back
 index da94bbd..56ac4eb 100755
 --- a/bin/sup-sync-back
 +++ b/bin/sup-sync-back
 @@ -16,7 +16,7 @@ def die msg
    exit(-1)
  end
  def has_any_from_source_with_label? index, source, label
 -  query = { :source_id => source.id, :label => label, :limit => 1 }
 +  query = { :source_id => source.id, :label => label, :limit => 1, :load_spam => true, :load_deleted => true, :load_killed => true }
    not Enumerable::Enumerator.new(index, :each_id, query).map.empty?
  end
  
 diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels
 index a8115ea..8ae5c26 100755
 --- a/bin/sup-tweak-labels
 +++ b/bin/sup-tweak-labels
 @@ -83,6 +83,7 @@ begin
    query += ' ' + opts[:query] if opts[:query]
  
    parsed_query = index.parse_query query
 +  parsed_query.merge! :load_spam => true, :load_deleted => true, :load_killed => true
    ids = Enumerable::Enumerator.new(index, :each_id, parsed_query).map
    num_total = ids.size
  
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Sat Jul 25 15:59:19 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Sat, 25 Jul 2009 15:59:19 -0400
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248513425-sup-2484@chistera.yi.org>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 Message-ID: <1248550384-sup-74@pion.club.cc.cmu.edu>
 
 Excerpts from Adeodato Sim?'s message of Sat Jul 25 05:21:16 -0400 2009:
 > One extra issue I just noticed: after dumping with ferret, reloading
 > into Xapian, and doing a dump again (with Xapian this time), all the
 > messages tagged "deleted" or "spam" do not appear in the dump at all.
 > Any ideas?
 
 The patch "xapian: dont exclude spam..." should fix this.
 
 One issue I've noticed is that removing labels from messages doesn't
 always immediately work. For example, label-list-mode shows a label as
 having some unread messages even though all of them are actually read.
 This tends to happen only after sup's been running for a while and
 restarting sup fixes it.
 
 From ingmar@exherbo.org  Sat Jul 25 19:28:16 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Sun, 26 Jul 2009 01:28:16 +0200
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248550384-sup-74@pion.club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 Message-ID: <1248564412-sup-7548@cannonball>
 
 Excerpts from Rich Lane's message of Sat Jul 25 21:59:19 +0200 2009:
 > One issue I've noticed is that removing labels from messages doesn't
 > always immediately work. For example, label-list-mode shows a label as
 > having some unread messages even though all of them are actually read.
 > This tends to happen only after sup's been running for a while and
 > restarting sup fixes it.
 
 I was just about to report that. :)
 Besides that, the Xapian index works very nicely. So I'd be happy to see
 it in next when that last regression (as far as my testing showed them) is fixed!
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 11:46:21 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 08:46:21 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248497184-sup-939@pion.club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 Message-ID: <1248709366-sup-5856@entry>
 
 Reformatted excerpts from Rich Lane's message of 2009-07-24:
 > > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an
 > > inspection of the code, it doesn't look to me as random negated
 > > labels are being parsed.
 > > 
 > > Any hints?
 > 
 > You need to specify a non-negated term in the query.  "type:mail
 > -label:inbox" should work.
 
 This is a typical restriction for inverted index-based search engines.
 You need to have at least one positive term or the computation is too
 expensive (it would have to iterate over every term ever seen.) It's
 true of Ferret, Google, etc.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 11:48:38 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 08:48:38 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248550384-sup-74@pion.club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 Message-ID: <1248709681-sup-4141@entry>
 
 Reformatted excerpts from Rich Lane's message of 2009-07-25:
 > One issue I've noticed is that removing labels from messages doesn't
 > always immediately work.
 
 Is this true even after you sync changes to the index? What about if you
 reload the label list buffer? ('@')
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:13:16 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:13:16 -0700
 Subject: [sup-talk] xapian merged into next
 Message-ID: <1248711109-sup-7061@entry>
 
 I've merged the xapian branch into next. Users of next need not worry;
 xapian only enabled when you set the environment variable
 SUP_INDEX=xapian. (And you'll have to regenerate your index; see my
 message of a few weeks ago for how.)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:16:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:16:43 -0700
 Subject: [sup-talk] [PATCH] xapian: dont exclude spam/etc in some
 	internal searches
 In-Reply-To: <1248550028-9703-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1248550028-9703-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1248711395-sup-5867@entry>
 
 Applied, thanks.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:17:00 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:17:00 -0700
 Subject: [sup-talk] [PATCH] xapian: fix mk_addrs args in build_message
 In-Reply-To: <1248492309-1980-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1248492309-1980-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1248711412-sup-674@entry>
 
 Applied, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:17:14 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:17:14 -0700
 Subject: [sup-talk] [PATCH] xapian: initialize sources in sup-dump
 In-Reply-To: <1248490254-31895-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1248490254-31895-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1248711426-sup-1184@entry>
 
 Aaaand applied. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:22:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:22:48 -0700
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
 	referencing an nonexistent variable)
 In-Reply-To: <1247322405-sup-1564@ntdws12.chass.utoronto.ca>
 References: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 	<1247322405-sup-1564@ntdws12.chass.utoronto.ca>
 Message-ID: <1248711741-sup-3733@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-07-11:
 > +1 for this.  Not sure how I managed to submit the original patch like
 > this, since I did test various forms of results returned from the
 > bounce-command hook...anyway, I've applied this and verified it.
 
 I don't see this in your bw/bounce_message branch. I'd like to remerge
 that.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Mon Jul 27 12:16:50 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 27 Jul 2009 18:16:50 +0200
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1248711109-sup-7061@entry>
 References: <1248711109-sup-7061@entry>
 Message-ID: <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 
 On Mon, Jul 27, 2009 at 6:13 PM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 > I've merged the xapian branch into next. Users of next need not worry;
 > xapian only enabled when you set the environment variable
 > SUP_INDEX=xapian. (And you'll have to regenerate your index; see my
 > message of a few weeks ago for how.)
 
 The big question is: is it interesting, as a user, to switch? :-)
 
 -- 
 Guillaume
 
 From bwalton@artsci.utoronto.ca  Mon Jul 27 12:25:52 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 27 Jul 2009 12:25:52 -0400
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
 	referencing an nonexistent variable)
 In-Reply-To: <1248711741-sup-3733@entry>
 References: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 	<1247322405-sup-1564@ntdws12.chass.utoronto.ca>
 	<1248711741-sup-3733@entry>
 Message-ID: <1248711899-sup-4693@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Mon Jul 27 12:22:48 -0400 2009:
 
 > I don't see this in your bw/bounce_message branch. I'd like to remerge
 > that.
 
 Sorry.  I didn't publish the change, I thought it would be `git am`'d
 from the original mail.  I applied it to my local running copy of next
 though, which is what I was referring to.  I'll try to remember to
 push things like this in the future.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/85a7f7a7/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:27:42 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:27:42 -0700
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 Message-ID: <1248711777-sup-9329@entry>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
 > The big question is: is it interesting, as a user, to switch? :-)
 
 Yes. It's noticeably faster than Ferret, especially for loading large
 threads in thread-index-mode. (Which isn't Xapian per se, but other
 improvements Rich has made).
 
 It's also much larger on disk, though there might be a way to trim that
 down.
 
 At some point I want to deprecate Ferret, since it's unmaintained, so
 you'll be forced to switch. No timeline on that though.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:29:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:29:20 -0700
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
 	referencing an nonexistent variable)
 In-Reply-To: <1248711899-sup-4693@ntdws12.chass.utoronto.ca>
 References: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 	<1247322405-sup-1564@ntdws12.chass.utoronto.ca>
 	<1248711741-sup-3733@entry>
 	<1248711899-sup-4693@ntdws12.chass.utoronto.ca>
 Message-ID: <1248712076-sup-7189@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-07-27:
 > Sorry. I didn't publish the change, I thought it would be `git am`'d
 > from the original mail.
 
 No problem. We can do it either way. I'll apply this patch directly.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Mon Jul 27 12:30:20 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 27 Jul 2009 12:30:20 -0400
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
 	referencing an nonexistent variable)
 In-Reply-To: <1248711899-sup-4693@ntdws12.chass.utoronto.ca>
 References: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 	<1247322405-sup-1564@ntdws12.chass.utoronto.ca>
 	<1248711741-sup-3733@entry>
 	<1248711899-sup-4693@ntdws12.chass.utoronto.ca>
 Message-ID: <1248712092-sup-5843@ntdws12.chass.utoronto.ca>
 
 Excerpts from Ben Walton's message of Mon Jul 27 12:25:52 -0400 2009:
 > Sorry.  I didn't publish the change, I thought it would be `git am`'d
 > from the original mail.  I applied it to my local running copy of next
 > though, which is what I was referring to.  I'll try to remember to
 > push things like this in the future.
 
 I've now `git am`'d and pushed on my development copy to
 git://code.chass.utoronto.ca/bwalton-sup.git.  You should be able to
 remerge the bw/bounce_message branch and get Adeodato's fix.
 
 Thanks
 -Ben
 
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/eb249faf/attachment.bin>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:30:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:30:50 -0700
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
 	referencing an nonexistent variable)
 In-Reply-To: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 References: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 Message-ID: <1248712242-sup-2953@entry>
 
 Applied, thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Mon Jul 27 12:31:46 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 27 Jul 2009 18:31:46 +0200
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1248711777-sup-9329@entry>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 Message-ID: <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 
 On Mon, Jul 27, 2009 at 6:27 PM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 > Yes. It's noticeably faster than Ferret, especially for loading large
 > threads in thread-index-mode. (Which isn't Xapian per se, but other
 > improvements Rich has made).
 Yummy!
 > It's also much larger on disk, though there might be a way to trim that
 > down.
 Less yummy!
 
 So, we just export SUP_INDEX=xapian and that's it? We start with an
 empty sup and we just have to reimport the mbox/maildir/whatever?
 Means losing the red states and tags, I guess.
 
 -- 
 Guillaume
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:41:05 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:41:05 -0700
 Subject: [sup-talk] Exception
 In-Reply-To: <1248453259-sup-3604@nixos>
 References: <1248453259-sup-3604@nixos>
 Message-ID: <1248712764-sup-736@entry>
 
 Reformatted excerpts from Marc Weber's message of 2009-07-24:
 > Hi, when either running sup-sync or sup (without -n) I get this
 > exception:
 > 
 > --- NoMethodError from thread: poll after loading inbox
 > undefined method `to_indexable_s' for nil:NilClass
 
 Weird. It looks like a date parsing issue, but I'm having a hard time
 seeing where the logic fails such that no date field is set.
 
 Can you try applying the following patch, and then running sup-sync with
 -v? I'm hoping that the debugging output prefixed with XX will provide a
 clue.
 
 Thanks!
 
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -92,11 +92,14 @@ class Message
        begin
          Time.parse date
        rescue ArgumentError => e
 -        #Redwood::log "faking mangled date header for #{@id} (orig #{header['da
 +        Redwood::log "faking mangled date header for #{@id} (orig #{header['dat
          Time.now
        end
 -    else
 -      #Redwood::log "faking non-existent date header for #{@id}"
 +    end
 +
 +    @date ||= begin
 +      Redwood::log "XX original header was #{header["date"].inspect}"
 +      Redwood::log "XX faking non-existent date header for #{@id}"
        Time.now
      end
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:44:54 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:44:54 -0700
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 Message-ID: <1248712876-sup-1446@entry>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
 > So, we just export SUP_INDEX=xapian and that's it? We start with an
 > empty sup and we just have to reimport the mbox/maildir/whatever?
 > Means losing the red states and tags, I guess.
 
 Current instructions:
 
 1. install the ruby xapian library and the ruby gdbm library, if you
    don't have them. These are packaged by your distro, and are not gems.
 2. git checkout next
 3. git pull
 4. cp ~/.sup/sources.yaml /tmp # just in case
 5. ruby -Ilib bin/sup-dump > dumpfile
 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile
 7. SUP_INDEX=xapian ruby -Ilib bin/sup -o
 8. Oooh, fast.
 
 This should not disturb your Ferret index, so you can switch back and forth
 between the two. (Message state, of course, is not shared.) However, adding new
 messages to one index will prevent it from being automatically added to the
 other, so I recommend running in Xapian mode with -o and not pressing 'P'.
 Unless, of of course, you're ready to switch permanently, in which case rm -rf
 ~/.sup/ferret. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:45:17 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:45:17 -0700
 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was
 	referencing an nonexistent variable)
 In-Reply-To: <1248712092-sup-5843@ntdws12.chass.utoronto.ca>
 References: <ef3825cbc25db1005616823980a339827c9db65e.1247313450.git.dato@net.com.org.es>
 	<1247322405-sup-1564@ntdws12.chass.utoronto.ca>
 	<1248711741-sup-3733@entry>
 	<1248711899-sup-4693@ntdws12.chass.utoronto.ca>
 	<1248712092-sup-5843@ntdws12.chass.utoronto.ca>
 Message-ID: <1248713108-sup-884@entry>
 
 Reformatted excerpts from Ben Walton's message of 2009-07-27:
 > I've now `git am`'d and pushed on my development copy to
 > git://code.chass.utoronto.ca/bwalton-sup.git.  You should be able to
 > remerge the bw/bounce_message branch and get Adeodato's fix.
 
 Heh. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Mon Jul 27 12:47:13 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 27 Jul 2009 18:47:13 +0200
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1248712876-sup-1446@entry>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 Message-ID: <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 
 On Mon, Jul 27, 2009 at 6:44 PM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 > Unless, of of course, you're ready to switch permanently, in which case rm -rf
 > ~/.sup/ferret. :)
 
 There's no reason not to, right?
 /me is following blinding the given instructions :-)
 
 -- 
 Guillaume
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:49:11 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:49:11 -0700
 Subject: [sup-talk] Reply calculation
 In-Reply-To: <1248549271-sup-3371@javelin>
 References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin>
 	<1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin>
 Message-ID: <1248713182-sup-172@entry>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-07-25:
 > After thinking about this some, I think that the only way to
 > reasonably handle all corner cases is to explicitly ask the user for a
 > choice in corner cases.
 
 What was the breakage when favoring reply-to over list-id? I was buying
 your arguments...
 
 Is it possible to identify these corner cases? Is it always when there's
 a reply-to and a list-id both set?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:50:12 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:50:12 -0700
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 Message-ID: <1248713360-sup-5448@entry>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
 > There's no reason not to, right?
 
 Well, the code isn't quite as well tested...
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:51:17 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:51:17 -0700
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset"
 	variable with the attachment charset
 In-Reply-To: <20090723093543.GA2265@chistera.yi.org>
 References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 	<20090723093543.GA2265@chistera.yi.org>
 Message-ID: <1248713434-sup-4961@entry>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
 > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
 > 
 > > +                          :charset => encoded_content.charset,
 > 
 > Hm, so apparently encoded_content doesn't always have a charset
 > member...
 > 
 
 In which case that value of that variable is nil, right? Is that a
 problem? The patch still seems useful.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:52:02 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:52:02 -0700
 Subject: [sup-talk] Choose "From:" address based on message content?
 In-Reply-To: <1248311332-sup-1053@sgoldmanlinux.tower-research.com>
 References: <1248311332-sup-1053@sgoldmanlinux.tower-research.com>
 Message-ID: <1248713502-sup-312@entry>
 
 Reformatted excerpts from Steve Goldman's message of 2009-07-22:
 > Can sup do it?
 
 Shit yes. These insane requests are exactly why I am favoring hooks over
 configuration.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 12:53:58 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 09:53:58 -0700
 Subject: [sup-talk] Choose "From:" address based on message content?
 In-Reply-To: <1248317360-sup-4094@sgoldmanlinux.tower-research.com>
 References: <1248311332-sup-1053@sgoldmanlinux.tower-research.com>
 	<1248317360-sup-4094@sgoldmanlinux.tower-research.com>
 Message-ID: <1248713574-sup-6167@entry>
 
 Reformatted excerpts from Steve Goldman's message of 2009-07-22:
 > require 'eregex'
 > 
 > r = Regexp.new('word', Regexp::IGNORECASE);
 > if header.to_s.grep(r).size > 0 or body.to_s.grep(r).size > 0
 
 You can just use body.to_s =~ /word/i || header.join =~ /i/. No need for
 all the fancy libraries and method calls.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marco-oweber@gmx.de  Mon Jul 27 12:55:46 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Mon, 27 Jul 2009 18:55:46 +0200
 Subject: [sup-talk] Exception
 In-Reply-To: <1248712764-sup-736@entry>
 References: <1248453259-sup-3604@nixos> <1248712764-sup-736@entry>
 Message-ID: <1248713299-sup-9062@nixos>
 
 You're right. I fixed it today by running sup-sync. (I was still reading
 my mails that's why I didn't respond earlier).
 I used p m at that location to get a message output saying something
 about offset is out of sync. Then I tried sup-sync -c.
 
 The strange thing is that I didn't open the mbox file using another
 program such as mutt. Maybe a locking issue or such ? I'm using
 procmail.
 
 I was surprised how easy it was to find the cause after starting looking
 into it.
 
 Thanks for taking the time sending this patch!
 
 Marc Weber
 
 Excerpts from William Morgan's message of Mon Jul 27 18:41:05 +0200 2009:
 > Reformatted excerpts from Marc Weber's message of 2009-07-24:
 > > Hi, when either running sup-sync or sup (without -n) I get this
 > > exception:
 > > 
 > > --- NoMethodError from thread: poll after loading inbox
 > > undefined method `to_indexable_s' for nil:NilClass
 > 
 > Weird. It looks like a date parsing issue, but I'm having a hard time
 > seeing where the logic fails such that no date field is set.
 > 
 > Can you try applying the following patch, and then running sup-sync with
 > -v? I'm hoping that the debugging output prefixed with XX will provide a
 > clue.
 > 
 > Thanks!
 > 
 > --- a/lib/sup/message.rb
 > +++ b/lib/sup/message.rb
 > @@ -92,11 +92,14 @@ class Message
 >        begin
 >          Time.parse date
 >        rescue ArgumentError => e
 > -        #Redwood::log "faking mangled date header for #{@id} (orig #{header['da
 > +        Redwood::log "faking mangled date header for #{@id} (orig #{header['dat
 >          Time.now
 >        end
 > -    else
 > -      #Redwood::log "faking non-existent date header for #{@id}"
 > +    end
 > +
 > +    @date ||= begin
 > +      Redwood::log "XX original header was #{header["date"].inspect}"
 > +      Redwood::log "XX faking non-existent date header for #{@id}"
 >        Time.now
 >      end
 > 
 
 From ingmar@exherbo.org  Mon Jul 27 12:56:28 2009
 From: ingmar@exherbo.org (Ingmar Vanhassel)
 Date: Mon, 27 Jul 2009 18:56:28 +0200
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248709681-sup-4141@entry>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 	<1248709681-sup-4141@entry>
 Message-ID: <1248713376-sup-5163@cannonball>
 
 Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-07-25:
 > > One issue I've noticed is that removing labels from messages doesn't
 > > always immediately work.
 > 
 > Is this true even after you sync changes to the index? What about if you
 > reload the label list buffer? ('@')
 
 It's true in both cases. Even after a sync, 'U' still produces read
 messages (among unread), and a search for label:foo has threads without
 that label. If you quit sup & restart it things work as expected for a
 while.
 
 I've also noticed that sup takes a long time to quit with the xapian
 index. This delay happens after this message:
 [Mon Jul 27 16:56:01 +0000 2009] unlocking /home/ingmar/.sup/lock...
 
 -- 
 Exherbo KDE, X.org maintainer
 
 From rlane@club.cc.cmu.edu  Mon Jul 27 13:06:34 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 27 Jul 2009 13:06:34 -0400
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248709681-sup-4141@entry>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 	<1248709681-sup-4141@entry>
 Message-ID: <1248710432-sup-1734@pion.club.cc.cmu.edu>
 
 Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
 > Reformatted excerpts from Rich Lane's message of 2009-07-25:
 > > One issue I've noticed is that removing labels from messages doesn't
 > > always immediately work.
 > 
 > Is this true even after you sync changes to the index? What about if you
 > reload the label list buffer? ('@')
 
 Yes. This is looking like a Xapian bug - I've reproduced it without any
 Sup code. I'm working on a fix.
 
 From ezyang@MIT.EDU  Mon Jul 27 13:09:13 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 13:09:13 -0400
 Subject: [sup-talk] Reply calculation
 In-Reply-To: <1248713182-sup-172@entry>
 References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin>
 	<1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin>
 	<1248713182-sup-172@entry>
 Message-ID: <1248713591-sup-8324@javelin>
 
 Excerpts from William Morgan's message of Mon Jul 27 12:49:11 -0400 2009:
 > What was the breakage when favoring reply-to over list-id? I was buying
 > your arguments...
 
 First and foremost, s/list-id/list-post/ in my previous posts; I was quoting
 the wrong field and double checked message.rb just now.
 
 I received mail from a mailing list as a call for applications that should
 not be sent back to the list.  The mail was constructed with headers like:
 
 From: correct@example.com
 To: correct at example.com
 Reply-To: correct at example.com
 List-Post: mailto:incorrect at example.com
 
 Sup detects List-Post, categorizes the message as a list message, and then
 sets the default reply mode as list, which results in List-Post being used
 as the to address.
 
 > Is it possible to identify these corner cases? Is it always when there's
 > a reply-to and a list-id both set?
 
 Unfortunately, mailing list administrating is notoriously broken.  I'm not
 sure at all what the right solution is.  Take for example this other case:
 
 From: person@example.com
 To: list at example.com
 Reply-To: person at example.com
 List-Post: mailto:list at example.com
 
 Reply-To, in this case, was set by the mailing list server.  This makes
 having Reply-To be the end-all be-all kind of spurious.  If we try
 to make Sup do the Right Thing (TM), you probably want to send mail to
 the list as a whole, which means you do want to either "reply all" semantics
 or "list post" magic.  ("reply all" semantics are what you see in traditional
 mail clients when you hit the "reply all" button.)
 
 However, consider the next case:
 
 From: persona@example.com
 To: list at example.com
 Cc: me at example.com
 
 Which is when someone else hit "Reply all" and you got CC'ed.  This means
 that the mail never passed through the mailing list agent, the List-Post/Reply-To
 headers never got set, and the only way to tell that you should reply to the
 whole list is to explicitly ask for "Reply all" semantics (Sup defaults to
 "Reply" semantics, which is damn confusing if you're not paying attention).
 
 The core problem is that subtle changes in state should not require the user
 to do things differently; it breaks muscle memory and makes mistakes easy.
 We could try to make it so that Sup requires /no/ user intervention, but
 this is seems to be an AI-hard problem.  Then, the logical other direction,
 is to make the interface as consistent as possible.
 
 Cheers,
 Edward
 
 PS. Djb wrote an article along these lines:
     http://cr.yp.to/proto/replyto.html
 I've skimmed it but I'm kind of skeptical about client support and not sure
 if it actually gives useful recommendations.
 
 From guillaume.quintard@gmail.com  Mon Jul 27 13:09:19 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 27 Jul 2009 19:09:19 +0200
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1248713360-sup-5448@entry>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 	<1248713360-sup-5448@entry>
 Message-ID: <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 
 On Mon, Jul 27, 2009 at 6:50 PM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 > Well, the code isn't quite as well tested...
 
 Someone has to do it, plus I still have my mbox archive...
 ...and I was getting tired of this mostly bugless mail experience.
 
 -- 
 Guillaume
 
 From ezyang@MIT.EDU  Mon Jul 27 13:13:01 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 13:13:01 -0400
 Subject: [sup-talk] Odd key bug
 Message-ID: <1248714653-sup-6926@javelin>
 
 After I finish editing a message and exit out of my editor (vim),
 if I try to press up arrow in order to move my focus to the
 reply mode field to toggle it, I get the errors:
 
     unknown keypress '^[' for compose-mode
     unknown keypress 'A' for compose-mode
 
 It then works properly.  A guess is something is messing with the
 terminal?  This is 100% reproduceable.
 
 Cheers,
 Edward
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:16:02 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:16:02 -0700
 Subject: [sup-talk] sup 0.8.1 crash
 In-Reply-To: <1246954373-sup-4550@sfo.thejof.com>
 References: <1246954373-sup-4550@sfo.thejof.com>
 Message-ID: <1248714912-sup-9402@entry>
 
 Reformatted excerpts from Jonathan Lassoff's message of 2009-07-07:
 > I took a little time to poke around in the sup source to try and get
 > an idea what was going on. I'm led to believe this is because I added
 > a source in the past that I later deleted -- but all of the mesages
 > are still in the index.
 
 That would do it!
 
 > So, when certain searches turn up results that are in that deleted
 > source, the sup index fails to reference the message source in
 > Redwood::Index. Is there a way to delete a source without having to
 > re-index everything?
 
 Yes, using devel/console.sh. Are you running master or next? (Or a
 release?) Details differ depending.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:19:14 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:19:14 -0700
 Subject: [sup-talk] [PATCH] Use /etc/mailname if present to determine
 	the hostname for Message-Id
 In-Reply-To: <e23a0f3ed1ae4e2007d0f8144207e0e2fe3d8c11.1247169308.git.dato@net.com.org.es>
 References: <e23a0f3ed1ae4e2007d0f8144207e0e2fe3d8c11.1247169308.git.dato@net.com.org.es>
 Message-ID: <1248715131-sup-8076@entry>
 
 Reformatted excerpts from Adeodato Sim?'s message of 2009-07-09:
 > on many systems (notably Debian-based systems), the /etc/mailname file
 > can be created to specify the public mail name for a host. If that
 > file exists, it'd be good to use its contents for generating the
 > Message-Id header.
 
 Excellent idea. Applied directly to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:24:09 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:24:09 -0700
 Subject: [sup-talk] Validating GPG keys in parallel and in background
 In-Reply-To: <1247256988-sup-2799@x200>
 References: <1247256988-sup-2799@x200>
 Message-ID: <1248715421-sup-9481@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-07-10:
 > it seems like sup is blocking during the validation of GPG
 > signed/encrypted mails. While for encryption it makes some sense to
 > block, for signed mails it would be better to just display the message
 > and add the information about the signature status later. The same
 > approach could be used for encrypted messages: Display "decrypting..."
 > and update it when done.
 
 I agree. This would be great.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:25:36 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:25:36 -0700
 Subject: [sup-talk] Adding/saving multiple attachments?
 In-Reply-To: <1247331130-sup-4923@x200>
 References: <1247331130-sup-4923@x200>
 Message-ID: <1248715516-sup-4466@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-07-11:
 > I?ve had the same problem with mutt: Isn?t there a way to add or save
 > multiple attachments? Why can?t I add ~/work/foo/* when pressing 'a'?
 > Why doesn?t the file browser save the last directory I?ve been in?
 > Can we please get a binding to save all attachments of a message into
 > a folder?
 
 All excellent ideas. I too am annoyed when I have more than one
 attachment to save.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:26:06 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:26:06 -0700
 Subject: [sup-talk] Invalid character on import
 In-Reply-To: <1247516120-sup-3116@ausone.local>
 References: <20090713090110.GA20996@ikn.schottelius.org>
 	<1247516120-sup-3116@ausone.local>
 Message-ID: <1248715552-sup-271@masanjin.net>
 
 Reformatted excerpts from Nicolas Pouillard's message of 2009-07-13:
 > The fix is trivial, I've submitted a merge request for exactly this:
 > 
 > http://gitorious.org/~ertai/sup/clone-by-ertai
 
 This has been applied to master. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:31:09 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:31:09 -0700
 Subject: [sup-talk] [PATCH] GSSAPI support for net/imap.rb and sup
 In-Reply-To: <1248092732-sup-9960@midna>
 References: <1248092732-sup-9960@midna>
 Message-ID: <1248715761-sup-5112@masanjin.net>
 
 Reformatted excerpts from Michael Stapelberg's message of 2009-07-20:
 > As I?m not very much involved in the ruby community (in fact, this is
 > my first piece of ruby code), I need someone to help me get things
 > upstream (for Net::IMAP in the first place, but someone maintaining
 > ruby-gss would be great).
 
 I don't have much advice for you other than find the guy who maintains
 Net::IMAP, beating him on the head a few times for me, and send him the
 patch. I believe net/imap is part of core ruby, which means you can
 probably just take this to the ruby-core mailing list.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:33:57 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:33:57 -0700
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248714653-sup-6926@javelin>
 References: <1248714653-sup-6926@javelin>
 Message-ID: <1248715911-sup-4656@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
 > It then works properly.  A guess is something is messing with the
 > terminal?  This is 100% reproduceable.
 
 This happens to me too. Maybe there's some more curses weirdness that
 needs to happen when shelling out---you can see the current magic spell
 at buffer.rb circa line 724, in BufferManager#shell_out. I've just
 suffered through it for the past three years.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:34:59 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:34:59 -0700
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com>
 	<1248713360-sup-5448@entry>
 	<1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com>
 Message-ID: <1248716073-sup-7443@masanjin.net>
 
 Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
 > Someone has to do it, plus I still have my mbox archive...
 > ...and I was getting tired of this mostly bugless mail experience.
 
 Ok, you're the official guinea pig then. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Mon Jul 27 13:36:10 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 13:36:10 -0400
 Subject: [sup-talk] Odd bug with lazy-loaded messages
 Message-ID: <1248716007-sup-5156@javelin>
 
 I've been experiencing an odd bug with the following patch
 for lazy loading messages:
 
 --- a/lib/sup/modes/thread-index-mode.rb
 +++ b/lib/sup/modes/thread-index-mode.rb
 @@ -103,7 +103,6 @@ EOS
          t.each_with_index do |(m, *o), i|
            next unless m
            BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1
 -          m.load_from_source! 
          end
        end
 
 Specifically, the "default" opened message when I open a thread
 gets a weird misrendering of the headers that looks like:
 
 To: foo
     foo <foo at example.com>
     foo
 
 And so forth, for all lines in To and Cc.
 
 Any ideas what could be causing this?  I checked load_from_source! in message.rb
 but didn't see anything obvious that would prevent this behavior.
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Mon Jul 27 13:39:27 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 13:39:27 -0400
 Subject: [sup-talk] [PATCH] Make logging less chatty
 Message-ID: <1248716313-sup-1608@javelin>
 
 Sup currently generates a lot of logging spew during initial startup
 when it is threading.  This makes it difficult to see other log
 messages that are more interesting.  I propose we turn these messages
 off.
 
 >From 1fc4107013a991f24a62dad54509913bb1270d5d Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <ezyang at mit.edu>
 Date: Sat, 25 Jul 2009 14:16:40 -0400
 Subject: [PATCH] Make logging less chatty.
 
 Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
 ---
  lib/sup/index.rb |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/lib/sup/index.rb b/lib/sup/index.rb
 index 9c985d9..fa33baa 100644
 --- a/lib/sup/index.rb
 +++ b/lib/sup/index.rb
 @@ -394,10 +394,10 @@ EOS
      end
  
      if killed
 -      Redwood::log "thread for #{m.id} is killed, ignoring"
 +      #Redwood::log "thread for #{m.id} is killed, ignoring"
        false
      else
 -      Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
 +      #Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0
        messages.each { |mid, builder| yield mid, builder }
        true
      end
 -- 
 1.6.3.3
 
 From ezyang@MIT.EDU  Mon Jul 27 13:40:48 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 13:40:48 -0400
 Subject: [sup-talk] [PATCH] before-search hook
 In-Reply-To: <1246035946-sup-7069@javelin>
 References: <1244612627-sup-982@javelin> <1245087294-sup-6276@entry>
 	<1246035946-sup-7069@javelin>
 Message-ID: <1248716405-sup-6097@javelin>
 
 Excerpts from Edward Z. Yang's message of Fri Jun 26 13:10:01 -0400 2009:
 > Done.
 
 What's the status on getting this patch into the tree?
 
 Cheers,
 Edward
 
 From alex@chmrr.net  Mon Jul 27 13:27:33 2009
 From: alex@chmrr.net (Alex Vandiver)
 Date: Mon, 27 Jul 2009 13:27:33 -0400
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248714653-sup-6926@javelin>
 References: <1248714653-sup-6926@javelin>
 Message-ID: <1248715577-sup-4766@utwig>
 
 At Mon Jul 27 13:13:01 -0400 2009, Edward Z. Yang wrote:
 > After I finish editing a message and exit out of my editor (vim),
 > if I try to press up arrow in order to move my focus to the
 > reply mode field to toggle it, I get the errors:
 > 
 >     unknown keypress '^[' for compose-mode
 >     unknown keypress 'A' for compose-mode
 > 
 > It then works properly.  A guess is something is messing with the
 > terminal?  This is 100% reproduceable.
 
 As another data point, I also see this, with emacs as my editor.
  - Alex
 -- 
 Networking -- only one letter away from not working
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 13:45:32 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 10:45:32 -0700
 Subject: [sup-talk] xapian question
 Message-ID: <1248716325-sup-7534@masanjin.net>
 
 Hey, I finally get to ask a question!
 
 One of the mildly irritating things about Ferret was that it was
 impossible to update the labels of a message without updating the entire
 entry, i.e. including the body. So updating the labels of a message and
 saving that to disk required either re-loading the body from the source,
 or keeping the body explicitly in the index so that it could be loaded
 without going back to the source.
 
 The latter approach is used by the current Ferret index implementation,
 since it's significantly faster (especially for slow sources like IMAP
 servers), but at the cost of a lot of disk space.
 
 My understanding of Xapian is that this is also the case, since fields
 are essentially represented as prefixed terms, and so you're basically
 updating a big blog, but I wanted to confirm this. I ask because the
 entries.db file is very big. :)
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Mon Jul 27 13:48:05 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 27 Jul 2009 13:48:05 -0400
 Subject: [sup-talk] [PATCH] Make logging less chatty
 In-Reply-To: <1248716313-sup-1608@javelin>
 References: <1248716313-sup-1608@javelin>
 Message-ID: <1248716783-sup-6509@ntdws12.chass.utoronto.ca>
 
 Excerpts from Edward Z. Yang's message of Mon Jul 27 13:39:27 -0400 2009:
 > Sup currently generates a lot of logging spew during initial startup
 > when it is threading.  This makes it difficult to see other log
 > messages that are more interesting.  I propose we turn these messages
 > off.
 
 +1 for the idea, but wouldn't a command line verbosity toggle be a
 better way to do this?  Maybe an arg that accepts a numeric value and
 then debug statements of type foo if $val > bar?
 
 Makes debugging this stuff easier, but the output is still optional
 and presumably below the default threshold.
 
 Just a thought.
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/60963ec8/attachment.bin>
 
 From bwalton@artsci.utoronto.ca  Mon Jul 27 13:52:02 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Mon, 27 Jul 2009 13:52:02 -0400
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248715577-sup-4766@utwig>
 References: <1248714653-sup-6926@javelin> <1248715577-sup-4766@utwig>
 Message-ID: <1248717027-sup-9556@ntdws12.chass.utoronto.ca>
 
 Excerpts from Alex Vandiver's message of Mon Jul 27 13:27:33 -0400 2009:
 > As another data point, I also see this, with emacs as my editor.
 
 And I saw it with vim until I switched to emacs a few months back.  I
 wonder if this is anything to do with how these curses apps interact
 with the 'alternate' screen buffer or something?  For the record, I've
 always run sup inside of screen...
 
 I've just been suffering through it too.  Edward, you've given voice
 to this insidious little annoyance! :)
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090727/580ec624/attachment.bin>
 
 From ezyang@MIT.EDU  Mon Jul 27 14:13:12 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 14:13:12 -0400
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248715911-sup-4656@masanjin.net>
 References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net>
 Message-ID: <1248718344-sup-1931@javelin>
 
 Excerpts from William Morgan's message of Mon Jul 27 13:33:57 -0400 2009:
 > This happens to me too. Maybe there's some more curses weirdness that
 > needs to happen when shelling out---you can see the current magic spell
 > at buffer.rb circa line 724, in BufferManager#shell_out. I've just
 > suffered through it for the past three years.
 
 I tried cargo culting a few extra function calls from the web, to no
 avail.  Man, where's an ncurses expert when you need them...
 
 Cheers,
 Edward
 
 From ezyang@MIT.EDU  Mon Jul 27 14:30:46 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 14:30:46 -0400
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248718344-sup-1931@javelin>
 References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net>
 	<1248718344-sup-1931@javelin>
 Message-ID: <1248719342-sup-9126@javelin>
 
 I currently suspect that if I send a null character to the stdscr
 (which would require bin/sup to be rewritten a little to make stdscr
 globally available) it would serve as a decent workaround.  I don't
 actually know how global variables work in Ruby.
 
 (Basically, add stdscr.keypad(0) when we return from the external shell.)
 
 Cheers,
 Edward
 
 From tarko@lanparty.ee  Mon Jul 27 14:47:00 2009
 From: tarko@lanparty.ee (Tarko Tikan)
 Date: Mon, 27 Jul 2009 21:47:00 +0300
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248714653-sup-6926@javelin>
 References: <1248714653-sup-6926@javelin>
 Message-ID: <1248720085-sup-7444@valgus>
 
 hey,
 
 > After I finish editing a message and exit out of my editor (vim),
 > if I try to press up arrow in order to move my focus to the
 > reply mode field to toggle it, I get the errors:
 
 Running sup in screen and seeing it aswell.
 
 As the discussion goes around external editor (and problems switching to and back), I want to throw up an question/idea.
 
 Currently, as the external editor is run, there is no way to switch between sup and external editor (for obvious reasons). Is anyone aware of any better idea how to integrate vim (even better, any editor) into sup and still have the excellent buffer system. Currently, going between received emails, and the one being composed, is a real pain.
 
 Inventing own editor is ofc one solution but it sounds silly to do it from scratch.
 
 -- 
 tarko
 
 From ezyang@MIT.EDU  Mon Jul 27 15:15:27 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Mon, 27 Jul 2009 15:15:27 -0400
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248719342-sup-9126@javelin>
 References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net>
 	<1248718344-sup-1931@javelin> <1248719342-sup-9126@javelin>
 Message-ID: <1248721402-sup-3517@javelin>
 
 Alex Vandiver points out that stdscr is a member variable of Ncurses.
 As such, this patch appears to fix the issue.
 
 However, my rationale in my previous message was completely bogus (I
 checked the manpage and keypad does NOT send a null key); thus,
 I have no fucking clue why this works.  Perhaps forcibly setting this
 setting clears some internal buffer.  Either 1 or 0 works, we probably
 want 1 since that's what bin/sup sets.
 
 Yay cargo culting! Whoo!
 
 >From 61696b6a097a949545db52b4a537d74f8256d807 Mon Sep 17 00:00:00 2001
 From: Edward Z. Yang <ezyang at mit.edu>
 Date: Mon, 27 Jul 2009 15:03:58 -0400
 Subject: [PATCH] Fix broken arrow keypresses after shelling out.
 
 Signed-off-by: Edward Z. Yang <ezyang at mit.edu>
 ---
  lib/sup/buffer.rb |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb
 index 8eedf96..5f52d1d 100644
 --- a/lib/sup/buffer.rb
 +++ b/lib/sup/buffer.rb
 @@ -723,6 +723,7 @@ EOS
      Ncurses.sync do
        Ncurses.endwin
        system command
 +      Ncurses.stdscr.keypad 1
        Ncurses.refresh
        Ncurses.curs_set 0
      end
 -- 
 1.6.3.3
 
 From wmorgan-sup@masanjin.net  Mon Jul 27 15:40:05 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 27 Jul 2009 12:40:05 -0700
 Subject: [sup-talk] [PATCH] before-search hook
 In-Reply-To: <1248716405-sup-6097@javelin>
 References: <1244612627-sup-982@javelin> <1245087294-sup-6276@entry>
 	<1246035946-sup-7069@javelin> <1248716405-sup-6097@javelin>
 Message-ID: <1248717965-sup-1834@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
 > What's the status on getting this patch into the tree?
 
 Thanks for the ping. I've put this on branch custom-search-hook and
 merged into next. Note that it only applies to Ferret for now. Now that
 we've split into two indexes, we need to plan out how this hook is going
 to work going forward, since different indexes have different query
 languages. Probably the best option is to have the index type be passed
 as an argument, and let the user special-case on that.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Mon Jul 27 16:04:58 2009
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Mon, 27 Jul 2009 22:04:58 +0200
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1248712876-sup-1446@entry>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 Message-ID: <1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com>
 
 On Mon, Jul 27, 2009 at 6:44 PM, William Morgan<wmorgan-sup at masanjin.net> wrote:
 all went well until:
 > 5. ruby -Ilib bin/sup-dump > dumpfile
 -> produces a empty file (not sure it's normal)
 
 > 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile
 -> error
 [Mon Jul 27 22:01:35 +0200 2009] using character set encoding "UTF-8"
 ./lib/sup/xapian_index.rb:17:in `at': bignum too big to convert into
 `long' (RangeError)
 	from ./lib/sup/xapian_index.rb:17
 	from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
 	from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
 	from ./lib/sup/index.rb:217
 	from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
 	from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
 	from ./lib/sup.rb:269
 	from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
 	from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require'
 	from bin/sup-sync:6
 
 l17 of xapian_index.rb is MAX_DATE = Time.at(2**31)
 
 -- 
 Guillaume
 
 From andrew@pimlott.net  Mon Jul 27 16:11:53 2009
 From: andrew@pimlott.net (Andrew Pimlott)
 Date: Mon, 27 Jul 2009 13:11:53 -0700
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248720085-sup-7444@valgus>
 References: <1248714653-sup-6926@javelin> <1248720085-sup-7444@valgus>
 Message-ID: <20090727201153.GI14010@pimlott.net>
 
 On Mon, Jul 27, 2009 at 09:47:00PM +0300, Tarko Tikan wrote:
 > Currently, as the external editor is run, there is no way to switch between sup and external editor (for obvious reasons). Is anyone aware of any better idea how to integrate vim (even better, any editor) into sup and still have the excellent buffer system.
 
 My idea is to make sup act like a shell and implement job control, so
 when you ctrl-z out of your editor, you're back in sup.  You can have
 multiple editors stopped in the background, and resume any of them at
 any point.
 
 Andrew
 
 From rgh@roughage.com.au  Mon Jul 27 20:33:16 2009
 From: rgh@roughage.com.au (Richard Heycock)
 Date: Tue, 28 Jul 2009 10:33:16 +1000
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1248711777-sup-9329@entry>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 Message-ID: <1248740968-sup-759@wrasse>
 
 Excerpts from William Morgan's message of Tue Jul 28 02:27:42 +1000 2009:
 > Reformatted excerpts from Guillaume Quintard's message of 2009-07-27:
 > > The big question is: is it interesting, as a user, to switch? :-)
 > 
 > Yes. It's noticeably faster than Ferret, especially for loading large
 > threads in thread-index-mode. (Which isn't Xapian per se, but other
 > improvements Rich has made).
 > 
 > It's also much larger on disk, though there might be a way to trim that
 > down.
 > 
 > At some point I want to deprecate Ferret, since it's unmaintained, so
 > you'll be forced to switch. No timeline on that though.
 
 Just to add to Williams answer not only is it faster it's also
 *significantly* more robust. I'm running Debian unstable which, at the
 moment is really living up to it's name, consequently my machine is
 dying a lot more times than it should and I haven't had to rebuild the
 index once. Compare that to ferret where I pretty much has to rebuild
 the index every time; I even wrote myself a one line script to do it.
 
 William there is work being done on the next xapian "engine" which aims
 to reduce the disc size.
 
 rgh
 
 From rlane@club.cc.cmu.edu  Mon Jul 27 23:19:29 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 27 Jul 2009 20:19:29 -0700
 Subject: [sup-talk] [PATCH 1/2] xapian: fix MAX_DATE
 Message-ID: <1248751170-4102-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/xapian_index.rb |    2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb
 index 303b4d0..6358a20 100644
 --- a/lib/sup/xapian_index.rb
 +++ b/lib/sup/xapian_index.rb
 @@ -14,7 +14,7 @@ class XapianIndex < BaseIndex
    ## so we must ensure they're reasonably valid. this typically only affect
    ## spam.
    MIN_DATE = Time.at 0
 -  MAX_DATE = Time.at(2**31)
 +  MAX_DATE = Time.at(2**31-1)
  
    def initialize dir=BASE_DIR
      super
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Mon Jul 27 23:19:30 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 27 Jul 2009 20:19:30 -0700
 Subject: [sup-talk] [PATCH 2/2] xapian: fix issue with empty ferret query
 In-Reply-To: <1248751170-4102-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1248751170-4102-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1248751170-4102-2-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  lib/sup/ferret_index.rb |    1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb
 index f2bb2a0..5473814 100644
 --- a/lib/sup/ferret_index.rb
 +++ b/lib/sup/ferret_index.rb
 @@ -442,6 +442,7 @@ private
  
    def build_ferret_query query
      q = Ferret::Search::BooleanQuery.new
 +    q.add_query Ferret::Search::MatchAllQuery.new, :must
      q.add_query query[:qobj], :must if query[:qobj]
      labels = ([query[:label]] + (query[:labels] || [])).compact
      labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must }
 -- 
 1.6.0.4
 
 
 From rlane@club.cc.cmu.edu  Mon Jul 27 23:33:16 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 27 Jul 2009 23:33:16 -0400
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com>
 Message-ID: <1248751256-sup-4491@pion.club.cc.cmu.edu>
 
 Excerpts from Guillaume Quintard's message of Mon Jul 27 16:04:58 -0400 2009:
 > > 5. ruby -Ilib bin/sup-dump > dumpfile
 > -> produces a empty file (not sure it's normal)
 >
 > ./lib/sup/xapian_index.rb:17:in `at': bignum too big to convert into
 
 Oops, breaking sup-dump would make switching to Xapian a little
 difficult. I've posted patches for both these issues. We really should
 have more tests to catch this sort of thing...
 
 From rlane@club.cc.cmu.edu  Tue Jul 28 01:02:29 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Mon, 27 Jul 2009 22:02:29 -0700
 Subject: [sup-talk] [PATCH] explicitly load messages in testcase
 Message-ID: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu>
 
 ---
  test/test_message.rb |    6 ++++++
  1 files changed, 6 insertions(+), 0 deletions(-)
 
 diff --git a/test/test_message.rb b/test/test_message.rb
 index 0a7db45..675b81d 100644
 --- a/test/test_message.rb
 +++ b/test/test_message.rb
 @@ -73,6 +73,7 @@ EOS
      source_info = 0
  
      sup_message = Message.new( {:source => source, :source_info => source_info } )
 +    sup_message.load_from_source!
  
      # see how well parsing the header went
  
 @@ -222,6 +223,7 @@ EOS
      source_info = 0
  
      sup_message = Message.new( {:source => source, :source_info => source_info } )
 +    sup_message.load_from_source!
      
      # read the message body chunks
  
 @@ -271,6 +273,7 @@ EOS
      source_info = 0
  
      sup_message = Message.new( {:source => source, :source_info => source_info } )
 +    sup_message.load_from_source!
      
      to = sup_message.to
  
 @@ -316,6 +319,7 @@ EOS
      source_info = 0
  
      sup_message = Message.new( {:source => source, :source_info => source_info } )
 +    sup_message.load_from_source!
      
      # read the message body chunks: no errors should reach this level
  
 @@ -414,6 +418,7 @@ EOS
      source_info = 0
  
      sup_message = Message.new( {:source => source, :source_info => source_info } )
 +    sup_message.load_from_source!
      
      # read the message body chunks
  
 @@ -504,6 +509,7 @@ EOS
      source_info = 0
  
      sup_message = Message.new( {:source => source, :source_info => source_info } )
 +    sup_message.load_from_source!
  
      # See how well parsing the message ID went.
      id = sup_message.id
 -- 
 1.6.0.4
 
 
 From olly@survex.com  Tue Jul 28 09:47:07 2009
 From: olly@survex.com (Olly Betts)
 Date: Tue, 28 Jul 2009 13:47:07 +0000 (UTC)
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry>
 Message-ID: <loom.20090728T134034-967@post.gmane.org>
 
 William Morgan <wmorgan-sup at masanjin.net> writes: 
 > Reformatted excerpts from Olly Betts's message of 2009-06-25:
 > > I'll make sure this fix makes it into the next Xapian release (which
 > > will be 1.0.14).
 > 
 > Awesome, thanks!
 
 Just to update, Xapian 1.0.14 was released last week with this fix.
 
 I tested with a distilled micro-testcase rather than sup and these patches,
 so if you still see problems please open a ticket on http://trac.xapian.org/
 
 Cheers,
     Olly
 
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 11:06:34 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 08:06:34 -0700
 Subject: [sup-talk] trying out sup ...
 In-Reply-To: <20090718074151.GF30748@cat.rubenette.is-a-geek.com>
 References: <20090718074151.GF30748@cat.rubenette.is-a-geek.com>
 Message-ID: <1248793474-sup-9541@masanjin.net>
 
 Hi Lee,
 
 Reformatted excerpts from lee's message of 2009-07-18:
 > So I had sup running on the console and tried out to search for
 > something while sup was looking for new messages in a maildir. But
 > then it crashed and told me I should send a bug report[3].
 > 
 > Maybe I have created some incompatibilities by installing the
 > replacement library. But is it currently possible to run sup on Debian
 > Testing without too much difficulty? If so, what do I need to do?
 
 That particular crash is a transient thing, I think---there is some
 race condition with the display logic that occasionally manifests itself
 as such. I would just retry. I have tentative plans to rewrite a lot of
 the display stuff without threads once we're Ruby 1.9 ready.
 
 I don't know why display is corrupt in rxvt. Do other ncurses apps
 display ok?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 11:07:11 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 08:07:11 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <loom.20090728T134034-967@post.gmane.org>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry>
 	<loom.20090728T134034-967@post.gmane.org>
 Message-ID: <1248793614-sup-5597@masanjin.net>
 
 Reformatted excerpts from Olly Betts's message of 2009-07-28:
 > Just to update, Xapian 1.0.14 was released last week with this fix.
 > 
 > I tested with a distilled micro-testcase rather than sup and these patches,
 > so if you still see problems please open a ticket on http://trac.xapian.org/
 
 Excellent. Thank you.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 11:12:51 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 08:12:51 -0700
 Subject: [sup-talk] [PATCH] explicitly load messages in testcase
 In-Reply-To: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu>
 References: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu>
 Message-ID: <1248793905-sup-2227@masanjin.net>
 
 Hi Rich,
 
 Not to be a pain, but can you give a little more context for this patch
 (and the other two you sent recently)? I'm just trying to understand
 what this fixes.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 11:13:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 08:13:52 -0700
 Subject: [sup-talk] xapian merged into next
 In-Reply-To: <1248751256-sup-4491@pion.club.cc.cmu.edu>
 References: <1248711109-sup-7061@entry>
 	<1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com>
 	<1248711777-sup-9329@entry>
 	<1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com>
 	<1248712876-sup-1446@entry>
 	<1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com>
 	<1248751256-sup-4491@pion.club.cc.cmu.edu>
 Message-ID: <1248793998-sup-5987@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-07-27:
 > We really should have more tests to catch this sort of thing...
 
 Agreed. Mostly my fault, I'm afraid.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 11:17:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 08:17:52 -0700
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248721402-sup-3517@javelin>
 References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net>
 	<1248718344-sup-1931@javelin> <1248719342-sup-9126@javelin>
 	<1248721402-sup-3517@javelin>
 Message-ID: <1248794177-sup-3810@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
 > Alex Vandiver points out that stdscr is a member variable of Ncurses.
 > As such, this patch appears to fix the issue.
 
 Applied with great relish direct to master. Thanks!
 
 > I have no fucking clue why this works.  Perhaps forcibly setting this
 > setting clears some internal buffer.  Either 1 or 0 works, we probably
 > want 1 since that's what bin/sup sets.
 
 Welcome to ncurses programming. Much like fortran, everyone who once
 knew what this stuff meant has since died.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 11:25:23 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 08:25:23 -0700
 Subject: [sup-talk] [PATCH] Make logging less chatty
 In-Reply-To: <1248716783-sup-6509@ntdws12.chass.utoronto.ca>
 References: <1248716313-sup-1608@javelin>
 	<1248716783-sup-6509@ntdws12.chass.utoronto.ca>
 Message-ID: <1248794676-sup-7855@masanjin.net>
 
 Reformatted excerpts from Ben Walton's message of 2009-07-27:
 > +1 for the idea, but wouldn't a command line verbosity toggle be a
 > better way to do this?
 
 I've applied the patch, but yes, the whole Redwood::log thing is crufty
 and needs to be replaced with a logger that's aware of levels.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From bwalton@artsci.utoronto.ca  Tue Jul 28 11:31:24 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Tue, 28 Jul 2009 11:31:24 -0400
 Subject: [sup-talk] Odd key bug
 In-Reply-To: <1248794177-sup-3810@masanjin.net>
 References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net>
 	<1248718344-sup-1931@javelin> <1248719342-sup-9126@javelin>
 	<1248721402-sup-3517@javelin> <1248794177-sup-3810@masanjin.net>
 Message-ID: <1248795045-sup-4556@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Tue Jul 28 11:17:52 -0400 2009:
 
 > Welcome to ncurses programming. Much like fortran, everyone who once
 > knew what this stuff meant has since died.
 
 ...or is making a 'mint' maintaining crap^H^H^H^Hcode from the 80's?
 <grin>
 
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090728/7f69db3f/attachment.bin>
 
 From rlane@club.cc.cmu.edu  Tue Jul 28 11:39:16 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 28 Jul 2009 11:39:16 -0400
 Subject: [sup-talk] [PATCH] explicitly load messages in testcase
 In-Reply-To: <1248793905-sup-2227@masanjin.net>
 References: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1248793905-sup-2227@masanjin.net>
 Message-ID: <1248794785-sup-1840@pion.club.cc.cmu.edu>
 
 Excerpts from William Morgan's message of Tue Jul 28 11:12:51 -0400 2009:
 > Hi Rich,
 > 
 > Not to be a pain, but can you give a little more context for this patch
 > (and the other two you sent recently)? I'm just trying to understand
 > what this fixes.
 
 Sure. The commit "don't automatically parse header on Message#new" broke
 test_message because the message id/etc fields are nil until
 load_from_source! is called. This patch just calls load_from_source!
 whenever we create a message in the testcase.
 
 The other two are fixes for problems reported by Guillaume Quintard.
 Ferret sup-dump was failing because the query passed to each_id didn't
 have any positive terms. The date-ceiling code was broken on 32 bit
 machines because the maximum signed long is 2**31-1, not 2**31.
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 11:48:48 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 08:48:48 -0700
 Subject: [sup-talk] Reply calculation
 In-Reply-To: <1248713591-sup-8324@javelin>
 References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin>
 	<1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin>
 	<1248713182-sup-172@entry> <1248713591-sup-8324@javelin>
 Message-ID: <1248794955-sup-3347@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-07-27:
 > From: correct at example.com
 > To: correct at example.com
 > Reply-To: correct at example.com
 > List-Post: mailto:incorrect at example.com
 > 
 > Sup detects List-Post, categorizes the message as a list message, and then
 > sets the default reply mode as list, which results in List-Post being used
 > as the to address.
 
 So in this case, following reply-to is correct.
 
 > Unfortunately, mailing list administrating is notoriously broken.  I'm not
 > sure at all what the right solution is.  Take for example this other case:
 > 
 > From: person at example.com
 > To: list at example.com
 > Reply-To: person at example.com
 > List-Post: mailto:list at example.com
 > 
 > Reply-To, in this case, was set by the mailing list server.
 
 In this case, I'd argue that this means the list administrator wants the
 default reply behavior to be to the individual and not the list. So I'd
 again prefer Sup default to the reply-to address rather than the list
 address. (With the caveat that this is overrideable by hooks on a
 per-list basis, so if it's a matter of an incompetent list
 administrator, or simply disagreeing with them, one can override this
 behavior for this list.)
 
 > However, consider the next case:
 > 
 > From: persona at example.com
 > To: list at example.com
 > Cc: me at example.com
 > 
 > Which is when someone else hit "Reply all" and you got CC'ed.  This means
 > that the mail never passed through the mailing list agent, the
 > List-Post/Reply-To
 > headers never got set, and the only way to tell that you should reply to the
 > whole list is to explicitly ask for "Reply all" semantics (Sup defaults to
 > "Reply" semantics, which is damn confusing if you're not paying attention).
 
 There's not much to be done in this case, EXCEPT that if you receive
 more than one copy of the message, you should keep the list header
 around. Then the only time you're in a funny situation is when you've
 received the first but not the other.
 
 This is presumably why Mutt had you register your mailing list addresses
 explicitly, which I always found a little irritating.
 
 (Or to have Sup keep around email addresses known to belong to lists,
 and match those in the To: field against that, which seems significantly
 more complicated.)
 
 > The core problem is that subtle changes in state should not require the user
 > to do things differently; it breaks muscle memory and makes mistakes easy.
 
 I agree with this in principle, but I see addressing a message as a
 fundamental part of composing it. You can remove the notion of a smart
 default reply-to address from your Sup, if you like, by using the
 reply-to hook.
 
 And as for the default, I think I'm of the opinion that setting the
 default reply address so as to obey the reply-to is correcter than
 anything else (including whatever Sup does currently).
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From rlane@club.cc.cmu.edu  Tue Jul 28 11:57:56 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Tue, 28 Jul 2009 11:57:56 -0400
 Subject: [sup-talk] xapian question
 In-Reply-To: <1248716325-sup-7534@masanjin.net>
 References: <1248716325-sup-7534@masanjin.net>
 Message-ID: <1248795865-sup-6634@pion.club.cc.cmu.edu>
 
 Excerpts from William Morgan's message of Mon Jul 27 13:45:32 -0400 2009:
 > Hey, I finally get to ask a question!
 > 
 > One of the mildly irritating things about Ferret was that it was
 > impossible to update the labels of a message without updating the entire
 > entry, i.e. including the body. So updating the labels of a message and
 > saving that to disk required either re-loading the body from the source,
 > or keeping the body explicitly in the index so that it could be loaded
 > without going back to the source.
 > 
 > The latter approach is used by the current Ferret index implementation,
 > since it's significantly faster (especially for slow sources like IMAP
 > servers), but at the cost of a lot of disk space.
 > 
 > My understanding of Xapian is that this is also the case, since fields
 > are essentially represented as prefixed terms, and so you're basically
 > updating a big blog, but I wanted to confirm this. I ask because the
 > entries.db file is very big. :)
 
 Xapian actually provides add_term and remove_term for documents. I'd
 definitely like to use these for label updates, but we need a way to
 tell if only the labels have changed in sync_message. Or, we update the
 index in Message#add_label/etc and get rid of the need to save buffers.
 That might not be an option for the Ferret index, though.
 
 We don't store the body in entries.db, just enough info for
 thread-index-mode. It's only about 800 bytes/message for me, but I don't
 have snippets enabled so yours would be larger.
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 12:04:20 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 09:04:20 -0700
 Subject: [sup-talk] [PATCH] explicitly load messages in testcase
 In-Reply-To: <1248794785-sup-1840@pion.club.cc.cmu.edu>
 References: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1248793905-sup-2227@masanjin.net>
 	<1248794785-sup-1840@pion.club.cc.cmu.edu>
 Message-ID: <1248796949-sup-4949@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-07-28:
 > Sure. The commit "don't automatically parse header on Message#new" broke
 > test_message because the message id/etc fields are nil until
 > load_from_source! is called. This patch just calls load_from_source!
 > whenever we create a message in the testcase.
 
 Got it. Applied, thanks!
 
 > The other two are fixes for problems reported by Guillaume Quintard.
 > Ferret sup-dump was failing because the query passed to each_id didn't
 > have any positive terms.
 
 Hah.
 
 > The date-ceiling code was broken on 32 bit machines because the
 > maximum signed long is 2**31-1, not 2**31.
 
 Ok, both applied. Thanks!
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From olly@survex.com  Tue Jul 28 12:53:46 2009
 From: olly@survex.com (Olly Betts)
 Date: Tue, 28 Jul 2009 16:53:46 +0000 (UTC)
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248709366-sup-5856@entry>
 Message-ID: <loom.20090728T134845-816@post.gmane.org>
 
 William Morgan <wmorgan-sup at masanjin.net> writes:
 > Reformatted excerpts from Rich Lane's message of 2009-07-24:
 > > You need to specify a non-negated term in the query.  "type:mail
 > > -label:inbox" should work.
 > 
 > This is a typical restriction for inverted index-based search engines.
 > You need to have at least one positive term or the computation is too
 > expensive (it would have to iterate over every term ever seen.) It's
 > true of Ferret, Google, etc.
 
 Actually, Xapian supports this - Xapian.Query.new("") is a "magic" query
 which matches all documents.
 
 It doesn't need to iterate over every term, just all documents.  But if you
 want the top ten documents without a particular filter, there's no relevance
 ranking, so it can stop after it has found ten matches, which should be
 pretty quick.
 
 This isn't currently supported by the QueryParser when using "-" on terms
 (the reasoning was that it was too easy to accidentally invoke when pasting
 text), but 'NOT label:inbox' will work if you enable it using
 QueryParser.FLAG_PURE_NOT.
 
 Cheers,
     Olly
 
 
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 13:01:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 10:01:43 -0700
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <loom.20090728T134845-816@post.gmane.org>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248709366-sup-5856@entry>
 	<loom.20090728T134845-816@post.gmane.org>
 Message-ID: <1248800452-sup-1121@masanjin.net>
 
 Reformatted excerpts from Olly Betts's message of 2009-07-28:
 > Actually, Xapian supports this - Xapian.Query.new("") is a "magic"
 > query which matches all documents.
 
 Yeah, I think Rich Lane just taught me how Ferret supports this too.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marka@pobox.com  Tue Jul 28 12:57:57 2009
 From: marka@pobox.com (Mark Alexander)
 Date: Tue, 28 Jul 2009 12:57:57 -0400
 Subject: [sup-talk] [PATCH] Make logging less chatty
 In-Reply-To: <1248794676-sup-7855@masanjin.net>
 References: <1248716313-sup-1608@javelin>
 	<1248716783-sup-6509@ntdws12.chass.utoronto.ca>
 	<1248794676-sup-7855@masanjin.net>
 Message-ID: <a412e2a70907280957y73c1f562mc2dc51eb2d738ae0@mail.gmail.com>
 
 On 7/28/09, William Morgan <wmorgan-sup at masanjin.net> wrote:
 > ... but yes, the whole Redwood::log thing is crufty
 > and needs to be replaced with a logger that's aware of levels.
 
 Or maybe something combining types and levels that you
 could configure like this in config.yaml:
 
 :logging:
   :mbox: 2
   :maildir: 3
   :ferret: 0
   ...etc...
 
 From ezyang@MIT.EDU  Tue Jul 28 14:34:46 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Tue, 28 Jul 2009 14:34:46 -0400
 Subject: [sup-talk] Reply calculation
 In-Reply-To: <1248794955-sup-3347@masanjin.net>
 References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin>
 	<1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin>
 	<1248713182-sup-172@entry> <1248713591-sup-8324@javelin>
 	<1248794955-sup-3347@masanjin.net>
 Message-ID: <1248805830-sup-2383@javelin>
 
 Excerpts from William Morgan's message of Tue Jul 28 11:48:48 -0400 2009:
 > > Unfortunately, mailing list administrating is notoriously broken.  I'm not
 > > sure at all what the right solution is.  Take for example this other case:
 > > 
 > > From: person at example.com
 > > To: list at example.com
 > > Reply-To: person at example.com
 > > List-Post: mailto:list at example.com
 > > 
 > > Reply-To, in this case, was set by the mailing list server.
 > 
 > In this case, I'd argue that this means the list administrator wants the
 > default reply behavior to be to the individual and not the list. So I'd
 > again prefer Sup default to the reply-to address rather than the list
 > address. (With the caveat that this is overrideable by hooks on a
 > per-list basis, so if it's a matter of an incompetent list
 > administrator, or simply disagreeing with them, one can override this
 > behavior for this list.)
 
 Nods.
 
 > > However, consider the next case:
 > > 
 > > From: persona at example.com
 > > To: list at example.com
 > > Cc: me at example.com
 > > 
 > > Which is when someone else hit "Reply all" and you got CC'ed.  This means
 > > that the mail never passed through the mailing list agent, the
 > > List-Post/Reply-To
 > > headers never got set, and the only way to tell that you should reply to the
 > > whole list is to explicitly ask for "Reply all" semantics (Sup defaults to
 > > "Reply" semantics, which is damn confusing if you're not paying attention).
 > 
 > There's not much to be done in this case, EXCEPT that if you receive
 > more than one copy of the message, you should keep the list header
 > around. Then the only time you're in a funny situation is when you've
 > received the first but not the other.
 
 This situation is not that uncommon; many mailing list software will notice
 that someone is on a CC list and will purposely omit them.
 
 > I agree with this in principle, but I see addressing a message as a
 > fundamental part of composing it. You can remove the notion of a smart
 > default reply-to address from your Sup, if you like, by using the
 > reply-to hook.
 
 This is true. However, when you compose a non-reply message, Sup prompts
 you for To, Cc and Subject, because they are such fundamental components
 of all messages you would write (well, maybe not so much Cc) and the
 user always has to make a judgment call there.
 
 > And as for the default, I think I'm of the opinion that setting the
 > default reply address so as to obey the reply-to is correcter than
 > anything else (including whatever Sup does currently).
 
 Fair enough.  You may get some complaints because this /will/ break muscle
 memory, and still presents the possibility for messages to have different
 behavior in subtle ways, as detailed in the Cc versus mailing list example
 from above.
 
 Cheers,
 Edward
 
 From kkourt@cslab.ece.ntua.gr  Tue Jul 28 12:58:23 2009
 From: kkourt@cslab.ece.ntua.gr (Kornilios Kourtis)
 Date: Tue, 28 Jul 2009 19:58:23 +0300
 Subject: [sup-talk] [PATCH] handle malformed multiplart messages
 Message-ID: <20090728165823.GA29533@solar.cslab.ece.ntua.gr>
 
 Hi,
 
 I've tried to use sup-mail, but sup-sync blows up due to some malformed
 messages I keep in my mailbox. Below is a quick patch that seems to fix the
 above issue for me.
 
 Thanks,
 
 -- 
 Kornilios Kourtis
 
 diff --git a/lib/sup/message.rb b/lib/sup/message.rb
 index ded577a..c6e6baf 100644
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -385,11 +385,15 @@ private
  
        chunks
      elsif m.header.content_type == "message/rfc822"
 -      payload = RMail::Parser.read(m.body)
 -      from = payload.header.from.first
 -      from_person = from ? Person.from_address(from.format) : nil
 -      [Chunk::EnclosedMessage.new(from_person, payload.to_s)] +
 -        message_to_chunks(payload, encrypted)
 +      if m.body
 +        payload = RMail::Parser.read(m.body)
 +        from = payload.header.from.first
 +        from_person = from ? Person.from_address(from.format) : nil
 +        [Chunk::EnclosedMessage.new(from_person, payload.to_s)] +
 +          message_to_chunks(payload, encrypted)
 +       else
 +        [Chunk::EnclosedMessage.new(nil, "")]
 +       end
      else
        filename =
          ## first, paw through the headers looking for a filename
 
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 14:55:50 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 11:55:50 -0700
 Subject: [sup-talk] error with Sup while sending mails
 In-Reply-To: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com>
 References: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com>
 Message-ID: <1248807059-sup-8075@masanjin.net>
 
 Hi Flo,
 
 Reformatted excerpts from paro 462's message of 2009-07-21:
 > --- NoMethodError from thread: poll after loading inbox
 > undefined method `to_indexable_s' for nil:NilClass
 > ./lib/sup/index.rb:243:in `sync_message'
 
 Interesting. You're the second person who's reported this. It has
 something to do with parsing a particular date. I'm not sure if it's
 locale-related... maybe.
 
 Can you try applying the following patch? I'm hoping that the debugging
 output prefixed with XX will provide a clue.
 
 --- a/lib/sup/message.rb
 +++ b/lib/sup/message.rb
 @@ -92,11 +92,14 @@ class Message
        begin
          Time.parse date
        rescue ArgumentError => e
 -        #Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].inspect} gave error: #{e.message})"
 +        Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].inspect} gave error: #{e.message})"
          Time.now
        end
 -    else
 -      #Redwood::log "faking non-existent date header for #{@id}"
 +    end
 +
 +    @date ||= begin
 +      Redwood::log "XX original header was #{header["date"].inspect}"
 +      Redwood::log "XX faking non-existent date header for #{@id}"
        Time.now
      end
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 15:05:39 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 12:05:39 -0700
 Subject: [sup-talk] xapian question
 In-Reply-To: <1248795865-sup-6634@pion.club.cc.cmu.edu>
 References: <1248716325-sup-7534@masanjin.net>
 	<1248795865-sup-6634@pion.club.cc.cmu.edu>
 Message-ID: <1248807365-sup-4965@masanjin.net>
 
 Reformatted excerpts from Rich Lane's message of 2009-07-28:
 > Xapian actually provides add_term and remove_term for documents.
 
 Excellent.
 
 > I'd definitely like to use these for label updates, but we need a way
 > to tell if only the labels have changed in sync_message.
 
 I've been running into this same issue with my sup-server experiments,
 so I think we should split the API into, say, three separate calls:
 something like add_new_message, update_labels, and update_body. (AFAIK
 the only client of update_body is in some of the draft editing stuff.)
 WDYT?
 
 > Or, we update the index in Message#add_label/etc and get rid of the
 > need to save buffers.  That might not be an option for the Ferret
 > index, though.
 
 I think that would actually be fine for Ferret, and it's a direction
 that's often been discussed. (Especially now that we have undo.) If we
 do the above, we can certainly do this as a later step.
 
 > We don't store the body in entries.db, just enough info for
 > thread-index-mode. It's only about 800 bytes/message for me, but I
 > don't have snippets enabled so yours would be larger.
 
 On second glance, it's a little smaller than I remembered. For my sample
 212m mbox, it's about 20m with snippets enabled.
 
 The total index size under Xapian (the xapian/ dir and all gdbm files)
 is larger than the original mbox file, which seems a little insane. But
 hey, disk space is cheap.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Jul 28 15:10:57 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 28 Jul 2009 12:10:57 -0700
 Subject: [sup-talk] Slow import of messages
 In-Reply-To: <20090713091516.GA21214@ikn.schottelius.org>
 References: <20090713091516.GA21214@ikn.schottelius.org>
 Message-ID: <1248808053-sup-5358@masanjin.net>
 
 Hi Nico,
 
 Reformatted excerpts from Nico Schottelius's message of 2009-07-13:
 > Now the problem is that sup gets about 3 mails per second into its
 > index.
 
 As others have pointed out, messages only have to be indexed once, so
 this isn't ultimately that big of a deal. But 3m/s seems very slow for a
 Maildir source.
 
 With my mbox on my reasonably-fast laptop, I start with around 50m/s
 using Ferret, and at 80m/s using Xapian. (These numbers degrade slightly
 as the index gets fuller.) I would expect similar numbers from Maildir.
 
 So something weird is happening for you. Do you have a notion of whether
 it's disk or CPU that's the bottleneck?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From iny+dev@iki.fi  Wed Jul 29 02:09:42 2009
 From: iny+dev@iki.fi (Ilpo =?iso-8859-1?Q?Nyyss=F6nen?=)
 Date: Wed, 29 Jul 2009 09:09:42 +0300
 Subject: [sup-talk] Handling big mailing lists
 Message-ID: <m3zlaovx3t.fsf@iny.iki.fi>
 
 
 I'm searching alternatives for my Gnus email + news setup. I don't
 expect Sup to be able to do everything Gnus can yet, but maybe in
 future? :) Note that I have never used Gmail.
 
 I tried to test Sup, but I wasn't able to get any emails because Sup
 failed to login to my IMAP server. This happened because the server
 requires client certificates and it looks like Sup doesn't support
 those.
 
 The bigger question is about handling big amount of mailing list mail. 
 I'm reading many small mailing lists and some big ones. Biggest is
 linux-kernel. I can split this to two: daily reading routine and
 expiration.
 
 How would my daily reading routine work with Sup? I want to read
 things in priority order:
 
 1. Personal email
 2. Emails related to my programming hobby
 3. Emails related to some associations like user groups
 4. Mailing lists, also in priority order
 
 The order is such that if I need to stop reading, I have read the most
 important ones already. The order is not static, I want to be able to
 change it.
 
 I have understood that labels are way to get this kind of grouping. 
 Can I get a view where the labels are sorted like this? And can I
 continue reading the next label in that order after I have finished
 the one before?
 
 Then about the expiration. The linux-kernel mailing list gets so much
 email that some kind of expiration is a must. Can Sup do such
 automatic deleting of old emails? Can Sup handle some other process
 doing such automatic deletion? (I would actually prefer some other
 process do it.)
 
 I'm mostly reading just only few authors from linux-kernel and skipping
 rest, but I do like to see the rest in the thread view as sometimes some
 subject is interesting and sometimes some thread gets big and is
 interesting because of that. How would this work?
 
 I would actually recommend reading linux-kernel to test Sup. :)
 
 -- 
 Ilpo Nyyss?nen # biny # /* :-) */
 
 
 From marco-oweber@gmx.de  Wed Jul 29 06:27:06 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Wed, 29 Jul 2009 12:27:06 +0200
 Subject: [sup-talk] error with Sup while sending mails
 In-Reply-To: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com>
 References: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com>
 Message-ID: <1248863105-sup-6533@nixos>
 
 > undefined method `to_indexable_s' for nil:NilClass
 > ./lib/sup/index.rb:243:in `sync_message'
 > ./lib/sup/util.rb:519:in `send'
 
 sup-sync -c did it for me. I don't know what was wrong at all though.
 This will take some time.
 
 If you open index.rb:243 you may want to add a 
 p m where m is the message object? Maybe the output will give you more
 insight as well.
 
 I hope sync helps you as well.
 
 Marc Weber
 
 From marco-oweber@gmx.de  Wed Jul 29 08:54:11 2009
 From: marco-oweber@gmx.de (Marc Weber)
 Date: Wed, 29 Jul 2009 14:54:11 +0200
 Subject: [sup-talk] Handling big mailing lists
 In-Reply-To: <m3zlaovx3t.fsf@iny.iki.fi>
 References: <m3zlaovx3t.fsf@iny.iki.fi>
 Message-ID: <1248871866-sup-9988@nixos>
 
 You can use hooks to add labels:
 
 my "~/.sup/hooks/before-add-message.rb":
 
   def matchR(email)
     not message.recipients.find{ |to|  /^#{email}$/i =~ to.email}.nil?
   end
 
   def matchRAddLabel(email, label, inbox = 0)
     if matchR email then
       message.add_label label 
       message.remove_label :inbox unless inbox
     end
   end
 
   def importantFrom(email)
     message.add_label :Starred if message.from.email == email
   end
 
   importantFrom "info at webkos.de"
 
 
   matchRAddLabel("mod_python at modpython.org","mod-python", 1)
   matchRAddLabel("mod_python at modpython.org","mod-python", 0)
 
   if message.subj =~ /^Project Notification$/ && message.from.email == "info at guru.com" then
     message.add_label "GURU_PROJECT_NOTIFICATION"
     message.add_label "delete_after_one_month"
   end
 
   if message.subj =~ /^WEBKOS_/ then
     message.remove_label :inbox
     message.add_label "WEBKOS_"
   end
 
 
 So adding labels onle if a contsraint is met is easy.
 About deleting mails: There is sup-sync-back. So there must be a way to delete
 "old" / whatever mails. I haven't used it yet.
 
 I'm new to sup myself.
 
 Yours
 Marc Weber
 
 From wmorgan-sup@masanjin.net  Wed Jul 29 09:46:19 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 29 Jul 2009 06:46:19 -0700
 Subject: [sup-talk] Handling big mailing lists
 In-Reply-To: <m3zlaovx3t.fsf@iny.iki.fi>
 References: <m3zlaovx3t.fsf@iny.iki.fi>
 Message-ID: <1248874122-sup-3830@masanjin.net>
 
 Hi,
 
 Excellent set of questions. Handling large volumes of mail is one of my
 main goals with Sup.
 
 Reformatted excerpts from iny+dev's message of 2009-07-28:
 > I tried to test Sup, but I wasn't able to get any emails because Sup
 > failed to login to my IMAP server. This happened because the server
 > requires client certificates and it looks like Sup doesn't support
 > those.
 
 As far as IMAP goes, Sup supports whatever authentication the Ruby IMAP
 libraries supports, which is probably not much.
 
 Any serious use of Sup with IMAP is best done via an intermediate like
 offlineimap, which syncs an IMAP folder to a local Maildir folder. The
 Ruby IMAP libraries, and possibly IMAP itself, is a little too slow for
 how Sup likes to work.
 
 > How would my daily reading routine work with Sup? I want to read
 > things in priority order:
 > 
 > 1. Personal email
 > 2. Emails related to my programming hobby
 > 3. Emails related to some associations like user groups
 > 4. Mailing lists, also in priority order
 
 Sup gives you two tools: search and labels. Sup will present a list of
 threads that match any search query. So, each of those steps is
 possible, to the extent that you can compose a search query that
 reflects it.
 
 You can automatically add labels via arbitrary code, so you have a fair
 amount of flexibility here.
 
 > The order is such that if I need to stop reading, I have read the most
 > important ones already. The order is not static, I want to be able to
 > change it.  I have understood that labels are way to get this kind of
 > grouping.  Can I get a view where the labels are sorted like this?
 
 Sup currently only orders chronologically. It would not be difficult to
 add a second level of user-defined sorting *on top* of the chronological
 one, but it would be difficult, if not impossible, to order all email in
 the index by an arbitrary function.
 
 (To be pedantic, if you can come up with a single number for each email,
 which never changes, and which is known at add time, you can order by
 that, with some work. But it doesn't sound like that's what you want.)
 
 > And can I continue reading the next label in that order after I have
 > finished the one before?
 
 Certainly, but not automatically. You can view one label, and then pick
 another label to view, etc.
 
 I suppose if the above second-round of ordering were implemented, you
 could view both labels at once and make an ordering function that placed
 one above the other.
 
 > Then about the expiration. The linux-kernel mailing list gets so much
 > email that some kind of expiration is a must.
 
 You don't want to just buy a bigger hard drive?
 
 > Can Sup do such automatic deleting of old emails? Can Sup handle some
 > other process doing such automatic deletion? (I would actually prefer
 > some other process do it.)
 
 That's best left to another process. You'll then have to tell Sup which
 messages were deleted so that it can remove them from the index. Let me
 know when you're at this point and I can help you---it will require a
 brief Ruby script.
 
 > I would actually recommend reading linux-kernel to test Sup. :)
 
 I read ruby-talk, which is probably not too far off.
 
 One last comment: large threads are irritatingly slow to create in
 thread-view-mode with the Ferret index, but there's a new Xapian index
 which is fast for this. It's still slightly experimental.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From iny+dev@iki.fi  Wed Jul 29 13:24:43 2009
 From: iny+dev@iki.fi (Ilpo =?iso-8859-1?Q?Nyyss=F6nen?=)
 Date: Wed, 29 Jul 2009 20:24:43 +0300
 Subject: [sup-talk] Handling big mailing lists
 References: <m3zlaovx3t.fsf@iny.iki.fi> <1248874122-sup-3830@masanjin.net>
 Message-ID: <m3prbjwgf8.fsf@iny.iki.fi>
 
 William Morgan <wmorgan-sup at masanjin.net> writes:
 
 > Sup currently only orders chronologically. It would not be difficult to
 > add a second level of user-defined sorting *on top* of the chronological
 > one, but it would be difficult, if not impossible, to order all email in
 > the index by an arbitrary function.
 
 I'm not talking about ordering of emails, I'm talking about ordering of
 the labels.
 
 When I start my daily routine, I want to see a list of labels with
 numbers telling how many unread emails each has. Labels containing
 nothing new must be hidden. And this list must be sorted to priority
 order. Then I want to read those labels through in that order.
 
 How many labels would I have? At least tens, probably over hundred.
 
 >> And can I continue reading the next label in that order after I have
 >> finished the one before?
 >
 > Certainly, but not automatically. You can view one label, and then pick
 > another label to view, etc.
 
 Picking one from alphabetically sorted list or writing it is not usable. 
 I don't remember the order, I just want to get the next one.
 
 >> Then about the expiration. The linux-kernel mailing list gets so much
 >> email that some kind of expiration is a must.
 >
 > You don't want to just buy a bigger hard drive?
 
 It's not a disk space problem. The problem is that many things would get
 slow (or I would need to configure exceptions) and I just do not have
 any need for them. They are all in searchable mailing list archives
 anyway.
 
 And another point is that I actually prefer not to order mailing lists. 
 It is much easier to just get them with nntp from news.gmane.org. How? I
 have a nntp to imap gateway and I use it to read also from other nntp
 servers. The thing here is that nntp servers usually do expire messages
 and so to be able to use that with Sup, it would need to tolerate the
 expiration.
 
 > That's best left to another process. You'll then have to tell Sup which
 > messages were deleted so that it can remove them from the index.
 
 So, I don't do the expiration. I guess it should be possible to find out
 the ones that went away when checking for new ones.
 
 > Let me know when you're at this point and I can help you---it will
 > require a brief Ruby script.
 
 Well, it is looking like in current state I won't even start trying.
 
 >> I would actually recommend reading linux-kernel to test Sup. :)
 >
 > I read ruby-talk, which is probably not too far off.
 
 Hmm,
 
 http://dir.gmane.org/gmane.comp.lang.ruby.general
 http://dir.gmane.org/gmane.linux.kernel
 
 I guess so. How long it takes to index few months of ruby-talk?
 
 Could Sup use IMAP search features?
 
 -- 
 Ilpo Nyyss?nen # biny # /* :-) */
 
 
 From dato@net.com.org.es  Thu Jul 30 11:56:56 2009
 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=)
 Date: Thu, 30 Jul 2009 17:56:56 +0200
 Subject: [sup-talk] [PATCH] mime-decode hook: provide a
 	"charset"	variable with the attachment charset
 In-Reply-To: <1248713434-sup-4961@entry>
 References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es>
 	<20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry>
 Message-ID: <20090730155656.GA20442@chistera.yi.org>
 
 + William Morgan (Mon, 27 Jul 2009 09:51:17 -0700):
 
 > Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23:
 > > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200):
 > > > +                          :charset => encoded_content.charset,
 
 > > Hm, so apparently encoded_content doesn't always have a charset
 > > member...
 
 > In which case that value of that variable is nil, right? Is that a
 > problem? The patch still seems useful.
 
 Yes, I took a closer look and you're right the result of
 encoded_content.charset is nil in that case. I also saw (I think) where
 the traceback I was seeing is coming from: apparently it's not possible
 to pass to HookContext a local that is nil, since then "super" will get
 called in HookContext::method_missing() as far as I can see.
 
 So, perhaps, to fix this patch, one could do:
 
     :charset => encoded_content.charset || ''
 
 But then, I think it would be better to fix HookContext to allow for
 @__locals to contain nil. I'm not very familiar with that class, but it
 seems easy enough to fix, see upcoming patch (also found in
 ~dato/sup/sup-dato:fixes at Gitorious, if you prefer that). With it,
 this improvement to mime-decode seems to work without any further
 trouble.
 
 Cheers,
 
 -- 
 - Are you sure we're good?
 - Always. -- Rory and Lorelai
 
 
 From dato@net.com.org.es  Thu Jul 30 11:57:16 2009
 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=)
 Date: Thu, 30 Jul 2009 17:57:16 +0200
 Subject: [sup-talk] [PATCH] HookContext::method_missing(): allow locals to
 	be nil
 In-Reply-To: <20090730155656.GA20442@chistera.yi.org>
 References: <20090730155656.GA20442@chistera.yi.org>
 Message-ID: <b6ff832e5f1872bda03e7846260165e8571c6dae.1248969435.git.dato@net.com.org.es>
 
 With the previous implementation of method_missing() in HookContext, it
 was not possible to set the value of a local to nil, since that would be
 assumed to mean "that local does not exist" and super would get called.
 
 Now we use has_key? to check whether the local exists or not, and nil
 will be returned normally from method_missing if that's the value of the
 @__locals[name].
 
 Signed-off-by: Adeodato Sim? <dato at net.com.org.es>
 ---
  lib/sup/hook.rb |   12 +++++++-----
  1 files changed, 7 insertions(+), 5 deletions(-)
 
 diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb
 index 0a0a2f6..8a52a96 100644
 --- a/lib/sup/hook.rb
 +++ b/lib/sup/hook.rb
 @@ -20,13 +20,15 @@ class HookManager
      attr_writer :__locals
  
      def method_missing m, *a
 -      case @__locals[m]
 -      when Proc
 -        @__locals[m] = @__locals[m].call(*a) # only call the proc once
 -      when nil
 +      if not @__locals.has_key? m
          super
        else
 -        @__locals[m]
 +        case @__locals[m]
 +        when Proc
 +          @__locals[m] = @__locals[m].call(*a) # only call the proc once
 +        else
 +          @__locals[m]
 +        end
        end
      end
  
 -- 
 1.6.3.3
 
 
 From tom@dbservice.com  Thu Jul 30 14:31:12 2009
 From: tom@dbservice.com (Tomas Carnecky)
 Date: Thu, 30 Jul 2009 20:31:12 +0200
 Subject: [sup-talk] sup on opensolaris
 Message-ID: <C1361ACC-8CF6-4AD9-955C-0B812197AF19@dbservice.com>
 
 Kids, don't try this at home, it kills kittens! Well, not directly,  
 but trying to get sup running will drive you so mad you will try to  
 kill everything that moves. In other words: it doesn't work and the  
 fact that I'm trying this on opensolaris doesn't make it any easier.
 
 The biggest issue is that the ruby binary from the package manager is  
 linked against the ancient solaris curses.so but ruby-ncurses needs  
 ncurses.so (which, to make the issue even more complicated, is in /usr/ 
 gnu/lib). When both libraries are liked into one application, they  
 don't play along well (=segfaults). I had to compile ruby from source  
 and make sure it's not liked with curses.so, and also patch ruby- 
 ncurses slightly. I then managed to get sup to start up and read my  
 mails. However, there is one issue left that I'm not able to fix:  
 Ncurses.field.field_buffer() is returning garbage, and that makes is  
 impossible to write mails, search and set tags etc. The problem is  
 somewhere inside sup, as the ruby-ncurses example form2.rb is working  
 just fine (maybe it has something to do with encoding/locale?).
 
 I have an ugly patch for lib/sup/textfield.rb that uses its own string  
 buffer instead of relying on field_buffer(). It's not perfect, but it  
 at least allows me to write emails and assign tags.
 
 Other issues:
   - strftime("%P") is a GNU extension, I work around this by using  
 strftime("%p").downcase.
   - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "// 
 IGNORE" is causing an InvalidEncoding exception, removing it didn't  
 seem to cause any regressions
 
 tom
 
 
 From garoth@gmail.com  Fri Jul 31 11:17:28 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 31 Jul 2009 11:17:28 -0400
 Subject: [sup-talk] Smooth Paging
 Message-ID: <1249053249-sup-9884@Longbow>
 
 Hello,
 
 One thing's that I've found a bit suboptimal in Sup has been the paging
 ie. scrolling of e-mails. When you reach the bottom, it scrolls the
 whole page up, rather than scrolling smoothly as might be the default
 behaviour of Vim for example.
 
 I find this really awkward at times, since I can't see what I just read
 while reading the next line. It's also just kind of jumpy. One main use
 case that his damages is when I'm doing patch review on mailing lists
 and stuff.
 
 I'll open a long e-mail with diffs in it, and I will be scrolling to see
 the patch. Then, as I reach the bottom, it jumps and hides what I just
 read, making understanding code logic painful at times. So then I have
 to jump up and down some more to figure it out, but that sucks because I
 have to look between the top and bottom of the screen.
 
 What do you guys think?
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From garoth@gmail.com  Fri Jul 31 11:23:07 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 31 Jul 2009 11:23:07 -0400
 Subject: [sup-talk] Sup Resource Usage
 Message-ID: <1249053483-sup-9050@Longbow>
 
 This isn't a serious complaint, but I'd just like to bring a couple
 things with respect to Sup resource usage to the light.
 
 According to top, Sup uses a fair bit of ram: about 30 MB at any point.
 For comparison, pidgin uses about that much, and firefox uses 4x more.
 That's generally acceptable, but more than I'd expect from a CLI app.
 This is probably unavoidable.
 
 What I find a bit more curious is Sup's wakeups. According to powertop,
 sup is actually one of the top power munchers on my computers. I don't
 understand why it has to wake up as often as it does: it's responsible
 for 20% of all wakeups, with a rating of ~115. By comparison, firefox
 does almost exactly the same amount of wakeups, and sup is the third
 thing on my list, way above my window manager/de which does considerably
 more.
 
 I wonder what could be up here. Anyway, I'm fine with it if it's
 un-investigated. Cheers.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From ezyang@MIT.EDU  Fri Jul 31 11:38:00 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 31 Jul 2009 11:38:00 -0400
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249053249-sup-9884@Longbow>
 References: <1249053249-sup-9884@Longbow>
 Message-ID: <1249054651-sup-1510@javelin>
 
 Excerpts from Andrei Thorp's message of Fri Jul 31 11:17:28 -0400 2009:
 > One thing's that I've found a bit suboptimal in Sup has been the paging
 > ie. scrolling of e-mails. When you reach the bottom, it scrolls the
 > whole page up, rather than scrolling smoothly as might be the default
 > behaviour of Vim for example.
 
 I agree with this assessment and think smoother scrolling would be a
 nice extra touch.
 
 Cheers,
 Edward
 
 From wmorgan-sup@masanjin.net  Fri Jul 31 11:43:26 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 31 Jul 2009 08:43:26 -0700
 Subject: [sup-talk] Sup Resource Usage
 In-Reply-To: <1249053483-sup-9050@Longbow>
 References: <1249053483-sup-9050@Longbow>
 Message-ID: <1249054758-sup-9479@masanjin.net>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-07-31:
 > What I find a bit more curious is Sup's wakeups. According to
 > powertop, sup is actually one of the top power munchers on my
 > computers. I don't understand why it has to wake up as often as it
 > does: it's responsible for 20% of all wakeups, with a rating of ~115.
 
 What's the wakeup behavior of "ruby -esleep"?
 
 What's the behavior of this Ruby program:
 
   require 'rubygems'
   require 'ncurses'
 
   Ncurses.initscr
   c = Ncurses.getch
   Ncurses.endwin
 
   puts c
 
 I'd also be curious if things change under Ruby 1.9.1, since I'd like to
 move to that as soon as feasible.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jul 31 11:44:25 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 31 Jul 2009 08:44:25 -0700
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249053249-sup-9884@Longbow>
 References: <1249053249-sup-9884@Longbow>
 Message-ID: <1249055039-sup-8105@masanjin.net>
 
 Reformatted excerpts from Andrei Thorp's message of 2009-07-31:
 > What do you guys think?
 
 Have you tried J and K vs j and k to scroll?
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From ezyang@MIT.EDU  Fri Jul 31 11:46:40 2009
 From: ezyang@MIT.EDU (Edward Z. Yang)
 Date: Fri, 31 Jul 2009 11:46:40 -0400
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249055039-sup-8105@masanjin.net>
 References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net>
 Message-ID: <1249055175-sup-4619@javelin>
 
 Excerpts from William Morgan's message of Fri Jul 31 11:44:25 -0400 2009:
 > Have you tried J and K vs j and k to scroll?
 
 In general, I use PgUp and PgDn to scroll.  I didn't realize those keybindings
 existed. :-)
 
 Cheers,
 Edward
 
 From wmorgan-sup@masanjin.net  Fri Jul 31 11:56:52 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 31 Jul 2009 08:56:52 -0700
 Subject: [sup-talk] sup on opensolaris
 In-Reply-To: <C1361ACC-8CF6-4AD9-955C-0B812197AF19@dbservice.com>
 References: <C1361ACC-8CF6-4AD9-955C-0B812197AF19@dbservice.com>
 Message-ID: <1249055178-sup-7149@masanjin.net>
 
 Hi Tom,
 
 Thanks for the report! It's nice to have another system "supported", at
 least technically.
 
 Reformatted excerpts from Tomas Carnecky's message of 2009-07-30:
 > However, there is one issue left that I'm not able to fix:
 > Ncurses.field.field_buffer() is returning garbage, and that makes is
 > impossible to write mails, search and set tags etc. The problem is
 > somewhere inside sup, as the ruby-ncurses example form2.rb is working
 > just fine (maybe it has something to do with encoding/locale?).
 
 The ncurses field stuff is some hellish bullshit that I hate with all my
 heart. It may very well be a locale problem... I really don't want to
 debug it.
 
 > I have an ugly patch for lib/sup/textfield.rb that uses its own string
 > buffer instead of relying on field_buffer(). It's not perfect, but it
 > at least allows me to write emails and assign tags.
 
 If it's not too much work to clean up, I'd be interested in this patch.
 The field buffer stuff is broken in weird ways anyways (the history
 never seems to be quite right), and anything that reduces the reliance
 on ncurses is always the right approach.
 
 
 >   - strftime("%P") is a GNU extension, I work around this by using  
 > strftime("%p").downcase.
 
 Submit a patch! I'm fine with this.
 
 >   - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "// 
 > IGNORE" is causing an InvalidEncoding exception, removing it didn't  
 > seem to cause any regressions
 
 Hm, this is a trickier one. Allegedly the //IGNORE reduces the
 exceptions thrown by Iconv, but since we're catching them all anyways,
 we might be able to get away with removing this. Or we could
 special-case it to your arch.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Jul 31 11:57:43 2009
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 31 Jul 2009 08:57:43 -0700
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249055175-sup-4619@javelin>
 References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net>
 	<1249055175-sup-4619@javelin>
 Message-ID: <1249055837-sup-9394@masanjin.net>
 
 Reformatted excerpts from Edward Z. Yang's message of 2009-07-31:
 > In general, I use PgUp and PgDn to scroll.  I didn't realize those
 > keybindings existed. :-)
 
 Ctrl-e and ctrl-y work as well, if you're a vi addict.
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From garoth@gmail.com  Fri Jul 31 12:00:00 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 31 Jul 2009 12:00:00 -0400
 Subject: [sup-talk] Sup Resource Usage
 In-Reply-To: <1249054758-sup-9479@masanjin.net>
 References: <1249053483-sup-9050@Longbow> <1249054758-sup-9479@masanjin.net>
 Message-ID: <1249055796-sup-2690@Longbow>
 
 Excerpts from William Morgan's message of Fri Jul 31 11:43:26 -0400 2009:
 > What's the wakeup behavior of "ruby -esleep"?
 
 Well, you can easily test this yourself with powertop, but just running
 this command does not cause a lot of wakeups. (It's not in the top
 causes list.)
 
 > What's the behavior of this Ruby program:
 > 
 >   require 'rubygems'
 >   require 'ncurses'
 > 
 >   Ncurses.initscr
 >   c = Ncurses.getch
 >   Ncurses.endwin
 > 
 >   puts c
 
 This program exits right away, so I don't really know how to test it.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From garoth@gmail.com  Fri Jul 31 12:01:08 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 31 Jul 2009 12:01:08 -0400
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249055039-sup-8105@masanjin.net>
 References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net>
 Message-ID: <1249056026-sup-1964@Longbow>
 
 Excerpts from William Morgan's message of Fri Jul 31 11:44:25 -0400 2009:
 > Reformatted excerpts from Andrei Thorp's message of 2009-07-31:
 > > What do you guys think?
 > 
 > Have you tried J and K vs j and k to scroll?
 
 No I haven't, but I'm glad to know they exist :)
 
 Thanks.
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From garoth@gmail.com  Fri Jul 31 12:11:29 2009
 From: garoth@gmail.com (Andrei Thorp)
 Date: Fri, 31 Jul 2009 12:11:29 -0400
 Subject: [sup-talk] Smooth Paging
 In-Reply-To: <1249055837-sup-9394@masanjin.net>
 References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net>
 	<1249055175-sup-4619@javelin> <1249055837-sup-9394@masanjin.net>
 Message-ID: <1249056674-sup-2428@Longbow>
 
 Excerpts from William Morgan's message of Fri Jul 31 11:57:43 -0400 2009:
 > Reformatted excerpts from Edward Z. Yang's message of 2009-07-31:
 > > In general, I use PgUp and PgDn to scroll.  I didn't realize those
 > > keybindings existed. :-)
 > 
 > Ctrl-e and ctrl-y work as well, if you're a vi addict.
 
 I didn't even know that one o_0. (in vim)
 -- 
 Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)
 
 From rlane@club.cc.cmu.edu  Fri Jul 31 12:20:41 2009
 From: rlane@club.cc.cmu.edu (Rich Lane)
 Date: Fri, 31 Jul 2009 12:20:41 -0400
 Subject: [sup-talk] [PATCH 0/18] Xapian-based index
 In-Reply-To: <1248710432-sup-1734@pion.club.cc.cmu.edu>
 References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu>
 	<1245854803-sup-4481@entry> <1245864733-sup-1216@entry>
 	<loom.20090625T222159-861@post.gmane.org>
 	<1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse>
 	<20090723102325.GA4291@chistera.yi.org>
 	<1248497184-sup-939@pion.club.cc.cmu.edu>
 	<1248513425-sup-2484@chistera.yi.org>
 	<1248550384-sup-74@pion.club.cc.cmu.edu>
 	<1248709681-sup-4141@entry>
 	<1248710432-sup-1734@pion.club.cc.cmu.edu>
 Message-ID: <1249056691-sup-9011@pion.club.cc.cmu.edu>
 
 Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009:
 > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009:
 > > Reformatted excerpts from Rich Lane's message of 2009-07-25:
 > > > One issue I've noticed is that removing labels from messages doesn't
 > > > always immediately work.
 > > 
 > > Is this true even after you sync changes to the index? What about if you
 > > reload the label list buffer? ('@')
 > 
 > Yes. This is looking like a Xapian bug - I've reproduced it without any
 > Sup code. I'm working on a fix.
 
 I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian
 SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1). 
 
 From bwalton@artsci.utoronto.ca  Fri Jul 31 12:59:16 2009
 From: bwalton@artsci.utoronto.ca (Ben Walton)
 Date: Fri, 31 Jul 2009 12:59:16 -0400
 Subject: [sup-talk] sup on opensolaris
 In-Reply-To: <1249055178-sup-7149@masanjin.net>
 References: <C1361ACC-8CF6-4AD9-955C-0B812197AF19@dbservice.com>
 	<1249055178-sup-7149@masanjin.net>
 Message-ID: <1249059493-sup-7953@ntdws12.chass.utoronto.ca>
 
 Excerpts from William Morgan's message of Fri Jul 31 11:56:52 -0400 2009:
 > Thanks for the report! It's nice to have another system "supported", at
 > least technically.
 
 I'm the ruby maintainer for OpenCSW, which provides binary packages
 for solaris 8+ linked against a modern curses.  Everything lives in
 /opt/csw/, so it's self contained except where linking to system
 stuff.
 
 I _think_ this should all work on opensolaris (but I don't use it) if
 you're interested in trying it.  That won't help things like %P (%z is
 another common offender I come across), but it may make part of your
 life easier.
 
 You'll get a modern libiconv too, although the version in opensolaris
 shouldn't be that old?
 
 http://www.opencsw.org/
 
 HTH
 -Ben
 -- 
 Ben Walton
 Systems Programmer - CHASS
 University of Toronto
 C:416.407.5610 | W:416.978.4302
 
 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
 Contact me to arrange for a CAcert assurance meeting.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: signature.asc
 Type: application/pgp-signature
 Size: 189 bytes
 Desc: not available
 URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090731/84805c4a/attachment.bin>