sup

community/pipermail-archives/sup-talk/2007-11.txt (276607B) - raw

 From manish@gslab.com  Thu Nov  1 00:59:59 2007
 From: manish@gslab.com (Manish Sapariya)
 Date: Thu, 01 Nov 2007 10:29:59 +0530
 Subject: [sup-talk] exception while syncing
 Message-ID: <47295D4F.9020101@gslab.com>
 
 Hi All,
 Is this known issue? If yes, can anyone suggest workaroud, if no
 where can log bug for this issue? Please let me know if you need
 more info in any case.
 
 I saw following warnings before the crash.
 [Thu Nov 01 10:11:12 +0530 2007] warning: error decoding message body
 from "us-ascii": "\222t waste time. C"...
 [Thu Nov 01 10:11:12 +0530 2007] ignoring erroneous message at
 mbox:/data/personel/mails/ImapMail/INBOX#25586133: no message-id field
 in header {} (source mbox:/data/personel/mails/ImapMail/INBOX offset
 25586133)
 [Thu Nov 01 10:11:56 +0530 2007] warning: error decoding message body
 from "iso-8859-8-i": invalid encoding ("UTF-8", ""iso-8859-8-i"")
 [Thu Nov 01 10:12:01 +0530 2007] warning: error decoding message body
 from "us-ascii": "\222ll save up to 5"...
 ## 2344 (32.39%) read; 0:01:00 elapsed; 0:02:05 remaining
 [Thu Nov 01 10:12:08 +0530 2007] warning: error decoding message body
 from "ks_c_5601-1987": invalid encoding ("UTF-8", ""ks_c_5601-1987"")
 
 
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/multipart.rb:159:in
 `[]=': can't modify frozen string (TypeError)
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/multipart.rb:159:in
 `read_chunk_low'
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/multipart.rb:94:in
 `loop'
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/multipart.rb:94:in
 `read_chunk_low'
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/multipart.rb:76:in
 `read_chunk'
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/pushbackreader.rb:85:in 
 
 `read'
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser.rb:285:in
 `parse_singlepart_body'
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser.rb:198:in
 `parse_low'
         from
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser.rb:275:in
 `parse_multipart_body'
          ... 26 levels...
         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/bin/sup-sync:128:in `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/bin/sup-sync:128
         from /usr/bin/sup-sync:16:in `load'
         from /usr/bin/sup-sync:16
 
 Regards,
 Manish
 
 
 From col@baibell.org  Thu Nov  1 01:33:26 2007
 From: col@baibell.org (Colin Bell)
 Date: Thu, 01 Nov 2007 16:33:26 +1100
 Subject: [sup-talk] exception while syncing
 In-Reply-To: <47295D4F.9020101@gslab.com>
 References: <47295D4F.9020101@gslab.com>
 Message-ID: <1193894943-sup-9567@lankhmar>
 
 Excerpts from Manish Sapariya's message of Thu Nov 01 15:59:59 +1100 2007:
 > Hi All,
 > Is this known issue? If yes, can anyone suggest workaroud, if no
 > where can log bug for this issue? Please let me know if you need
 > more info in any case.
 /usr/lib/ruby/gems/1.8/gems/rmail-0.17/lib/rmail/parser/multipart.rb:159:in
 > `[]=': can't modify frozen string (TypeError)
 >         from
 
 Probably this problem from the FAQ
 http://sup.rubyforge.org/FAQ.txt
 
 P: I get some error message from Rubymail about frozen strings when
    importing messages with attachments.
 S: The current solution is to directly modify RubyMail.
   Change line 159 of   multipart.rb to:
      chunk = chunk[0..start]
    This is because RubyMail hasn't been updated since like Ruby 1.8.2.
    Please bug Matt Lickey.
 
 From marcus-sup@quintic.co.uk  Thu Nov  1 05:02:57 2007
 From: marcus-sup@quintic.co.uk (Marcus Williams)
 Date: Thu, 01 Nov 2007 09:02:57 +0000
 Subject: [sup-talk] [PATCH] Check IMAP capabilities before using auth methods
 Message-ID: <1193907675-sup-9254@tomsk>
 
 Hi -
 
 Following patch speeds up IMAP logins if your server doesnt support
 CRAM-MD5 or the LOGIN auth methods by checking the advertised
 capabilities on the connection before trying to use them.
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: imap-diffs
 Type: application/octet-stream
 Size: 986 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071101/d9d0e2e4/attachment.obj 
 
 From marcus-sup@quintic.co.uk  Thu Nov  1 05:10:26 2007
 From: marcus-sup@quintic.co.uk (Marcus Williams)
 Date: Thu, 01 Nov 2007 09:10:26 +0000
 Subject: [sup-talk] Seen flag treated incorrectly on IMAP mail
 In-Reply-To: <2d4a3f900012fe89@IMSS-WIN>
 References: <2d4a3f900012fe89@IMSS-WIN>
 Message-ID: <47299802.50007@quintic.co.uk>
 
 On 31/10/2007 Colin Bell wrote:
 > I think its caused by this code in each(...) in imap.rb
 > 
 >  labels = { :Seen => :unread,
 >             :Flagged => :starred,
 >             :Deleted => :deleted
 >           }.inject(@labels) do |cur, (imap, sup)|
 >     cur + (state[:flags].include?(imap) ? [sup] : [])
 > 
 > This seems (to my non-existent Ruby skills) to be equating the IMAP
 > Seen flag to be the same as the Sup Unread flag, instead of Seen as
 > being Not Unread.
 
 Yep, I submitted a patch earlier last month (search for imap patch) to 
 fix this although what it did was use the /Recent flag to check for 
 unread messages. This works as long as you dont use the IMAP source in 
 any other client before sup checks for new messages.
 
 In reality what it should be checking for is the lack of the /Seen flag. 
 That requires a patch to the sources generally so they can work out if 
 they've been read or not (included in my patch). I've also got some 
 further tweaks to the patch locally that I'll submit once I've tested 
 them a bit more.
 
 Marcus
 
 
 From manish@gslab.com  Thu Nov  1 08:48:54 2007
 From: manish@gslab.com (Manish Sapariya)
 Date: Thu, 01 Nov 2007 18:18:54 +0530
 Subject: [sup-talk] one more exception,
 Message-ID: <4729CB36.3050408@gslab.com>
 
 Hi,
 Sorry for posting each and every exception, but I am not been able
 to use sup since yesterday, because of one or the other reason.
 Any help will be appreciated.
 Thanks,
 Manish
 
 The problem was: 'can't convert nil into String' (error type TypeError)
 A backtrace follows:
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:323:in 
 `initialize': can't convert nil into String (TypeError)
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:323:in 
 `new'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:323:in 
 `load_entry_for_id'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in 
 `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in 
 `method_missing'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:149:in 
 `add_messages_from'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/source.rb:93:in 
 `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in 
 `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in 
 `__pass'
          ... 28 levels...
         from 
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/modes/thread-index-mode.rb:422:in 
 `load_threads'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup:188
         from /usr/bin/sup:16:in `load'
         from /usr/bin/sup:16
 
 
 From grant@antiflux.org  Thu Nov  1 13:06:47 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Thu, 01 Nov 2007 13:06:47 -0400
 Subject: [sup-talk] [PATCH] Check IMAP capabilities before using auth
 	methods
 In-Reply-To: <1193907675-sup-9254@tomsk>
 References: <1193907675-sup-9254@tomsk>
 Message-ID: <1193936725-sup-5565@spooky.local>
 
 Excerpts from Marcus Williams's message of Thu Nov 01 05:02:57 -0400 2007:
 > Following patch speeds up IMAP logins if your server doesnt support
 > CRAM-MD5 or the LOGIN auth methods by checking the advertised
 > capabilities on the connection before trying to use them.
 
 Much better!
 
 Are there any plans to have IMAP sources with a common server share a connection?
 
 From stubbsd@zetani.com  Thu Nov  1 17:07:20 2007
 From: stubbsd@zetani.com (=?utf-8?B?RGF2aWQgU3R1YmJz?=)
 Date: Thu, 1 Nov 2007 21:07:20 +0000
 Subject: [sup-talk] one more exception,
 In-Reply-To: <4729CB36.3050408@gslab.com>
 References: <4729CB36.3050408@gslab.com>
 Message-ID: <1347250505-1193951242-cardhu_decombobulator_blackberry.rim.net-134551103-@bxe008.bisx.produk.on.blackberry>
 
 Q
 -----Original Message-----
 From: Manish Sapariya <manish at gslab.com>
 
 Date: Thu, 01 Nov 2007 18:18:54 
 To:sup-talk at rubyforge.org
 Subject: [sup-talk] one more exception,
 
 
 Hi,
 Sorry for posting each and every exception, but I am not been able
 to use sup since yesterday, because of one or the other reason.
 Any help will be appreciated.
 Thanks,
 Manish
 
 The problem was: 'can't convert nil into String' (error type TypeError)
 A backtrace follows:
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:323:in
 `initialize': can't convert nil into String (TypeError)
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:323:in
 `new'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:323:in
 `load_entry_for_id'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in
 `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in
 `method_missing'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:149:in
 `add_messages_from'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/source.rb:93:in
 `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in
 `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in
 `__pass'
          ... 28 levels...
         from
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/modes/thread-index-mode.rb:422:in
 `load_threads'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup:188
         from /usr/bin/sup:16:in `load'
         from /usr/bin/sup:16
 
 _______________________________________________
 sup-talk mailing list
 sup-talk at rubyforge.org
 http://rubyforge.org/mailman/listinfo/sup-talk
 
 From col@baibell.org  Thu Nov  1 18:09:00 2007
 From: col@baibell.org (Colin Bell)
 Date: Fri, 02 Nov 2007 09:09:00 +1100
 Subject: [sup-talk] Seen flag treated incorrectly on IMAP mail
 In-Reply-To: <47299802.50007@quintic.co.uk>
 References: <2d4a3f900012fe89@IMSS-WIN> <47299802.50007@quintic.co.uk>
 Message-ID: <1193954846-sup-9117@lankhmar>
 
 Excerpts from Marcus Williams's message of Thu Nov 01 20:10:26 +1100 2007:
 >
 > Yep, I submitted a patch earlier last month (search for imap patch) to
 > fix this although what it did was use the /Recent flag to check for
 > unread messages. This works as long as you dont use the IMAP source in
 > any other client before sup checks for new messages.
 
 Got it. Thanks for the patch.
 
 From itaylor@uark.edu  Thu Nov  1 20:14:55 2007
 From: itaylor@uark.edu (Ian Taylor)
 Date: Thu, 01 Nov 2007 20:14:55 -0400
 Subject: [sup-talk] [PATCH] Fix for imap based sources
 In-Reply-To: <47206F23.6080400@quintic.co.uk>
 References: <47206F23.6080400@quintic.co.uk>
 Message-ID: <1193962132-sup-5058@silver>
 
 Excerpts from Marcus Williams's message of Thu Oct 25 06:25:39 -0400 2007:
 > Hi -
 > 
 > Apply this one at your peril. This patch makes the unread status
 > correct on sources that arent mbox - unfortunately I cant test on
 > Maildir so if someone wants to confirm it still works that would be
 > good :)
 > 
 > If you implement a new source, it means you now have to add a
 > marked_read? method to your source as well. Argument is a message id.
 > message.rb now calls this when source_marked_read is called.
 > 
 > It also fixes what I think is a bug in the imap sup source - the imap
 > "/Seen" flag means a message has been read from the way I interpret the
 > RFC, the "/Recent" flag is what you need to check for "unreadness".
 > 
 > This fixes my problem with imap (in that all new messages were getting
 > marked as read). To get just this fix all you have to do is replace Seen
 > for Recent in the imap.rb. The line currently looks like:
 > 
 > labels = { :Seen => :unread,
 > 
 > and it should be
 > 
 > labels = { :Recent => :unread,
 > 
 > 
 > 
 > Marcus
 
 That doesn't seem quite right to me. The RFC seems to state that the
 'Recent' flag is more of a notification that this is the first session
 to see the message.
 
 What about this instead?
 
       labels = { :Flagged => :starred,                                                                                                                                                                              
                  :Deleted => :deleted                                                                                                                                                                               
                }.inject(@labels) do |cur, (imap, sup)|                                                                                                                                                              
         cur + (state[:flags].include?(imap) ? [sup] : [])                                                                                                                                                           
       end
       labels += [:unread] unless state[:flags].include?(:Seen)
 
 Seems like we want to tag it as unread if it isn't marked as 'Seen'.
 
 -- 
 Ian Taylor
 
 From col@baibell.org  Thu Nov  1 21:19:10 2007
 From: col@baibell.org (Colin Bell)
 Date: Fri, 02 Nov 2007 12:19:10 +1100
 Subject: [sup-talk] [PATCH] Fix for imap based sources
 In-Reply-To: <1193962132-sup-5058@silver>
 References: <47206F23.6080400@quintic.co.uk> <1193962132-sup-5058@silver>
 Message-ID: <1193966225-sup-1066@lankhmar>
 
 Excerpts from Ian Taylor's message of Fri Nov 02 11:14:55 +1100 2007:
 >
 > That doesn't seem quite right to me. The RFC seems to state that the
 > 'Recent' flag is more of a notification that this is the first session
 > to see the message.
 >
 > What about this instead?
 >
 >       labels = { :Flagged => :starred,
 >                  :Deleted => :deleted
 >                }.inject(@labels) do |cur, (imap, sup)|
 >         cur + (state[:flags].include?(imap) ? [sup] : [])
 >       end
 >       labels += [:unread] unless state[:flags].include?(:Seen)
 >
 > Seems like we want to tag it as unread if it isn't marked as 'Seen'.
 
 Works for me. Thanks
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 21:33:44 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 18:33:44 -0700
 Subject: [sup-talk] Want utf-8 ?
 In-Reply-To: <6205b42d0710090621k580b1f0g2ac2633530668553@mail.gmail.com>
 References: <6205b42d0710090621k580b1f0g2ac2633530668553@mail.gmail.com>
 Message-ID: <1193967168-sup-7761@south>
 
 Pierre,
 
 Excerpts from Pierre Baillet's message of Tue Oct 09 06:21:17 -0700 2007:
 > I quickly hacked utf-8 support in sup. My first modification aimed at
 > allowing Unicode alias in the contact manager.
 
 Thanks for doing this! I can't wait to try it out.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 22:18:19 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 19:18:19 -0700
 Subject: [sup-talk] patch with keymaps for editing message headers
 In-Reply-To: <1192119420-sup-7831@timmy>
 References: <1192119420-sup-7831@timmy>
 Message-ID: <1193969885-sup-7804@south>
 
 Excerpts from Eyal Oren's message of Thu Oct 11 09:19:17 -0700 2007:
 > Attached another small patch, adding keymaps to edit 'To:', 'Cc:', and
 > 'Subject:' field of messages. Again something small that I missed,
 > coming from Mutt. 
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 22:24:46 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 19:24:46 -0700
 Subject: [sup-talk] [PATCH] Toggle show only laebls with unread email
 In-Reply-To: <1192246072-sup-7445@lankhmar>
 References: <1192246072-sup-7445@lankhmar>
 Message-ID: <1193970277-sup-6391@south>
 
 Excerpts from Colin Bell's message of Fri Oct 12 20:29:50 -0700 2007:
 > This patch allows you to toggle between showing all labels and only
 > those with unread mail in label list mode by pressing the TAB key.
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 22:32:19 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 19:32:19 -0700
 Subject: [sup-talk] Ferret Errors
 In-Reply-To: <1193693839-sup-8512@chris-tablet>
 References: <1193693839-sup-8512@chris-tablet>
 Message-ID: <1193970558-sup-3687@south>
 
 Excerpts from Christopher Warrington's message of Mon Oct 29 14:40:37 -0700 2007:
 > I'm getting odd ferret errors, usually when I am composing messages in
 > nano.
 > 
 > I suspect that it has something to do with the fact that I am running
 > sup under cygwin on Windows...
 > 
 > Here's the exception:
 > --- IOError at Mon Oct 29 16:27:51 -0500 2007
 > IO Error occured at <except.c>:117 in xpop_context
 > Error occured in fs_store.c:70 - fs_exists
 >     checking existance of /home/chrisw/.sup/ferret/_g9c.cfs: <Permission denied>
 
 Yeah, the typical completely incomprehensible Ferret error message.
 Current known things that make Ferret generate scary messages:
 - running more than one process touching the index at the same time (Sup
   locks the index now so this shouldn't happen unless you are being
   particularly devious)
 - having too many open filehandles, including too many "usual" mbox
   sources at the moment until I fix the mbox code not to keep
   filehandles open all the time.
 - running out of disk space.
 
 Could it have been any of those?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 22:35:15 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 19:35:15 -0700
 Subject: [sup-talk] tiny fix for sup-faked message id's crashing sup-sync
 In-Reply-To: <fba9be1d0710291855x15e90fbbp6138a31dd48f0cc1@mail.gmail.com>
 References: <fba9be1d0710291855x15e90fbbp6138a31dd48f0cc1@mail.gmail.com>
 Message-ID: <1193970811-sup-9784@south>
 
 Excerpts from Brendan O'Connor's message of Mon Oct 29 18:55:59 -0700 2007:
 > After a tiny bugfix off SVN 650, I'm importing gmail imap!  Very
 > exciting!
 
 Great news.
 
 > I hate it when I add a puts or logging statement and it messes up
 > ruby's returning conventions, returning nil that clobbers something
 > elsewhere. Glad to see it happens to other people too :)
 
 Ruby is flawless. I am to blame. Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 22:36:02 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 19:36:02 -0700
 Subject: [sup-talk] [PATCH] svn sup "can't convert nil into String"
 	(index.rb)
 In-Reply-To: <1193739855.10424.7.camel@onnadayr.ca>
 References: <1193739855.10424.7.camel@onnadayr.ca>
 Message-ID: <1193970918-sup-4226@south>
 
 Excerpts from rick.tessner's message of Tue Oct 30 03:24:15 -0700 2007:
 > I'm using svn sup and just recently started getting the following
 > error when getting new email without a proper message_id (patch is
 > attached):
 
 Gadzooks, two simultaneous patches from two different users for the same
 problem! Truly a milestone in Sup's development. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 23:02:44 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 20:02:44 -0700
 Subject: [sup-talk] Google and IMAP
 In-Reply-To: <1193677196-sup-2982@londonbackup>
 References: <414a99f20710240051m4656b3b6sbd0057ba95dc68a6@mail.gmail.com>
 	<20071024084757.GO5471@horacrux> <1193677196-sup-2982@londonbackup>
 Message-ID: <1193971010-sup-3497@south>
 
 Excerpts from Tim Vaughan's message of Mon Oct 29 10:17:57 -0700 2007:
 > * Gmail seems to store messages sent with its SMTP server so when a
 > brand-new email is sent it appears in the inbox.  This is a bit
 > annoying but I don't think that you can make sup store its sent emails
 > in an IMAP folder.
 
 This is correct. I don't ever plan to write IMAP saving code, but I
 would accept a patch to this effect.
 
 > * Sometimes I load a largeish thread and find that a thread has a red
 > line with "message not downloaded" in it.
 
 If you mean a "message not received" line in Sup, that signifies that
 some message had a References: header that mentioned some message id
 that never occurred. So it could be symptomatic of someone replying to
 an off-list message, or it could be a corrupted References: header, or
 it could be a message that you just didn't receive for whatever reason.
 (Or that isn't stored in Gmail.)
 
 > * Feature request: saved searches!
 
 Acknowledged. On the todo.
 
 > * Is there a way to make sup reply from the address an email was sent
 > to (like Gmail does when it handles more than one account)?
 
 If you add an account to config.yaml with that email address, it should
 start replying from it as well. Unfortunately this is still a manual
 process at this point.
 
 > * Sup is great but having to rebuild the index every time I use
 > Gmail's web interface to send an email hurts :(.  Although I realise
 > that's just the Way Things Are.
 
 Sadly, yes...
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov  1 23:54:43 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 20:54:43 -0700
 Subject: [sup-talk] [PATCH] Configurable automatic CC and BCC
 In-Reply-To: <6205b42d0710310142r4c1a699co6776e3180a21e46c@mail.gmail.com>
 References: <6205b42d0710140517n1b006956tef57f60b101568e2@mail.gmail.com>
 	<6205b42d0710310142r4c1a699co6776e3180a21e46c@mail.gmail.com>
 Message-ID: <1193975643-sup-9164@south>
 
 Hi Pierre,
 
 Sorry for taking so long to review this. Other patch submitters, don't
 worry---I'm going through them one by one and nothing will be ignored!
 
 Excerpts from Pierre Baillet's message of Wed Oct 31 01:42:58 -0700 2007:
 > maybe you came accross my patch, but I don't know what you think about
 > integrating it to the trunk or not. Maybe it's not near enough in your
 > TODO, too :)
 
 I like this functionality. But, instead of another set of configuration
 options, I would rather see a before-edit hook, which would allow for
 auto-filling cc/bcc programmatically and for all sorts of other fun
 stuff. Would you be interested in submitting a patch for that instead?
 
 Marcus just submitted a before-add hook which you can probably use as a
 reference.
 
 What do you think?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  2 00:02:38 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 21:02:38 -0700
 Subject: [sup-talk] new user of sup
 In-Reply-To: <20071031180510.GA7449@lenin.sovietwar.org>
 References: <4728B67A.7020604@gslab.com>
 	<20071031180510.GA7449@lenin.sovietwar.org>
 Message-ID: <1193976129-sup-2591@south>
 
 Excerpts from vasudeva's message of Wed Oct 31 11:05:10 -0700 2007:
 > I had an issue like this, and found it to be related somehow to the
 > following lines being present in my ~/.sup/sources.yaml...
 > 
 > - !masanjin.net,2006-10-01/Redwood/SentLoader
 >   cur_offset: 29245
 > - !masanjin.net,2006-10-01/Redwood/DraftLoader
 >   cur_offset: 4
 > 
 > It seems if I snipped those out, then sup-add would actually add all
 > the sources I told it, not simply the final one.
 
 Interesting. I'm going to look into this.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  2 00:10:20 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 21:10:20 -0700
 Subject: [sup-talk] PATCH - Refine Search
 In-Reply-To: <1192430824-sup-1710@chris-tablet>
 References: <1192430824-sup-1710@chris-tablet>
 Message-ID: <1193976606-sup-197@south>
 
 Excerpts from Christopher Warrington's message of Sun Oct 14 23:49:55
 -0700 2007:
 > The attached patch (my first one: I may have screwed it up) adds the
 > ability to refine a search from the results view. Pressing '.' will
 > prompt for a new query, using the old one as the seed.
 
 Applied (in slightly modified form). Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  2 00:12:25 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 01 Nov 2007 21:12:25 -0700
 Subject: [sup-talk] one more exception,
 In-Reply-To: <4729CB36.3050408@gslab.com>
 References: <4729CB36.3050408@gslab.com>
 Message-ID: <1193976706-sup-5069@south>
 
 Excerpts from Manish Sapariya's message of Thu Nov 01 05:48:54 -0700 2007:
 > The problem was: 'can't convert nil into String' (error type TypeError)
 
 This is fixed in SVN.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@quintic.co.uk  Fri Nov  2 06:01:16 2007
 From: marcus-sup@quintic.co.uk (Marcus Williams)
 Date: Fri, 02 Nov 2007 10:01:16 +0000
 Subject: [sup-talk] tiny fix for sup-faked message id's crashing sup-sync
 In-Reply-To: <321bb12900151bd3@IMSS-WIN>
 References: <fba9be1d0710291855x15e90fbbp6138a31dd48f0cc1@mail.gmail.com>
 	<321bb12900151bd3@IMSS-WIN>
 Message-ID: <472AF56C.5070807@quintic.co.uk>
 
 On 02/11/2007 William Morgan wrote:
 > > I hate it when I add a puts or logging statement and it messes up
 > > > ruby's returning conventions, returning nil that clobbers something
 > > > elsewhere. Glad to see it happens to other people too :)
 > 
 > Ruby is flawless. I am to blame. Applied, thanks!
 
 ... you may want to remove the @id from the log message - wont this 
 always be nil at this point (as it gets assigned by this block)?
 
 Marcus
 
 From pierre@baillet.name  Fri Nov  2 07:21:30 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Fri, 2 Nov 2007 12:21:30 +0100
 Subject: [sup-talk] [PATCH] Configurable automatic CC and BCC
 In-Reply-To: <1193975643-sup-9164@south>
 References: <6205b42d0710140517n1b006956tef57f60b101568e2@mail.gmail.com>
 	<6205b42d0710310142r4c1a699co6776e3180a21e46c@mail.gmail.com>
 	<1193975643-sup-9164@south>
 Message-ID: <6205b42d0711020421y6198e446s77bdab118666e20c@mail.gmail.com>
 
 Hi William and all :)
 
 I'll have a look into Marcus patch and see if I can use it to make the same
 functionality. Thanks for the idea !
 
 -- 
 Pierre.
 
 On 11/2/07, William Morgan <wmorgan-sup at masanjin.net> wrote:
 >
 > Hi Pierre,
 >
 > Sorry for taking so long to review this. Other patch submitters, don't
 > worry---I'm going through them one by one and nothing will be ignored!
 >
 > Excerpts from Pierre Baillet's message of Wed Oct 31 01:42:58 -0700 2007:
 > > maybe you came accross my patch, but I don't know what you think about
 > > integrating it to the trunk or not. Maybe it's not near enough in your
 > > TODO, too :)
 >
 > I like this functionality. But, instead of another set of configuration
 > options, I would rather see a before-edit hook, which would allow for
 > auto-filling cc/bcc programmatically and for all sorts of other fun
 > stuff. Would you be interested in submitting a patch for that instead?
 >
 > Marcus just submitted a before-add hook which you can probably use as a
 > reference.
 >
 > What do you think?
 >
 > --
 > William <wmorgan-sup at masanjin.net>
 > _______________________________________________
 > sup-talk mailing list
 > sup-talk at rubyforge.org
 > http://rubyforge.org/mailman/listinfo/sup-talk
 >
 
 
 
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071102/1b88c3c7/attachment.html 
 
 From marcus-sup@quintic.co.uk  Fri Nov  2 08:18:19 2007
 From: marcus-sup@quintic.co.uk (Marcus Williams)
 Date: Fri, 02 Nov 2007 12:18:19 +0000
 Subject: [sup-talk] [PATCH] More IMAP/Maildir functionality
 Message-ID: <1194005479-sup-2005@tomsk>
 
 Hi -
 
 This patch cleans up my last IMAP patch, and adds the
 each_raw_message_line method to both Maildir and IMAP so that you dont
 get an exception when you try to save a message to a file with an IMAP
 or maildir source. I cant test the Maildir version works easily, so if
 someone else could that would be good. If I get time I'll get around
 to testing the Maildir stuff, just not now as I dont use it :)
 
 This fixes the unread status problem to use the lack of /Seen properly
 and adds the marked_read? methods to all sources.
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: source-diffs
 Type: application/octet-stream
 Size: 4527 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071102/a3d8a87c/attachment-0001.obj 
 
 From marcus-sup@quintic.co.uk  Fri Nov  2 08:55:15 2007
 From: marcus-sup@quintic.co.uk (Marcus Williams)
 Date: Fri, 02 Nov 2007 12:55:15 +0000
 Subject: [sup-talk] patch with keymaps for editing message headers
 In-Reply-To: <320c39cf00151583@IMSS-WIN>
 References: <1192119420-sup-7831@timmy> <320c39cf00151583@IMSS-WIN>
 Message-ID: <472B1E33.7000207@quintic.co.uk>
 
 On 02/11/2007 William Morgan wrote:
 > Excerpts from Eyal Oren's message of Thu Oct 11 09:19:17 -0700 2007:
 > > > Attached another small patch, adding keymaps to edit 'To:', 'Cc:', and
 > > > 'Subject:' field of messages. Again something small that I missed,
 > > > coming from Mutt. 
 > 
 > Applied, thanks!
 
 This adds a method in edit-message-mode called "edit_field" with 1 
 argument. reply-mode has an edit_field method that overrides this if you 
 are replying so you get an exception as it gets called instead when you 
 try to edit the field in reply mode.
 
 It doesnt look like the reply mode edit_field method gets used anywhere 
 so this might need to be removed or the edit-message-mode method needs 
 renaming perhaps.
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Fri Nov  2 11:17:58 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 02 Nov 2007 08:17:58 -0700
 Subject: [sup-talk] tiny fix for sup-faked message id's crashing sup-sync
 In-Reply-To: <472AF56C.5070807@quintic.co.uk>
 References: <fba9be1d0710291855x15e90fbbp6138a31dd48f0cc1@mail.gmail.com>
 	<321bb12900151bd3@IMSS-WIN> <472AF56C.5070807@quintic.co.uk>
 Message-ID: <1194016481-sup-2712@south>
 
 Excerpts from Marcus Williams's message of Fri Nov 02 03:01:16 -0700 2007:
 > ... you may want to remove the @id from the log message - wont this 
 > always be nil at this point (as it gets assigned by this block)?
 
 Good point. A chance to use my k combinator! Check this out:
 
   --- lib/sup/message.rb  (revision 658)
   +++ lib/sup/message.rb  (working copy)
   @@ -62,8 +62,9 @@
          if header["message-id"]
            sanitize_message_id header["message-id"]
          else
   -        Redwood::log "faking message-id for message from #@from: #@id"
   -        "sup-faked-" + Digest::MD5.hexdigest(raw_header)
   +        returning("sup-faked-" + Digest::MD5.hexdigest(raw_header)) do |id|
   +          Redwood::log "faking message-id for message from #@from: #{id}"
   +        end
          end
        
        date = header["date"]
 
 God I love this language.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  2 11:23:48 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 02 Nov 2007 08:23:48 -0700
 Subject: [sup-talk] patch with keymaps for editing message headers
 In-Reply-To: <472B1E33.7000207@quintic.co.uk>
 References: <1192119420-sup-7831@timmy> <320c39cf00151583@IMSS-WIN>
 	<472B1E33.7000207@quintic.co.uk>
 Message-ID: <1194016851-sup-1240@south>
 
 Excerpts from Marcus Williams's message of Fri Nov 02 05:55:15 -0700 2007:
 > This adds a method in edit-message-mode called "edit_field" with 1
 > argument. reply-mode has an edit_field method that overrides this if
 > you are replying so you get an exception as it gets called instead
 > when you try to edit the field in reply mode.
 
 Good catch. I renamed the original EditMessageMode#edit_field method
 (which ReplyMode overrode) to edit_field_or_message, and forgot to check
 subclasses.
 
 Who needs unit tests when you have enough users pulling the SVN head?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  2 15:07:37 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 02 Nov 2007 12:07:37 -0700
 Subject: [sup-talk] [PATCH] Added --search option to sup
 In-Reply-To: <47149A98.1040800@quintic.co.uk>
 References: <47149A98.1040800@quintic.co.uk>
 Message-ID: <1194030370-sup-1200@south>
 
 Excerpts from Marcus Williams's message of Tue Oct 16 04:03:52 -0700 2007:
 > Attached is a simple patch to sup to add a command line option to jump
 > straight into a search from the command line.
 
 Interesting idea! What's your usage case: that you do the search, maybe
 read some resulting messages, and then quit Sup? Or do you continue to
 use Sup as normal? I.e. should we bother to even load the inbox?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From manish@gslab.com  Sat Nov  3 06:39:21 2007
 From: manish@gslab.com (Manish Sapariya)
 Date: Sat, 03 Nov 2007 16:09:21 +0530
 Subject: [sup-talk] Can I redirect logs to file,
 	instead of using s command in sup console
 Message-ID: <472C4FD9.5060707@gslab.com>
 
 I want to see at the log files when sup crashes. I could not find
 any command line option and brief grepping in the sources did not
 gave any clue.
 
 Thanks and Regards,
 Manish
 
 
 From marcus-sup@bar-coded.net  Sat Nov  3 16:20:48 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Sat, 03 Nov 2007 20:20:48 +0000
 Subject: [sup-talk] [PATCH] Added --search option to sup
 In-Reply-To: <<35a8c9eb0016c658@IMSS-WIN>>
 References: <47149A98.1040800@quintic.co.uk> <<35a8c9eb0016c658@IMSS-WIN>>
 Message-ID: <1194120151-sup-6999@tomsk>
 
 [resubscribing under a different address, not sure if this will thread
 properly]
 
 On 2.11.2007, William Morgan wrote:
 > Interesting idea! What's your usage case: that you do the search, maybe
 > read some resulting messages, and then quit Sup? Or do you continue to
 > use Sup as normal? I.e. should we bother to even load the inbox?
 
 I use my email for all sorts, but one thing I do often is use it as a
 todo list. So I have a set of current todos (labeled todo). Its good
 to be able to bring up sup, with the todos only. Sometimes I'll stay
 in sup, sometimes not. 
 
 Anyone who is into gtd could use this for contexts, my "todo" label
 is like a context. I can enter sup and deal with this and not get 
 distracted by other stuff.
 
 It also means I can alias "todo" in my shell to "sup --search
 'label:todo'" or something.
 
 In some cases I dont need the inbox at all like you say. I tried to 
 add a --no-inbox flag to sup, but I couldnt get it to work. I think
 the buffer sizes screwed up somehow when I stopped the inbox mode from
 spawning. I must have missed something.
 
 I spotted that the inbox is actually a search result whilst trawling
 the code so my idea is now that instead of a --no-inbox what you
 actually do is have another search argument --inbox that takes a
 search term This would set the search term for the inbox mode. That
 way you could go into sup and have your inbox mode permanently in
 whatever search term you entered.
 
 This would mean you could go in via --search and keep your inbox as
 normal. Or via --inbox and have a specialised inbox. 
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Sat Nov  3 17:17:27 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 03 Nov 2007 14:17:27 -0700
 Subject: [sup-talk] [PATCH] Added --search option to sup
 In-Reply-To: <1194120151-sup-6999@tomsk>
 References: <47149A98.1040800@quintic.co.uk> <<35a8c9eb0016c658@IMSS-WIN>
 	<1194120151-sup-6999@tomsk>
 Message-ID: <1194124287-sup-468@south>
 
 Excerpts from Marcus Williams's message of Sat Nov 03 13:20:48 -0700 2007:
 > I use my email for all sorts, but one thing I do often is use it as a
 > todo list. So I have a set of current todos (labeled todo). Its good
 > to be able to bring up sup, with the todos only. Sometimes I'll stay
 > in sup, sometimes not. 
 
 Very nice. One of the items on the TODO for quite a while has been to
 add "notes" as a first-class object, which will be treated more or less
 as draft emails are now, except they'll have no from/to/cc/etc, only a
 body, and obviously can't be sent, just created, edited, and deleted.
 
 These can be used as general notes, as todo items, and can be "attached"
 to emails or other notes via the threading system. And of course the
 full-text search and labeling can be used as normal.
 
 Then all I have to do is add a web browser mode and a partial
 implementation of lisp and sup will be feature complete!
 
 > I spotted that the inbox is actually a search result whilst trawling
 > the code so my idea is now that instead of a --no-inbox what you
 > actually do is have another search argument --inbox that takes a
 > search term This would set the search term for the inbox mode. That
 > way you could go into sup and have your inbox mode permanently in
 > whatever search term you entered.
 
 The problem is that inbox-mode per se has some special functionality
 that doesn't quite make sense unless it's applied to the search with
 "label:inbox". We could force that to be prepended to any search phrase
 passed in from the command line, I suppose.
 
 For the time being, I'll apply the patch as is.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Sat Nov  3 17:35:55 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Sat, 03 Nov 2007 21:35:55 +0000
 Subject: [sup-talk] [PATCH] Added --search option to sup
 In-Reply-To: <1194124287-sup-468@south>
 References: <47149A98.1040800@quintic.co.uk> <<35a8c9eb0016c658@IMSS-WIN>
 	<1194120151-sup-6999@tomsk> <1194124287-sup-468@south>
 Message-ID: <1194125144-sup-1843@tomsk>
 
 On 3.11.2007, William Morgan wrote:
 > Very nice. One of the items on the TODO for quite a while has been to
 > add "notes" as a first-class object, which will be treated more or less
 > as draft emails are now, except they'll have no from/to/cc/etc, only a
 > body, and obviously can't be sent, just created, edited, and deleted.
 
 Yeah, I noticed that on the todo list. That would be very nice -
 something that has always bothered me about email is that I cant just
 add notes to them (in most clients). And not having to actually send
 myself a message to "add" a note would be less work! 
 
 > Then all I have to do is add a web browser mode and a partial
 > implementation of lisp and sup will be feature complete!
 
 I've been trying to figure out if a web browser mode would be possible
 in the current mode system. I couldnt figure out if the mode stuff was
 reliant on ncurses or just happened to be modes that used ncurses.
 
 > The problem is that inbox-mode per se has some special functionality
 > that doesn't quite make sense unless it's applied to the search with
 > "label:inbox". We could force that to be prepended to any search phrase
 > passed in from the command line, I suppose.
 
 To be honest I probably wouldnt use the --inbox flag that often, it
 just struck me as nicer way to implement no having an inbox. I use the
 search flag quite a lot though so good to see it got in :)
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Sat Nov  3 18:12:07 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 03 Nov 2007 15:12:07 -0700
 Subject: [sup-talk] [PATCH] Added --search option to sup
 In-Reply-To: <1194125144-sup-1843@tomsk>
 References: <47149A98.1040800@quintic.co.uk> <<35a8c9eb0016c658@IMSS-WIN>
 	<1194120151-sup-6999@tomsk> <1194124287-sup-468@south>
 	<1194125144-sup-1843@tomsk>
 Message-ID: <1194127019-sup-6911@south>
 
 Excerpts from Marcus Williams's message of Sat Nov 03 14:35:55 -0700 2007:
 > I've been trying to figure out if a web browser mode would be possible
 > in the current mode system. I couldnt figure out if the mode stuff was
 > reliant on ncurses or just happened to be modes that used ncurses.
 
 That was actually a sick joke about writing my own ncurses-based browser
 from within Sup. But to answer what I think was a serious question about
 a web version of sup itself, a couple people have expressed a desire to
 write this, which I think is a little ironic, but which I'm certainly
 not opposed to.
 
 The mode system (in contrast with the buffer system) is not *explicitly*
 tied to ncurses but probably has all sorts of implicit ties. I.e. it
 might be possible to come up with some explicit mapping of modes to web
 pages and commands to web form buttons, but my personal suspicion is
 that the paradigms are so radically different that that level of
 integration will be impossible.
 
 But certainly searching the index and pulling up threads, messages, etc
 all is done through nice programmatic interfaces, and I've started
 documenting this on the wiki, mostly from that email I sent you about
 sup-cli.
 
 > To be honest I probably wouldnt use the --inbox flag that often, it
 > just struck me as nicer way to implement no having an inbox. I use the
 > search flag quite a lot though so good to see it got in :)
 
 Just added --search to SVN. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov  3 18:23:23 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 03 Nov 2007 15:23:23 -0700
 Subject: [sup-talk] Changing sources with same URI
 In-Reply-To: <1193759439-sup-5378@tomsk>
 References: <1193759439-sup-5378@tomsk>
 Message-ID: <1194128155-sup-8975@south>
 
 Excerpts from Marcus Williams's message of Tue Oct 30 08:55:18 -0700 2007:
 > I've got two (actually more than two, but that doesnt matter) IMAP
 > sources with the same URI, with different logins. The only problem is
 > I forgot to add a label to one of them. What I want to do is add that
 > source back in with the label added.
 > 
 > I thought all I'd need to do was add the label to the sources.yaml and
 > then run sup-sync --changed <source>, or maybe --all but neither of
 > them pick the right source as the source I want is the second of the
 > two sources in the yaml file (and they both have the same uri).
 
 Heheh. I think you can differentiate the two by putting the username in
 as a component of the URI. It's ignored by Sup completely, except, it
 turns out for the purposes of comparing URIs.
 
 E.g.: imaps://account1 at imap.server.com and
 imaps://account2 at imap.server.com.
 
 (Just figured this out myself!)
 
 > probably want to make both of these sources "unusual" as well, can I
 > do that with sup-sync?
 
 Nope, all modifications of source properties must be done by editing
 source.yaml by hand atm.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov  3 18:25:36 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 03 Nov 2007 15:25:36 -0700
 Subject: [sup-talk] Can I redirect logs to file,
 	instead of using s command in sup console
 In-Reply-To: <472C4FD9.5060707@gslab.com>
 References: <472C4FD9.5060707@gslab.com>
 Message-ID: <1194128631-sup-6070@south>
 
 Excerpts from Manish Sapariya's message of Sat Nov 03 03:39:21 -0700 2007:
 > I want to see at the log files when sup crashes. I could not find any
 > command line option and brief grepping in the sources did not gave any
 > clue.
 
 There's no way to do this currently. Typically the log doesn't actually
 contain that much useful stuff for diagnosing a crash; the exception is
 more information (written out to sup-exeption-log.txt currently).
 
 Wouldn't be too hard to do this by modified Logger#log.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  4 21:40:58 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 04 Nov 2007 18:40:58 -0800
 Subject: [sup-talk] [PATCH] New hook (enabling message filters)
 In-Reply-To: <4718B60F.1090208@quintic.co.uk>
 References: <47188C6F.30008@quintic.co.uk> <4d4780f700181787@IMSS-WIN>
 	<4d6e9e1600182d59@IMSS-WIN> <4718B60F.1090208@quintic.co.uk>
 Message-ID: <1194230448-sup-727@south>
 
 Excerpts from Marcus Williams's message of Fri Oct 19 06:50:07 -0700 2007:
 > On 19/10/2007 Marcus Williams wrote:
 > > Ta - and heres an update that includes that and redirects say to log if
 > > running from sup-sync and ask_yes_or_no to gets.
 > 
 > ... this time I'll attach the right patch :(
 
 Applied. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  4 21:46:21 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 04 Nov 2007 18:46:21 -0800
 Subject: [sup-talk] [PATCH] Tag all threads
 In-Reply-To: <471F0988.4010909@quintic.co.uk>
 References: <471F0988.4010909@quintic.co.uk>
 Message-ID: <1194230718-sup-8877@south>
 
 Excerpts from Marcus Williams's message of Wed Oct 24 01:59:52 -0700 2007:
 > Attached is a patch to toggle the tag status on all threads in the
 > current view. Use the 'T' to toggle.
 
 Applied. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  4 22:15:51 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 04 Nov 2007 19:15:51 -0800
 Subject: [sup-talk] [PATCH] More IMAP/Maildir functionality
 In-Reply-To: <1194005479-sup-2005@tomsk>
 References: <1194005479-sup-2005@tomsk>
 Message-ID: <1194232297-sup-5089@south>
 
 Hi Marcus,
 
 Excerpts from Marcus Williams's message of Fri Nov 02 05:18:19 -0700 2007:
 > This patch cleans up my last IMAP patch, and adds the
 > each_raw_message_line method to both Maildir and IMAP so that you dont
 > get an exception when you try to save a message to a file with an IMAP
 > or maildir source.
 
 This all looks great, except for the source_marked_read stuff, which is
 only there as a nasty hack to avoid scanning mbox files twice (because
 you can't tell if an mbox message is read or not until you go through
 all the headers).
 
 For non-mbox read/unread, it should be sufficient to simply set the flags
 as you do in IMAP#raw_header.
 
 If you get a chance, can you resubmit without that? I may have a chance
 to clean it up in the next few days if not.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov  4 22:17:57 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 04 Nov 2007 19:17:57 -0800
 Subject: [sup-talk] [PATCH] Check IMAP capabilities before using auth
 	methods
 In-Reply-To: <1193936725-sup-5565@spooky.local>
 References: <1193907675-sup-9254@tomsk> <1193936725-sup-5565@spooky.local>
 Message-ID: <1194232657-sup-9019@south>
 
 Excerpts from Grant Hollingworth's message of Thu Nov 01 10:06:47 -0700 2007:
 > Are there any plans to have IMAP sources with a common server share a
 > connection?
 
 Sounds like a truly excellent idea. Added to the TODO!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Mon Nov  5 04:54:17 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 05 Nov 2007 09:54:17 +0000
 Subject: [sup-talk] [PATCH] More IMAP/Maildir functionality
 In-Reply-To: <1194232297-sup-5089@south>
 References: <1194005479-sup-2005@tomsk> <1194232297-sup-5089@south>
 Message-ID: <1194256027-sup-6540@tomsk>
 
 On 5.11.2007, William Morgan wrote:
 > For non-mbox read/unread, it should be sufficient to simply set the flags
 > as you do in IMAP#raw_header.
 > 
 > If you get a chance, can you resubmit without that? I may have a chance
 > to clean it up in the next few days if not.
 
 So do you want it removed completely or implemented differently?
 
 From col@baibell.org  Mon Nov  5 05:01:31 2007
 From: col@baibell.org (Colin Bell)
 Date: Mon, 05 Nov 2007 21:01:31 +1100
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 Message-ID: <1194256715-sup-4315@lankhmar>
 
 Hi,
 
 This patch shows the unread message count in the thread index as well
 as the total number of messages in the thread.
 
 E.G:
 
 
 2:17pm Marcus,Grant,William (1/ 3)  [sup-talk] [PATCH] Check IMAP
 2:15pm Marcus,William       (0/ 2)  [sup-talk] [PATCH] More IMAP/
 
 --
 Col
 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: unread.diff
 Type: application/octet-stream
 Size: 1745 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071105/167121b3/attachment.obj 
 
 From marcus-sup@bar-coded.net  Mon Nov  5 10:03:40 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 05 Nov 2007 15:03:40 +0000
 Subject: [sup-talk] [PATCH] New hook (enabling message filters)
 In-Reply-To: <1194230448-sup-727@south>
 References: <47188C6F.30008@quintic.co.uk> <4d4780f700181787@IMSS-WIN>
 	<4d6e9e1600182d59@IMSS-WIN> <4718B60F.1090208@quintic.co.uk>
 	<1194230448-sup-727@south>
 Message-ID: <1194274725-sup-5324@tomsk>
 
 On 5.11.2007, William Morgan wrote:
 > > > Ta - and heres an update that includes that and redirects say to log if
 > > > running from sup-sync and ask_yes_or_no to gets.
 
 > Applied. Thanks!
 
 What I really want to do is get the inbox mode to do handle the cases
 when the hook adds the spam/deleted/starred/archive labels. What I
 mean is, if the hook adds a spam label then I dont want it to appear
 in the inbox.
 
 Currently I have to hit "@" after a poll. This is useful for
 debugging, but I'm not sure its what people would expect.
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Mon Nov  5 10:38:45 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 05 Nov 2007 07:38:45 -0800
 Subject: [sup-talk] [PATCH] New hook (enabling message filters)
 In-Reply-To: <1194274725-sup-5324@tomsk>
 References: <47188C6F.30008@quintic.co.uk> <4d4780f700181787@IMSS-WIN>
 	<4d6e9e1600182d59@IMSS-WIN> <4718B60F.1090208@quintic.co.uk>
 	<1194230448-sup-727@south> <1194274725-sup-5324@tomsk>
 Message-ID: <1194277062-sup-3404@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 05 07:03:40 -0800 2007:
 > What I really want to do is get the inbox mode to do handle the cases
 > when the hook adds the spam/deleted/starred/archive labels. What I
 > mean is, if the hook adds a spam label then I dont want it to appear
 > in the inbox.
 
 Try modifying InboxMode#is_relevant? (called by
 ThreadIndexMode#handle_add_update).
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  5 10:44:12 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 05 Nov 2007 07:44:12 -0800
 Subject: [sup-talk] [PATCH] More IMAP/Maildir functionality
 In-Reply-To: <1194256027-sup-6540@tomsk>
 References: <1194005479-sup-2005@tomsk> <1194232297-sup-5089@south>
 	<1194256027-sup-6540@tomsk>
 Message-ID: <1194277185-sup-797@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 05 01:54:17 -0800 2007:
 > On 5.11.2007, William Morgan wrote:
 > > For non-mbox read/unread, it should be sufficient to simply set the flags
 > > as you do in IMAP#raw_header.
 > > 
 > > If you get a chance, can you resubmit without that? I may have a chance
 > > to clean it up in the next few days if not.
 > 
 > So do you want it removed completely or implemented differently?
 
 Removed completely from the patch, as the resulting functionality should
 be exactly the same. If an IMAP message doesn't have :unread, then it's
 treated as read. There's no reason to extend the horrible hackishness of
 source_marked_read anywhere beyond mbox.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From itaylor@uark.edu  Mon Nov  5 13:26:24 2007
 From: itaylor@uark.edu (Ian Taylor)
 Date: Mon, 05 Nov 2007 13:26:24 -0500
 Subject: [sup-talk] searching current buffer
 Message-ID: <1194286869-sup-3211@silver>
 
 I find myself wanting to search emails and the current buffer all the
 time. Is there a way to do this? I was looking at adding a search for
 the filebrowser view, but then decided that it should probably be for
 every buffer, not just that one. If this needs to be implemented, where
 would be the likely place for it?
 
 I keep hitting '/' when wanting search the current buffer, which is
 currently for searching all messages. Is this left over from mutt? If
 not, it seems to kind of clash with behavior of many other unix
 programs. Anyone else feel this should change?
 
 -- 
 Ian Taylor
 
 From wmorgan-sup@masanjin.net  Mon Nov  5 13:37:17 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 05 Nov 2007 10:37:17 -0800
 Subject: [sup-talk] searching current buffer
 In-Reply-To: <1194286869-sup-3211@silver>
 References: <1194286869-sup-3211@silver>
 Message-ID: <1194287462-sup-9734@south>
 
 Excerpts from Ian Taylor's message of Mon Nov 05 10:26:24 -0800 2007:
 > I find myself wanting to search emails and the current buffer all the
 > time. Is there a way to do this?
 
 Definitely on the near-term TODO. There was a patch to do this in a
 limited way a few weeks back from Eyal Oren. I'm not sure if he's
 planning on further work or not. Doing it "right" is a little
 complicated.
 
 > If this needs to be implemented, where would be the likely place for
 > it?
 
 Mostly in scroll-mode, with a little bit in line-cursor-mode to
 move the cursor around, and maybe some in thread-view-mode to expand
 messages before searching. To do highlighting, scroll-mode as well.
 
 > I keep hitting '/' when wanting search the current buffer, which is
 > currently for searching all messages. Is this left over from mutt? If
 > not, it seems to kind of clash with behavior of many other unix
 > programs. Anyone else feel this should change?
 
 I'd be amenable to change. What should the global search command be
 then?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From itaylor@uark.edu  Mon Nov  5 14:27:23 2007
 From: itaylor@uark.edu (Ian Taylor)
 Date: Mon, 05 Nov 2007 14:27:23 -0500
 Subject: [sup-talk] Exception from initial sup-sync
 Message-ID: <1194290667-sup-5900@silver>
 
 It said no method normalize_whitespace for nil, not sure why that didn't
 make it to sup-exception-log.txt
 
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/message.rb:358:in `message_to_chunks'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/message.rb:326:in `message_to_chunks'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/message.rb:326:in `map'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/message.rb:326:in `message_to_chunks'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/message.rb:158:in `load_from_source!'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/message.rb:211:in `content'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/index.rb:173:in `sync_message'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in `send'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in `method_missing'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:158:in `add_messages_from'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/imap.rb:175:in `each'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/imap.rb:163:in `upto'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/imap.rb:163:in `each'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in `send'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in `__pass'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/util.rb:420:in `method_missing'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:139:in `add_messages_from'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in `send'
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in `method_missing'
 /var/lib/gems/1.8/gems/sup-0.2/bin/sup-sync:133
 /var/lib/gems/1.8/gems/sup-0.2/bin/sup-sync:128:in `each'
 /var/lib/gems/1.8/gems/sup-0.2/bin/sup-sync:128
 /var/lib/gems/1.8/bin/sup-sync:16:in `load'
 /var/lib/gems/1.8/bin/sup-sync:16
 
 -- 
 Ian Taylor
 
 From eyal.oren@deri.org  Mon Nov  5 15:37:07 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Mon, 05 Nov 2007 21:37:07 +0100
 Subject: [sup-talk] searching current buffer
 In-Reply-To: <1194287462-sup-9734@south>
 References: <1194286869-sup-3211@silver> <1194287462-sup-9734@south>
 Message-ID: <1194294948-sup-4269@timmy>
 
 Excerpts from William Morgan's message of Mon Nov 05 19:37:17 +0100 2007:
 > Excerpts from Ian Taylor's message of Mon Nov 05 10:26:24 -0800 2007:
 > > I find myself wanting to search emails and the current buffer all the
 > > time. Is there a way to do this?
 > 
 > Definitely on the near-term TODO. There was a patch to do this in a
 > limited way a few weeks back from Eyal Oren. I'm not sure if he's
 > planning on further work or not. Doing it "right" is a little
 > complicated.
 I went back to mutt for a couple of weeks, but couldn't resist. So I'm back at 
 sup again now, and I might continue my very simple first attempts in the near 
 future with the tips you gave me.
 
  -eyal
 
 From wmorgan-sup@masanjin.net  Mon Nov  5 19:24:32 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 05 Nov 2007 16:24:32 -0800
 Subject: [sup-talk] searching current buffer
 In-Reply-To: <1194294948-sup-4269@timmy>
 References: <1194286869-sup-3211@silver> <1194287462-sup-9734@south>
 	<1194294948-sup-4269@timmy>
 Message-ID: <1194308588-sup-4298@south>
 
 Excerpts from Eyal Oren's message of Mon Nov 05 12:37:07 -0800 2007:
 > I went back to mutt for a couple of weeks, but couldn't resist. So I'm
 > back at sup again now, and I might continue my very simple first
 > attempts in the near future with the tips you gave me.
 
 Actually I got so excited by your patch that I started working on it. I
 might be able to check something in today or tomorrow! Just a few
 remaining tweaks. Stay tuned...
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov  5 19:42:11 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 05 Nov 2007 16:42:11 -0800
 Subject: [sup-talk] Exception from initial sup-sync
 In-Reply-To: <1194290667-sup-5900@silver>
 References: <1194290667-sup-5900@silver>
 Message-ID: <1194309716-sup-1684@south>
 
 Excerpts from Ian Taylor's message of Mon Nov 05 11:27:23 -0800 2007:
 > It said no method normalize_whitespace for nil, not sure why that didn't
 > make it to sup-exception-log.txt
 
 Yay, another RubyMail weirdness to work around!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From alexander.panek@brainsware.org  Tue Nov  6 03:57:36 2007
 From: alexander.panek@brainsware.org (Alexander Panek)
 Date: Tue, 6 Nov 2007 09:57:36 +0100
 Subject: [sup-talk] Crash on retrieving (many) mails
 Message-ID: <20071106095736.baa060ad.alexander.panek@brainsware.org>
 
 This happened when I retrieved like mails from a few accounts from the last four days (a few hundred mails, so to speak).
 
 Trace:
 > The problem was: 'undefined method `longname' for nil:NilClass' (error type NoMethodError)
 > A backtrace follows:
 > /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/poll.rb:96:in `do_poll': undefined method `longname' for nil:NilClass (NoMethodError)
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/poll.rb:150:in `add_messages_from'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/imap.rb:174:in `each'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/imap.rb:163:in `upto'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/imap.rb:163:in `each'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/util.rb:431:in `send'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/util.rb:431:in `__pass'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/util.rb:420:in `method_missing'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/poll.rb:133:in `add_messages_from'
 >          ... 26 levels...
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/modes/thread-index-mode.rb:422:in `load_threads'
 >         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/bin/sup:188
 >         from /usr/bin/sup:16:in `load'
 >         from /usr/bin/sup:16
 
 Apart from that, sup (or sup-sync, don't know) seems to be quite slow when syncing a few accounts with lots of mails. Is that caused by the mail servers or by sup itself?
 -- 
 Alexander Panek <alexander.panek at brainsware.org>
 
 From manish@gslab.com  Tue Nov  6 04:37:27 2007
 From: manish@gslab.com (Manish Sapariya)
 Date: Tue, 06 Nov 2007 15:07:27 +0530
 Subject: [sup-talk] Crash on retrieving (many) mails
 In-Reply-To: <20071106095736.baa060ad.alexander.panek@brainsware.org>
 References: <20071106095736.baa060ad.alexander.panek@brainsware.org>
 Message-ID: <473035D7.4020803@gslab.com>
 
 I ran into same kind of problem but I could never zero on what was the 
 cause.
 I was actually playing around to get more than one sources working and 
 trying
 to sync the new source.
 
 However after running sup-sync externally I did work started working. 
 See if that
 helps you. I was using Thunderbird mbox as my sources.
 
 Regards,
 Manish
 
 Alexander Panek wrote:
 > This happened when I retrieved like mails from a few accounts from the last four days (a few hundred mails, so to speak).
 >
 > Trace:
 >   
 >> The problem was: 'undefined method `longname' for nil:NilClass' (error type NoMethodError)
 >> A backtrace follows:
 >> /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/poll.rb:96:in `do_poll': undefined method `longname' for nil:NilClass (NoMethodError)
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/poll.rb:150:in `add_messages_from'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/imap.rb:174:in `each'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/imap.rb:163:in `upto'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/imap.rb:163:in `each'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/util.rb:431:in `send'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/util.rb:431:in `__pass'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/util.rb:420:in `method_missing'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/poll.rb:133:in `add_messages_from'
 >>          ... 26 levels...
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/lib/sup/modes/thread-index-mode.rb:422:in `load_threads'
 >>         from /usr/lib/ruby/gems/1.8/gems/sup-0.1/bin/sup:188
 >>         from /usr/bin/sup:16:in `load'
 >>         from /usr/bin/sup:16
 >>     
 >
 > Apart from that, sup (or sup-sync, don't know) seems to be quite slow when syncing a few accounts with lots of mails. Is that caused by the mail servers or by sup itself?
 >   
 
 
 From marcus-sup@bar-coded.net  Tue Nov  6 05:00:00 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 06 Nov 2007 10:00:00 +0000
 Subject: [sup-talk] [PATCH] Delete attachments bug fix
 Message-ID: <1194342872-sup-365@tomsk>
 
 Hi -
 
 First of a few patches. This fixes the bug where you hit the 'd' key
 to delete an attachment in edit/reply mode when there isnt an
 attachment (or isnt one under the cursor possibly as well)
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: delete-attachments
 Type: application/octet-stream
 Size: 507 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071106/e883e671/attachment.obj 
 
 From marcus-sup@bar-coded.net  Tue Nov  6 05:02:13 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 06 Nov 2007 10:02:13 +0000
 Subject: [sup-talk] [PATCH] Save messages from maildir source
 Message-ID: <1194343227-sup-7270@tomsk>
 
 Hi -
 
 Next one :) This fixes the bug where you try to save a message from a
 maildir source (crashes currently with missing method)
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: maildir-diffs
 Type: application/octet-stream
 Size: 566 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071106/d560c770/attachment.obj 
 
 From marcus-sup@bar-coded.net  Tue Nov  6 05:05:42 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 06 Nov 2007 10:05:42 +0000
 Subject: [sup-talk] [PATCH] IMAP fixes
 Message-ID: <1194343383-sup-7427@tomsk>
 
 Hi -
 
 And another. This is the IMAP fixes without the marked_read? stuff.
 This adds:
 
  * unread status fix
 
  * save message fix (same as maildir fix in last patch sent)
 
  * capability checks before using auth methods (note that if your
  server does not advertise an auth capability, even if it supports it
  it will not be used. Check log buffer for messages on login to double
  check what method you use)
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: imap-diffs
 Type: application/octet-stream
 Size: 1872 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071106/a124b40f/attachment.obj 
 
 From marcus-sup@bar-coded.net  Tue Nov  6 05:25:04 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 06 Nov 2007 10:25:04 +0000
 Subject: [sup-talk] [PATCH] Fix for before-add-message hook
 Message-ID: <1194344471-sup-8807@tomsk>
 
 Hi -
 
 Last one for now. This fixes the hook for filtering messages so that
 messages you tag with spam/killed/deleted in the hook dont get
 displayed by the inbox.
 
 Just to confirm something: if you want to tag using one of these
 labels you need to use the ruby symbol in the hook :spam, :killed and
 :deleted
 
 Eg:
 
 message.add_label :spam if message.raw_header =~ /X-Spam-Flag: YES/
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: before-add-message-hook
 Type: application/octet-stream
 Size: 1117 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071106/07ad0c18/attachment.obj 
 
 From marcus-sup@bar-coded.net  Tue Nov  6 08:39:49 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 06 Nov 2007 13:39:49 +0000
 Subject: [sup-talk] [PATCH] xterm title
 Message-ID: <1194356217-sup-6416@tomsk>
 
 Not sure what this will do if you're not running in a capable term
 client (and I'm not sure how to check!), but this patch adds makes the
 status line in sup appear in the title bar of your terminal (as well
 as the usual place at the bottom of the screen). Useful if you have
 multiple terminals open :)
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: xterm-title
 Type: application/octet-stream
 Size: 421 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071106/ed7c0e9f/attachment.obj 
 
 From tim@timvaughan.co.uk  Tue Nov  6 08:52:27 2007
 From: tim@timvaughan.co.uk (Tim Vaughan)
 Date: Tue, 6 Nov 2007 13:52:27 +0000
 Subject: [sup-talk] Feature requests for more Googlish behaviour
 Message-ID: <414a99f20711060552u1f35363ai46fad5719f66847c@mail.gmail.com>
 
 I know - feature requests are easy to make but hopefully these will be helpful:
 
 * Google-style contact autocompletion: typing a contact's name, or
 part thereof, should provide autocomplete suggestions which can be
 chosen before or after composing the message body.
 * Undo button: since I'm still learning the keyboard commands (and, I
 think, because they're still in flux) an undo button would be useful
 so I can un-tag an email mistakenly tagged as spam.
 
 -- 
 Tim Vaughan
 07725749263
 
 From marcus-sup@bar-coded.net  Tue Nov  6 09:10:12 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 06 Nov 2007 14:10:12 +0000
 Subject: [sup-talk] Feature requests for more Googlish behaviour
 In-Reply-To: <414a99f20711060552u1f35363ai46fad5719f66847c@mail.gmail.com>
 References: <414a99f20711060552u1f35363ai46fad5719f66847c@mail.gmail.com>
 Message-ID: <1194358083-sup-2587@tomsk>
 
 On 6.11.2007, Tim Vaughan wrote:
 > * Google-style contact autocompletion: typing a contact's name, or
 > part thereof, should provide autocomplete suggestions which can be
 > chosen before or after composing the message body.
 
 Try pressing tab when you type a contact. It should give you options
 from your contacts list. The only oddness is that now sup doesnt
 auto-add contacts that have no name (ie only an addresS) some contacts
 wont work. So if you want a contact to be auto-completable you may
 need to add it manually with a name/alias.
 
 Marcus
 
 From eyal.oren@deri.org  Tue Nov  6 09:19:29 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Tue, 06 Nov 2007 15:19:29 +0100
 Subject: [sup-talk] Feature requests for more Googlish behaviour
 In-Reply-To: <1194358083-sup-2587@tomsk>
 References: <414a99f20711060552u1f35363ai46fad5719f66847c@mail.gmail.com>
 	<1194358083-sup-2587@tomsk>
 Message-ID: <1194358627-sup-630@timmy>
 
 Excerpts from Marcus Williams's message of Tue Nov 06 15:10:12 +0100 2007:
 > On 6.11.2007, Tim Vaughan wrote:
 > > * Google-style contact autocompletion: typing a contact's name, or
 > > part thereof, should provide autocomplete suggestions which can be
 > > chosen before or after composing the message body.
 > 
 > Try pressing tab when you type a contact. It should give you options
 > from your contacts list. The only oddness is that now sup doesnt
 > auto-add contacts that have no name (ie only an addresS) some contacts
 > wont work. So if you want a contact to be auto-completable you may
 > need to add it manually with a name/alias.
 Regarding autocomplete, I have problems when autocompleting contacts whose name is something like 
 "Doe, John". Maybe somebody is seeing similar issues?
 
 The name is autocompleted correctly, but the email is sent to two addresses: 
 doe at smtphost (which doesn't arrive) and to john.doe at ... (which arrives 
 correctly). Has anyone seen something similar?
 
  -eyal
 
 From marcus-sup@bar-coded.net  Tue Nov  6 10:05:28 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 06 Nov 2007 15:05:28 +0000
 Subject: [sup-talk] [PATCH] xterm title
 In-Reply-To: <1194356217-sup-6416@tomsk>
 References: <1194356217-sup-6416@tomsk>
 Message-ID: <1194361216-sup-2140@tomsk>
 
 On 6.11.2007, Marcus Williams wrote:
 > Not sure what this will do if you're not running in a capable term
 > client (and I'm not sure how to check!), but this patch adds makes the
 > status line in sup appear in the title bar of your terminal (as well
 > as the usual place at the bottom of the screen). Useful if you have
 > multiple terminals open :)
 
 If this gets applied, it would actually be more useful to display a
 new message count in front of the status line. I havnt had time to
 look to see if I can get the new message count somehow from within
 buffer.rb though.
 
 Something like:
 
 Sup/0.2 - (3 new) [inbox-mode] ..........
 
 It needs to be at the front of the status line because then its
 visible in the title bar. I think it can be added somewhere in one of
 the mode classes but I'm not sure how to get the number of new
 messages short of searching for all messages tagged wth :unread.
 
 If theres a way of doing this thats quick I'll resubmit the patch.
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 17:41:37 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 14:41:37 -0800
 Subject: [sup-talk] new in svn: in-buffer search
 Message-ID: <1194388505-sup-2866@south>
 
 Thanks to Eyal Oren, who took a first crack at a patch and got me
 excited, SVN head now has in-buffer search.
 
 First, note that I've remapped the index search from '/' to '\'. Hah!
 
 '/' now does an in-buffer search, highlights the results, and jumps to
 the first one. 'n' jumps to the next result; ^G or any other key cancels
 the current search.
 
 Also note that the search is restricted to exactly what you see on the
 screen. Collapsed messages in thread-view-mode, etc must be uncollapsed
 in order to be in-buffer search candidates. Maybe there will be fancier
 behavior in the future.
 
 Future plans: regex search (very easy to do now), and use the
 highlighting code to make search-results-mode nicer.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From itaylor@uark.edu  Tue Nov  6 17:57:25 2007
 From: itaylor@uark.edu (Ian Taylor)
 Date: Tue, 06 Nov 2007 17:57:25 -0500
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194388505-sup-2866@south>
 References: <1194388505-sup-2866@south>
 Message-ID: <1194389659-sup-2148@silver>
 
 Excerpts from William Morgan's message of Tue Nov 06 17:41:37 -0500 2007:
 > Thanks to Eyal Oren, who took a first crack at a patch and got me
 > excited, SVN head now has in-buffer search.
 > 
 > First, note that I've remapped the index search from '/' to '\'. Hah!
 > 
 > '/' now does an in-buffer search, highlights the results, and jumps to
 > the first one. 'n' jumps to the next result; ^G or any other key cancels
 > the current search.
 > 
 > Also note that the search is restricted to exactly what you see on the
 > screen. Collapsed messages in thread-view-mode, etc must be uncollapsed
 > in order to be in-buffer search candidates. Maybe there will be fancier
 > behavior in the future.
 > 
 > Future plans: regex search (very easy to do now), and use the
 > highlighting code to make search-results-mode nicer.
 > 
 
 Not sure if this was introduced as a result of this patch, but '?' in
 the first view seems to crash sup with this error:
 
 The problem was: 'unknown key name "ctrl_g"' (error type ArgumentError)
 A backtrace follows:
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:54:in `keysym_to_string': unknown key name "ctrl_g" (ArgumentError)
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:80:in `help_text'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:80:in `map'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:80:in `help_text'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:77:in `map'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:77:in `help_text'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/modes/help-mode.rb:13:in `initialize'
         from /var/lib/gems/1.8/gems/sup-0.2/bin/sup:217:in `new'
         from /var/lib/gems/1.8/gems/sup-0.2/bin/sup:217
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/buffer.rb:262:in `spawn_unless_exists'
         from /var/lib/gems/1.8/gems/sup-0.2/bin/sup:217
         from /var/lib/gems/1.8/bin/sup:16:in `load'
         from /var/lib/gems/1.8/bin/sup:16
 
 My guess is that the following changes need to be made in keymap.rb
 
      when :end: "<end>"
      when :enter, :return: "<enter>"
      when :ctrl_l: "ctrl-l"
 -    when :ctrl_l: "ctrl-g"
 +    when :ctrl_g: "ctrl-g"
      when :tab: "tab"
      when " ": "<space>"
      else
 
 -- 
 Ian Taylor
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 17:59:37 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 14:59:37 -0800
 Subject: [sup-talk] run-mailcap not working correctly
 In-Reply-To: <1193790417-sup-3611@chris-tablet>
 References: <1192497496-sup-690@silver>
 	<6205b42d0710160119k5291a5e2ta1e89a0040471972@mail.gmail.com>
 	<1193783673-sup-4792@south> <1193790417-sup-3611@chris-tablet>
 Message-ID: <1194389962-sup-1890@south>
 
 Excerpts from Christopher Warrington's message of Tue Oct 30 17:29:29 -0700 2007:
 > process > /dev/null 2> /dev/null
 
 Fixed in svn. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 19:18:41 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 16:18:41 -0800
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194389659-sup-2148@silver>
 References: <1194388505-sup-2866@south> <1194389659-sup-2148@silver>
 Message-ID: <1194394699-sup-6551@south>
 
 Excerpts from Ian Taylor's message of Tue Nov 06 14:57:25 -0800 2007:
 > My guess is that the following changes need to be made in keymap.rb
 
 Exactly. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 20:55:22 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 17:55:22 -0800
 Subject: [sup-talk] [PATCH] Delete attachments bug fix
 In-Reply-To: <1194342872-sup-365@tomsk>
 References: <1194342872-sup-365@tomsk>
 Message-ID: <1194400502-sup-6815@south>
 
 Excerpts from Marcus Williams's message of Tue Nov 06 02:00:00 -0800 2007:
 > This fixes the bug where you hit the 'd' key to delete an attachment
 > in edit/reply mode when there isnt an attachment (or isnt one under
 > the cursor possibly as well)
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 20:55:37 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 17:55:37 -0800
 Subject: [sup-talk] [PATCH] Save messages from maildir source
 In-Reply-To: <1194343227-sup-7270@tomsk>
 References: <1194343227-sup-7270@tomsk>
 Message-ID: <1194400526-sup-7357@south>
 
 Excerpts from Marcus Williams's message of Tue Nov 06 02:02:13 -0800 2007:
 > This fixes the bug where you try to save a message from a maildir
 > source (crashes currently with missing method)
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 20:55:53 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 17:55:53 -0800
 Subject: [sup-talk] [PATCH] IMAP fixes
 In-Reply-To: <1194343383-sup-7427@tomsk>
 References: <1194343383-sup-7427@tomsk>
 Message-ID: <1194400540-sup-8291@south>
 
 Excerpts from Marcus Williams's message of Tue Nov 06 02:05:42 -0800 2007:
 > This is the IMAP fixes without the marked_read? stuff.
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 20:56:31 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 17:56:31 -0800
 Subject: [sup-talk] [PATCH] Fix for before-add-message hook
 In-Reply-To: <1194344471-sup-8807@tomsk>
 References: <1194344471-sup-8807@tomsk>
 Message-ID: <1194400555-sup-7015@south>
 
 Excerpts from Marcus Williams's message of Tue Nov 06 02:25:04 -0800 2007:
 > Last one for now. This fixes the hook for filtering messages so that
 > messages you tag with spam/killed/deleted in the hook dont get
 > displayed by the inbox.
 
 And applied. Thanks for all your hard work, Marcus!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov  6 21:09:46 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 06 Nov 2007 18:09:46 -0800
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 In-Reply-To: <1194256715-sup-4315@lankhmar>
 References: <1194256715-sup-4315@lankhmar>
 Message-ID: <1194400626-sup-6556@south>
 
 Hi Colin,
 
 Excerpts from Colin Bell's message of Mon Nov 05 02:01:31 -0800 2007:
 > This patch shows the unread message count in the thread index as well
 > as the total number of messages in the thread.
 
 I personally don't like this, because I feel like it clutters up
 index-mode. But I'd like people to be able to do this sort of thing.
 
 How about an "index-mode-widget" hook instead, that lets you replace the
 "(###)" with any string you want, based on the thread? (And if the
 return value is nil, use the current thread.size string.)
 
 You'll have to scan over them twice to get the sizing right, but it
 shouldn't be too bad of a patch...
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From col@baibell.org  Tue Nov  6 22:55:17 2007
 From: col@baibell.org (Colin Bell)
 Date: Wed, 07 Nov 2007 14:55:17 +1100
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 In-Reply-To: <1194400626-sup-6556@south>
 References: <1194256715-sup-4315@lankhmar> <1194400626-sup-6556@south>
 Message-ID: <1194407592-sup-4584@lankhmar>
 
 Excerpts from William Morgan's message of Wed Nov 07 13:09:46 +1100 2007:
 > I personally don't like this, because I feel like it clutters up
 > index-mode. But I'd like people to be able to do this sort of thing.
 >
 > How about an "index-mode-widget" hook instead, that lets you replace the
 > "(###)" with any string you want, based on the thread? (And if the
 > return value is nil, use the current thread.size string.)
 
 Good idea. I'll try to take a look at it tonight.
 
 From marcus-sup@bar-coded.net  Wed Nov  7 03:53:35 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 07 Nov 2007 08:53:35 +0000
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194388505-sup-2866@south>
 References: <1194388505-sup-2866@south>
 Message-ID: <1194425266-sup-7682@tomsk>
 
 On 6.11.2007, William Morgan wrote:
 > First, note that I've remapped the index search from '/' to '\'. Hah!
 > 
 > '/' now does an in-buffer search, highlights the results, and jumps to
 > the first one. 'n' jumps to the next result; ^G or any other key cancels
 > the current search.
 
 This feels a bit wrong to me (might just be me though). I'd say that
 searching for emails is the most used case for a search option in sup
 so should have the '/', and searching in buffer should be something
 different.
 
 Better than that, make '/' mode dependant so you can use say ctrl-s to
 search for emails (always), ctrl-f to search in buffer (always) but
 map '/' to ctrl-s in thread-index mode (so that would be in inbox and
 search results). In all other modes '/' could map to ctrl-f.
 
 Any thoughts?
 
 Marcus
 
 From eyal.oren@deri.org  Wed Nov  7 04:21:57 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Wed, 07 Nov 2007 10:21:57 +0100
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194425266-sup-7682@tomsk>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 Message-ID: <1194427158-sup-6839@timmy>
 
 Excerpts from Marcus Williams's message of Wed Nov 07 09:53:35 +0100 2007:
 > On 6.11.2007, William Morgan wrote:
 > > First, note that I've remapped the index search from '/' to '\'. Hah!
 > > 
 > > '/' now does an in-buffer search, highlights the results, and jumps to
 > > the first one. 'n' jumps to the next result; ^G or any other key cancels
 > > the current search.
 > 
 > This feels a bit wrong to me (might just be me though). I'd say that
 > searching for emails is the most used case for a search option in sup
 > so should have the '/', and searching in buffer should be something
 > different.
 > 
 > Better than that, make '/' mode dependant so you can use say ctrl-s to
 > search for emails (always), ctrl-f to search in buffer (always) but
 > map '/' to ctrl-s in thread-index mode (so that would be in inbox and
 > search results). In all other modes '/' could map to ctrl-f.
 Personally, I feel that '/' should search in buffer, as many other UNIX tools do 
 (vi, mutt, less, etc). 
 
 Btw, William, thanks for the search! It's great. But wouldn't you like to search 
 from the top instead of searching from cursor position? I often want to use 
 search instead of hitting cursor-up seven times.
 
 -- 
  -eyal
 
 From manish@gslab.com  Wed Nov  7 04:32:59 2007
 From: manish@gslab.com (Manish Sapariya)
 Date: Wed, 07 Nov 2007 15:02:59 +0530
 Subject: [sup-talk] undefined method `normalize_whitespace' for nil:NilClass
  (NoMethodError) in Revision: 673
 Message-ID: <4731864B.4050205@gslab.com>
 
 Any Clues?
 Thanks,
 Manish
 
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/message.rb:358:in 
 `message_to_chunks': undefined method `normalize_whitespace' for 
 nil:NilClass (NoMethodError)
         from 
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/message.rb:158:in 
 `load_from_source!'
         from 
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/message.rb:211:in `content'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:173:in 
 `sync_message'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in 
 `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:395:in 
 `method_missing'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:158:in 
 `add_messages_from'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/source.rb:93:in 
 `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in 
 `send'
          ... 6 levels...
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup-sync:128:in `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup-sync:128
         from /usr/bin/sup-sync:16:in `load'
         from /usr/bin/sup-sync:16
 
 
 From manish@gslab.com  Wed Nov  7 04:35:07 2007
 From: manish@gslab.com (Manish Sapariya)
 Date: Wed, 07 Nov 2007 15:05:07 +0530
 Subject: [sup-talk] 'undefined method `longname' for nil:NilClass' (error
 	type NoMethodError)
 Message-ID: <473186CB.8090307@gslab.com>
 
 This is seen when I run sup. The previous one was with sup-sync.
 
 Looks like some problem with handling encoded messages.
 How can I back track?
 Thanks,
 -Manish
 
 
 The problem was: 'undefined method `longname' for nil:NilClass' (error 
 type NoMethodError)
 A backtrace follows:
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:102:in `do_poll': 
 undefined method `longname' for nil:NilClass (NoMethodError)
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:157:in 
 `add_messages_from'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/source.rb:93:in 
 `each'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in 
 `send'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:431:in 
 `__pass'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:420:in 
 `method_missing'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:139:in 
 `add_messages_from'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:96:in 
 `do_poll'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:84:in 
 `each'
          ... 24 levels...
         from 
 /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/modes/thread-index-mode.rb:431:in 
 `load_threads'
         from /usr/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup:193
         from /usr/bin/sup:16:in `load'
         from /usr/bin/sup:16
 
 
 From marcus-sup@bar-coded.net  Wed Nov  7 04:43:47 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 07 Nov 2007 09:43:47 +0000
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194427158-sup-6839@timmy>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<1194427158-sup-6839@timmy>
 Message-ID: <1194428338-sup-2107@tomsk>
 
 On 7.11.2007, Eyal Oren wrote:
 > Personally, I feel that '/' should search in buffer, as many other
 > UNIX tools do (vi, mutt, less, etc). 
 
 I agree with you, but I dont think it makes sense in the inbox or
 thread index views which is why I suggested having it mode dependant.
 Maybe that would just confuse though.
 
 That aside I like it :)
 
 Marcus
 
 From marcus-sup@bar-coded.net  Wed Nov  7 04:53:16 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 07 Nov 2007 09:53:16 +0000
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194427158-sup-6839@timmy>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<1194427158-sup-6839@timmy>
 Message-ID: <1194429069-sup-681@tomsk>
 
 On 7.11.2007, Eyal Oren wrote:
 > Btw, William, thanks for the search! It's great. But wouldn't you
 > like to search from the top instead of searching from cursor
 > position? I often want to use search instead of hitting cursor-up
 > seven times.
 
 Forgot to add - you can just hit '1' to move your cursor to the top of
 the buffer if that helps.
 
 Marcus
 
 From col@baibell.org  Wed Nov  7 05:29:03 2007
 From: col@baibell.org (Colin Bell)
 Date: Wed, 07 Nov 2007 21:29:03 +1100
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 In-Reply-To: <1194400626-sup-6556@south>
 References: <1194256715-sup-4315@lankhmar> <1194400626-sup-6556@south>
 Message-ID: <1194430991-sup-3015@lankhmar>
 
 Excerpts from William Morgan's message of Wed Nov 07 13:09:46 +1100 2007:
 > How about an "index-mode-widget" hook instead, that lets you replace the
 > "(###)" with any string you want, based on the thread? (And if the
 > return value is nil, use the current thread.size string.)
 >
 > You'll have to scan over them twice to get the sizing right, but it
 > shouldn't be too bad of a patch...
 >
 
 Attempt 2 :-)
 
 I've attached an example hook as well as the diff. If you accept the
 patch something like the example should go up on the wiki.
 
 Please take a careful look at this patch as I am just learning Ruby so
 I've probably done a few silly things.
 
 index-mode-widget
 -----------------
 File: ~/.sup/hooks/index-mode-widget.rb
 Executes when formatting the output of the number of messages for each thread in the thread index.
 Variables:
       thread: The message thread to be formatted.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: widget.diff
 Type: application/octet-stream
 Size: 2708 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071107/dd62a04e/attachment.obj 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: index-mode-widget.rb
 Type: application/octet-stream
 Size: 203 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071107/dd62a04e/attachment-0001.obj 
 
 From vasudeva@linkswarm.com  Wed Nov  7 09:25:27 2007
 From: vasudeva@linkswarm.com (vasudeva)
 Date: Wed, 7 Nov 2007 09:25:27 -0500
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194425266-sup-7682@tomsk>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 Message-ID: <20071107142527.GB1579@lenin.sovietwar.org>
 
 * on 11-07-07, Marcus Williams wrote:
 > On 6.11.2007, William Morgan wrote:
 > > First, note that I've remapped the index search from '/' to '\'. Hah!
 > > 
 > > '/' now does an in-buffer search, highlights the results, and jumps to
 > > the first one. 'n' jumps to the next result; ^G or any other key cancels
 > > the current search.
 > 
 > This feels a bit wrong to me (might just be me though). I'd say that
 > searching for emails is the most used case for a search option in sup
 > so should have the '/', and searching in buffer should be something
 > different.
 > 
 > Better than that, make '/' mode dependant so you can use say ctrl-s to
 > search for emails (always), ctrl-f to search in buffer (always) but
 > map '/' to ctrl-s in thread-index mode (so that would be in inbox and
 > search results). In all other modes '/' could map to ctrl-f.
 
 For purposes of migration from existing tools, and conforming to
 established UNIX conventions, I like keeping / as buffer search (per
 the 'screen search' CLI norm) and \ as ferret-index search (somewhat
 unusual functionality in terms of CLI app search conventions, thus
 deserving of a lower-priority keybinding). 
 
 That said, I think mode-dependency could be a neat resolve. 
 
 
 
 /></
 
 --
 linkswarm.com :: Collaborative Insolence
 vasudeva.linkswarm.com/gallery :: For The Faint of Heart
 
 
 From marcus-sup@bar-coded.net  Wed Nov  7 11:06:18 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 07 Nov 2007 16:06:18 +0000
 Subject: [sup-talk] [PATCH] Fix for before-add-message hook
 In-Reply-To: <1194400555-sup-7015@south>
 References: <1194344471-sup-8807@tomsk> <1194400555-sup-7015@south>
 Message-ID: <1194451347-sup-1828@tomsk>
 
 On 7.11.2007, William Morgan wrote:
 > Excerpts from Marcus Williams's message of Tue Nov 06 02:25:04 -0800 2007:
 > > Last one for now. This fixes the hook for filtering messages so that
 > > messages you tag with spam/killed/deleted in the hook dont get
 > > displayed by the inbox.
 > 
 > And applied. Thanks for all your hard work, Marcus!
 
 ... Mmmm - I'm having a few problems with that is-relevant change.
 Sometimes (I've just seen one now) I get a new message that doesnt
 make it to the inbox. Whats odd is that it does appear if I pull in a
 few more threads or somehow update the inbox buffer.
 
 It might not be related to this change, but I'd not noticed it until
 just now. I'll see if I can reproduce it somehow.
 
 Marcus
 
 From marcus-sup@bar-coded.net  Wed Nov  7 11:34:32 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 07 Nov 2007 16:34:32 +0000
 Subject: [sup-talk] [PATCH] Fix for before-add-message hook
 In-Reply-To: <1194451347-sup-1828@tomsk>
 References: <1194344471-sup-8807@tomsk> <1194400555-sup-7015@south>
 	<1194451347-sup-1828@tomsk>
 Message-ID: <1194452873-sup-8208@tomsk>
 
 On 7.11.2007, Marcus Williams wrote:
 > It might not be related to this change, but I'd not noticed it until
 > just now. I'll see if I can reproduce it somehow.
 
 Got it - in is_relevant you changed the patch to use "&&" instead of
 "and" and I think this broke it because of the precedence of "&&"
 makes it do
 
 m.labels.include? (:inbox && ......)
 
 whereas mine does
 
 (m.labels.include? :inbox) and (......)
 
 reverting back to "and" fixes it in my version.
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 12:35:11 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 09:35:11 -0800
 Subject: [sup-talk] [PATCH] Fix for before-add-message hook
 In-Reply-To: <1194452873-sup-8208@tomsk>
 References: <1194344471-sup-8807@tomsk> <1194400555-sup-7015@south>
 	<1194451347-sup-1828@tomsk> <1194452873-sup-8208@tomsk>
 Message-ID: <1194456839-sup-763@south>
 
 Excerpts from Marcus Williams's message of Wed Nov 07 08:34:32 -0800 2007:
 > Got it - in is_relevant you changed the patch to use "&&" instead of
 > "and" and I think this broke it because of the precedence of "&&"
 > makes it do
 
 Good catch. Fixed in SVN. (Still refusing to use "and" though
 :) )
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 12:41:36 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 09:41:36 -0800
 Subject: [sup-talk] [PATCH] Fix for before-add-message hook
 In-Reply-To: <1194456839-sup-763@south>
 References: <1194344471-sup-8807@tomsk> <1194400555-sup-7015@south>
 	<1194451347-sup-1828@tomsk> <1194452873-sup-8208@tomsk>
 	<1194456839-sup-763@south>
 Message-ID: <1194457060-sup-5193@south>
 
 Excerpts from William Morgan's message of Wed Nov 07 09:35:11 -0800 2007:
 > Good catch. Fixed in SVN. (Still refusing to use "and" though
 > :) )
 
 To be clear, idiomatic Ruby is to use and/or for short-cut exit checks
 like "or return nil", and use && and || for all "normal" boolean
 comparisons. I'm not just trying to be a jerk! But I did blindly make
 that change your patch without thinking about what I was doing, so thank
 you for catching that.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From chrisw@rice.edu  Wed Nov  7 13:38:19 2007
 From: chrisw@rice.edu (Christopher Warrington)
 Date: Wed, 07 Nov 2007 12:38:19 -0600
 Subject: [sup-talk] [PATCH] Fix for before-add-message hook
 In-Reply-To: <1194456839-sup-763@south>
 References: <1194344471-sup-8807@tomsk> <1194400555-sup-7015@south>
 	<1194451347-sup-1828@tomsk> <1194452873-sup-8208@tomsk>
 	<1194456839-sup-763@south>
 Message-ID: <1194460683-sup-6198@chris-tablet>
 
 Excerpts from William Morgan's message of Wed Nov 07 11:35:11 -0600 2007:
 > Good catch. Fixed in SVN. (Still refusing to use "and" though
 > :) )
 
 Thanks guys! This had been bugging me all day.
 
 -- 
 Christopher Warrington <chrisw at rice.edu>
 Jones College
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 15:08:50 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 12:08:50 -0800
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 In-Reply-To: <1194430991-sup-3015@lankhmar>
 References: <1194256715-sup-4315@lankhmar> <1194400626-sup-6556@south>
 	<1194430991-sup-3015@lankhmar>
 Message-ID: <1194465975-sup-3345@south>
 
 Excerpts from Colin Bell's message of Wed Nov 07 02:29:03 -0800 2007:
 > Please take a careful look at this patch as I am just learning Ruby so
 > I've probably done a few silly things.
 
 I've applied this patch in modified form. There was a little work to be
 done when the size of the widget changes (namely, if a widget suddenly
 exceeds the previous size due to a change, the whole screen has to be
 redrawn).
 
 I've also renamed the hook "index-mode-size-widget", in case there are
 other widgets you'll want to tweak later. :)
 
 I've been trying it and I actually quite like this slight modification
 of your hook code, which only displays the unread/total breakdown in the
 case where some, but not all, messages in a thread are unread:
 
   unread_size = thread.map { |m, *o| m && m.has_label?(:unread) ? 1 : 0 }.sum
   size = thread.size
   
   case
     when size == 1 : ""
     when (unread_size == 0) || (unread_size == size) : "(#{size})"
     else "(#{unread_size}/#{size})"
   end
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 15:38:30 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 12:38:30 -0800
 Subject: [sup-talk] undefined method `normalize_whitespace' for
 	nil:NilClass
 In-Reply-To: <4731864B.4050205@gslab.com>
 References: <4731864B.4050205@gslab.com>
 Message-ID: <1194467886-sup-3015@south>
 
 Excerpts from Manish Sapariya's message of Wed Nov 07 01:32:59 -0800 2007:
 > /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/message.rb:358:in `message_to_chunks': undefined method `normalize_whitespace' for nil:NilClass (NoMethodError)
 
 This should be fixed in SVN now.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 15:39:26 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 12:39:26 -0800
 Subject: [sup-talk] 'undefined method `longname' for nil:NilClass'
 	(error type NoMethodError)
 In-Reply-To: <473186CB.8090307@gslab.com>
 References: <473186CB.8090307@gslab.com>
 Message-ID: <1194467915-sup-5870@south>
 
 Excerpts from Manish Sapariya's message of Wed Nov 07 01:35:07 -0800 2007:
 > The problem was: 'undefined method `longname' for nil:NilClass' (error 
 > type NoMethodError)
 > A backtrace follows:
 > /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:102:in `do_poll': undefined method `longname' for nil:NilClass (NoMethodError)
 
 This should be fixed in SVN now. You may have to re-index the offending
 source (sup-sync --all <source uri>).
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 15:41:46 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 12:41:46 -0800
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <20071107142527.GB1579@lenin.sovietwar.org>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<20071107142527.GB1579@lenin.sovietwar.org>
 Message-ID: <1194467985-sup-8861@south>
 
 Excerpts from vasudeva's message of Wed Nov 07 06:25:27 -0800 2007:
 > For purposes of migration from existing tools, and conforming to
 > established UNIX conventions, I like keeping / as buffer search (per
 > the 'screen search' CLI norm) and \ as ferret-index search (somewhat
 > unusual functionality in terms of CLI app search conventions, thus
 > deserving of a lower-priority keybinding). 
 
 This was pretty much my thinking. Anyone else want to weight in?  (I'll
 admit I'm having to retrain myself to use the new keybindings, which is
 mildly irritating.)
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Wed Nov  7 16:05:58 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 07 Nov 2007 21:05:58 +0000
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194467985-sup-8861@south>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<20071107142527.GB1579@lenin.sovietwar.org>
 	<1194467985-sup-8861@south>
 Message-ID: <1194469177-sup-3271@tomsk>
 
 On 7.11.2007, William Morgan wrote:
 > This was pretty much my thinking. Anyone else want to weight in?  (I'll
 > admit I'm having to retrain myself to use the new keybindings, which is
 > mildly irritating.)
 
 Retraining is one thing, the other is that the '\' is in different
 places on all the keyboards I use! I'm sure I'll get over it though :)
 
 Two things - can we make the prompts different to make it more obvious
 and make a blank search not do anything?
 
 Marcus
 
 From marcus-sup@bar-coded.net  Wed Nov  7 16:09:10 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 07 Nov 2007 21:09:10 +0000
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 In-Reply-To: <1194465975-sup-3345@south>
 References: <1194256715-sup-4315@lankhmar> <1194400626-sup-6556@south>
 	<1194430991-sup-3015@lankhmar> <1194465975-sup-3345@south>
 Message-ID: <1194469570-sup-4239@tomsk>
 
 On 7.11.2007, William Morgan wrote:
 > I've also renamed the hook "index-mode-size-widget", in case there are
 > other widgets you'll want to tweak later. :)
 
 ... status bar for instance :) I'm in the middle of doing one for this
 but its causing me bother! Is there any way to get the new message
 count without search for unread labels? How fast is that in ferret?
 What happens if your result set has 60k messages in it, does it chew
 memory? I cant imagine having 60k new messages, but on initial
 sup-sync you might on a big mailbox.
 
 Marcus
 
 From col@baibell.org  Wed Nov  7 16:56:21 2007
 From: col@baibell.org (Colin Bell)
 Date: Thu, 08 Nov 2007 08:56:21 +1100
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194467985-sup-8861@south>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<20071107142527.GB1579@lenin.sovietwar.org>
 	<1194467985-sup-8861@south>
 Message-ID: <1194472330-sup-3257@lankhmar>
 
 Excerpts from William Morgan's message of Thu Nov 08 07:41:46 +1100 2007:
 > Excerpts from vasudeva's message of Wed Nov 07 06:25:27 -0800 2007:
 > > For purposes of migration from existing tools, and conforming to
 > > established UNIX conventions, I like keeping / as buffer search (per
 > > the 'screen search' CLI norm) and \ as ferret-index search (somewhat
 > > unusual functionality in terms of CLI app search conventions, thus
 > > deserving of a lower-priority keybinding).
 >
 > This was pretty much my thinking. Anyone else want to weight in?  (I'll
 > admit I'm having to retrain myself to use the new keybindings, which is
 > mildly irritating.)
 
 You could replace \ with F for Filter or Ferret-index search if the \
 character is too annoying. My first thought was to borrow L for Limit
 from mutt but that doesn't work too well with labels :-)
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 18:12:03 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 15:12:03 -0800
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 In-Reply-To: <1194469570-sup-4239@tomsk>
 References: <1194256715-sup-4315@lankhmar> <1194400626-sup-6556@south>
 	<1194430991-sup-3015@lankhmar> <1194465975-sup-3345@south>
 	<1194469570-sup-4239@tomsk>
 Message-ID: <1194476394-sup-4617@south>
 
 Excerpts from Marcus Williams's message of Wed Nov 07 13:09:10 -0800 2007:
 > Is there any way to get the new message count without search for
 > unread labels?
 
 Nope. Unread is just another label, so you've got to do the search.
 
 > How fast is that in ferret?
 
 Pretty fast!
 
   $ sh devel/console.sh
   [Wed Nov 07 15:03:42 -0800 2007] loading index...
   [Wed Nov 07 15:03:42 -0800 2007] loaded index of 65765 messages
   >> require 'benchmark'
   >> all = "+label:unread -label:deleted -label:killed -label:spam"
   >> inbox = all + " +label:inbox"
   >> puts Benchmark.measure { Index.ferret.search(all).total_hits }
     0.020000   0.000000   0.020000 (  0.015534)
   >> Index.ferret.search(all).total_hits
   => 57551
   >> puts Benchmark.measure { Index.ferret.search(inbox).total_hits }
   => nil
   >> Index.ferret.search(inbox).total_hits
   => 13
 
 The number in parentheses is elapsed real time. Probably fast enough to
 call on every keypress, but feel free to cache it if you like.
 
 > What happens if your result set has 60k messages in it, does it chew
 > memory?
 
 Nope. Play around with the methods above. Ferret is pretty good about
 this.
 
 > I cant imagine having 60k new messages, but on initial sup-sync you
 > might on a big mailbox.
 
 As you can see above, 57k of the 66k messages in my index are new.
 (It's the last few years of ruby-talk.) Have I blown your mind? :)
 
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 20:40:48 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 17:40:48 -0800
 Subject: [sup-talk] new in svn: subscribe/unsubscribe from list
 Message-ID: <1194485819-sup-2326@south>
 
 In thread-view-mode, pressing ( or ) will dump you into compose mode
 with a pre-generated email to subscribe or unsubscribe from the
 corresponding mailing list. (I guess this means it's time to add support
 for multi-key keybindings.)
 
 Now you can unsubscribe from sup-talk even more easily!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov  7 21:08:00 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 07 Nov 2007 18:08:00 -0800
 Subject: [sup-talk] wup
 Message-ID: <1194487545-sup-8478@south>
 
 Hi Suppers,
 
 My friend Leslie has hacked together "wup", a web interface on top of
 Sup: http://jinsync.com/?q=node/16.
 
 75 lines of code gets you quite a lot!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From manish@gslab.com  Thu Nov  8 00:15:09 2007
 From: manish@gslab.com (Manish Sapariya)
 Date: Thu, 08 Nov 2007 10:45:09 +0530
 Subject: [sup-talk] 'undefined method `longname' for
  nil:NilClass'	(error type NoMethodError)
 In-Reply-To: <1194467915-sup-5870@south>
 References: <473186CB.8090307@gslab.com> <1194467915-sup-5870@south>
 Message-ID: <47329B5D.4090907@gslab.com>
 
 Hi Williams,
 Thanks for the fix. However looks like I have some weird mail in my box.
 The body and the charset both are nil. Is there any way I can backtrack the
 offending message and find out whats the character set and encoding used
 for that message?
 Thanks,
 Manish
 
 (rdb:1) list
 [372, 381] in /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/message.rb
    372    def self.convert_from body, charset
    373      begin
    374        raise MessageFormatError, "RubyMail decode returned a null 
 body" unless body
    375        return body unless charset
    376        Iconv.iconv($encoding, charset, body).join
    377      rescue Errno::EINVAL, Iconv::InvalidEncoding, 
 Iconv::IllegalSequence, MessageFormatError => e
    378        Redwood::log "warning: error (#{e.class.name}) decoding 
 message body from #{charset}: #{e.message}"
    379        File.open("sup-unable-to-decode.txt", "w") { |f| f.write 
 body }
    380        body
    381      end
 (rdb:1) p m.charset
 nil
 (rdb:1) p m.body
 nil
 
 
 
 William Morgan wrote:
 > Excerpts from Manish Sapariya's message of Wed Nov 07 01:35:07 -0800 2007:
 >   
 >> The problem was: 'undefined method `longname' for nil:NilClass' (error 
 >> type NoMethodError)
 >> A backtrace follows:
 >> /usr/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/poll.rb:102:in `do_poll': undefined method `longname' for nil:NilClass (NoMethodError)
 >>     
 >
 > This should be fixed in SVN now. You may have to re-index the offending
 > source (sup-sync --all <source uri>).
 >
 >   
 
 
 From marcus-sup@bar-coded.net  Thu Nov  8 03:31:35 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 08 Nov 2007 08:31:35 +0000
 Subject: [sup-talk] [PATCH] Show unread message count in thread index
 In-Reply-To: <1194476394-sup-4617@south>
 References: <1194256715-sup-4315@lankhmar> <1194400626-sup-6556@south>
 	<1194430991-sup-3015@lankhmar> <1194465975-sup-3345@south>
 	<1194469570-sup-4239@tomsk> <1194476394-sup-4617@south>
 Message-ID: <1194510622-sup-5004@tomsk>
 
 On 7.11.2007, William Morgan wrote:
 > > I cant imagine having 60k new messages, but on initial sup-sync you
 > > might on a big mailbox.
 > 
 > As you can see above, 57k of the 66k messages in my index are new.
 > (It's the last few years of ruby-talk.) Have I blown your mind? :)
 
 ruby seems to do this regularly (at the moment daily!) :)
 
 From kevin.mark@verizon.net  Thu Nov  8 03:49:10 2007
 From: kevin.mark@verizon.net (Kevin Mark)
 Date: Thu, 8 Nov 2007 03:49:10 -0500
 Subject: [sup-talk] wup
 In-Reply-To: <1194487545-sup-8478@south>
 References: <1194487545-sup-8478@south>
 Message-ID: <20071108084910.GH13064@horacrux>
 
 On Wed, Nov 07, 2007 at 06:08:00PM -0800, William Morgan wrote:
 > Hi Suppers,
 > 
 > My friend Leslie has hacked together "wup", a web interface on top of
 > Sup: http://jinsync.com/?q=node/16.
 > 
 > 75 lines of code gets you quite a lot!
 > 
 This is what make FLOSS great! Release early, Release often. And allow
 folks to build on it. Cool.
 -K
 -- 
 |  .''`.  == Debian GNU/Linux == |       my web site:           |
 | : :' :      The  Universal     |mysite.verizon.net/kevin.mark/|
 | `. `'      Operating System    | go to counter.li.org and     |
 |   `-    http://www.debian.org/ |    be counted! #238656       |
 |  my keyserver: subkeys.pgp.net |     my NPO: cfsg.org         |
 |join the new debian-community.org to help Debian!              |
 |_______  Unless I ask to be CCd, assume I am subscribed _______|
 
 From pierre@baillet.name  Thu Nov  8 05:22:29 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Thu, 8 Nov 2007 11:22:29 +0100
 Subject: [sup-talk] [BUG] Killed thread and unread count
 Message-ID: <6205b42d0711080222i119831cdl64edf4a3291a3078@mail.gmail.com>
 
 Hi,
 
 When an unread thread is killed, it is still marked as belonging to +inbox
 and hence is accounted as unread by sup in the "Label list". However, when
 displaying the +inbox labelled emails, this thread does not appear. I think
 this behaviour may confuse the user. Shouldn't killed threads be marked as
 read ?
 
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071108/cbc7065b/attachment.html 
 
 From marcus-sup@bar-coded.net  Thu Nov  8 05:44:44 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 08 Nov 2007 10:44:44 +0000
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 Message-ID: <1194518450-sup-4792@tomsk>
 
 This patch adds two new hooks that allow you to set the title bar of a
 terminal (default is no title, to support non-terminal users) and the
 status bar of sup (default is standard status bar string).
 
 status-bar-widget
 -----------------
 File: /home/marcus/.sup/hooks/status-bar-widget.rb
 Generates the contents of the status bar
 Variables:
   total: Total number of messages in inbox
   spam: Total number of messages marked as spam
   new: Total number of messages marked as unread (new)
   mode: Mode string
   status: Mode status
   title: Mode title
 
 terminal-title-widget
 ---------------------
 File: /home/marcus/.sup/hooks/terminal-title-widget.rb
 Generates the contents of the title bar
 Variables:
   total: Total number of messages in inbox
   spam: Total number of messages marked as spam
   new: Total number of messages marked as unread (new)
   mode: Mode string
   status: Mode status
   title: Mode title
 
 So I have in my terminal-title-widget.rb (giving me a quick way to see
 if I have any email when iconised):
 
 "Sup/#{Redwood::VERSION} - #{new} unread of #{total} messages"
 
 In my title bar this looks like
 
 Sup/0.2 - 12 unread of 4520 messages
 
 Note that the numbers come from the index, so if you read a message
 and dont save (via '$') the display doesnt know about those changes.
 Incoming messages go straight to index so will update it
 automatically.
 
 If its any use I could add counts for other forms of messages
 (starred/killed etc) but I only use the spam, new and total and I only
 use spam to track what the before-add-message hook is doing :)
 
 Marcus
 
 From marcus-sup@bar-coded.net  Thu Nov  8 06:18:51 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 08 Nov 2007 11:18:51 +0000
 Subject: [sup-talk] Sup sources question
 Message-ID: <1194520465-sup-413@tomsk>
 
 I cocked up when I set up one of my sources so that I added a sent
 folder from imap to sup without the sent label.
 
 What I thought I'd do is sup-dump, sup-sync everything again and then
 restore my settings. Then I remembered I'd noticed that you have a
 source_id in the ferret index, so I can search for messages marked
 with that source_id and add the label in manually. The only problem is
 I dont know the source_id (although its easy to find out in the
 console.sh).
 
 What I'm thinking is, rather than use an auto-generated id which I
 assume is some index into the source.yaml could you not name the
 sources in some way in the yaml so that you can then use this name to
 look up certain sources? This would also stop your source.yaml and
 your source_id's getting out of sync which I assume they can if you
 add a source to your yaml file in the middle somewhere. On startup you
 could check for uniqueness if needed.
 
 Does this make sense?
 
 Marcus
 
 From marcus-sup@bar-coded.net  Thu Nov  8 06:21:06 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 08 Nov 2007 11:21:06 +0000
 Subject: [sup-talk] Sup sources question
 In-Reply-To: <1194520465-sup-413@tomsk>
 References: <1194520465-sup-413@tomsk>
 Message-ID: <1194520783-sup-4954@tomsk>
 
 On 8.11.2007, Marcus Williams wrote:
 > What I'm thinking is, rather than use an auto-generated id which I
 > assume is some index into the source.yaml could you not name the
 > sources in some way in the yaml so that you can then use this name to
 > look up certain sources? This would also stop your source.yaml and
 > your source_id's getting out of sync which I assume they can if you
 > add a source to your yaml file in the middle somewhere. On startup you
 > could check for uniqueness if needed.
 
 Rather embarrassingly, I just noticed the id flag in sources.yaml
 which probably does exactly this :)
 
 Ignore the noise..
 
 From vasudeva@linkswarm.com  Thu Nov  8 07:10:27 2007
 From: vasudeva@linkswarm.com (vasudeva)
 Date: Thu, 8 Nov 2007 07:10:27 -0500
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <1194518450-sup-4792@tomsk>
 References: <1194518450-sup-4792@tomsk>
 Message-ID: <20071108121027.GA19876@lenin.sovietwar.org>
 
 * on 11-08-07, Marcus Williams wrote:
 > This patch adds two new hooks that allow you to set the title bar of a
 > terminal (default is no title, to support non-terminal users) and the
 > status bar of sup (default is standard status bar string).
 
 A case for :confirm_no_patches ? ;)
 
 
 
 /></
 
 --
 linkswarm.com :: Collaborative Insolence
 vasudeva.linkswarm.com/gallery :: For The Faint of Heart
 
 
 From nevans@mdlogix.com  Thu Nov  8 09:49:22 2007
 From: nevans@mdlogix.com (nicholas a. evans)
 Date: Thu, 08 Nov 2007 09:49:22 -0500
 Subject: [sup-talk] wup
 In-Reply-To: <1194487545-sup-8478@south>
 References: <1194487545-sup-8478@south>
 Message-ID: <1194533290-sup-646@nevans-desktop>
 
 Excerpts from William Morgan's message of Wed Nov 07 21:08:00 -0500 2007:
 > My friend Leslie has hacked together "wup", a web interface on top of
 > Sup: http://jinsync.com/?q=node/16.
 > 
 > 75 lines of code gets you quite a lot!
 
 Sweet!  Using merb too.  :-)
 
 -- 
 Nick
 
 From eyal.oren@deri.org  Thu Nov  8 10:47:30 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Thu, 08 Nov 2007 16:47:30 +0100
 Subject: [sup-talk] patch: execute shell command
 Message-ID: <1194536747-sup-4081@timmy>
 
 Find attached a simple patch (against svn head) to execute a shell command using 
 '!' (as in vi or mutt). It requires the 'session' gem: if you want to get rid of 
 that dependency you can just capture the output using >& etc.
 
 It works for me. If I did something wrong, let me know.
 
 -- 
  -eyal
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: shell.patch
 Type: application/octet-stream
 Size: 1154 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071108/1f8becde/attachment.obj 
 
 From eyal.oren@deri.org  Thu Nov  8 10:51:30 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Thu, 08 Nov 2007 16:51:30 +0100
 Subject: [sup-talk] bugfix in thread-index-mode
 Message-ID: <1194536965-sup-2478@timmy>
 
 Find attached tiny bugfix in thread-index-mode that caused sup (svn) to crash 
 when archiving/deleting messages in thread-mode.
 
 -- 
  -eyal
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: thread.patch
 Type: application/octet-stream
 Size: 455 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071108/162203a4/attachment.obj 
 
 From sup-talk@gurski.org  Thu Nov  8 11:57:26 2007
 From: sup-talk@gurski.org (Michael Gurski)
 Date: Thu, 08 Nov 2007 11:57:26 -0500
 Subject: [sup-talk] bugfix in thread-index-mode
 In-Reply-To: <1194536965-sup-2478@timmy>
 References: <1194536965-sup-2478@timmy>
 Message-ID: <1194540012-sup-3316@ln>
 
 Excerpts from eyal.oren's message of Thu Nov 08 10:51:30 -0500 2007:
 > Find attached tiny bugfix in thread-index-mode that caused sup (svn) to crash 
 > when archiving/deleting messages in thread-mode.
 
 Excellent, this seems to have fixed the problem I posted about
 earlier.
 
 
 -- 
 Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
 1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
 1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
 4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
 Views expressed by the host do not reflect the staff, management or sponsors.
 
 
 From sup-talk@gurski.org  Thu Nov  8 09:56:38 2007
 From: sup-talk@gurski.org (Michael Gurski)
 Date: Thu, 08 Nov 2007 09:56:38 -0500
 Subject: [sup-talk] exception when archiving in rev 684
 Message-ID: <1194533224-sup-2750@ln>
 
 I've been getting exceptions whenever I attempt to archive a message
 or thread if I'm NOT in the main index, in rev 684.  I can either be
 reading a thread and hit "a" or be in an index for a specific label
 and hit "a", and both will trigger the following exception:
 
 The problem was: 'undefined method `contains?' for
 #<Array:0x4159b5b4>' (error type NoMethodError)
 A backtrace follows:
 ./lib/sup/modes/thread-index-mode.rb:71:in `contains_thread?': undefined method `contains?' for #<Array:0x4159b5b4> (NoMethodError)
         from ./lib/sup/modes/inbox-mode.rb:42:in `handle_archived_update'
         from ./lib/sup/update.rb:16:in `send'
         from ./lib/sup/update.rb:16:in `relay'
         from ./lib/sup/update.rb:16:in `each'
         from ./lib/sup/update.rb:16:in `relay'
         from ./lib/sup/util.rb:422:in `send'
         from ./lib/sup/util.rb:422:in `method_missing'
         from ./lib/sup/modes/thread-index-mode.rb:198:in `actually_toggle_archived'
         from ./lib/sup/modes/thread-index-mode.rb:227:in `toggle_archived'
         from ./lib/sup/mode.rb:54:in `send'
         from ./lib/sup/mode.rb:54:in `handle_input'
         from ./lib/sup/buffer.rb:203:in `handle_input'
         from bin/sup:210
 
 Currently, to archive, I need to "x" while reading, and make sure I
 hit "a" in the main index.
 
 -- 
 Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
 1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
 1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
 4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
 Views expressed by the host do not reflect the staff, management or sponsors.
 
 
 From marcus-sup@bar-coded.net  Fri Nov  9 02:40:32 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 09 Nov 2007 07:40:32 +0000
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <20071108121027.GA19876@lenin.sovietwar.org>
 References: <1194518450-sup-4792@tomsk>
 	<20071108121027.GA19876@lenin.sovietwar.org>
 Message-ID: <1194593969-sup-9828@tomsk>
 
 On 8.11.2007, vasudeva wrote:
 > * on 11-08-07, Marcus Williams wrote:
 > > This patch adds two new hooks that allow you to set the title bar of a
 > > terminal (default is no title, to support non-terminal users) and the
 > > status bar of sup (default is standard status bar string).
 > 
 > A case for :confirm_no_patches ? ;)
 
 Oops! :) Attached this time....
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: widgets-patch
 Type: application/octet-stream
 Size: 2037 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071109/5cedd47f/attachment.obj 
 
 From marcus-sup@bar-coded.net  Fri Nov  9 10:33:35 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 09 Nov 2007 15:33:35 +0000
 Subject: [sup-talk] [PATCH] Pipe message/attachement to shell command
 Message-ID: <1194622205-sup-2949@tomsk>
 
 Hi -
 
 On the back of Eyal's patch heres a patch to pipe a message or
 attachment to a shell command via '|' in thread view mode.
 
 William, in the code it says that message.raw_message is slow but
 thats the only way I could do it without creating a string via
 each_raw_message_line. Is there a better way than this?
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: pipe-patch
 Type: application/octet-stream
 Size: 1467 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071109/4a0fc011/attachment.obj 
 
 From wmorgan-sup@masanjin.net  Fri Nov  9 13:46:52 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 09 Nov 2007 10:46:52 -0800
 Subject: [sup-talk] [PATCH] Natural language date searches
 In-Reply-To: <1193519205-sup-6445@tomsk>
 References: <1193436327-sup-5753@tomsk> <1193519205-sup-6445@tomsk>
 Message-ID: <1194633682-sup-962@south>
 
 Excerpts from Marcus Williams's message of Sat Oct 27 14:10:35 -0700 2007:
 > Attached is a tweaked patch so that you dont get an error if you pass
 > a query string that Chronic cant parse.
 
 Modified to skip parsing if Chronic isn't available, and applied.
 Thanks!
 
 Also made it accept one-word Chronic tokens without parentheses,
 although "after:yesterday" means "after yesterday noon", which maybe is
 not so useful...
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  9 14:04:43 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 09 Nov 2007 11:04:43 -0800
 Subject: [sup-talk] Crash on retrieving (many) mails
 In-Reply-To: <20071106095736.baa060ad.alexander.panek@brainsware.org>
 References: <20071106095736.baa060ad.alexander.panek@brainsware.org>
 Message-ID: <1194635022-sup-600@south>
 
 Excerpts from Alexander Panek's message of Tue Nov 06 00:57:36 -0800 2007:
 > This happened when I retrieved like mails from a few accounts from the
 > last four days (a few hundred mails, so to speak).
 > 
 > Trace:
 > > The problem was: 'undefined method `longname' for nil:NilClass' (error type NoMethodError)
 
 This should be fixed in SVN.
 
 > Apart from that, sup (or sup-sync, don't know) seems to be quite slow
 > when syncing a few accounts with lots of mails. Is that caused by the
 > mail servers or by sup itself?
 
 The message importation process is slow. There's no getting around it;
 it's the price you pay for searching being really quick.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  9 14:07:05 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 09 Nov 2007 11:07:05 -0800
 Subject: [sup-talk] Feature requests for more Googlish behaviour
 In-Reply-To: <1194358627-sup-630@timmy>
 References: <414a99f20711060552u1f35363ai46fad5719f66847c@mail.gmail.com>
 	<1194358083-sup-2587@tomsk> <1194358627-sup-630@timmy>
 Message-ID: <1194635118-sup-766@south>
 
 Excerpts from Eyal Oren's message of Tue Nov 06 06:19:29 -0800 2007:
 > Regarding autocomplete, I have problems when autocompleting contacts
 > whose name is something like "Doe, John". Maybe somebody is seeing
 > similar issues?
 > 
 > The name is autocompleted correctly, but the email is sent to two
 > addresses: doe at smtphost (which doesn't arrive) and to john.doe at ...
 > (which arrives correctly). Has anyone seen something similar?
 
 I think this should be fixed in SVN. (By, of course, writing my own
 55-line state machine to parse sequences of email addresses. Sigh.)
 
 The downside is that names with commas like "Doe, John" now require
 double-quotes in order to complete. 
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  9 14:09:17 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 09 Nov 2007 11:09:17 -0800
 Subject: [sup-talk] Feature requests for more Googlish behaviour
 In-Reply-To: <414a99f20711060552u1f35363ai46fad5719f66847c@mail.gmail.com>
 References: <414a99f20711060552u1f35363ai46fad5719f66847c@mail.gmail.com>
 Message-ID: <1194635257-sup-765@south>
 
 Excerpts from Tim Vaughan's message of Tue Nov 06 05:52:27 -0800 2007:
 > * Google-style contact autocompletion: typing a contact's name, or
 > part thereof, should provide autocomplete suggestions which can be
 > chosen before or after composing the message body.
 
 As Marcus points out, Sup has tab completion. Only does prefix matches,
 but it's the same basic functionality.
 
 > * Undo button: since I'm still learning the keyboard commands (and, I
 > think, because they're still in flux) an undo button would be useful
 > so I can un-tag an email mistakenly tagged as spam.
 
 Yes, this has been on the todo list for quite some time. One day!
 Currently you can "undo everything since I last pressed the $ key" by
 hitting @.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  9 14:10:05 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 09 Nov 2007 11:10:05 -0800
 Subject: [sup-talk] Exception from initial sup-sync
 In-Reply-To: <1194309716-sup-1684@south>
 References: <1194290667-sup-5900@silver> <1194309716-sup-1684@south>
 Message-ID: <1194635397-sup-79@south>
 
 Excerpts from William Morgan's message of Mon Nov 05 16:42:11 -0800 2007:
 > Yay, another RubyMail weirdness to work around!
 
 Should be fixed in SVN.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  9 14:13:45 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 09 Nov 2007 11:13:45 -0800
 Subject: [sup-talk] 'undefined method `longname' for nil:NilClass'
 	(error type NoMethodError)
 In-Reply-To: <47329B5D.4090907@gslab.com>
 References: <473186CB.8090307@gslab.com> <1194467915-sup-5870@south>
 	<47329B5D.4090907@gslab.com>
 Message-ID: <1194635480-sup-4853@south>
 
 Excerpts from Manish Sapariya's message of Wed Nov 07 21:15:09 -0800 2007:
 > Thanks for the fix. However looks like I have some weird mail in my
 > box.  The body and the charset both are nil. Is there any way I can
 > backtrack the offending message and find out whats the character set
 > and encoding used for that message?
 
 You have two options: insert some puts or logging statements in the code
 and try and figure out what the message id was (which then you can use
 to locate the message in the source), or convert the source into an mbox
 file (if it isn't already) and divide and conquer it until you find the
 offending message.
 
 Probably the first one is easier at this point.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov  9 14:17:21 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 09 Nov 2007 11:17:21 -0800
 Subject: [sup-talk] bugfix in thread-index-mode
 In-Reply-To: <1194536965-sup-2478@timmy>
 References: <1194536965-sup-2478@timmy>
 Message-ID: <1194635834-sup-4277@south>
 
 Excerpts from Eyal Oren's message of Thu Nov 08 07:51:30 -0800 2007:
 > Find attached tiny bugfix in thread-index-mode that caused sup (svn)
 > to crash when archiving/deleting messages in thread-mode.
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Fri Nov  9 15:29:58 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 09 Nov 2007 20:29:58 +0000
 Subject: [sup-talk] [PATCH] Natural language date searches
 In-Reply-To: <1194633682-sup-962@south>
 References: <1193436327-sup-5753@tomsk> <1193519205-sup-6445@tomsk>
 	<1194633682-sup-962@south>
 Message-ID: <1194639409-sup-6180@tomsk>
 
 On 9.11.2007, William Morgan wrote:
 > Modified to skip parsing if Chronic isn't available, and applied.
 > Thanks!
 > 
 > Also made it accept one-word Chronic tokens without parentheses,
 > although "after:yesterday" means "after yesterday noon", which maybe is
 > not so useful...
 
 I think I may have worked out how to fix that - change the parse
 method to be:
 
 realdate = Chronic.parse(datestr, :guess => false).begin
 
 If guess is set to false it looks like Chronic always returns a span
 and you can just select the beginning of the span.  At the moment I'm
 pretty sure you always want the beginning of the span in search
 situations. Certainly makes the single tokens more usable:
 
 irb(main):003:0> Chronic.parse("november", :guess => false).begin
 => Thu Nov 01 00:00:00 +0000 2007
 irb(main):004:0> Chronic.parse("monday", :guess => false).begin
 => Mon Nov 12 00:00:00 +0000 2007
 irb(main):005:0> Chronic.parse("24 hours ago", :guess => false).begin
 => Thu Nov 08 20:24:14 +0000 2007
 irb(main):006:0> Chronic.parse("sunday", :guess => false).begin
 => Sun Nov 11 00:00:00 +0000 2007
 irb(main):008:0> Chronic.parse("last sunday", :guess => false).begin
 => Sun Nov 04 00:00:00 +0000 2007
 irb(main):010:0> Chronic.parse("first monday of november", :guess => false).begin
 => Mon Nov 05 00:00:00 +0000 2007
 
 Marcus
 
 From marcus-sup@bar-coded.net  Fri Nov  9 15:44:08 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 09 Nov 2007 20:44:08 +0000
 Subject: [sup-talk] [PATCH] Natural language date searches
 In-Reply-To: <1194639409-sup-6180@tomsk>
 References: <1193436327-sup-5753@tomsk> <1193519205-sup-6445@tomsk>
 	<1194633682-sup-962@south> <1194639409-sup-6180@tomsk>
 Message-ID: <1194640984-sup-1658@tomsk>
 
 On 9.11.2007, Marcus Williams wrote:
 > On 9.11.2007, William Morgan wrote:
 > > Modified to skip parsing if Chronic isn't available, and applied.
 > > Thanks!
 > > 
 > > Also made it accept one-word Chronic tokens without parentheses,
 > > although "after:yesterday" means "after yesterday noon", which maybe is
 > > not so useful...
 > 
 > I think I may have worked out how to fix that - change the parse
 > method to be:
 > 
 > realdate = Chronic.parse(datestr, :guess => false).begin
 
 Mmmm - in fact it might be that you want to use .begin when you are
 searching "before", but .end when you are searching "after"
 
 That way searches like after:yesterday or after:(last monday) do what
 you expect. Patch attached 
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: search-patch
 Type: application/octet-stream
 Size: 1111 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071109/1631a80b/attachment.obj 
 
 From marcus-sup@bar-coded.net  Fri Nov  9 16:20:33 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 09 Nov 2007 21:20:33 +0000
 Subject: [sup-talk] [PATCH] Natural language date searches
 In-Reply-To: <1194640984-sup-1658@tomsk>
 References: <1193436327-sup-5753@tomsk> <1193519205-sup-6445@tomsk>
 	<1194633682-sup-962@south> <1194639409-sup-6180@tomsk>
 	<1194640984-sup-1658@tomsk>
 Message-ID: <1194643094-sup-4630@tomsk>
 
 On 9.11.2007, Marcus Williams wrote:
 > Mmmm - in fact it might be that you want to use .begin when you are
 > searching "before", but .end when you are searching "after"
 > 
 > That way searches like after:yesterday or after:(last monday) do what
 > you expect. Patch attached 
 
 ... on a roll here :) ... which means you can also have some sugar for
 single date search allowing "on:monday" or "on:(11th november)" saving
 you typing "after:(10th november) before:(12th november)".
 "on" probably isnt the best choice of words (on:november?) - so I
 added the alias "in" that does the same thing so you can type
 in:november.
 
 Updated patch attached. 
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: search-patch
 Type: application/octet-stream
 Size: 1480 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071109/075e087c/attachment.obj 
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 18:57:55 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 15:57:55 -0800
 Subject: [sup-talk] [BUG] Killed thread and unread count
 In-Reply-To: <6205b42d0711080222i119831cdl64edf4a3291a3078@mail.gmail.com>
 References: <6205b42d0711080222i119831cdl64edf4a3291a3078@mail.gmail.com>
 Message-ID: <1194824455-sup-3508@south>
 
 Hi Pierre,
 
 Excerpts from Pierre Baillet's message of Thu Nov 08 02:22:29 -0800 2007:
 > When an unread thread is killed, it is still marked as belonging to
 > +inbox and hence is accounted as unread by sup in the "Label list".
 > However, when displaying the +inbox labelled emails, this thread does
 > not appear. I think this behaviour may confuse the user. Shouldn't
 > killed threads be marked as read ?
 
 Excellent question. This is actually a symptom of a larger problem,
 which is that threading information is never explicitly stored in the
 Sup index, and that being killed is a thread-level, not a message-level,
 feature. (A killed thread is a thread in which at least one message has
 the label :killed.)
 
 So even if you marked a thread as unread before you killed it, the next
 time a message in that thread was received, it would count as a new
 message in the inbox, even though it never showed up.
 
 In order for unread messages in killed threads to not count as unread
 messages, Sup would have to maintain a list of all message-ids in all
 killed threads, and check new messages against that list before
 incrementing the unread message count. Not impossible, but substantially
 harder than just marking killed messages as unread. I've added it to the
 TODO.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 19:02:16 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 16:02:16 -0800
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194472330-sup-3257@lankhmar>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<20071107142527.GB1579@lenin.sovietwar.org>
 	<1194467985-sup-8861@south> <1194472330-sup-3257@lankhmar>
 Message-ID: <1194825592-sup-8870@south>
 
 Excerpts from Colin Bell's message of Wed Nov 07 13:56:21 -0800 2007:
 > You could replace \ with F for Filter or Ferret-index search if the \
 > character is too annoying. My first thought was to borrow L for Limit
 > from mutt but that doesn't work too well with labels :-)
 
 I'm actually quite liking \ now that I've gotten used to it. I'll add F.
 If you're tired of being bound by my capricious whims, patches to make
 keybindings configurable are welcome!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 19:11:58 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 16:11:58 -0800
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194469177-sup-3271@tomsk>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<20071107142527.GB1579@lenin.sovietwar.org>
 	<1194467985-sup-8861@south> <1194469177-sup-3271@tomsk>
 Message-ID: <1194826308-sup-2152@south>
 
 Excerpts from Marcus Williams's message of Wed Nov 07 13:05:58 -0800 2007:
 > Two things - can we make the prompts different to make it more obvious
 > and make a blank search not do anything?
 
 Done!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 19:13:43 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 16:13:43 -0800
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194427158-sup-6839@timmy>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<1194427158-sup-6839@timmy>
 Message-ID: <1194826336-sup-7538@south>
 
 Excerpts from Eyal Oren's message of Wed Nov 07 01:21:57 -0800 2007:
 > Btw, William, thanks for the search! It's great. But wouldn't you like
 > to search from the top instead of searching from cursor position? I
 > often want to use search instead of hitting cursor-up seven times.
 
 I'm following vi, emacs, and less precedent here. You can hit 1 or Home
 to jump up to the top. (Maybe that should be 0.)
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From chrisw@rice.edu  Sun Nov 11 19:33:19 2007
 From: chrisw@rice.edu (Christopher Warrington)
 Date: Sun, 11 Nov 2007 18:33:19 -0600
 Subject: [sup-talk] new in svn: in-buffer search
 In-Reply-To: <1194825592-sup-8870@south>
 References: <1194388505-sup-2866@south> <1194425266-sup-7682@tomsk>
 	<20071107142527.GB1579@lenin.sovietwar.org>
 	<1194467985-sup-8861@south> <1194472330-sup-3257@lankhmar>
 	<1194825592-sup-8870@south>
 Message-ID: <1194827554-sup-6010@chris-tablet>
 
 Excerpts from William Morgan's message of Sun Nov 11 18:02:16 -0600 2007:
 > I'm actually quite liking \ now that I've gotten used to it. I'll add F.
 > If you're tired of being bound by my capricious whims, patches to make
 > keybindings configurable are welcome!
 
 The "Refine Search" keybinding probably needs to be re-adjusted.
 Currently, it is '.', which is right next to / on a normal QWERTY
 keyboard.
 
 Right now, ']' is unbound and next to '\' on typical QWERTY keyboards.
 
 -- 
 Christopher Warrington <chrisw at rice.edu>
 
 From philsnow@gmail.com  Sun Nov 11 19:49:55 2007
 From: philsnow@gmail.com (Phil Snowberger)
 Date: Sun, 11 Nov 2007 19:49:55 -0500
 Subject: [sup-talk] ruby/sup causing lots of wakeups-from-idle
 Message-ID: <6ab4c98f0711111649o3e06c24aq73750c99bc4af248@mail.gmail.com>
 
 I was wondering if anybody else has a problem with sup/ruby causing
 lots of wakeups-from-idle?  The following line comes from the output
 of powertop on my thinkpad:
 
 ...
   20.6% ( 94.8)              ruby : do_nanosleep (hrtimer_wakeup)
 ...
 
 That is, there are ~94.8 wakeups-from-idle per second occuring because
 ruby is do_nanosleep'ing a lot.  Is there any workaround for this?
 Cursory searching seems to indicate that lots of wakeups can be caused
 by doing usleep()s instead of select()/poll().  I'm trying to save as
 much battery power as possible, and I currently leave sup off until I
 want to check my email, which introduces startup time, etc.
 
 I could just run it on some other host and access it with ssh, but for
 a few reasons (mostly not wanting to do X forwarding), I'd like to try
 getting ruby/sup to behave a little better.
 
 Thanks,
 --Phil
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 19:48:39 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 16:48:39 -0800
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <1194518450-sup-4792@tomsk>
 References: <1194518450-sup-4792@tomsk>
 Message-ID: <1194827264-sup-5774@south>
 
 Hi Marcus,
 
 Excerpts from Marcus Williams's message of Thu Nov 08 02:44:44 -0800 2007:
 > This patch adds two new hooks that allow you to set the title bar of a
 > terminal (default is no title, to support non-terminal users) and the
 > status bar of sup (default is standard status bar string).
 
 This patch actually has a problem, which you can see if you try and use
 "say" from within one of those hooks, or if you insert an error into the
 hook code.
 
 The problem is that the hooks are executed from draw_status, which is
 executed within the context of a lock on Ncurses.mutex.
 BufferManager#flash (which is triggered by both a call to #say and an
 error) cannot be called within that lock or a double-lock exception
 occurs.
 
 So, either Ncurses.mutex needs to be a reentrant lock (I have played
 around with this but haven't yet been able to get it to work), or the
 code that runs these hooks needs to run outside of the lock (which takes
 place in BufferManager#draw_screen and #completely_redraw_screen).
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From alec@thened.net  Sun Nov 11 19:48:05 2007
 From: alec@thened.net (Alec Berryman)
 Date: Sun, 11 Nov 2007 19:48:05 -0500
 Subject: [sup-talk] two crashes on reply
 Message-ID: <20071112004805.GA25086@thened.net>
 
 I'm new to sup and running it from svn (r689), and get not one but two
 crashes while trying to reply.
 
 I sent a message to myself, then tried to reply to it by hitting 'r'
 from the message list buffer I get when I start up.  It popped up a
 buffer entitled "Customized reply" with the From line highlighted.  All
 the fields - From, To, Cc, Bcc, Subject - were blank.  From here I can
 trigger two crashes.
 
 First, if I press enter, my editor pops up.  If I change the file's
 contents, save, and exit, I get the following:
 
 [Sun Nov 11 19:33:29 -0500 2007] locking /home/alec/.sup/lock...
 [Sun Nov 11 19:33:29 -0500 2007] loading index...
 [Sun Nov 11 19:33:29 -0500 2007] loaded index of 829 messages
 [Sun Nov 11 19:33:29 -0500 2007] starting curses
 [Sun Nov 11 19:35:47 -0500 2007] stopped cursing
 [Sun Nov 11 19:35:47 -0500 2007] oh crap, an exception
 [Sun Nov 11 19:35:47 -0500 2007] unlocking /home/alec/.sup/lock...
 ----------------------------------------------------------------
 I'm very sorry, but it seems that an error occurred in Sup.
 Please accept my sincere apologies. If you don't mind, please
 send the backtrace below and a brief report of the circumstances
 to sup-talk at rubyforge dot orgs so that I might address this
 problem. Thank you!
 
 Sincerely,
 William
 ----------------------------------------------------------------
 
 The problem was: 'undefined method `size' for nil:NilClass' (error type NoMethodError)
 A backtrace follows:
 ./lib/sup/modes/reply-mode.rb:113:in `handle_new_text': undefined method `size' for nil:NilClass (NoMethodError)
     from ./lib/sup/modes/edit-message-mode.rb:94:in `edit_message'
     from ./lib/sup/mode.rb:54:in `send'
     from ./lib/sup/mode.rb:54:in `handle_input'
     from ./lib/sup/buffer.rb:203:in `handle_input'
     from bin/sup:210
 
 If I don't change the contents, everything's fine.
 
 The second crash comes if I try and use the reply-mode keybindings to
 change the To field by pressing 't'.  I get this:
 
 [Sun Nov 11 19:43:36 -0500 2007] starting curses
 [Sun Nov 11 19:45:07 -0500 2007] stopped cursing
 [Sun Nov 11 19:45:07 -0500 2007] oh crap, an exception
 [Sun Nov 11 19:45:07 -0500 2007] unlocking /home/alec/.sup/lock...
 ----------------------------------------------------------------
 I'm very sorry, but it seems that an error occurred in Sup.
 Please accept my sincere apologies. If you don't mind, please
 send the backtrace below and a brief report of the circumstances
 to sup-talk at rubyforge dot orgs so that I might address this
 problem. Thank you!
 
 Sincerely,
 William
 ----------------------------------------------------------------
 
 The problem was: 'undefined method `join' for nil:NilClass' (error type NoMethodError)
 A backtrace follows:
 ./lib/sup/modes/edit-message-mode.rb:306:in `edit_field': undefined method `join' for nil:NilClass (NoMethodError)
     from ./lib/sup/modes/reply-mode.rb:125:in `edit_field'
     from ./lib/sup/modes/edit-message-mode.rb:73:in `edit_to'
     from ./lib/sup/mode.rb:54:in `send'
     from ./lib/sup/mode.rb:54:in `handle_input'
     from ./lib/sup/buffer.rb:203:in `handle_input'
     from bin/sup:210
 
 I get similar errors if I try to change CC:, but not if I try to change
 the subject.
 
 I'm also not sure why sup isn't filling in the To and Subject fields.
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 20:24:37 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 17:24:37 -0800
 Subject: [sup-talk] ruby/sup causing lots of wakeups-from-idle
 In-Reply-To: <6ab4c98f0711111649o3e06c24aq73750c99bc4af248@mail.gmail.com>
 References: <6ab4c98f0711111649o3e06c24aq73750c99bc4af248@mail.gmail.com>
 Message-ID: <1194830575-sup-5874@south>
 
 Excerpts from Phil Snowberger's message of Sun Nov 11 16:49:55 -0800 2007:
 > I was wondering if anybody else has a problem with sup/ruby causing
 > lots of wakeups-from-idle?
 
 Does this happen with other multithreaded Ruby apps? Sup uses select()
 for input, and the only persistent threads have multi-second sleep
 times. But I have no idea how that translates down to the OS level, as
 Ruby does its own threading.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 23:03:47 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 20:03:47 -0800
 Subject: [sup-talk] Sup sources question
 In-Reply-To: <1194520465-sup-413@tomsk>
 References: <1194520465-sup-413@tomsk>
 Message-ID: <1194840179-sup-2716@south>
 
 Excerpts from Marcus Williams's message of Thu Nov 08 03:18:51 -0800 2007:
 > What I thought I'd do is sup-dump, sup-sync everything again and then
 > restore my settings. Then I remembered I'd noticed that you have a
 > source_id in the ferret index, so I can search for messages marked
 > with that source_id and add the label in manually.
 
 Just curious if you managed to make this work. I sent an example to the
 list a few weeks back about using console.sh to do just this sort of
 thing.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sun Nov 11 23:13:40 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sun, 11 Nov 2007 20:13:40 -0800
 Subject: [sup-talk] patch: execute shell command
 In-Reply-To: <1194536747-sup-4081@timmy>
 References: <1194536747-sup-4081@timmy>
 Message-ID: <1194840554-sup-9310@south>
 
 Hi Eyal,
 
 Excerpts from Eyal Oren's message of Thu Nov 08 07:47:30 -0800 2007:
 > Find attached a simple patch (against svn head) to execute a shell
 > command using '!' (as in vi or mutt). It requires the 'session' gem:
 > if you want to get rid of that dependency you can just capture the
 > output using >& etc.
 
 I like this functionality but the session gem seems like it's overkill
 here. Is there a reason to use it instead of just something like
   output = `#{cmd}`
 ? I'm not that familiar with the gem, so maybe there is.
 
 Also I think the code for this should be in bin/sup rather than in
 scroll-mode.rb, since, unless I'm mistaken, it's not specific to
 scroll-mode at all.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From eyal.oren@deri.org  Mon Nov 12 00:05:31 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Mon, 12 Nov 2007 14:05:31 +0900
 Subject: [sup-talk] patch: execute shell command
 In-Reply-To: <1194840554-sup-9310@south>
 References: <1194536747-sup-4081@timmy> <1194840554-sup-9310@south>
 Message-ID: <1194843828-sup-7014@timmy>
 
 Excerpts from William Morgan's message of Mon Nov 12 13:13:40 +0900 2007:
 > I like this functionality but the session gem seems like it's overkill
 > here. Is there a reason to use it instead of just something like
 >   output = `#{cmd}`
 I also wanted to catch error output, to find out if an unexisting command was 
 invoked, and I didn't know how to do that with ``?
 
 > Also I think the code for this should be in bin/sup rather than in
 > scroll-mode.rb, since, unless I'm mistaken, it's not specific to
 > scroll-mode at all.
 Agree. Wasn't sure where to put it, actually.
 
 -- 
  -eyal
 
 From eyal.oren@deri.org  Mon Nov 12 00:07:59 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Mon, 12 Nov 2007 14:07:59 +0900
 Subject: [sup-talk] starting with threads opened vs. closed in
 	thread-view-mode
 Message-ID: <1194843956-sup-1110@timmy>
 
 Hi, 
 
 I find myself always hitting 'h' in thread-view-mode to read emails, because I 
 don't care for the header details and rather read the email without abstraction. 
 Would there be a way to make the fact that headers start opened/closed 
 configurable? Or is there a hook I could use just to close the header before 
 displaying the thread? 
 
 -- 
  -eyal
 
 From marcus-sup@bar-coded.net  Mon Nov 12 04:23:59 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 12 Nov 2007 09:23:59 +0000
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <1194827264-sup-5774@south>
 References: <1194518450-sup-4792@tomsk> <1194827264-sup-5774@south>
 Message-ID: <1194859333-sup-9479@tomsk>
 
 On 12.11.2007, William Morgan wrote:
 > So, either Ncurses.mutex needs to be a reentrant lock (I have played
 > around with this but haven't yet been able to get it to work), or the
 > code that runs these hooks needs to run outside of the lock (which takes
 > place in BufferManager#draw_screen and #completely_redraw_screen).
 
 Presumably after the unlock, rather than before the lock on the mutex
 if the stuff is redrawing? I'll resubmit later today.
 
 Marcus
 
 From marcus-sup@bar-coded.net  Mon Nov 12 08:29:30 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 12 Nov 2007 13:29:30 +0000
 Subject: [sup-talk] Sup sources question
 In-Reply-To: <1194840179-sup-2716@south>
 References: <1194520465-sup-413@tomsk> <1194840179-sup-2716@south>
 Message-ID: <1194873885-sup-8903@tomsk>
 
 On 12.11.2007, William Morgan wrote:
 > Just curious if you managed to make this work. I sent an example to the
 > list a few weeks back about using console.sh to do just this sort of
 > thing.
 
 Yep - cleaned up all of my sources without having to resync. I wrote a
 little wrapper tool to do it, might clean up that and post it some
 time. For info, the way I did it was almost exactly the way you
 suggested (to be run in console.sh):
 
 # remove inbox label and add sent label on all messages coming from a
 # single source (id is 3)
 Index.ferret.search_each("source_id:3", :limit => :all) do |id, score|
   m = Index.build_message id
   puts "Modifying #{m.id}\t[#{m.labels.join ','}]"
   m.labels.uniq!
   m.labels -= [:inbox] unless m.labels.include? :starred
   m.labels += [:sent]
   puts ".......to #{m.id}\t[#{m.labels.join ','}]"
   Index.sync_message m
 end
 Index.ferret.optimize
 
 I did notice some messages had a lot of repeated labels. Not sure why,
 but calling uniq! fixed it.
 
 Marcus
 
 From marcus-sup@bar-coded.net  Mon Nov 12 10:35:34 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 12 Nov 2007 15:35:34 +0000
 Subject: [sup-talk] patch: execute shell command
 In-Reply-To: <1194843828-sup-7014@timmy>
 References: <1194536747-sup-4081@timmy> <1194840554-sup-9310@south>
 	<1194843828-sup-7014@timmy>
 Message-ID: <1194881637-sup-5906@tomsk>
 
 On 12.11.2007, Eyal Oren wrote:
 > > I like this functionality but the session gem seems like it's overkill
 > > here. Is there a reason to use it instead of just something like
 > >   output = `#{cmd}`
 > I also wanted to catch error output, to find out if an unexisting command was 
 > invoked, and I didn't know how to do that with ``?
 
 Shouldnt this be possible with open3? The only problem is that open3
 is unix only (in std ruby). I think there is a win32 open3 gem though.
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 11:59:35 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 08:59:35 -0800
 Subject: [sup-talk] patch: execute shell command
 In-Reply-To: <1194881637-sup-5906@tomsk>
 References: <1194536747-sup-4081@timmy> <1194840554-sup-9310@south>
 	<1194843828-sup-7014@timmy> <1194881637-sup-5906@tomsk>
 Message-ID: <1194886486-sup-6107@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 12 07:35:34 -0800 2007:
 > Shouldnt this be possible with open3? The only problem is that open3
 > is unix only (in std ruby). I think there is a win32 open3 gem though.
 
 It looks like Session doesn't work on windows, anyways:
 http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/173910
 
 So how's this for a plan:
  1. First version just uses open3.
  2. When windows people complain, add code to detect the platform and
     load in win32-open3 accordingly.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 12:02:13 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 09:02:13 -0800
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <1194859333-sup-9479@tomsk>
 References: <1194518450-sup-4792@tomsk> <1194827264-sup-5774@south>
 	<1194859333-sup-9479@tomsk>
 Message-ID: <1194886848-sup-8236@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 12 01:23:59 -0800 2007:
 > Presumably after the unlock, rather than before the lock on the mutex
 > if the stuff is redrawing? I'll resubmit later today.
 
 Actually I think the best would be to call the hooks before the lock,
 and pass in the values to actually be drawn into the locked code, so
 that the draw happens within the lock. It means adding a couple
 arguments to some of these methods, probably.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 12:20:44 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 09:20:44 -0800
 Subject: [sup-talk] Sup sources question
 In-Reply-To: <1194873885-sup-8903@tomsk>
 References: <1194520465-sup-413@tomsk> <1194840179-sup-2716@south>
 	<1194873885-sup-8903@tomsk>
 Message-ID: <1194888016-sup-9385@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 12 05:29:30 -0800 2007:
 > I did notice some messages had a lot of repeated labels. Not sure why,
 > but calling uniq! fixed it.
 
 Interesting. Well, I'll throw a uniq into the index saving code for good
 measure. 
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 12:55:54 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 09:55:54 -0800
 Subject: [sup-talk] [PATCH] Pipe message/attachement to shell command
 In-Reply-To: <1194622205-sup-2949@tomsk>
 References: <1194622205-sup-2949@tomsk>
 Message-ID: <1194889791-sup-3292@south>
 
 Excerpts from Marcus Williams's message of Fri Nov 09 07:33:35 -0800 2007:
 > William, in the code it says that message.raw_message is slow but
 > thats the only way I could do it without creating a string via
 > each_raw_message_line. Is there a better way than this?
 
 Hey, this is another reason to use open3 instead of Session. You need to
 have access to use the stdin filehandle in order to use
 #each_raw_message_line. (There's no speed difference for IMAP, but for
 Maildir and mbox, it's quite large. Maildir could be sped up, but mbox
 fundamentally not.)
 
 BTW, that first argument to BufferManager#ask should ideally be a symbol
 of some sort rather than nil. History is shared amongst all invocations
 with the same symbol.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 13:01:43 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 10:01:43 -0800
 Subject: [sup-talk] [PATCH] Natural language date searches
 In-Reply-To: <1194643094-sup-4630@tomsk>
 References: <1193436327-sup-5753@tomsk> <1193519205-sup-6445@tomsk>
 	<1194633682-sup-962@south> <1194639409-sup-6180@tomsk>
 	<1194640984-sup-1658@tomsk> <1194643094-sup-4630@tomsk>
 Message-ID: <1194890483-sup-9349@south>
 
 Excerpts from Marcus Williams's message of Fri Nov 09 13:20:33 -0800 2007:
 > ... on a roll here :) ... which means you can also have some sugar for
 > single date search allowing "on:monday" or "on:(11th november)" saving
 > you typing "after:(10th november) before:(12th november)".  "on"
 > probably isnt the best choice of words (on:november?) - so I added the
 > alias "in" that does the same thing so you can type in:november.
 
 This is great stuff. Thanks, Marcus. Applied!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 13:23:40 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 10:23:40 -0800
 Subject: [sup-talk] two crashes on reply
 In-Reply-To: <20071112004805.GA25086@thened.net>
 References: <20071112004805.GA25086@thened.net>
 Message-ID: <1194891731-sup-468@south>
 
 Hi Alec,
 
 Excerpts from Alec Berryman's message of Sun Nov 11 16:48:05 -0800 2007:
 > I sent a message to myself, then tried to reply to it by hitting 'r'
 > from the message list buffer I get when I start up.  It popped up a
 > buffer entitled "Customized reply" with the From line highlighted.  All
 > the fields - From, To, Cc, Bcc, Subject - were blank.  From here I can
 > trigger two crashes.
 
 This is quite strange. The From field should never be blank. (And that's
 what triggers the other crashes, I believe.) Can you post your
 config.yaml?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Mon Nov 12 17:06:01 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 12 Nov 2007 22:06:01 +0000
 Subject: [sup-talk] [PATCH] Pipe message/attachement to shell command
 In-Reply-To: <1194889791-sup-3292@south>
 References: <1194622205-sup-2949@tomsk> <1194889791-sup-3292@south>
 Message-ID: <1194905067-sup-4236@tomsk>
 
 On 12.11.2007, William Morgan wrote:
 > Hey, this is another reason to use open3 instead of Session. You need to
 > have access to use the stdin filehandle in order to use
 > #each_raw_message_line. (There's no speed difference for IMAP, but for
 > Maildir and mbox, it's quite large. Maildir could be sped up, but mbox
 > fundamentally not.)
 
 Attached is a patch for the shell/pipe code so that it uses open3.
 Just realised I've not moved shell method into sup in this patch, but
 its a start!
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: open3-diffs
 Type: application/octet-stream
 Size: 3068 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071112/0add038a/attachment.obj 
 
 From marcus-sup@bar-coded.net  Mon Nov 12 17:07:17 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 12 Nov 2007 22:07:17 +0000
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <1194886848-sup-8236@south>
 References: <1194518450-sup-4792@tomsk> <1194827264-sup-5774@south>
 	<1194859333-sup-9479@tomsk> <1194886848-sup-8236@south>
 Message-ID: <1194905177-sup-2828@tomsk>
 
 On 12.11.2007, William Morgan wrote:
 > Actually I think the best would be to call the hooks before the lock,
 > and pass in the values to actually be drawn into the locked code, so
 > that the draw happens within the lock. It means adding a couple
 > arguments to some of these methods, probably.
 
 Attached is a patch for this. Not sure if this is the best way of
 doing it as I've used accessors on buffer class rather than passing
 args.
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: widget-diffs
 Type: application/octet-stream
 Size: 2692 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071112/a834f4e4/attachment.obj 
 
 From marcus-sup@bar-coded.net  Mon Nov 12 17:09:19 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 12 Nov 2007 22:09:19 +0000
 Subject: [sup-talk] [PATCH] Bugfix for message counts
 Message-ID: <1194905311-sup-2362@tomsk>
 
 Simple bugfix attached for fixing message counts when you're using the
 filter hooks.
 
 Marcus
 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: bugfix-diffs
 Type: application/octet-stream
 Size: 518 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071112/d34abf9e/attachment.obj 
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 18:49:40 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 15:49:40 -0800
 Subject: [sup-talk] starting with threads opened vs. closed in
 	thread-view-mode
 In-Reply-To: <1194843956-sup-1110@timmy>
 References: <1194843956-sup-1110@timmy>
 Message-ID: <1194911317-sup-4000@south>
 
 Excerpts from Eyal Oren's message of Sun Nov 11 21:07:59 -0800 2007:
 > I find myself always hitting 'h' in thread-view-mode to read emails,
 > because I don't care for the header details and rather read the email
 > without abstraction.  Would there be a way to make the fact that
 > headers start opened/closed configurable? Or is there a hook I could
 > use just to close the header before displaying the thread? 
 
 Seems a little excessive for a hook, especially since I can't think of
 anything else related that would really be tweakable. Maybe a config
 option would be a reasonable choice here.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 18:54:03 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 15:54:03 -0800
 Subject: [sup-talk] [PATCH] Bugfix for message counts
 In-Reply-To: <1194905311-sup-2362@tomsk>
 References: <1194905311-sup-2362@tomsk>
 Message-ID: <1194911631-sup-8094@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 12 14:09:19 -0800 2007:
 > Simple bugfix attached for fixing message counts when you're using the
 > filter hooks.
 
 Applied, thanks.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 12 19:13:03 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 12 Nov 2007 16:13:03 -0800
 Subject: [sup-talk] new user of sup
 In-Reply-To: <20071031180510.GA7449@lenin.sovietwar.org>
 References: <4728B67A.7020604@gslab.com>
 	<20071031180510.GA7449@lenin.sovietwar.org>
 Message-ID: <1194912687-sup-4696@south>
 
 Excerpts from vasudeva's message of Wed Oct 31 11:05:10 -0700 2007:
 > I had an issue like this, and found it to be related somehow to the
 > following lines being present in my ~/.sup/sources.yaml...
 > 
 > - !masanjin.net,2006-10-01/Redwood/SentLoader
 >   cur_offset: 29245
 > - !masanjin.net,2006-10-01/Redwood/DraftLoader
 >   cur_offset: 4
 > 
 > It seems if I snipped those out, then sup-add would actually add all
 > the sources I told it, not simply the final one. That is, if those
 > lines were present, sup-add seemed to overwrite any recently-added
 > source with the next source I'd add. (The two lines get generated
 > and replaced by sup at some point.)
 
 I'm not able to reproduce this. Does the same behavior happen now? If
 so, can you post a source.yaml and some commands that exhibit the
 overwriting?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From alec@thened.net  Mon Nov 12 19:16:37 2007
 From: alec@thened.net (Alec Berryman)
 Date: Mon, 12 Nov 2007 19:16:37 -0500
 Subject: [sup-talk] two crashes on reply
 In-Reply-To: <1194891731-sup-468@south>
 References: <20071112004805.GA25086@thened.net> <1194891731-sup-468@south>
 Message-ID: <20071113001636.GA6682@thened.net>
 
 William Morgan on 2007-11-12 10:23:40 -0800:
 
 > Hi Alec,
 >
 > Excerpts from Alec Berryman's message of Sun Nov 11 16:48:05 -0800 2007:
 > > I sent a message to myself, then tried to reply to it by hitting 'r'
 > > from the message list buffer I get when I start up.  It popped up a
 > > buffer entitled "Customized reply" with the From line highlighted.  All
 > > the fields - From, To, Cc, Bcc, Subject - were blank.  From here I can
 > > trigger two crashes.
 >
 > This is quite strange. The From field should never be blank. (And that's
 > what triggers the other crashes, I believe.) Can you post your
 > config.yaml?
 
 It's inlined below; I assume sup-config made it and haven't touched it since
 except to edit my alternative address here.  When I sent the original message
 to myself, the From field was filled in correctly.  Additionally, this only
 seems to happen on messages I send myself; I tried to reply to another message
 and it seemed to work fine.
 
 ---
 :ask_for_subject: true
 :confirm_no_attachments: true
 :thread_by_subject: false
 :confirm_top_posting: true
 :edit_signature: false
 :ask_for_cc: true
 :accounts:
   :default:
     :sendmail: /usr/sbin/sendmail -oem -ti
     :alternates:
     - aberryman at otheraddress.com
     :name: Alec Berryman
     :signature: /home/alec/.signature
     :email: alec at thened.net
 :editor: vim
 :ask_for_bcc: false
 
 
 From brenocon@gmail.com  Mon Nov 12 20:56:22 2007
 From: brenocon@gmail.com (Brendan O'Connor)
 Date: Mon, 12 Nov 2007 17:56:22 -0800
 Subject: [sup-talk] Excluding a certain name and/or email from being
 	auto-added to people.txt?
 Message-ID: <1194918770-sup-9170@bdawg>
 
 I feel lame for asking a question without a patch fixing it and adding 5 new
 features :) but was wondering: is there a way to exclude a particular email
 address from having names being added to it?  i have emails from a bug tracking
 system (JIRA) that puts various person names but always with the same email
 address <issues at bla.com> which ends up getting saved in ~/.sup/people.txt and
 then sup displays all emails from issues at bla.com based on the people.txt name
 instead of the individual names on the emails.  I think being able to say
 "never auto-save for emails matching a certain regex" is the right solution but
 not sure...
 
 From sup-talk@gurski.org  Mon Nov 12 22:29:11 2007
 From: sup-talk@gurski.org (Michael Gurski)
 Date: Mon, 12 Nov 2007 22:29:11 -0500
 Subject: [sup-talk] Excluding a certain name and/or email from being
 	auto-added to people.txt?
 In-Reply-To: <1194918770-sup-9170@bdawg>
 References: <1194918770-sup-9170@bdawg>
 Message-ID: <1194923879-sup-1418@ln>
 
 Excerpts from Brendan O'Connor's message of Mon Nov 12 20:56:22 -0500 2007:
 > I feel lame for asking a question without a patch fixing it and adding 5 new
 > features :) but was wondering: is there a way to exclude a particular email
 > address from having names being added to it?  i have emails from a bug tracking
 > system (JIRA) that puts various person names but always with the same email
 > address <issues at bla.com> which ends up getting saved in ~/.sup/people.txt and
 > then sup displays all emails from issues at bla.com based on the people.txt name
 > instead of the individual names on the emails.  I think being able to say
 > "never auto-save for emails matching a certain regex" is the right solution but
 > not sure...
 
 I'd have to agree.  Certain sites like linkedin.com, as well as some
 web-to-mailinglist gateways (notably the ruby on rails list) do the
 same thing.  Worse, the gateways periodically get spam that isn't
 trapped anywhere, and so now all mail from that address shows up as
 being from <reallylongspamtext> <reallylongspamtext>.  Since sup's the
 only client I've used that caches the name fields, this is the first
 I've run into this particular problem...
 
 
 -- 
 Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
 1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
 1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
 4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
 Views expressed by the host do not reflect the staff, management or sponsors.
 
 
 From chrisw@rice.edu  Mon Nov 12 23:30:13 2007
 From: chrisw@rice.edu (Christopher Warrington)
 Date: Mon, 12 Nov 2007 22:30:13 -0600
 Subject: [sup-talk] Ferret Errors
 In-Reply-To: <1193970558-sup-3687@south>
 References: <1193693839-sup-8512@chris-tablet> <1193970558-sup-3687@south>
 Message-ID: <1194928185-sup-2189@chris-tablet>
 
 (So, this has been sitting in my drafts folder FOREVER...)
 
 Excerpts from William Morgan's message of Thu Nov 01 21:32:19 -0500 2007:
 > Yeah, the typical completely incomprehensible Ferret error message.
 > Current known things that make Ferret generate scary messages:
 > - running more than one process touching the index at the same time (Sup
 >   locks the index now so this shouldn't happen unless you are being
 >   particularly devious)
 Perhaps... I'm not explicitly running two copies of sup, nor am I
 running sup and another sup- tool at the same time. I'm just composing a
 message.
 
 > - having too many open filehandles, including too many "usual" mbox
 >   sources at the moment until I fix the mbox code not to keep
 >   filehandles open all the time.
 I don't think so.
 
 > - running out of disk space.
 Nope.
 
 > Could it have been any of those?
 
 If MIGHT be the first. It just happened again. I think that it only
 happens when I am composing a message and, during a background poll for
 new messages, sup finds one.
 
 This might not even be the problem, but, it seems to me, that the editor
 does not need to have sup's open files handles.
 
 -- 
 Christopher Warrington <chrisw at rice.edu>
 
 From marcus-sup@bar-coded.net  Tue Nov 13 06:58:27 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 13 Nov 2007 11:58:27 +0000
 Subject: [sup-talk] [PATCH] Pipe message/attachement to shell command
 In-Reply-To: <1194905067-sup-4236@tomsk>
 References: <1194622205-sup-2949@tomsk> <1194889791-sup-3292@south>
 	<1194905067-sup-4236@tomsk>
 Message-ID: <1194955037-sup-614@tomsk>
 
 On 12.11.2007, Marcus Williams wrote:
 > Attached is a patch for the shell/pipe code so that it uses open3.
 > Just realised I've not moved shell method into sup in this patch, but
 > its a start!
 
 Mmmm. Seem to be having some buffering problems with open3 on slightly
 longer messages. The pipe stuff blocks because of it.
 
 Will have to resubmit when I figure it out.
 
 Marcus
 
 From eyal.oren@deri.org  Tue Nov 13 10:12:44 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Wed, 14 Nov 2007 00:12:44 +0900
 Subject: [sup-talk] joining threads manually
 Message-ID: <1194966571-sup-6200@timmy>
 
 Hi,
 
 Due to other people's broken email clients, threads are sometimes not properly 
 connected (eg. their client doesn't use the in-reply-to header).  Mutt allows 
 you to manually join such broken threads by first tagging the child message and
 then going to the parent message and pressing '&'. 
 
 Would it be possible to do this in sup? Given a pointer to some places in the 
 code, I could try to hack something.
 
 PS: Mutt also allows you to break threads ('#') but for me that's less useful.
 
  -eyal
 
 From sup-talk@gurski.org  Tue Nov 13 11:42:40 2007
 From: sup-talk@gurski.org (Michael Gurski)
 Date: Tue, 13 Nov 2007 11:42:40 -0500
 Subject: [sup-talk] joining threads manually
 In-Reply-To: <1194966571-sup-6200@timmy>
 References: <1194966571-sup-6200@timmy>
 Message-ID: <1194970669-sup-1917@ln>
 
 Excerpts from eyal.oren's message of Tue Nov 13 10:12:44 -0500 2007:
 > PS: Mutt also allows you to break threads ('#') but for me that's less useful.
 
 You must have better-trained people on mailing lists you frequent. :-(
 There are several I'm on that have subscribers that keep believing
 that "reply" means "start a completely new, distinct, unrelated
 topic".  Which was fine back in the pine days and no one really
 threading anything.  These days, it's...painful.
 
 If no one else wants to tackle either of these, I could probably give
 it a shot at some point.  No promises though, as I never seem to have
 that "time" thing that I keep hearing about.
 
 -- 
 Michael A. Gurski (opt. [first].)[last]@pobox.com  http://www.pobox.com/~[last]
 1024R/39B5BADD PGP: 34 93 A9 94 B1 59 48 B7  17 57 1E 4E 62 56 45 70
 1024D/1166213E GPG: 628F 37A4 62AF 1475 45DB  AD81 ADC9 E606 1166 213E
 4096R/C0B4F04B GPG: 5B3E 75D7 43CF CF34 4042  7788 1DCE B5EE C0B4 F04B
 Views expressed by the host do not reflect the staff, management or sponsors.
 
 
 From wmorgan-sup@masanjin.net  Tue Nov 13 12:12:54 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 13 Nov 2007 09:12:54 -0800
 Subject: [sup-talk] joining threads manually
 In-Reply-To: <1194966571-sup-6200@timmy>
 References: <1194966571-sup-6200@timmy>
 Message-ID: <1194973525-sup-1660@south>
 
 Excerpts from Eyal Oren's message of Tue Nov 13 07:12:44 -0800 2007:
 > Due to other people's broken email clients, threads are sometimes not
 > properly connected (eg. their client doesn't use the in-reply-to
 > header).  Mutt allows you to manually join such broken threads by
 > first tagging the child message and then going to the parent message
 > and pressing '&'. 
 
 There is an option in config.yaml to also thread by subject, although I
 haven't tested it for quite a while. But that has its own problems, so I
 leave it off by default. The best solution, of course, is to go to where
 those people live and punish them until they switch to a reasonable
 email client.
 
 > Would it be possible to do this in sup? Given a pointer to some places
 > in the code, I could try to hack something.
 
 Here's what I would try. In thread-index-mode, given n>1 tagged threads,
 you simply want to add the message-id of the root message of the
 earliest thread to the refs field of the root messages of all other
 threads. (You'll have to make refs a r/w attribute of message instead of
 r/o.) That will thread them all at the top level, which probably is the
 most reasonable thing to do.
 
 Then you'll need to update thread-index-mode's Threadset to handle the
 new structure. It might be enough to call ThreadSet#link (which you'll
 have to make public). Or you can first delete the messages from the
 threadset with #remove, munge the refs as above, and re-add them with
 #add_message. This step will require a little experimentation.
 
 Once the threadset's in place, you can call the ThreadIndexMode#update
 to regenerate the display.
 
 > PS: Mutt also allows you to break threads ('#') but for me that's less
 > useful.
 
 If you can accomplish the above, then this will be very similar,
 although it will belong in thread-view-mode.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From vasudeva@linkswarm.com  Tue Nov 13 13:41:29 2007
 From: vasudeva@linkswarm.com (vasudeva)
 Date: Tue, 13 Nov 2007 13:41:29 -0500
 Subject: [sup-talk] new user of sup
 In-Reply-To: <1194912687-sup-4696@south>
 References: <4728B67A.7020604@gslab.com>
 	<20071031180510.GA7449@lenin.sovietwar.org>
 	<1194912687-sup-4696@south>
 Message-ID: <20071113184129.GA11753@lenin.sovietwar.org>
 
 * on 11-12-07, William Morgan wrote:
 > Excerpts from vasudeva's message of Wed Oct 31 11:05:10 -0700 2007:
 > > I had an issue like this, and found it to be related somehow to the
 > > following lines being present in my ~/.sup/sources.yaml...
 > > 
 > > - !masanjin.net,2006-10-01/Redwood/SentLoader
 > >   cur_offset: 29245
 > > - !masanjin.net,2006-10-01/Redwood/DraftLoader
 > >   cur_offset: 4
 > > 
 > > It seems if I snipped those out, then sup-add would actually add all
 > > the sources I told it, not simply the final one. That is, if those
 > > lines were present, sup-add seemed to overwrite any recently-added
 > > source with the next source I'd add. (The two lines get generated
 > > and replaced by sup at some point.)
 > 
 > I'm not able to reproduce this. Does the same behavior happen now? If
 > so, can you post a source.yaml and some commands that exhibit the
 > overwriting?
 
 I've just svn updated sup, and I can reproduce this.
 
 I'm using the same sup-add command I documented in the wiki under
 AddingSources...
 
 http://sup.rubyforge.org/wiki/wiki.pl?AddingSources
 
 to wit...
 
 for i in $(find muttmail -type f); do ruby -I lib -w sup/trunk/bin/sup-add  -l `basename $i` -a mbox://`pwd`/$i; done
 
 Here's my ~/.sup/sources.yaml before I start...
 
 ***
 cat ~/.sup/sources.yaml
 ---
 - !masanjin.net,2006-10-01/Redwood/MBox/Loader
   uri: mbox:///home/vasudeva/muttmail/projects/amsterdam
   cur_offset:
   usual: true
   archived: true
   id: 3
   labels:
   - amsterdam
 - !masanjin.net,2006-10-01/Redwood/SentLoader
   cur_offset: 29245
 - !masanjin.net,2006-10-01/Redwood/DraftLoader
   cur_offset: 4
 ***
 
 And here it is after letting the batch sup-add command run...
 
 ***
 cat ~/.sup/sources.yaml
 ---
 - !masanjin.net,2006-10-01/Redwood/MBox/Loader
   uri: mbox:///home/vasudeva/muttmail/windows.lib
   cur_offset:
   usual: true
   archived: true
   id: 3
   labels:
   - windows.lib
 - !masanjin.net,2006-10-01/Redwood/SentLoader
   cur_offset: 29245
 - !masanjin.net,2006-10-01/Redwood/DraftLoader
   cur_offset: 4
 ***
 
 The find routine returns 67 sources, the names of which are all
 alpha plus the following characters: -_+.@
 
 I'll send you a list of the sourcenames off-list, where my
 meticulously-sorted furryporn email archive can't come back to haunt
 me some day.
 
 
 
 /></
 
 --
 linkswarm.com :: Collaborative Insolence
 vasudeva.linkswarm.com/gallery :: For The Faint of Heart
 
 
 From pierre@baillet.name  Tue Nov 13 14:38:19 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Tue, 13 Nov 2007 20:38:19 +0100
 Subject: [sup-talk] Address input bug
 Message-ID: <6205b42d0711131138g32f232d5s8877fdcf8952efea@mail.gmail.com>
 
 Hi,
 
 I don't know if this is an already known issue but it does seem to be
 impossible to type a long long list of recipient in the TO field. It seems
 that as soon as it wraps, sup loses everything before the wrap :
 
 say I have a 10 columns terminal (yes my screen is uber small) :
 
 To: ab at c.c <- wrap
 om<- here is press enter
 
 In vim, I only see :
 
 To: om
 
 This can be annoying when you spend some times to type this long list.
 
 Cheers,
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071113/33167c5c/attachment.html 
 
 From pierre@baillet.name  Tue Nov 13 14:50:34 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Tue, 13 Nov 2007 20:50:34 +0100
 Subject: [sup-talk] Suggested new feature : little brother database support
 Message-ID: <6205b42d0711131150o55e00a95q3116aee72170e93b@mail.gmail.com>
 
 Hi,
 
 I'm just writing you a small mail to inform you that I'd love to see sup
 support the "little brother database" (http://www.spinnaker.de/lbdb/) which
 is very well supported under mutt and pretty useful when writing emails...
 
 Maybe the contact manager could do as well as lbdb, but I've yet to
 understand how the CM works exactly :)
 
 If nobody is against that idea, I think I will look into adding this feature
 sometimes soon...
 
 Cheers,
 ps: I'm still working on my before-edit patch but real life and emailing
 takes always too much time :)
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071113/b759b539/attachment.html 
 
 From chrisw@rice.edu  Tue Nov 13 15:19:14 2007
 From: chrisw@rice.edu (Christopher Warrington)
 Date: Tue, 13 Nov 2007 14:19:14 -0600
 Subject: [sup-talk] Address input bug
 In-Reply-To: <6205b42d0711131138g32f232d5s8877fdcf8952efea@mail.gmail.com>
 References: <6205b42d0711131138g32f232d5s8877fdcf8952efea@mail.gmail.com>
 Message-ID: <1194985118-sup-2616@chris-tablet>
 
 Excerpts from Pierre Baillet's message of Tue Nov 13 13:38:19 -0600 2007:
 > I don't know if this is an already known issue but it does seem to be
 > impossible to type a long long list of recipient in the TO field. It
 > seems that as soon as it wraps, sup loses everything before the wrap :
 
 I've seen something similar when attaching files.
 
 -- 
 Christopher Warrington <chrisw at rice.edu>
 
 
 From philsnow@gmail.com  Tue Nov 13 15:26:26 2007
 From: philsnow@gmail.com (Phil Snowberger)
 Date: Tue, 13 Nov 2007 15:26:26 -0500
 Subject: [sup-talk] ruby/sup causing lots of wakeups-from-idle
 In-Reply-To: <1194830575-sup-5874@south>
 References: <6ab4c98f0711111649o3e06c24aq73750c99bc4af248@mail.gmail.com>
 	<1194830575-sup-5874@south>
 Message-ID: <6ab4c98f0711131226q4772e60fuda2d98fe3d3e5b7d@mail.gmail.com>
 
 On Nov 11, 2007 8:24 PM, William Morgan <wmorgan-sup at masanjin.net> wrote:
 > Excerpts from Phil Snowberger's message of Sun Nov 11 16:49:55 -0800 2007:
 > > I was wondering if anybody else has a problem with sup/ruby causing
 > > lots of wakeups-from-idle?
 >
 > Does this happen with other multithreaded Ruby apps? Sup uses select()
 > for input, and the only persistent threads have multi-second sleep
 > times. But I have no idea how that translates down to the OS level, as
 > Ruby does its own threading.
 
 I tried raggle to see if it would cause a similar amount of wakeups,
 and it does;  Once it settles into a steady state (after it's checked
 each feed on startup), it does ~95 wakeups per second, just like sup.
 
 Sorry for what appears to be a false alarm; I'll take this question to
 some ruby folks.
 
 Thanks,
 --Phil
 
 From pierre@baillet.name  Tue Nov 13 17:44:01 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Tue, 13 Nov 2007 23:44:01 +0100
 Subject: [sup-talk] [PATCH] before-edit hook
 Message-ID: <6205b42d0711131444w6d4a397buad33dad9ba4ded5@mail.gmail.com>
 
 Hi,
 
 Please find here the patch for the before-edit hook. It enables you to alter
 the headers and the body before editing an email. I'm using it to
 automically Bcc me.
 
 Sample hook : before-edit.rb
 --->8-----8<------
 header["Bcc"] = "pierre at baillet.name"
 --->8-----8<------
 
 
 Not sure sending the body to the hook is useful though.
 
 HTH !
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071113/976d943b/attachment.html 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: before_edit_hook_sup.patch
 Type: application/octet-stream
 Size: 802 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071113/976d943b/attachment.obj 
 
 From pierre@baillet.name  Tue Nov 13 18:00:06 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Wed, 14 Nov 2007 00:00:06 +0100
 Subject: [sup-talk] Crash when deleting an email from
 	person-search-results-mode
 Message-ID: <6205b42d0711131500k2c784316t9dd6ae831e98a0ed@mail.gmail.com>
 
 Hi there,
 
 while playing with the contact manager (shouldn't tab look for
 "*typedstring* instead of "typedstring*" when selecting TO recipients ?), I
 did a search "S" on one of my contact. Sup brought back one email which I
 could read by pressing enter. However, as soon as i typed d to delete the
 email, sup crashed :
 
 The problem was: 'no implicit conversion from nil to integer' (error type
 TypeError)
 A backtrace follows:
 /home/oct/temp/sup_trunk/lib/sup/modes/thread-index-mode.rb:483:in
 `delete_at': no implicit conversion from nil to integer (TypeError)
         from /home/oct/temp/sup_trunk/lib/sup/modes/thread-index-mode.rb:483:in
 `hide_thread'
         from /usr/lib/ruby/1.8/thread.rb:135:in `synchronize'
         from /home/oct/temp/sup_trunk/lib/sup/modes/thread-index-mode.rb:479:in
 `hide_thread'
         from /home/oct/temp/sup_trunk/lib/sup/modes/thread-index-mode.rb:126:in
 `handle_deleted_update'
         from /home/oct/temp/sup_trunk/lib/sup/update.rb:16:in `send'
         from /home/oct/temp/sup_trunk/lib/sup/update.rb:16:in `relay'
         from /home/oct/temp/sup_trunk/lib/sup/update.rb:16:in `each'
         from /home/oct/temp/sup_trunk/lib/sup/update.rb:16:in `relay'
          ... 7 levels...
         from /home/oct/temp/sup_trunk/lib/sup/mode.rb:54:in `send'
         from /home/oct/temp/sup_trunk/lib/sup/mode.rb:54:in `handle_input'
         from /home/oct/temp/sup_trunk/lib/sup/buffer.rb:203:in
 `handle_input'
         from /home/oct/temp/sup_trunk/bin/sup:208
 
 I had just synchronised my sup with my mailbox. From the backtrace, I
 suspect that this is the redraw of the updated (now empty) result list that
 poses problem, but i didn't look into it very much...
 
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071114/f5b6822f/attachment.html 
 
 From chrisw@rice.edu  Tue Nov 13 19:07:44 2007
 From: chrisw@rice.edu (Christopher Warrington)
 Date: Tue, 13 Nov 2007 18:07:44 -0600
 Subject: [sup-talk] [PATCH] before-edit hook
 In-Reply-To: <6205b42d0711131444w6d4a397buad33dad9ba4ded5@mail.gmail.com>
 References: <6205b42d0711131444w6d4a397buad33dad9ba4ded5@mail.gmail.com>
 Message-ID: <1194998809-sup-9124@chris-tablet>
 
 Excerpts from Pierre Baillet's message of Tue Nov 13 16:44:01 -0600 2007:
 > Not sure sending the body to the hook is useful though.
 
 If body text can somehow be returned, we could start implementing
 templates.
 
 -- 
 Christopher Warrington <chrisw at rice.edu>
 
 From wmorgan-sup@masanjin.net  Wed Nov 14 02:04:52 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 13 Nov 2007 23:04:52 -0800
 Subject: [sup-talk] Excluding a certain name and/or email from being
 	auto-added to people.txt?
 In-Reply-To: <1194918770-sup-9170@bdawg>
 References: <1194918770-sup-9170@bdawg>
 Message-ID: <1195023641-sup-7821@south>
 
 Excerpts from Brendan O'Connor's message of Mon Nov 12 17:56:22 -0800 2007:
 > i have emails from a bug tracking system (JIRA) that puts various
 > person names but always with the same email address <issues at bla.com>
 > which ends up getting saved in ~/.sup/people.txt and then sup displays
 > all emails from issues at bla.com based on the people.txt name instead of
 > the individual names on the emails.
 
 Yeah, this is a problem because Sup stores only the email address in the
 index and discards the corresponding name. You can override the name by
 adding the email address to contacts.txt, which at least makes it
 consistent, but in the long run I've got to change how Sup handles this.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 14 02:36:32 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 13 Nov 2007 23:36:32 -0800
 Subject: [sup-talk] two crashes on reply
 In-Reply-To: <20071113001636.GA6682@thened.net>
 References: <20071112004805.GA25086@thened.net> <1194891731-sup-468@south>
 	<20071113001636.GA6682@thened.net>
 Message-ID: <1195025575-sup-9780@south>
 
 Excerpts from Alec Berryman's message of Mon Nov 12 16:16:37 -0800 2007:
 > When I sent the original message to myself, the From field was filled
 > in correctly.  Additionally, this only seems to happen on messages I
 > send myself; I tried to reply to another message and it seemed to work
 > fine.
 
 This should be fixed in SVN now. It was a border case in determining 
 what the set of possible reply-to options should be. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From brenocon@gmail.com  Wed Nov 14 03:17:28 2007
 From: brenocon@gmail.com (Brendan O'Connor)
 Date: Wed, 14 Nov 2007 08:17:28 +0000
 Subject: [sup-talk] bugfix to message-chunks.rb
 Message-ID: <1195028091-sup-5871@aa0-000-6.u.powerset.com>
 
 I was getting some crashes and tracked it down to this line.  This patch makes
 the crash go away, so I think it's a bugfix (local variable masking the
 accessor?) but am not sure.
 
 Index: lib/sup/message-chunks.rb
 ===================================================================
 --- lib/sup/message-chunks.rb   (revision 698)
 +++ lib/sup/message-chunks.rb   (working copy)
 @@ -111,7 +111,7 @@
        @lines = lines.map { |l| l.chomp.wrap WRAP_LEN }.flatten # wrap
  
        ## trim off all empty lines except one
 -      lines.pop while lines.last =~ /^\s*$/ 
 +      @lines.pop while @lines.last =~ /^\s*$/ 
      end
  
      def inlineable?; true end
 
 From marcus-sup@bar-coded.net  Wed Nov 14 04:40:23 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 14 Nov 2007 09:40:23 +0000
 Subject: [sup-talk] [PATCH] Pipe message/attachement to shell command
 In-Reply-To: <1194955037-sup-614@tomsk>
 References: <1194622205-sup-2949@tomsk> <1194889791-sup-3292@south>
 	<1194905067-sup-4236@tomsk> <1194955037-sup-614@tomsk>
 Message-ID: <1195032303-sup-7083@tomsk>
 
 On 13.11.2007, Marcus Williams wrote:
 > Mmmm. Seem to be having some buffering problems with open3 on slightly
 > longer messages. The pipe stuff blocks because of it.
 > 
 > Will have to resubmit when I figure it out.
 
 Ok, heres the new one. I think in the pipe to command case, the
 session gem is probably the best way to go (although I've not use it
 here) because it handles the blocking problems for you.
 
 This patch will:
 
 * return an error correctly if the command returns an error initially
 (like a usage error, or missing file etc)
 * pipes the mail/attachment to the command
 * read either stdout OR stderr, whichever is ready first and display that.
 
 The last step is where the problem lies. If a command produces both I
 cant figure out what to do with it, should it display two separate
 buffers, one with errors and one with output? What happens if the
 context of the error is important (ie where it is in the output
 stream)?
 
 I'm pretty sure this is an edge case, as the majority of usages of
 this would be to pipe through a spam filter, or a file viewer (like
 textviewer.sh from claws mail or antiword) and this patch works fine
 in those cases.
 
 Anyone any comments?
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: open3-diffs
 Type: application/octet-stream
 Size: 3524 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071114/5d29ac10/attachment.obj 
 
 From marcus-sup@bar-coded.net  Wed Nov 14 05:04:39 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Wed, 14 Nov 2007 10:04:39 +0000
 Subject: [sup-talk] [PATCH] Move save to disk out to text mode
 Message-ID: <1195034553-sup-5745@tomsk>
 
 Save to disk is useful in text mode in conjunction with the shell/pipe
 command patches. This patch moves the code out from log modle to the
 text mode so you can save the output of a command to a file.
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: save-diffs
 Type: application/octet-stream
 Size: 1291 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071114/15ec679d/attachment.obj 
 
 From alec@thened.net  Wed Nov 14 08:12:33 2007
 From: alec@thened.net (Alec Berryman)
 Date: Wed, 14 Nov 2007 08:12:33 -0500
 Subject: [sup-talk] two crashes on reply
 In-Reply-To: <1195025575-sup-9780@south>
 References: <20071112004805.GA25086@thened.net> <1194891731-sup-468@south>
 	<20071113001636.GA6682@thened.net> <1195025575-sup-9780@south>
 Message-ID: <20071114131233.GA22726@thened.net>
 
 William Morgan on 2007-11-13 23:36:32 -0800:
 
 > Excerpts from Alec Berryman's message of Mon Nov 12 16:16:37 -0800 2007:
 > > When I sent the original message to myself, the From field was filled
 > > in correctly.  Additionally, this only seems to happen on messages I
 > > send myself; I tried to reply to another message and it seemed to work
 > > fine.
 >
 > This should be fixed in SVN now. It was a border case in determining
 > what the set of possible reply-to options should be. Thanks!
 
 I just tried it out and everything works!  Thanks!
 
 From wmorgan-sup@masanjin.net  Wed Nov 14 10:53:36 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 14 Nov 2007 07:53:36 -0800
 Subject: [sup-talk] bugfix to message-chunks.rb
 In-Reply-To: <1195028091-sup-5871@aa0-000-6.u.powerset.com>
 References: <1195028091-sup-5871@aa0-000-6.u.powerset.com>
 Message-ID: <1195055576-sup-449@south>
 
 Excerpts from Brendan O'Connor's message of Wed Nov 14 00:17:28 -0800 2007:
 > I was getting some crashes and tracked it down to this line.  This
 > patch makes the crash go away, so I think it's a bugfix (local
 > variable masking the accessor?) but am not sure.
 
 I believe you're right. Applied. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 14 11:05:31 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 14 Nov 2007 08:05:31 -0800
 Subject: [sup-talk] [PATCH] Move save to disk out to text mode
 In-Reply-To: <1195034553-sup-5745@tomsk>
 References: <1195034553-sup-5745@tomsk>
 Message-ID: <1195056286-sup-8701@south>
 
 Excerpts from Marcus Williams's message of Wed Nov 14 02:04:39 -0800 2007:
 > Save to disk is useful in text mode in conjunction with the shell/pipe
 > command patches. This patch moves the code out from log modle to the
 > text mode so you can save the output of a command to a file.
 
 Been meaning to do this for a while, since I end up viewing most patches
 through text-mode and it's a pain to not to be able to save from that
 screen. Applied. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 14 11:08:17 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 14 Nov 2007 08:08:17 -0800
 Subject: [sup-talk] Address input bug
 In-Reply-To: <6205b42d0711131138g32f232d5s8877fdcf8952efea@mail.gmail.com>
 References: <6205b42d0711131138g32f232d5s8877fdcf8952efea@mail.gmail.com>
 Message-ID: <1195056393-sup-8856@south>
 
 Excerpts from Pierre Baillet's message of Tue Nov 13 11:38:19 -0800 2007:
 > I don't know if this is an already known issue but it does seem to be
 > impossible to type a long long list of recipient in the TO field. It
 > seems that as soon as it wraps, sup loses everything before the wrap :
 
 This is another miracle of Ncurses forms. I'm waiting to fix this until
 I've done something really bad and am in need of punishment.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 14 11:44:55 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 14 Nov 2007 08:44:55 -0800
 Subject: [sup-talk] [PATCH] before-edit hook
 In-Reply-To: <6205b42d0711131444w6d4a397buad33dad9ba4ded5@mail.gmail.com>
 References: <6205b42d0711131444w6d4a397buad33dad9ba4ded5@mail.gmail.com>
 Message-ID: <1195058615-sup-3814@south>
 
 Excerpts from Pierre Baillet's message of Tue Nov 13 14:44:01 -0800 2007:
 > Please find here the patch for the before-edit hook. It enables you to
 > alter the headers and the body before editing an email. I'm using it
 > to automically Bcc me.
 
 Applied. Note that body is an array, not a string.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 14 12:07:04 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 14 Nov 2007 09:07:04 -0800
 Subject: [sup-talk] Crash when deleting an email from
 	person-search-results-mode
 In-Reply-To: <6205b42d0711131500k2c784316t9dd6ae831e98a0ed@mail.gmail.com>
 References: <6205b42d0711131500k2c784316t9dd6ae831e98a0ed@mail.gmail.com>
 Message-ID: <1195059761-sup-5443@south>
 
 Excerpts from Pierre Baillet's message of Tue Nov 13 15:00:06 -0800 2007:
 > while playing with the contact manager (shouldn't tab look for
 > "*typedstring* instead of "typedstring*" when selecting TO recipients
 > ?)
 
 Prefix match is more what I'm used to in console apps, but infix match
 is what Gmail does. Vim does infix match on tab-completion for things
 like switching buffers, so it's not unheard of...
 
 What do people think?
 
 > I did a search "S" on one of my contact. Sup brought back one email
 > which I could read by pressing enter. However, as soon as i typed d to
 > delete the email, sup crashed :
 
 This should be fixed in SVN now. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Wed Nov 14 12:39:10 2007
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Wed, 14 Nov 2007 18:39:10 +0100
 Subject: [sup-talk] Crash when deleting an email from
 	person-search-results-mode
 In-Reply-To: <1195059761-sup-5443@south>
 References: <6205b42d0711131500k2c784316t9dd6ae831e98a0ed@mail.gmail.com>
 	<1195059761-sup-5443@south>
 Message-ID: <1195061802-sup-1844@ausone.local>
 
 Excerpts from William Morgan's message of Wed Nov 14 18:07:04 +0100 2007:
 > Excerpts from Pierre Baillet's message of Tue Nov 13 15:00:06 -0800 2007:
 > > while playing with the contact manager (shouldn't tab look for
 > > "*typedstring* instead of "typedstring*" when selecting TO recipients
 > > ?)
 > 
 > Prefix match is more what I'm used to in console apps, but infix match
 > is what Gmail does. Vim does infix match on tab-completion for things
 > like switching buffers, so it's not unheard of...
 > 
 > What do people think?
 
 I would prefer infix match.
 
 What about using prefix match when the query starts with a '^'?
 
 Regards,
 -- 
 Nicolas Pouillard aka Ertai
 
 From vasudeva@linkswarm.com  Wed Nov 14 19:36:25 2007
 From: vasudeva@linkswarm.com (vasudeva)
 Date: Wed, 14 Nov 2007 19:36:25 -0500
 Subject: [sup-talk] Crash when deleting an email from
 	person-search-results-mode
 In-Reply-To: <1195061802-sup-1844@ausone.local>
 References: <6205b42d0711131500k2c784316t9dd6ae831e98a0ed@mail.gmail.com>
 	<1195059761-sup-5443@south> <1195061802-sup-1844@ausone.local>
 Message-ID: <20071115003625.GA4938@lenin.sovietwar.org>
 
 * on 11-14-07, Nicolas Pouillard wrote:
 > Excerpts from William Morgan's message of Wed Nov 14 18:07:04 +0100 2007:
 > > Excerpts from Pierre Baillet's message of Tue Nov 13 15:00:06 -0800 2007:
 > > > while playing with the contact manager (shouldn't tab look for
 > > > "*typedstring* instead of "typedstring*" when selecting TO recipients
 > > > ?)
 > > 
 > > Prefix match is more what I'm used to in console apps, but infix match
 > > is what Gmail does. Vim does infix match on tab-completion for things
 > > like switching buffers, so it's not unheard of...
 > > 
 > > What do people think?
 > 
 > I would prefer infix match.
 
 Same.
 
 
 
 > What about using prefix match when the query starts with a '^'?
 
 This smacks of sensibility.
 
 
 
 /></
 
 --
 linkswarm.com :: Collaborative Insolence
 vasudeva.linkswarm.com/gallery :: For The Faint of Heart
 
 
 From dylans@gmail.com  Wed Nov 14 22:36:31 2007
 From: dylans@gmail.com (Dylan Stamat)
 Date: Thu, 15 Nov 2007 16:36:31 +1300
 Subject: [sup-talk] Odd behaviour on message creation
 Message-ID: <63501594-4912-428D-B20B-B2D252877160@gmail.com>
 
 When creating a message, and filling out the :to, :cc, :subject... I  
 can't erase my input... ie:  backspace isn't working.
 I have the config pointing to local vim, and vim commands won't erase  
 the input either.
 The rest of the program seems to be working fine.
 
 So... if I create an email, and make a typo on the :to... I have to  
 abort :)
 Any suggestions / ideas would be appreciated.
 
 Thanks !
 ==
 Dylan
 
 From chrisw@rice.edu  Thu Nov 15 03:09:13 2007
 From: chrisw@rice.edu (Christopher Warrington)
 Date: Thu, 15 Nov 2007 02:09:13 -0600
 Subject: [sup-talk] Odd behaviour on message creation
 In-Reply-To: <63501594-4912-428D-B20B-B2D252877160@gmail.com>
 References: <63501594-4912-428D-B20B-B2D252877160@gmail.com>
 Message-ID: <1195114107-sup-1008@chris-tablet>
 
 Excerpts from Dylan Stamat's message of Wed Nov 14 21:36:31 -0600 2007:
 > When creating a message, and filling out the :to, :cc, :subject... I
 > can't erase my input... ie: backspace isn't working. I have the config
 > pointing to local vim, and vim commands won't erase the input either.
 > The rest of the program seems to be working fine.
 > 
 > So... if I create an email, and make a typo on the :to... I have to  
 > abort :)
 
 > Any suggestions / ideas would be appreciated.
 
 Does ^H work instead of backspace? If so, check your key bindings.
 
 -- 
 Christopher Warrington <chrisw at rice.edu>
 Jones College
 
 From kingshivan@gmail.com  Thu Nov 15 11:26:36 2007
 From: kingshivan@gmail.com (shivan)
 Date: Thu, 15 Nov 2007 17:26:36 +0100
 Subject: [sup-talk] uninitialized constant problem
 Message-ID: <1e5fdab70711150826v2e916586t19c7bc150af92c34@mail.gmail.com>
 
 Hi, I get a error from sup when I try to  start it :
 
 /var/lib/gems/1.8/gems/sup-0.1/lib/sup/buffer.rb:32: warning: already
 initialized constant KEY_ENTER
 /var/lib/gems/1.8/gems/sup-0.1/lib/sup/buffer.rb:33: warning: already
 initialized constant KEY_CANCEL
 [Thu Nov 15 17:25:16 +0100 2007] locking /home/shivan/.sup/lock...
 [Thu Nov 15 17:25:16 +0100 2007] stopped cursing
 [Thu Nov 15 17:25:16 +0100 2007] oh crap, an exception
 [Thu Nov 15 17:25:16 +0100 2007] unlocking /home/shivan/.sup/lock...
 ----------------------------------------------------------------
 I'm very sorry, but it seems that an error occurred in Sup.
 Please accept my sincere apologies. If you don't mind, please
 send the backtrace below and a brief report of the circumstances
 to sup-talk at rubyforge dot orgs so that I might address this
 problem. Thank you!
 
 Sincerely,
 William
 ----------------------------------------------------------------
 
 The problem was: 'uninitialized constant Redwood::CanSpawnComposeMode'
 (error type NameError)
 A backtrace follows:
 sup/bin/sup:97: uninitialized constant Redwood::CanSpawnComposeMode (NameError)
 
 that's with the revision 704 of the svn version.
 my only source is an mbox file of my gmail account (sup-sync
 --all-sources died a few times before indexing it completely)
 
 any idea ?
 
 -- 
 shivan
 
 From wmorgan-sup@masanjin.net  Thu Nov 15 12:42:19 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 15 Nov 2007 09:42:19 -0800
 Subject: [sup-talk] uninitialized constant problem
 In-Reply-To: <1e5fdab70711150826v2e916586t19c7bc150af92c34@mail.gmail.com>
 References: <1e5fdab70711150826v2e916586t19c7bc150af92c34@mail.gmail.com>
 Message-ID: <1195148436-sup-4453@south>
 
 Excerpts from kingshivan's message of Thu Nov 15 08:26:36 -0800 2007:
 > Hi, I get a error from sup when I try to  start it :
 > 
 > /var/lib/gems/1.8/gems/sup-0.1/lib/sup/buffer.rb:32: warning: already
 > initialized constant KEY_ENTER
 > /var/lib/gems/1.8/gems/sup-0.1/lib/sup/buffer.rb:33: warning: already
 > initialized constant KEY_CANCEL
 [snip]
 > The problem was: 'uninitialized constant Redwood::CanSpawnComposeMode'
 > (error type NameError)
 > A backtrace follows:
 > sup/bin/sup:97: uninitialized constant Redwood::CanSpawnComposeMode (NameError)
 > 
 > that's with the revision 704 of the svn version.
 
 It looks like you're running the SVN version of bin/sup but it's loading
 code from the 0.1 gem. Run sup from SVN like this:
   ruby -I lib bin/sup
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Mon Nov 19 07:15:18 2007
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 19 Nov 2007 13:15:18 +0100
 Subject: [sup-talk] Sup error when saving mails using maildir
 Message-ID: <1195474360-sup-4962@ausone.inria.fr>
 
 I  was  trying  to switch to a maildir with all my mails, so I marked them and
 read and archive them all. However I hit this error while saving.
 
 Any idea?
 
 Here is the backtrace...
 
 The problem was: 'trying to delete non-corresponding entry 3321 with index message-id "3DB8D934-72AE-11D9-A8FB-000A95DBE2C4 at feydakins.org" and parameter message id "20050206210231.GA3364 at yargla.epita.fr"' (error type RuntimeError)
 A backtrace follows:
 /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:164:in `sync_message': trying to delete non-corresponding entry 3321 with index message-id "3DB8D934-72AE-11D9-A8FB-000A95DBE2C4 at feydakins.org" and parameter message id "20050206210231.GA3364 at yargla.epita.fr" (RuntimeError)
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:485:in `send'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:485:in `method_missing'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/message.rb:126:in `save'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:110:in `save'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:66:in `each'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:166:in `each_with_stuff'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:164:in `each_with_stuff'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:166:in `each_with_stuff'
 	 ... 15 levels...
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/buffer.rb:203:in `handle_input'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup:210
 	from /opt/local/bin/sup:18:in `load'
 	from /opt/local/bin/sup:18
 
 -- 
 Nicolas Pouillard aka Ertai
 
 From nicolas.pouillard@gmail.com  Mon Nov 19 08:53:33 2007
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Mon, 19 Nov 2007 14:53:33 +0100
 Subject: [sup-talk] More sup errors...
 Message-ID: <1195480287-sup-1830@ausone.inria.fr>
 
 Sorry to came up with some new backtraces...
 
 I've saved some more mails and get this kind of errors:
 
 The problem was: ':20492 is out of range [0..20456] for IndexReader#[]' (error type ArgumentError)
 A backtrace follows:
 /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in `[]': :20492 is out of range [0..20456] for IndexReader#[] (ArgumentError)
 	from /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in `[]'
 	from /opt/local/lib/ruby/1.8/monitor.rb:238:in `synchronize'
 	from /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:403:in `[]'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:304:in `build_message'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:286:in `each_message_in_thread_for'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:319:in `call'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:319:in `load_thread_for_message'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:297:in `each_message_in_thread_for'
 	 ... 36 levels...
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/util.rb:485:in `method_missing'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup:196
 	from /opt/local/bin/sup:16:in `load'
 	from /opt/local/bin/sup:16
 
 And then this kind of errors:
 
 The problem was: 'State Error occured at <except.c>:93 in xraise
 Error occured in index.c:4142 - sr_get_lazy_doc
 	Document 9761 has already been deleted
 
 ' (error type Ferret::StateError)
 A backtrace follows:
 /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in `[]': State Error occured at <except.c>:93 in xraise (Ferret::StateError)
 Error occured in index.c:4142 - sr_get_lazy_doc
 	Document 9761 has already been deleted
 
 	from /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in `[]'
 	from /opt/local/lib/ruby/1.8/monitor.rb:238:in `synchronize'
 	from /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:403:in `[]'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:217:in `each_id_by_date'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:217:in `each'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/index.rb:217:in `each_id_by_date'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/thread.rb:304:in `load_n_threads'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/modes/thread-index-mode.rb:413:in `__unprotected_load_n_threads'
 	 ... 17 levels...
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/lib/sup/buffer.rb:203:in `handle_input'
 	from /opt/local/lib/ruby/gems/1.8/gems/sup-0.2/bin/sup:210
 	from /opt/local/bin/sup:16:in `load'
 	from /opt/local/bin/sup:16
 
 Best regards,
 -- 
 Nicolas Pouillard aka Ertai
 
 From col@baibell.org  Tue Nov 20 23:26:40 2007
 From: col@baibell.org (Colin Bell)
 Date: Wed, 21 Nov 2007 15:26:40 +1100
 Subject: [sup-talk] [PATCH] New hook to allow formatting of message headers
 Message-ID: <1195618839-sup-4347@lankhmar>
 
 Hi,
 
 This patch allows you to format the headers shown in the Detailed
 Headers view. Also attached is an example hook which will show the
 email client and a spam header.
 
 --
 Col
 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: headers.diff
 Type: application/octet-stream
 Size: 1193 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071121/a752531a/attachment.obj 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: format-message-headers.rb
 Type: application/octet-stream
 Size: 202 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071121/a752531a/attachment-0001.obj 
 
 From grant@antiflux.org  Wed Nov 21 14:53:34 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Wed, 21 Nov 2007 12:53:34 -0700
 Subject: [sup-talk] [PATCH] label-list-mode with no unread messages
 Message-ID: <1195673904-sup-7215@spooky>
 
 This patch sets the status to "No labels with unread messages" for label-list-mode when unread_only is toggled on and there are, well, no labels with unread messages. I thought the blank buffer looked a little odd.
 
 It would be nicer if label-list-mode wasn't modal. I keep hitting 'b' and 'x' and 'q' with no effect, and then hitting C-g. It would be more work to keep the counts up to date, but that could use some work anyway. If I read all the new mail in one label and then activate label-list-mode, the unread count will be wrong... unless I kill the label buffer or sync it first.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: label-list-no-unread.diff
 Type: application/octet-stream
 Size: 912 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071121/760d8bb6/attachment.obj 
 
 From grant@antiflux.org  Wed Nov 21 15:41:28 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Wed, 21 Nov 2007 13:41:28 -0700
 Subject: [sup-talk] [PATCH] keep buffer-list-mode up-to-date
 Message-ID: <1195677515-sup-8177@spooky>
 
 If you kill or create buffers, but leave buffer-list-mode open, the list of buffers will no longer be correct. If you then select a buffer that has been killed, Sup will crash at BufferManager.raise_to_front.
 
 This patch just reloads the buffer list every time you switch back to it.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-buffer-list-focus-reload.diff
 Type: application/octet-stream
 Size: 467 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071121/24fcd1c0/attachment.obj 
 
 From grant@antiflux.org  Thu Nov 22 01:35:34 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Wed, 21 Nov 2007 23:35:34 -0700
 Subject: [sup-talk] [PATCH] chronic parsing for 'today'
 Message-ID: <1195712820-sup-7120@spooky>
 
 It turns out Chronic.parse has a poorly documented option of :context => :none.
 
 By default, Chronic uses :context => :future, so 'today' means the rest of today. This also applies to 'this day' (which is what Chronic normalizes 'today' to), 'this week', 'this month', etc.  
 
 With :context => :none, 'today' means all of today. I think it's safe to use for all searches.
 
 This feature has been around for at least a year -- Chronic 0.1.6 is the earliest gem I have, and it works.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-chronic-today.diff
 Type: application/octet-stream
 Size: 607 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071121/4657fc5d/attachment-0001.obj 
 
 From eyal.oren@deri.org  Thu Nov 22 03:51:55 2007
 From: eyal.oren@deri.org (Eyal Oren)
 Date: Thu, 22 Nov 2007 09:51:55 +0100
 Subject: [sup-talk] replying to html emails
 Message-ID: <1195721327-sup-8333@timmy>
 
 Hi all,
 
 When I reply to HTML emails, the quoted body text is empty (I guess, because the 
 emails only contains an HTML attachment, without actual body text). As a result, 
 I cannot properly reply (inline) to these people.
 
 Has anyone else seen this? Where in the code should I look to fix this (I also 
 still want to fix the manual thread-joining, but this annoys me more right now)?
 
  -eyal
 
 From pierre@baillet.name  Thu Nov 22 03:57:08 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Thu, 22 Nov 2007 09:57:08 +0100
 Subject: [sup-talk] Contact Manager and fullname aliasing
 Message-ID: <6205b42d0711220057l79ecc2ect6c4a29dc5efff4ef@mail.gmail.com>
 
 Hi,
 
 I'd like to alter the way the ContactManager work so that it could be able
 to save contact which don't have an alias but for which the #name has been
 modified: For some of my contacts,  I'd like to be able to change the #name
 without adding an alias (such as rename dad at home.com to "Dad Home" and
 dad at work.com to "Dad Work") in order to make the Inbox List much easier to
 read.
 
 The problem is that the contact manager is not able to handle alias-less
 contacts and hence any modification to a Person during the run of Sup is
 never saved for unaliased contacts (I actually patched my sup to allow
 fullname modification before understanding that sup will never save these
 changes :p).
 
 Another idea would be to force all displays to use aliases instead of real
 names when displaying emails.  This is probably simple to implement because
 there is no need to rework on the Contact Manager, but i still think that
 "full name" (this full name is used in TO: headers)  and "alias" (this alias
 is only used internally) should be different : I might want to have an alias
 name "annoyingcolleague" and still have "John Doe" displayed when sending
 him an email... Maybe a mix of these two ideas : allow fullname aliasing and
 present all "internal" emails list in the following priority order: alias,
 aliased fullname, fullname from the real email.
 
 What do you think ?
 
 Cheers,
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071122/5bcffae0/attachment.html 
 
 From wmorgan-sup@masanjin.net  Fri Nov 23 13:56:58 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 23 Nov 2007 10:56:58 -0800
 Subject: [sup-talk] Contact Manager and fullname aliasing
 In-Reply-To: <6205b42d0711220057l79ecc2ect6c4a29dc5efff4ef@mail.gmail.com>
 References: <6205b42d0711220057l79ecc2ect6c4a29dc5efff4ef@mail.gmail.com>
 Message-ID: <1195843961-sup-2106@south>
 
 Hi Pierre,
 
 Excerpts from Pierre Baillet's message of Thu Nov 22 00:57:08 -0800 2007:
 > I'd like to alter the way the ContactManager work so that it could be
 > able to save contact which don't have an alias but for which the #name
 > has been modified:
 
 Sounds great.
 
 > The problem is that the contact manager is not able to handle
 > alias-less contacts and hence any modification to a Person during the
 > run of Sup is never saved for unaliased contacts (I actually patched
 > my sup to allow fullname modification before understanding that sup
 > will never save these changes :p).
 
 I think the best solution is to alter the contact manager such that it
 can handle contacts without aliases. I think it currently stores
 everything as a hash from alias to Person object, so you'll have to add
 an array instead.
 
 On the UI side, we can mimic Mutt-style alias prompts. Press 'l' and it
 asks you for the person name (pre-filled with the name from the email),
 and then asks you for the alias, allowing you to hit enter for none.
 Something like that.
 
 > Another idea would be to force all displays to use aliases instead of
 > real names when displaying emails.  This is probably simple to
 > implement because there is no need to rework on the Contact Manager,
 > but i still think that "full name" (this full name is used in TO:
 > headers)  and "alias" (this alias is only used internally) should be
 > different
 
 I agree that it's better that the two fields are different.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov 23 17:44:09 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 23 Nov 2007 14:44:09 -0800
 Subject: [sup-talk] replying to html emails
 In-Reply-To: <1195721327-sup-8333@timmy>
 References: <1195721327-sup-8333@timmy>
 Message-ID: <1195857737-sup-1500@south>
 
 Excerpts from Eyal Oren's message of Thu Nov 22 00:51:55 -0800 2007:
 > When I reply to HTML emails, the quoted body text is empty (I guess,
 > because the emails only contains an HTML attachment, without actual
 > body text). As a result, I cannot properly reply (inline) to these
 > people.
 
 The proper reply to these people, of course, is "Can you please re-send
 without the abomination that is HTML email?".
 
 But, ok, I've fixed this in SVN, such that anything that successfully
 goes through the mime-decode hook will be quoted for replies and
 forwards.
 
 I've also sped up IMAP a little bit... let me know if people notice any
 difference.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Fri Nov 23 17:50:54 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Fri, 23 Nov 2007 14:50:54 -0800
 Subject: [sup-talk] [PATCH] chronic parsing for 'today'
 In-Reply-To: <1195712820-sup-7120@spooky>
 References: <1195712820-sup-7120@spooky>
 Message-ID: <1195858234-sup-7252@south>
 
 Excerpts from Grant Hollingworth's message of Wed Nov 21 22:35:34 -0800 2007:
 > With :context => :none, 'today' means all of today. I think it's safe
 > to use for all searches.
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From grant@antiflux.org  Fri Nov 23 18:35:07 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Fri, 23 Nov 2007 16:35:07 -0700
 Subject: [sup-talk] replying to html emails
 In-Reply-To: <1195857737-sup-1500@south>
 References: <1195721327-sup-8333@timmy> <1195857737-sup-1500@south>
 Message-ID: <1195860795-sup-2643@spooky>
 
 Excerpts from William Morgan's message of Fri Nov 23 15:44:09 -0700 2007:
 > I've also sped up IMAP a little bit... let me know if people notice any
 > difference.
 
 Startup is way faster now. Thanks! It does look a little crazy as the flash messages pile up on each other, but that's not a big deal.
 
 
 From nicolas.pouillard@gmail.com  Sat Nov 24 05:25:57 2007
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 24 Nov 2007 11:25:57 +0100
 Subject: [sup-talk] Weird behaviour saving attachments.
 Message-ID: <1195899951-sup-7842@ausone.local>
 
 Hi,
 
 Sometimes  when  I  save attachment the file name is not properly unquoted and
 then save a file with double quotes in the name (e.g. "foo.bar").
 
 Best regards,
 
 -- 
 Nicolas Pouillard aka Ertai
 
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 11:52:22 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 08:52:22 -0800
 Subject: [sup-talk] replying to html emails
 In-Reply-To: <1195860795-sup-2643@spooky>
 References: <1195721327-sup-8333@timmy> <1195857737-sup-1500@south>
 	<1195860795-sup-2643@spooky>
 Message-ID: <1195922940-sup-510@south>
 
 Excerpts from Grant Hollingworth's message of Fri Nov 23 15:35:07 -0800 2007:
 > Startup is way faster now. Thanks!
 
 Excellent. The next critical IMAP thing is connection sharing.
 
 > It does look a little crazy as the flash messages pile up on each
 > other, but that's not a big deal.
 
 Heck, the very act of using Sup to read your email is crazy! I actually
 am proud of the stacking status bar. My contribution to the fast-paced
 world of Curses-based interfaces, we'll call it.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From guillaume.quintard@gmail.com  Sat Nov 24 12:13:22 2007
 From: guillaume.quintard@gmail.com (Guillaume Quintard)
 Date: Sat, 24 Nov 2007 18:13:22 +0100
 Subject: [sup-talk] Can't use "H" or "?"
 Message-ID: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 
 hi,
 I can't access to the helmp menu, whenever I press H or ? (no matter
 if I use left or right shift key) I get this :
 The problem was: 'unknown key name "ctrl_g"' (error type ArgumentError)
 A backtrace follows:
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:54:in
 `keysym_to_string': unknown key name "ctrl_g" (ArgumentError)
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:80:in `help_text'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:80:in `map'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:80:in `help_text'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:77:in `map'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/keymap.rb:77:in `help_text'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/modes/help-mode.rb:13:in
 `initialize'
         from sup/bin/sup:209:in `new'
         from sup/bin/sup:209
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/buffer.rb:251:in
 `spawn_unless_exists'
         from sup/bin/sup:209
 
 I'm using an azerty keyboard
 
 -- 
 shivan
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 12:18:06 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 09:18:06 -0800
 Subject: [sup-talk] More sup errors...
 In-Reply-To: <1195480287-sup-1830@ausone.inria.fr>
 References: <1195480287-sup-1830@ausone.inria.fr>
 Message-ID: <1195923981-sup-4149@south>
 
 Excerpts from nicolas.pouillard's message of Mon Nov 19 05:53:33 -0800 2007:
 > The problem was: ':20492 is out of range [0..20456] for IndexReader#[]' (error
 > type ArgumentError)
 > A backtrace follows:
 > /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in
 > `[]': :20492 is out of range [0..20456] for IndexReader#[] (ArgumentError)
 [snip]
 > The problem was: 'State Error occured at <except.c>:93 in xraise
 > Error occured in index.c:4142 - sr_get_lazy_doc
 >     Document 9761 has already been deleted
 > 
 > ' (error type Ferret::StateError)
 > A backtrace follows:
 > /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in
 > `[]': State Error occured at <except.c>:93 in xraise (Ferret::StateError)
 > Error occured in index.c:4142 - sr_get_lazy_doc
 >     Document 9761 has already been deleted
 
 These errors (and the previous errors you reported about the
 non-matching message ids) suggest that Ferret is very confused---it's
 returning document ids (each message is stored as a Ferret "document")
 from a search that don't correspond to the right messages, or that
 correspond to documents that have already been deleted, or that are
 simply bigger than the max document id in the index.
 
 I suspect a bug in Ferret has somehow broken your index. Here's what I
 suggest.
 
 0. Make a backup of ~/.sup in case something terrible happens.
 1. Upgrade your Ferret gem to 11.5 (the latest).
 2. sup-sync --all --optimize. (Might take a while.)
 
 If step #2 fails with the same Ferret errors, try:
 
 3. sup-dump | bzip2 > /tmp/state.bz2
 4. rm -rf ~/.sup/ferret # you did make a backup, right?
 5. sup-sync --all --restore <(bzcat /tmp/state.bz2) # assumes bash
 
 But hopefully step #2 will work. And if we're lucky step #1 will fix
 whatever Ferret bug caused this.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 12:24:36 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 09:24:36 -0800
 Subject: [sup-talk] Can't use "H" or "?"
 In-Reply-To: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 References: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 Message-ID: <1195924950-sup-1007@south>
 
 Excerpts from Guillaume Quintard's message of Sat Nov 24 09:13:22 -0800 2007:
 > I can't access to the helmp menu, whenever I press H or ? (no matter
 > if I use left or right shift key) I get this :
 > The problem was: 'unknown key name "ctrl_g"' (error type ArgumentError)
 
 It looks like you're using an out-of-date SVN checkout. Time to SVN update!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 12:34:28 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 09:34:28 -0800
 Subject: [sup-talk] Weird behaviour saving attachments.
 In-Reply-To: <1195899951-sup-7842@ausone.local>
 References: <1195899951-sup-7842@ausone.local>
 Message-ID: <1195925357-sup-8894@south>
 
 Excerpts from nicolas.pouillard's message of Sat Nov 24 02:25:57 -0800 2007:
 > Sometimes  when  I  save attachment the file name is not properly
 > unquoted and then save a file with double quotes in the name (e.g.
 > "foo.bar").
 
 Can you track down the MIME header in the raw message that names the
 attachment? 
 
 If you save the message to disk with 's' and search the file for
 "filename", you should see it. (Probably a Content-Disposition header.)
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 12:41:38 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 09:41:38 -0800
 Subject: [sup-talk] [PATCH] keep buffer-list-mode up-to-date
 In-Reply-To: <1195677515-sup-8177@spooky>
 References: <1195677515-sup-8177@spooky>
 Message-ID: <1195926040-sup-8821@south>
 
 Excerpts from Grant Hollingworth's message of Wed Nov 21 12:41:28 -0800 2007:
 > This patch just reloads the buffer list every time you switch back to
 > it.
 
 Applied, thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 12:45:22 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 09:45:22 -0800
 Subject: [sup-talk] Can't use "H" or "?"
 In-Reply-To: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 References: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 Message-ID: <1195926236-sup-3173@south>
 
 Excerpts from Guillaume Quintard's message of Sat Nov 24 09:13:22 -0800 2007:
 >         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/buffer.rb:251:in
 > `spawn_unless_exists'
 >         from sup/bin/sup:209
 
 Oh, I see that you're starting sup from SVN but that it's loading code
 from the 0.2 gem. You need to use something like "ruby -Ilib bin/sup" to
 start it if you're running from SVN. You should probably uninstall that
 gem to prevent further confusion.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From pierre@baillet.name  Sat Nov 24 13:38:49 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Sat, 24 Nov 2007 19:38:49 +0100
 Subject: [sup-talk] Contact Manager and fullname aliasing
 In-Reply-To: <1195843961-sup-2106@south>
 References: <6205b42d0711220057l79ecc2ect6c4a29dc5efff4ef@mail.gmail.com>
 	<1195843961-sup-2106@south>
 Message-ID: <6205b42d0711241038j3f1b75e6s3ad7a2d7f4d5b316@mail.gmail.com>
 
 Hi,
 
 This is my first implementation. Interestingly enough, most of the code
 modified is in person.rb because this class already seems to store the full
 name of contacts. Can the full name stored in it be overwritten by sup when
 it receives new emails ? If this is the case, maybe we should add another
 field there to indicate that the fullname has been modified by the user and
 that sup shouldn't change it. I wanted to avoid to duplicate the full names
 between person and contact but maybe i'm too lazy... At the same time, no
 data migration is needed to add an extra field in the person or contact.txt:)
 
 The Contact Manager now has an Array instead of a hash. One problem might
 happen : duplicate aliases. How can i warm the user that the alias he just
 typed already exists ? This should be done in #update_alias of
 #alias_contact. The method contact_for aalias has been modified and now
 includes a grep. I don't know when this method is called, but i always take
 the first elements returned. What if the aalias passed as parameter yields
 no match ? Last method implementation yielded nil. Can this happen ?
 
 I aliased everything to "a" like before, and made sup ask for the alias and
 the full name (my mutt has this bound on "a" too...).
 
 Let me know what you think of all this :)
 -- 
 Pierre.
 
 
 On Nov 23, 2007 7:56 PM, William Morgan <wmorgan-sup at masanjin.net> wrote:
 
 > Hi Pierre,
 >
 > Excerpts from Pierre Baillet's message of Thu Nov 22 00:57:08 -0800 2007:
 > > I'd like to alter the way the ContactManager work so that it could be
 > > able to save contact which don't have an alias but for which the #name
 > > has been modified:
 >
 > Sounds great.
 >
 > > The problem is that the contact manager is not able to handle
 > > alias-less contacts and hence any modification to a Person during the
 > > run of Sup is never saved for unaliased contacts (I actually patched
 > > my sup to allow fullname modification before understanding that sup
 > > will never save these changes :p).
 >
 > I think the best solution is to alter the contact manager such that it
 > can handle contacts without aliases. I think it currently stores
 > everything as a hash from alias to Person object, so you'll have to add
 > an array instead.
 >
 > On the UI side, we can mimic Mutt-style alias prompts. Press 'l' and it
 > asks you for the person name (pre-filled with the name from the email),
 > and then asks you for the alias, allowing you to hit enter for none.
 > Something like that.
 >
 > > Another idea would be to force all displays to use aliases instead of
 > > real names when displaying emails.  This is probably simple to
 > > implement because there is no need to rework on the Contact Manager,
 > > but i still think that "full name" (this full name is used in TO:
 > > headers)  and "alias" (this alias is only used internally) should be
 > > different
 >
 > I agree that it's better that the two fields are different.
 >
 > --
 > William <wmorgan-sup at masanjin.net>
 > _______________________________________________
 > sup-talk mailing list
 > sup-talk at rubyforge.org
 > http://rubyforge.org/mailman/listinfo/sup-talk
 >
 
 
 
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071124/157e6dd2/attachment.html 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: contact_manager.patch
 Type: application/octet-stream
 Size: 4344 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071124/157e6dd2/attachment.obj 
 
 From guillaume.quintard@enst-bretagne.fr  Sat Nov 24 12:58:21 2007
 From: guillaume.quintard@enst-bretagne.fr (Guillaume Quintard)
 Date: Sat, 24 Nov 2007 18:58:21 +0100
 Subject: [sup-talk] Can't use "H" or "?"
 In-Reply-To: <1195926236-sup-3173@south>
 References: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 	<1195926236-sup-3173@south>
 Message-ID: <1e5fdab70711240958v3d3fe89ak7c6b670bb54e5103@mail.gmail.com>
 
 On Nov 24, 2007 6:45 PM, William Morgan <wmorgan-sup at masanjin.net> wrote:
 > Oh, I see that you're starting sup from SVN but that it's loading code
 > from the 0.2 gem. You need to use something like "ruby -Ilib bin/sup" to
 > start it if you're running from SVN. You should probably uninstall that
 > gem to prevent further confusion.
 
 actually, I tried without the gem, but I got this error message :
 
 /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in
 `gem_original_require': no such file to load -- sup (LoadError)
         from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require'
         from sup/bin/sup:8
 
 and now that I uninstalled it, I get the message agin
 
 
 -- 
 shivan
 
 From nicolas.pouillard@gmail.com  Sat Nov 24 14:00:52 2007
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sat, 24 Nov 2007 20:00:52 +0100
 Subject: [sup-talk] More sup errors...
 In-Reply-To: <1195923981-sup-4149@south>
 References: <1195480287-sup-1830@ausone.inria.fr> <1195923981-sup-4149@south>
 Message-ID: <1195930793-sup-417@ausone.local>
 
 Excerpts from William Morgan's message of Sat Nov 24 18:18:06 +0100 2007:
 > Excerpts from nicolas.pouillard's message of Mon Nov 19 05:53:33 -0800 2007:
 > > The problem was: ':20492 is out of range [0..20456] for IndexReader#[]' (error
 > > type ArgumentError)
 > > A backtrace follows:
 > > /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in
 > > `[]': :20492 is out of range [0..20456] for IndexReader#[] (ArgumentError)
 > [snip]
 > > The problem was: 'State Error occured at <except.c>:93 in xraise
 > > Error occured in index.c:4142 - sr_get_lazy_doc
 > >     Document 9761 has already been deleted
 > > 
 > > ' (error type Ferret::StateError)
 > > A backtrace follows:
 > > /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.4/lib/ferret/index.rb:411:in
 > > `[]': State Error occured at <except.c>:93 in xraise (Ferret::StateError)
 > > Error occured in index.c:4142 - sr_get_lazy_doc
 > >     Document 9761 has already been deleted
 > 
 > These errors (and the previous errors you reported about the
 > non-matching message ids) suggest that Ferret is very confused---it's
 > returning document ids (each message is stored as a Ferret "document")
 > from a search that don't correspond to the right messages, or that
 > correspond to documents that have already been deleted, or that are
 > simply bigger than the max document id in the index.
 > 
 > I suspect a bug in Ferret has somehow broken your index. Here's what I
 > suggest.
 
 Thanks a lot.
 
 I no longer have these errors, so I keep the recipe when errors will come.
 
 > 0. Make a backup of ~/.sup in case something terrible happens.
 > 1. Upgrade your Ferret gem to 11.5 (the latest).
 > 2. sup-sync --all --optimize. (Might take a while.)
 > 
 > If step #2 fails with the same Ferret errors, try:
 > 
 > 3. sup-dump | bzip2 > /tmp/state.bz2
 > 4. rm -rf ~/.sup/ferret # you did make a backup, right?
 > 5. sup-sync --all --restore <(bzcat /tmp/state.bz2) # assumes bash
 > 
 > But hopefully step #2 will work. And if we're lucky step #1 will fix
 > whatever Ferret bug caused this.
 > 
 
 -- 
 Nicolas Pouillard aka Ertai
 
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 15:10:34 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 12:10:34 -0800
 Subject: [sup-talk] Can't use "H" or "?"
 In-Reply-To: <1e5fdab70711240958v3d3fe89ak7c6b670bb54e5103@mail.gmail.com>
 References: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 	<1195926236-sup-3173@south>
 	<1e5fdab70711240958v3d3fe89ak7c6b670bb54e5103@mail.gmail.com>
 Message-ID: <1195934992-sup-1552@south>
 
 Excerpts from guillaume.quintard's message of Sat Nov 24 09:58:21 -0800 2007:
 > /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in
 > `gem_original_require': no such file to load -- sup (LoadError)
 >         from /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in `require'
 >         from sup/bin/sup:8
 > 
 > and now that I uninstalled it, I get the message agin
 
 Are you in the SVN directory? I.e. are "bin" and "lib" both
 subdirectories of the current directory?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Sat Nov 24 15:47:34 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Sat, 24 Nov 2007 12:47:34 -0800
 Subject: [sup-talk] [PATCH] label-list-mode with no unread messages
 In-Reply-To: <1195673904-sup-7215@spooky>
 References: <1195673904-sup-7215@spooky>
 Message-ID: <1195936974-sup-3449@south>
 
 Excerpts from Grant Hollingworth's message of Wed Nov 21 11:53:34 -0800 2007:
 > This patch sets the status to "No labels with unread messages" for
 > label-list-mode when unread_only is toggled on and there are, well, no
 > labels with unread messages. I thought the blank buffer looked a
 > little odd.
 > 
 > It would be nicer if label-list-mode wasn't modal. I keep hitting 'b'
 > and 'x' and 'q' with no effect, and then hitting C-g.
 
 I've committed the following changes to SVN:
 
 1. LabelListMode is no longer modal (it was bugging me too)
 2. Hitting tab now cycles the cursor between labels with unread
    messages, just like in ThreadIndexMode.
 3. Hitting 'u' does the toggle that tab used to. (Sorry to everyone who
    has to retrain their fingers---maybe this is motivation to submit a
    configurable keybinding patch!)
 
 > It would be more work to keep the counts up to date, but that could
 > use some work anyway. If I read all the new mail in one label and then
 > activate label-list-mode, the unread count will be wrong... unless I
 > kill the label buffer or sync it first.
 
 Shouldn't be too hard to do this if you use catch the appropriate
 events from UpdateManager.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Sun Nov 25 06:28:34 2007
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Sun, 25 Nov 2007 12:28:34 +0100
 Subject: [sup-talk] Weird behaviour saving attachments.
 In-Reply-To: <1195925357-sup-8894@south>
 References: <1195899951-sup-7842@ausone.local> <1195925357-sup-8894@south>
 Message-ID: <1195990103-sup-5438@ausone.local>
 
 Excerpts from William Morgan's message of Sat Nov 24 18:34:28 +0100 2007:
 > Excerpts from nicolas.pouillard's message of Sat Nov 24 02:25:57 -0800 2007:
 > > Sometimes  when  I  save attachment the file name is not properly
 > > unquoted and then save a file with double quotes in the name (e.g.
 > > "foo.bar").
 > 
 > Can you track down the MIME header in the raw message that names the
 > attachment? 
 > 
 > If you save the message to disk with 's' and search the file for
 > "filename", you should see it. (Probably a Content-Disposition header.)
 > 
 
 It  was  the  name  attribute of the Content-Type header that was not unquoted
 like Content-Disposition filename. Here is a patch as attachment.
 
 -- 
 Nicolas Pouillard aka Ertai
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: unquote-content-type-name.patch
 Type: application/octet-stream
 Size: 494 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071125/287d1205/attachment.obj 
 
 From guillaume.quintard@enst-bretagne.fr  Sat Nov 24 22:29:50 2007
 From: guillaume.quintard@enst-bretagne.fr (Guillaume Quintard)
 Date: Sun, 25 Nov 2007 04:29:50 +0100
 Subject: [sup-talk] Can't use "H" or "?"
 In-Reply-To: <1195934992-sup-1552@south>
 References: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 	<1195926236-sup-3173@south>
 	<1e5fdab70711240958v3d3fe89ak7c6b670bb54e5103@mail.gmail.com>
 	<1195934992-sup-1552@south>
 Message-ID: <1e5fdab70711241929i2e07565bt745dd103a69e169@mail.gmail.com>
 
 On Nov 24, 2007 9:10 PM, William Morgan <wmorgan-sup at masanjin.net> wrote:
 > Are you in the SVN directory? I.e. are "bin" and "lib" both
 > subdirectories of the current directory?
 
 yep, sup is in sup/bin, and there's a lib directory on the same level as lib
 
 
 -- 
 Black masses are cool, as long as you're not the virgin.
 
 From pierre@baillet.name  Mon Nov 26 01:50:04 2007
 From: pierre@baillet.name (Pierre Baillet)
 Date: Mon, 26 Nov 2007 07:50:04 +0100
 Subject: [sup-talk] [BUG] Forward in ThreadViewMode broken ?
 Message-ID: <6205b42d0711252250x319ee165h3c83fd4eadb6426a@mail.gmail.com>
 
 Hi,
 
 trunk sup crashes when attempting to forward an email from the Thread View :
 
 The problem was: 'undefined method `spawn_forward_mode' for
 #<Redwood::ThreadViewMode:0x2f1350d26e90>' (error type NoMethodError)
 A backtrace follows:
 /home/oct/temp/sup_trunk/lib/sup/modes/thread-view-mode.rb:130:in `forward':
 undefined method `spawn_forward_mode' for
 #<Redwood::ThreadViewMode:0x2f1350d26e90> (NoMethodError)
         from /home/oct/temp/sup_trunk/lib/sup/mode.rb:54:in `send'
         from /home/oct/temp/sup_trunk/lib/sup/mode.rb:54:in `handle_input'
         from /home/oct/temp/sup_trunk/lib/sup/buffer.rb:204:in
 `handle_input'
         from /home/oct/temp/sup_trunk/bin/sup:201
 [1]    18225 exit 1     sup
 
 Cheers,
 -- 
 Pierre Baillet <pierre at baillet.name>
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071126/8d35957d/attachment.html 
 
 From marcus-sup@bar-coded.net  Mon Nov 26 07:09:06 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 26 Nov 2007 12:09:06 +0000
 Subject: [sup-talk] [BUG] Forward in ThreadViewMode broken ?
 In-Reply-To: <6205b42d0711252250x319ee165h3c83fd4eadb6426a@mail.gmail.com>
 References: <6205b42d0711252250x319ee165h3c83fd4eadb6426a@mail.gmail.com>
 Message-ID: <1196078892-sup-2549@tomsk>
 
 On 26.11.2007, Pierre Baillet wrote:
 > trunk sup crashes when attempting to forward an email from the Thread View :
 
 .. as is compose from within thread view with a similar stack trace
 (but with spawn_compose_view)
 
 Marcus
 
 From grant@antiflux.org  Mon Nov 26 13:57:49 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Mon, 26 Nov 2007 13:57:49 -0500
 Subject: [sup-talk] [PATCH] label-list-mode with no unread messages
 In-Reply-To: <1195936974-sup-3449@south>
 References: <1195673904-sup-7215@spooky> <1195936974-sup-3449@south>
 Message-ID: <1196103315-sup-3020@spooky.local>
 
 Excerpts from William Morgan's message of Sat Nov 24 15:47:34 -0500 2007:
 > Shouldn't be too hard to do this if you use catch the appropriate
 > events from UpdateManager.
 
 I hadn't looked at the UpdateManager before... that's pretty cool.
 
 The problem is that the text in label-list-mode is created by LabelListMode#regen_text. It would be awkward to fiddle with @text outside of there. Since regen_text gets its numbers from Index.num_results_for, the other buffer has to sync to the index before the label list will know about it. So it seems to be just as effective to add 'def focus; reload; end' to LabelListMode.
 
 Handling the unread counts in LabelListMode seems dirty, anyway. You'd have to watch more than just the :read event, right? If a thread is archived from the inbox, for instance, the unread count for 'Inbox' should go down.
 
 So I haven't done any of that... but I found a related problem: the inbox doesn't update if you unarchive a thread elsewhere. I made a na?ve patch that works in some cases.
 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-inbox-unarchived.diff
 Type: application/octet-stream
 Size: 988 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071126/5ad3bba1/attachment.obj 
 
 From wmorgan-sup@masanjin.net  Mon Nov 26 15:09:31 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 26 Nov 2007 12:09:31 -0800
 Subject: [sup-talk] [BUG] Forward in ThreadViewMode broken ?
 In-Reply-To: <1196078892-sup-2549@tomsk>
 References: <6205b42d0711252250x319ee165h3c83fd4eadb6426a@mail.gmail.com>
 	<1196078892-sup-2549@tomsk>
 Message-ID: <1196107764-sup-7455@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 26 04:09:06 -0800 2007:
 > On 26.11.2007, Pierre Baillet wrote:
 > > trunk sup crashes when attempting to forward an email from the Thread View :
 > 
 > .. as is compose from within thread view with a similar stack trace
 > (but with spawn_compose_view)
 
 Fixed. Sorry!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 26 15:11:28 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 26 Nov 2007 12:11:28 -0800
 Subject: [sup-talk] Weird behaviour saving attachments.
 In-Reply-To: <1195990103-sup-5438@ausone.local>
 References: <1195899951-sup-7842@ausone.local> <1195925357-sup-8894@south>
 	<1195990103-sup-5438@ausone.local>
 Message-ID: <1196107869-sup-201@south>
 
 Excerpts from nicolas.pouillard's message of Sun Nov 25 03:28:34 -0800 2007:
 > It  was  the  name  attribute of the Content-Type header that was not
 > unquoted like Content-Disposition filename. Here is a patch as
 > attachment.
 
 Applied. Thanks!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 26 15:37:29 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 26 Nov 2007 12:37:29 -0800
 Subject: [sup-talk] new user of sup
 In-Reply-To: <20071113184129.GA11753@lenin.sovietwar.org>
 References: <4728B67A.7020604@gslab.com>
 	<20071031180510.GA7449@lenin.sovietwar.org>
 	<1194912687-sup-4696@south>
 	<20071113184129.GA11753@lenin.sovietwar.org>
 Message-ID: <1196109402-sup-5167@south>
 
 Excerpts from vasudeva's message of Tue Nov 13 10:41:29 -0800 2007:
 > I've just svn updated sup, and I can reproduce this.
 
 Sorry for the delay! Finally fixed this. It was something dumb on 
 my part. SVN update and see if it works now.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Mon Nov 26 15:42:48 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 26 Nov 2007 12:42:48 -0800
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <1194905177-sup-2828@tomsk>
 References: <1194518450-sup-4792@tomsk> <1194827264-sup-5774@south>
 	<1194859333-sup-9479@tomsk> <1194886848-sup-8236@south>
 	<1194905177-sup-2828@tomsk>
 Message-ID: <1196109465-sup-5703@south>
 
 Excerpts from Marcus Williams's message of Mon Nov 12 14:07:17 -0800 2007:
 > Attached is a patch for this. Not sure if this is the best way of
 > doing it as I've used accessors on buffer class rather than passing
 > args.
 
 I've added this functionality to SVN trunk, although I had to deviate
 pretty far from the patch in order to get everything right. I also
 changed the variable names slightly. Check it out and see if it does
 everything you want.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Mon Nov 26 15:45:47 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 26 Nov 2007 20:45:47 +0000
 Subject: [sup-talk] [PATCH] Title bar and status bar widget
 In-Reply-To: <1196109465-sup-5703@south>
 References: <1194518450-sup-4792@tomsk> <1194827264-sup-5774@south>
 	<1194859333-sup-9479@tomsk> <1194886848-sup-8236@south>
 	<1194905177-sup-2828@tomsk> <1196109465-sup-5703@south>
 Message-ID: <1196109865-sup-4282@tomsk>
 
 On 26.11.2007, William Morgan wrote:
 > I've added this functionality to SVN trunk, although I had to deviate
 > pretty far from the patch in order to get everything right. I also
 > changed the variable names slightly. Check it out and see if it does
 > everything you want.
 
 On it now - cant get the title text to work yet, but I might be
 missing something. Just trying to re-jig my shell and pipe patches so
 that the shell one is in bin/sup. Will submit soon.
 
 Marcus
 
 From wmorgan-sup@masanjin.net  Mon Nov 26 15:46:28 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Mon, 26 Nov 2007 12:46:28 -0800
 Subject: [sup-talk] Can't use "H" or "?"
 In-Reply-To: <1e5fdab70711241929i2e07565bt745dd103a69e169@mail.gmail.com>
 References: <1e5fdab70711240913m57c14e6etfa3f97dded8a0163@mail.gmail.com>
 	<1195926236-sup-3173@south>
 	<1e5fdab70711240958v3d3fe89ak7c6b670bb54e5103@mail.gmail.com>
 	<1195934992-sup-1552@south>
 	<1e5fdab70711241929i2e07565bt745dd103a69e169@mail.gmail.com>
 Message-ID: <1196109860-sup-6281@south>
 
 Excerpts from guillaume.quintard's message of Sat Nov 24 19:29:50 -0800 2007:
 > On Nov 24, 2007 9:10 PM, William Morgan <wmorgan-sup at masanjin.net> wrote:
 > > Are you in the SVN directory? I.e. are "bin" and "lib" both
 > > subdirectories of the current directory?
 > 
 > yep, sup is in sup/bin, and there's a lib directory on the same level as lib
 
 If you are in the SVN checkout directory, and there's a bin/sup, and a
 lib/sup.rb, and a lot of lib/sup/*.rb, then it must be the case that:
   ruby -I lib bin/sup
 finds the correct libraries!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From marcus-sup@bar-coded.net  Mon Nov 26 15:57:05 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 26 Nov 2007 20:57:05 +0000
 Subject: [sup-talk] [PATCH] Pipe message/attachement to shell command
 In-Reply-To: <1195032303-sup-7083@tomsk>
 References: <1194622205-sup-2949@tomsk> <1194889791-sup-3292@south>
 	<1194905067-sup-4236@tomsk> <1194955037-sup-614@tomsk>
 	<1195032303-sup-7083@tomsk>
 Message-ID: <1196110544-sup-3133@tomsk>
 
 On 14.11.2007, Marcus Williams wrote:
 > Ok, heres the new one. I think in the pipe to command case, the
 > session gem is probably the best way to go (although I've not use it
 > here) because it handles the blocking problems for you.
 
 Here we go again. Attached is the shell patch (pipe to follow) as a
 patch to bin/sup instead of in the scroll mode.
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: shell-patch
 Type: application/octet-stream
 Size: 1221 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071126/bd47d15c/attachment-0001.obj 
 
 From marcus-sup@bar-coded.net  Mon Nov 26 16:01:22 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Mon, 26 Nov 2007 21:01:22 +0000
 Subject: [sup-talk] [PATCH] Pipe message/attachement to shell command
 In-Reply-To: <1196110544-sup-3133@tomsk>
 References: <1194622205-sup-2949@tomsk> <1194889791-sup-3292@south>
 	<1194905067-sup-4236@tomsk> <1194955037-sup-614@tomsk>
 	<1195032303-sup-7083@tomsk> <1196110544-sup-3133@tomsk>
 Message-ID: <1196110823-sup-7451@tomsk>
 
 On 26.11.2007, Marcus Williams wrote:
 > Here we go again. Attached is the shell patch (pipe to follow) as a
 > patch to bin/sup instead of in the scroll mode.
 
 ... and here is the pipe patch.
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: pipe-patch
 Type: application/octet-stream
 Size: 1926 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071126/4a9e950a/attachment.obj 
 
 From mr@fudgie.org  Tue Nov 27 07:00:01 2007
 From: mr@fudgie.org (Erlend Simonsen)
 Date: Tue, 27 Nov 2007 13:00:01 +0100
 Subject: [sup-talk] backtrace
 Message-ID: <1196164801.15000.1.camel@quad>
 
 I composed a reply, and noticed I had typed a signature as well as gotten an auto-included one. Pressed 'd' on my typed signature '-- Erlend' and got this:
 
 
 /var/lib/gems/1.8/gems/sup-0.2/lib/sup/modes/edit-message-mode.rb:124:in `-': nil can't be coerced into Fixnum (TypeError)
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/modes/edit-message-mode.rb:124:in `delete_attachment'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/mode.rb:52:in `send'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/mode.rb:52:in `handle_input'
         from /var/lib/gems/1.8/gems/sup-0.2/lib/sup/buffer.rb:193:in `handle_input'
         from /var/lib/gems/1.8/gems/sup-0.2/bin/sup:201
         from /var/lib/gems/1.8/bin/sup:16:in `load'
         from /var/lib/gems/1.8/bin/sup:16
 
 
 
 From wmorgan-sup@masanjin.net  Tue Nov 27 12:16:39 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 27 Nov 2007 09:16:39 -0800
 Subject: [sup-talk] backtrace
 In-Reply-To: <1196164801.15000.1.camel@quad>
 References: <1196164801.15000.1.camel@quad>
 Message-ID: <1196183750-sup-8312@south>
 
 Excerpts from Erlend Simonsen's message of Tue Nov 27 04:00:01 -0800 2007:
 > I composed a reply, and noticed I had typed a signature as well as
 > gotten an auto-included one. Pressed 'd' on my typed signature '--
 > Erlend' and got this:
 
 This is fixed in SVN. I'm going to release an 0.3 soon.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Tue Nov 27 14:46:47 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Tue, 27 Nov 2007 11:46:47 -0800
 Subject: [sup-talk] [ANN] Sup 0.3 released
 Message-ID: <1196192739-sup-4301@south>
 
 Sup version 0.3 has been released!
 
 http://sup.rubyforge.org
 
 Sup is a console-based email client for people with a lot of email.
 It supports tagging, very fast full-text search, automatic contact-
 list management, and more. If you're the type of person who treats
 email as an extension of your long-term memory, Sup is for you.
 
 Sup makes it easy to:
 - Handle massive amounts of email.
 
 - Mix email from different sources: mbox files (even across different
   machines), Maildir directories, IMAP folders, POP accounts, and
   GMail accounts.
 
 - Instantaneously search over your entire email collection. Search
   over body text, or use a query language to combine search
   predicates in any way.
 
 - Handle multiple accounts. Replying to email sent to a particular
   account will use the correct SMTP server, signature, and from
   address.
 
 - Add custom code to handle certain types of messages or to handle
   certain types of text within messages.
 
 - Organize email with user-defined labels, automatically track
   recent contacts, and much more!
 
 The goal of Sup is to become the email client of choice for nerds
 everywhere.
 
 Changes:
 
 ## 0.3 / 2007-10-29
 * In-buffer search (finally!)
 * Subscribe to/unsubscribe from mailing list commands.
 * IMAP speedups.
 * More hooks: set status bar, set terminal title bar, modify message headers
   and bodies before editing, etc.
 * Optionally use chronic gem to allow for natural-language dates in searches.
 * Many, many bugfixes and minor improvements.
 * Tomorrow is Sup's first birthday!
 
 * http://sup.rubyforge.org
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From grant@antiflux.org  Tue Nov 27 17:18:42 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Tue, 27 Nov 2007 17:18:42 -0500
 Subject: [sup-talk] [PATCH] mode.focus not called when buffer killed
 Message-ID: <1196201559-sup-3731@spooky.local>
 
 r708 changed buffer.rb to set @focus_buf in kill_buffer. The problem with that is that focus_on (called through raise_to_front) sees that @focus_buf is set and returns without doing anything... so mode.focus is never called. Since focus_on will set @focus_buf, I changed kill_buffer back and moved the focus_on call in raise_to_front out of the conditional. I think that should still work as expected.
 
 If I added some tests, would you use them? Some assertions would really help with cases like this.
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: sup-kill-buffer-focus.diff
 Type: application/octet-stream
 Size: 678 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071127/f9132051/attachment.obj 
 
 From marcus-sup@bar-coded.net  Tue Nov 27 17:34:02 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Tue, 27 Nov 2007 22:34:02 +0000
 Subject: [sup-talk] [PATCH] More gmail search goodness
 Message-ID: <1196202259-sup-7348@tomsk>
 
 Simple patch attached. Adds the "during" operator to the date searches
 so you can say during:today or during:november . I prefer it to in/on
 today :)
 
 Also adds an alias for the label search of "is" so that you can do
 more gmail like searches is:starred, is:unread, is:spam, is:deleted.
 The last two required changing the return value to a list/pair in
 parse_user_string_query and I'm not sure what the best way to do this
 in ruby is. For now its a simple list. Also is there a better way to
 deal with a nil result other than returning [nil,nil]? The first
 element is the parsed query string, the second allows the parser to
 add options to the query like :load_spam, :load_deleted which are then
 used in the code already to drop (or not) the spam/deleted labeled
 messages.
 
 I figured you'd never want to search killed threads... and it made the
 patch nastier because of the :skip_killed flag.
 
 I'd like to add a has:attachment operator but the ferret index doesnt
 appear to store enough info for this. It would be really nice to be
 able to search for attachments (of certain types as well with
 filename:...) I took a look at extending the index to add a new field
 "filename" that contains a list of filenames attached to a message,
 but this would break everyones index so I'm just requesting it as a
 wishlist item rather than submitting a patch. With it you could do
 wildcard filename attachment searches and the has:attachment search
 would just be converted to a search for the presence of any filename. 
 
 Marcus
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: more-gmail-search-prefix-patch
 Type: application/octet-stream
 Size: 2972 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071127/311423df/attachment.obj 
 
 From daniel@electricrain.com  Tue Nov 27 20:25:22 2007
 From: daniel@electricrain.com (Dan Sully)
 Date: Tue, 27 Nov 2007 17:25:22 -0800
 Subject: [sup-talk] Syncing from Exchange IMAP
 Message-ID: <20071128012522.GA2951@electricrain.com>
 
 So I really like pain, and am trying to sync from an Exchange server via
 IMAP. Login appears to work ok, but then:
 
 Updating message imaps://owa015.foo.net/Inbox#11848861110123690,
 source 1 => 1, offset 11848861110123690 => 11848861110123690, state {inbox}
 => {inbox}
 
 [Tue Nov 27 17:21:37 -0800 2007] problem getting messages from
 imaps://owa015.foo.net/Inbox: IMAP message mismatch: requested
 11848861110123690, got 11848861110160176.
 
 [Tue Nov 27 17:21:37 -0800 2007] error loading messages from
 imaps://owa015.foo.net/Inbox: IMAP message mismatch: requested
 11848861110123690, got 11848861110160176.
 
 Scanned 1, added 0, updated 1 messages from
 imaps://owa015.foo.net/Inbox.
 
 I've tried with both Inbox and INBOX. Any thoughts? Thunderbird (*spit*)
 talks to the server fine.
 
 -D
 --
 <dsully> please describe web 2.0 to me in 2 sentences or less.
 <jwb> you make all the content. they keep all the revenue.
 
 From andrei@andreimaxim.ro  Tue Nov 27 21:19:43 2007
 From: andrei@andreimaxim.ro (Andrei Maxim)
 Date: Wed, 28 Nov 2007 04:19:43 +0200
 Subject: [sup-talk] to_time_s
 Message-ID: <a630bbc30711271819y8d1d5d1o53e70adc47a6ca15@mail.gmail.com>
 
 Hi guys,
 
 I just grabbed the latest sup using `sudo gem install sup` after seeing the
 announce on RubyTalk, configured my Gmail account and did a `sup-sync` and
 this is what I got:
 
 [Wed Nov 28 03:50:30 +0200 2007] unlocking /Users/andrei/.sup/lock...
 /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:14:in `to_i':
 Infinity (FloatDomainError)
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:14:in
 `to_time_s'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:182
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/poll.rb:158:in
 `add_messages_from'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/imap.rb:170:in
 `each'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/imap.rb:158:in
 `upto'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/imap.rb:158:in
 `each'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/util.rb:533:in
 `send'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/util.rb:533:in
 `__pass'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/util.rb:522:in
 `method_missing'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/poll.rb:140:in
 `add_messages_from'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/util.rb:496:in
 `send'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/lib/sup/util.rb:496:in
 `method_missing'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:134
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:129:in
 `each'
         from /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:129
         from /usr/local/bin/sup-sync:16:in `load'
         from /usr/local/bin/sup-sync:16
 
 Here's the line of the code that's causing the issues:
 
 $stderr.puts "## #{num_scanned} (#{pctdone}%) read; #{elapsed.to_time_s}
 elapsed; #{remaining.to_time_s} remaining"
 
 It seems that the time difference is way too big. The mailbox is not so big,
 around 400 MB according to Gmail, but I have a couple of months of high
 traffic emails like Rails and RubyTalk. Sup detects that I have 66844 emails
 in the INBOX folder.
 
 If needed, I could send a patch.
 
 -- 
 Andrei Maxim
 http://andreimaxim.ro
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071128/d0463ad2/attachment-0001.html 
 
 From alexg@kuicr.kyoto-u.ac.jp  Wed Nov 28 04:17:11 2007
 From: alexg@kuicr.kyoto-u.ac.jp (Alex Gutteridge)
 Date: Wed, 28 Nov 2007 18:17:11 +0900
 Subject: [sup-talk] Exception on start up
 Message-ID: <BAF01BB7-5D51-418D-830B-044583A26FC9@kuicr.kyoto-u.ac.jp>
 
 This was thrown on OSX 10.5.1. Running iTerm 0.9.5.
 
 --- ArgumentError from thread: main
 couldn't initialize curses color pair 4, 0 (key 1)
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/colormap.rb:88:in  
 `color_for'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/colormap.rb:112:in `send'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/colormap.rb:112:in  
 `method_missing'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/buffer.rb:104:in `write'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/scroll-mode.rb:49:in  
 `draw'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/scroll-mode.rb:47:in  
 `each'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/scroll-mode.rb:47:in  
 `draw'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/line-cursor-mode.rb: 
 24:in `draw'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/buffer.rb:95:in `draw'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/buffer.rb:283:in  
 `draw_screen'
 /Library/Ruby/Gems/1.8/gems/sup-0.3/bin/sup:172
 /usr/bin/sup:19:in `load'
 /usr/bin/sup:19
 
 Alex Gutteridge
 
 Bioinformatics Center
 Kyoto University
 
 
 
 From wmorgan-sup@masanjin.net  Wed Nov 28 12:08:45 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 28 Nov 2007 09:08:45 -0800
 Subject: [sup-talk] to_time_s
 In-Reply-To: <a630bbc30711271819y8d1d5d1o53e70adc47a6ca15@mail.gmail.com>
 References: <a630bbc30711271819y8d1d5d1o53e70adc47a6ca15@mail.gmail.com>
 Message-ID: <1196269623-sup-7802@south>
 
 Excerpts from Andrei Maxim's message of Tue Nov 27 18:19:43 -0800 2007:
 > [Wed Nov 28 03:50:30 +0200 2007] unlocking /Users/andrei/.sup/lock...
 > /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:14:in `to_i':
 > Infinity (FloatDomainError)
 
 Heh. Does this patch help?
 
 --- bin/sup-sync        (revision 731)
 +++ bin/sup-sync        (working copy)
 @@ -7,6 +7,9 @@
  
  class Float
    def to_s; sprintf '%.2f', self; end
 +  def to_time_s
 +    infinite? ? "unknown" : super
 +  end
  end
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 28 12:11:50 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 28 Nov 2007 09:11:50 -0800
 Subject: [sup-talk] Syncing from Exchange IMAP
 In-Reply-To: <20071128012522.GA2951@electricrain.com>
 References: <20071128012522.GA2951@electricrain.com>
 Message-ID: <1196269754-sup-8420@south>
 
 Excerpts from Dan Sully's message of Tue Nov 27 17:25:22 -0800 2007:
 > [Tue Nov 27 17:21:37 -0800 2007] problem getting messages from imaps://owa015.foo.net/Inbox: IMAP message mismatch: requested 11848861110123690, got 11848861110160176.
 
 This suggests that Exchange is crazy and is giving different sizes for
 the same message at different points in time.
 
 But that error is only a sanity check (hence "crazy"). If you comment
 out the line that raises it (lib/sup/imap.rb line 276), do things work
 right? Specifically, when you hit enter in thread-index-mode, do you
 actually see the messages you thought you would?
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 28 12:21:59 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 28 Nov 2007 09:21:59 -0800
 Subject: [sup-talk] [PATCH] mode.focus not called when buffer killed
 In-Reply-To: <1196201559-sup-3731@spooky.local>
 References: <1196201559-sup-3731@spooky.local>
 Message-ID: <1196270440-sup-7754@south>
 
 Excerpts from Grant Hollingworth's message of Tue Nov 27 14:18:42 -0800 2007:
 > r708 changed buffer.rb to set @focus_buf in kill_buffer. The problem
 > with that is that focus_on (called through raise_to_front) sees that
 > @focus_buf is set and returns without doing anything... so mode.focus
 > is never called. Since focus_on will set @focus_buf, I changed
 > kill_buffer back and moved the focus_on call in raise_to_front out of
 > the conditional. I think that should still work as expected.
 
 Applied, thanks.
 
 > If I added some tests, would you use them? Some assertions would
 > really help with cases like this.
 
 Sure!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Wed Nov 28 12:27:07 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 28 Nov 2007 09:27:07 -0800
 Subject: [sup-talk] Exception on start up
 In-Reply-To: <BAF01BB7-5D51-418D-830B-044583A26FC9@kuicr.kyoto-u.ac.jp>
 References: <BAF01BB7-5D51-418D-830B-044583A26FC9@kuicr.kyoto-u.ac.jp>
 Message-ID: <1196270623-sup-6328@south>
 
 Excerpts from Alex Gutteridge's message of Wed Nov 28 01:17:11 -0800 2007:
 > This was thrown on OSX 10.5.1. Running iTerm 0.9.5.
 > 
 > --- ArgumentError from thread: main
 > couldn't initialize curses color pair 4, 0 (key 1)
 
 This suggests that ncurses doesn't want to work. Not knowing too much
 about MacOS, are you missing some ncurses libraries?  Have you installed
 the ncurses ruby gem? Are you able to run any other ncurses apps from
 that terminal? (For example, the ncurses gem comes with a couple example
 .rb files. Do they work?)
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From daniel@electricrain.com  Wed Nov 28 13:09:01 2007
 From: daniel@electricrain.com (Dan Sully)
 Date: Wed, 28 Nov 2007 10:09:01 -0800
 Subject: [sup-talk] Syncing from Exchange IMAP
 In-Reply-To: <1196269754-sup-8420@south>
 References: <20071128012522.GA2951@electricrain.com>
 	<1196269754-sup-8420@south>
 Message-ID: <20071128180901.GA22871@electricrain.com>
 
 * William Morgan shaped the electrons to say...
 
 >This suggests that Exchange is crazy and is giving different sizes for
 >the same message at different points in time.
 
 I concur that Exchange is crazy.
 
 >But that error is only a sanity check (hence "crazy"). If you comment
 >out the line that raises it (lib/sup/imap.rb line 276), do things work
 >right? Specifically, when you hit enter in thread-index-mode, do you
 >actually see the messages you thought you would?
 
 Yes, things appear to work right. The mismatch only fails on the first 2
 messages.
 
 -D
 --
 <dsully> please describe web 2.0 to me in 2 sentences or less.
 <jwb> you make all the content. they keep all the revenue.
 
 From brenocon@gmail.com  Wed Nov 28 17:35:23 2007
 From: brenocon@gmail.com (Brendan O'Connor)
 Date: Wed, 28 Nov 2007 22:35:23 +0000
 Subject: [sup-talk] Syncing from Exchange IMAP
 In-Reply-To: <20071128180901.GA22871@electricrain.com>
 References: <20071128012522.GA2951@electricrain.com>
 	<1196269754-sup-8420@south>
 	<20071128180901.GA22871@electricrain.com>
 Message-ID: <1196289275-sup-7343@aa0-000-6.u.powerset.com>
 
 Excerpts from Dan Sully's message of Wed Nov 28 18:09:01 +0000 2007:
 > * William Morgan shaped the electrons to say...
 > 
 > >This suggests that Exchange is crazy and is giving different sizes for
 > >the same message at different points in time.
 > 
 > I concur that Exchange is crazy.
 > 
 > >But that error is only a sanity check (hence "crazy"). If you comment
 > >out the line that raises it (lib/sup/imap.rb line 276), do things work
 > >right? Specifically, when you hit enter in thread-index-mode, do you
 > >actually see the messages you thought you would?
 > 
 > Yes, things appear to work right. The mismatch only fails on the first 2
 > messages.
 
 Yep, I did the same workaround for exchange IMAP and it works for me too.
 
 
 From andrei@andreimaxim.ro  Wed Nov 28 19:58:33 2007
 From: andrei@andreimaxim.ro (Andrei Maxim)
 Date: Thu, 29 Nov 2007 02:58:33 +0200
 Subject: [sup-talk] to_time_s
 In-Reply-To: <1196269623-sup-7802@south>
 References: <a630bbc30711271819y8d1d5d1o53e70adc47a6ca15@mail.gmail.com>
 	<1196269623-sup-7802@south>
 Message-ID: <a630bbc30711281658h3b515c57k529289402eab7ce1@mail.gmail.com>
 
 On 11/28/07, William Morgan <wmorgan-sup at masanjin.net> wrote:
 >
 > Excerpts from Andrei Maxim's message of Tue Nov 27 18:19:43 -0800 2007:
 > > [Wed Nov 28 03:50:30 +0200 2007] unlocking /Users/andrei/.sup/lock...
 > > /usr/local/lib/ruby/gems/1.8/gems/sup-0.3/bin/sup-sync:14:in `to_i':
 > > Infinity (FloatDomainError)
 >
 > Heh. Does this patch help?
 >
 > --- bin/sup-sync        (revision 731)
 > +++ bin/sup-sync        (working copy)
 > @@ -7,6 +7,9 @@
 >
 > class Float
 >    def to_s; sprintf '%.2f', self; end
 > +  def to_time_s
 > +    infinite? ? "unknown" : super
 > +  end
 > end
 >
 
 I have decided to delete most of the emails and it worked ok. But thanks for
 the patch :)
 
 -- 
 Andrei Maxim
 http://andreimaxim.ro
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071129/57c172b4/attachment.html 
 
 From andrei@andreimaxim.ro  Wed Nov 28 20:05:02 2007
 From: andrei@andreimaxim.ro (Andrei Maxim)
 Date: Thu, 29 Nov 2007 03:05:02 +0200
 Subject: [sup-talk] Skipped '.'
 Message-ID: <a630bbc30711281705r3df5f40au11940deb886625f0@mail.gmail.com>
 
 Hi again guys,
 I'm trying to move away from Gmail (mostly because I hate to top post and
 because I'd like to be able to read my emails when I'm offline) to A Better
 Email Client and sup seems a very interesting solution. But the ride isn't
 as smooth as I thought it would be.
 
 I did a sup-config and then a sup-sync. Everything went fine. But when I'm
 starting sup, all I get is "Skipped '.'" and then exits:
 
 
 $ sup
 Skipped '.'
 $
 
 I tried to google around, but it seems to be an odd error. What might be the
 problem? Is there a log or something similar?
 
 I'm running Mac OS X 10.4, I have ncurses installed, I installed every
 dependency for sup and I have the latest 0.3.
 
 Thanks,
 -- 
 Andrei Maxim
 http://andreimaxim.ro
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071129/ce461bce/attachment.html 
 
 From alexg@kuicr.kyoto-u.ac.jp  Wed Nov 28 20:49:34 2007
 From: alexg@kuicr.kyoto-u.ac.jp (Alex Gutteridge)
 Date: Thu, 29 Nov 2007 10:49:34 +0900
 Subject: [sup-talk] Exception on start up
 Message-ID: <2F2233F8-7973-4157-A6B8-600502AD6D6F@kuicr.kyoto-u.ac.jp>
 
 > This was thrown on OSX 10.5.1. Running iTerm 0.9.5.
 >
 > --- ArgumentError from thread: main
 > couldn't initialize curses color pair 4, 0 (key 1)
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/colormap.rb:88:in  
 > `color_for'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/colormap.rb:112:in `send'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/colormap.rb:112:in  
 > `method_missing'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/buffer.rb:104:in `write'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/scroll-mode.rb: 
 > 49:in `draw'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/scroll-mode.rb: 
 > 47:in `each'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/scroll-mode.rb: 
 > 47:in `draw'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/modes/line-cursor- 
 > mode.rb:24:in `draw'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/buffer.rb:95:in `draw'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/lib/sup/buffer.rb:283:in  
 > `draw_screen'
 > /Library/Ruby/Gems/1.8/gems/sup-0.3/bin/sup:172
 > /usr/bin/sup:19:in `load'
 > /usr/bin/sup:19
 
 All the ncurses examples run, but not in color, so there's clearly  
 something going wrong with OSX or my terminal. Curses wont initialize  
 any color pair, so it's seems to be a problem with curses on OSX not  
 sup.
 
 irb(main):001:0> require 'rubygems'
 => true
 irb(main):002:0> require 'curses'
 => true
 irb(main):003:0> require 'ncurses'
 => true
 irb(main):004:0> Curses.init_pair 1, -1, -1
 => false
 irb(main):005:0> Curses.init_pair 1, Curses::COLOR_WHITE,  
 Curses::COLOR_BLACK
 => false
 
 Alex Gutteridge
 
 Bioinformatics Center
 Kyoto University
 
 
 
 From chrisw@rice.edu  Wed Nov 28 23:17:03 2007
 From: chrisw@rice.edu (Christopher Warrington)
 Date: Wed, 28 Nov 2007 22:17:03 -0600
 Subject: [sup-talk] Exception on start up
 In-Reply-To: <2F2233F8-7973-4157-A6B8-600502AD6D6F@kuicr.kyoto-u.ac.jp>
 References: <2F2233F8-7973-4157-A6B8-600502AD6D6F@kuicr.kyoto-u.ac.jp>
 Message-ID: <1196309742-sup-1589@chris-tablet>
 
 Excerpts from Alex Gutteridge's message of Wed Nov 28 19:49:34 -0600 2007:
 > All the ncurses examples run, but not in color, so there's clearly  
 > something going wrong with OSX or my terminal. Curses wont initialize  
 > any color pair, so it's seems to be a problem with curses on OSX not  
 > sup.
 
 If I remember correctly, the Apple Terminal program identified itself as
 "xterm-color". This has caused me problems in the past. Changing it to
 simply "xterm" has fixed it for me with no loss of functionality.
 
 -- 
 Christopher Warrington <chrisw at rice.edu>
 
 
 From wmorgan-sup@masanjin.net  Thu Nov 29 00:44:29 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Wed, 28 Nov 2007 21:44:29 -0800
 Subject: [sup-talk] Skipped '.'
 In-Reply-To: <a630bbc30711281705r3df5f40au11940deb886625f0@mail.gmail.com>
 References: <a630bbc30711281705r3df5f40au11940deb886625f0@mail.gmail.com>
 Message-ID: <1196314902-sup-9299@south>
 
 Excerpts from Andrei Maxim's message of Wed Nov 28 17:05:02 -0800 2007:
 > $ sup
 > Skipped '.'
 > $
 
 That looks like the output of "svn update". Do you have "sup" aliased?
 
 Someone on ruby-talk pointed out that "sup" was the name of an old BSD
 source checkout tool, or something. Maybe you have that installed? A
 "which sup" might clear things up.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From andrei@andreimaxim.ro  Thu Nov 29 01:54:50 2007
 From: andrei@andreimaxim.ro (Andrei Maxim)
 Date: Thu, 29 Nov 2007 08:54:50 +0200
 Subject: [sup-talk] Skipped '.'
 In-Reply-To: <1196314902-sup-9299@south>
 References: <a630bbc30711281705r3df5f40au11940deb886625f0@mail.gmail.com>
 	<1196314902-sup-9299@south>
 Message-ID: <a630bbc30711282254y7012e9acgc452dd5e490286cf@mail.gmail.com>
 
 On 11/29/07, William Morgan <wmorgan-sup at masanjin.net> wrote:
 >
 > Excerpts from Andrei Maxim's message of Wed Nov 28 17:05:02 -0800 2007:
 > > $ sup
 > > Skipped '.'
 > > $
 >
 > That looks like the output of "svn update". Do you have "sup" aliased?
 >
 
 I totally forgot about the sup alias. Thanks, guys.
 Now I'm overwhelmed with memories form the mutt days 8^)
 
 -- 
 Andrei Maxim
 http://andreimaxim.ro
 -------------- next part --------------
 An HTML attachment was scrubbed...
 URL: http://rubyforge.org/pipermail/sup-talk/attachments/20071129/65428552/attachment.html 
 
 From marcus-sup@bar-coded.net  Thu Nov 29 03:51:46 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Thu, 29 Nov 2007 08:51:46 +0000
 Subject: [sup-talk] New from address choosing code borked
 Message-ID: <1196325968-sup-4654@tomsk>
 
 Hi -
 
 Looks like the reply address selection code is broken in svn - most of
 the time it works but on my default account I get a reply (from)
 address of:
 
 <Marcus Williams <Marcus Williams <marcus at .......>>>
 
 or something similar. Is this due to the changes just gone in (updated
 late last night r732?). I think its only reproducible if you reply to
 a message that you sent. Sup does what I'd expect (doesnt reply to me,
 replies to the recipient I sent to) but somehow breaks the from
 address.
 
 Marcus
 
 
 From grant@antiflux.org  Thu Nov 29 10:15:01 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Thu, 29 Nov 2007 10:15:01 -0500
 Subject: [sup-talk] Exception on start up
 In-Reply-To: <2F2233F8-7973-4157-A6B8-600502AD6D6F@kuicr.kyoto-u.ac.jp>
 References: <2F2233F8-7973-4157-A6B8-600502AD6D6F@kuicr.kyoto-u.ac.jp>
 Message-ID: <1196348740-sup-7327@spooky.local>
 
 Excerpts from Alex Gutteridge's message of Wed Nov 28 20:49:34 -0500 2007:
 > All the ncurses examples run, but not in color, so there's clearly  
 > something going wrong with OSX or my terminal. Curses wont initialize  
 > any color pair, so it's seems to be a problem with curses on OSX not  
 > sup.
 > 
 > irb(main):001:0> require 'rubygems'
 > => true
 > irb(main):002:0> require 'curses'
 > => true
 > irb(main):003:0> require 'ncurses'
 > => true
 > irb(main):004:0> Curses.init_pair 1, -1, -1
 > => false
 > irb(main):005:0> Curses.init_pair 1, Curses::COLOR_WHITE,  
 > Curses::COLOR_BLACK
 > => false
 
 Sup works for me, in colour, in Terminal.app. $TERM is set to xterm-color. I'm using ncurses 5.6 from MacPorts.
 
 I get the same results as you in irb. Does curses normally work there?
 
 From grant@antiflux.org  Thu Nov 29 10:50:36 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Thu, 29 Nov 2007 10:50:36 -0500
 Subject: [sup-talk] [PATCH] mode.focus not called when buffer killed
 In-Reply-To: <1196270440-sup-7754@south>
 References: <1196201559-sup-3731@spooky.local> <1196270440-sup-7754@south>
 Message-ID: <1196351158-sup-2243@spooky.local>
 
 Excerpts from William Morgan's message of Wed Nov 28 12:21:59 -0500 2007:
 > Applied, thanks.
 
 I noticed that you used 'focus_on buf' instead of 'focus_on @buffers.last'. I assumed that if @buffers.last.force_to_top? was true, that you'd want to focus on the last buffer instead of the one just moved to @buffers[-2]. Or do you just want to make sure that the force_to_top buffer stays at the end of @buffers?
 
 From grant@antiflux.org  Thu Nov 29 11:22:10 2007
 From: grant@antiflux.org (Grant Hollingworth)
 Date: Thu, 29 Nov 2007 11:22:10 -0500
 Subject: [sup-talk] mailcap for os x
 Message-ID: <1196351498-sup-4803@spooky.local>
 
 run-mailcap(1), which sup uses to view attachments, doesn't exist on OS X.
 
 I used the mime-decode hook to monkey patch Attachment.view! to also use the mime-decode hook. A case statement works as a pretty good replacement for my simple .mailcap.
 
 view_attachment[1] uses file(1) to figure out what an attachment's extension should be, before passing it to open(1). For quicklook I went another way, converting from the MIME type to the OS X UTI[2] using mime2uti, an ugly little program I made.
 
 It's messy, but seems to work for my attachements.
 
 [1] http://filibusta.crema.unimi.it/~gufo/files/view_attachment.sh
 [2] http://en.wikipedia.org/wiki/Uniform_Type_Identifier
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: mime-decode.rb
 Type: application/octet-stream
 Size: 957 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071129/ab231270/attachment.obj 
 -------------- next part --------------
 A non-text attachment was scrubbed...
 Name: mime2uti.m
 Type: application/octet-stream
 Size: 763 bytes
 Desc: not available
 Url : http://rubyforge.org/pipermail/sup-talk/attachments/20071129/ab231270/attachment-0001.obj 
 
 From wmorgan-sup@masanjin.net  Thu Nov 29 13:12:39 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 29 Nov 2007 10:12:39 -0800
 Subject: [sup-talk] New from address choosing code borked
 In-Reply-To: <1196325968-sup-4654@tomsk>
 References: <1196325968-sup-4654@tomsk>
 Message-ID: <1196359948-sup-4655@south>
 
 Excerpts from Marcus Williams's message of Thu Nov 29 00:51:46 -0800 2007:
 > Looks like the reply address selection code is broken in svn - most of
 > the time it works but on my default account I get a reply (from)
 > address of:
 > 
 > <Marcus Williams <Marcus Williams <marcus at .......>>>
 
 Should be fixed. Sorry about that.
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From wmorgan-sup@masanjin.net  Thu Nov 29 13:18:09 2007
 From: wmorgan-sup@masanjin.net (William Morgan)
 Date: Thu, 29 Nov 2007 10:18:09 -0800
 Subject: [sup-talk] [PATCH] mode.focus not called when buffer killed
 In-Reply-To: <1196351158-sup-2243@spooky.local>
 References: <1196201559-sup-3731@spooky.local> <1196270440-sup-7754@south>
 	<1196351158-sup-2243@spooky.local>
 Message-ID: <1196360200-sup-5728@south>
 
 Excerpts from Grant Hollingworth's message of Thu Nov 29 07:50:36 -0800 2007:
 > I noticed that you used 'focus_on buf' instead of 'focus_on
 > @buffers.last'. I assumed that if @buffers.last.force_to_top? was
 > true, that you'd want to focus on the last buffer instead of the one
 > just moved to @buffers[-2]. Or do you just want to make sure that the
 > force_to_top buffer stays at the end of @buffers?
 
 Nope, you're correct. Focus should stay on the force_to_top? buffer,
 regardless of whether something was deleted underneath it. I had tried a
 couple different variations and didn't clean up properly. Thanks again!
 
 -- 
 William <wmorgan-sup at masanjin.net>
 
 From nicolas.pouillard@gmail.com  Fri Nov 30 03:34:13 2007
 From: nicolas.pouillard@gmail.com (Nicolas Pouillard)
 Date: Fri, 30 Nov 2007 09:34:13 +0100
 Subject: [sup-talk] When replying to an attachment...
 Message-ID: <1196411410-sup-5575@ausone.local>
 
 Hi,
 
 Sometimes  some  (bad)  mailers wrap the entire body in an attachment, that is
 considered  by  sup  as  just  an  attachment  (still opened by default). When
 replying  to  this  kind  of  email the original message is not present in the
 answer mode.
 
 That's quite annoying to copy, paste, quote manually to reply to these mails.
 
 TIA,
 -- 
 Nicolas Pouillard aka Ertai
 
 From marcus-sup@bar-coded.net  Fri Nov 30 07:05:27 2007
 From: marcus-sup@bar-coded.net (Marcus Williams)
 Date: Fri, 30 Nov 2007 12:05:27 +0000
 Subject: [sup-talk] Email extensions/alternate emails
 Message-ID: <1196423833-sup-2326@tomsk>
 
 Hi -
 
 I've never quite figured out why I'd add alternate emails to my
 config/accounts. Last time I used them it appeared that emails coming
 into an alternate address used the default email address on that
 account to reply with - is this still the case?
 
 I ask because I'm trying to implement support for email extensions
 basically an email address like name-someotherid at domain.tld where
 -someotherid is the extension. I added an "extensions" config option
 that allowed me to add regexes for my extensions. I then extended
 account_for to return the correct account given an email that matched
 one of these extensions.
 
 But... what I really wanted sup to do then was what I expected it to
 do with alternates, is to reply to an email that came in on one of
 these extensions with the same email address, not with the account
 email address.
 
 What else do I need to do? Is it just a matter of extending the reply
 mode code? To do this should I have to create a dummy account/person
 object for the extension address to be able to use it (this seems to
 be the case)? Is there a better way to handle extensions?
 
 Thanks
 
 Marcus
 
 From a.panek@brainsware.at  Thu Nov 29 01:52:22 2007
 From: a.panek@brainsware.at (Alexander Panek)
 Date: Thu, 29 Nov 2007 07:52:22 +0100
 Subject: [sup-talk] Multiple accounts
 Message-ID: <1196318883-sup-1121@panicroom>
 
 Hey guys,
 
 is it possible to somehow change the used SMTP relayhost at runtime 
 (specifically: the parameters of the MTA, in my case msmtp)?
 
 Thanks in advance.
 
 P.S.: Great job with 0.3, and congratulations for the first anniversary
 
 -- 
 Alexander Panek