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 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 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 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 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 :117 in xpop_context > Error occured in fs_store.c:70 - fs_exists > checking existance of /home/chrisw/.sup/ferret/_g9c.cfs: 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 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: References: 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 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 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 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 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 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 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 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: <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 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 > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > -- Pierre Baillet -------------- 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: <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 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 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 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 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 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 , 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 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 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 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 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 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 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 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 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 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 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 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 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 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: "" when :enter, :return: "" when :ctrl_l: "ctrl-l" - when :ctrl_l: "ctrl-g" + when :ctrl_g: "ctrl-g" when :tab: "tab" when " ": "" 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 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 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 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 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 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 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 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. /> 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 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 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 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 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 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 ). -- William 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 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 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 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 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 ). > > 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 -------------- 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 ? ;) /> 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 #' (error type NoMethodError) A backtrace follows: ./lib/sup/modes/thread-index-mode.rb:71:in `contains_thread?': undefined method `contains?' for # (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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 . 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 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 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. /> 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 -------------- 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 -------------- 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 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 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 -------------- 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 -------------- 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 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 > 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 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 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 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 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 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 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 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. /> 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 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 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 :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 :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 -------------- 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 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 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 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 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 :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 :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 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 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 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 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 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 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 > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > -- Pierre Baillet -------------- 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 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 :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 :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 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 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 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 #' (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 # (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 -------------- 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 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 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 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 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 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 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 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 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 -- please describe web 2.0 to me in 2 sentences or less. 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: 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: 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: References: 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 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 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 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: References: 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 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 -- please describe web 2.0 to me in 2 sentences or less. 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: <1196269623-sup-7802@south> Message-ID: On 11/28/07, William Morgan 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: 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 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: References: 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 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: <1196314902-sup-9299@south> Message-ID: On 11/29/07, William Morgan 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: >> 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: > > >> Should be fixed. Sorry about that. -- William 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 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