From manish at gslab.com Thu Nov 1 00:59:59 2007 From: manish at 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 at baibell.org Thu Nov 1 01:33:26 2007 From: col at 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 at quintic.co.uk Thu Nov 1 05:02:57 2007 From: marcus-sup at 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 at quintic.co.uk Thu Nov 1 05:10:26 2007 From: marcus-sup at 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 at gslab.com Thu Nov 1 08:48:54 2007 From: manish at 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 at antiflux.org Thu Nov 1 13:06:47 2007 From: grant at 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 at zetani.com Thu Nov 1 17:07:20 2007 From: stubbsd at 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 at baibell.org Thu Nov 1 18:09:00 2007 From: col at 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 at uark.edu Thu Nov 1 20:14:55 2007 From: itaylor at 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 at baibell.org Thu Nov 1 21:19:10 2007 From: col at 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 at masanjin.net Thu Nov 1 21:33:44 2007 From: wmorgan-sup at 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 at masanjin.net Thu Nov 1 22:18:19 2007 From: wmorgan-sup at 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 at masanjin.net Thu Nov 1 22:24:46 2007 From: wmorgan-sup at 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 at masanjin.net Thu Nov 1 22:32:19 2007 From: wmorgan-sup at 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 at masanjin.net Thu Nov 1 22:35:15 2007 From: wmorgan-sup at 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 at masanjin.net Thu Nov 1 22:36:02 2007 From: wmorgan-sup at 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 at masanjin.net Thu Nov 1 23:02:44 2007 From: wmorgan-sup at 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 at masanjin.net Thu Nov 1 23:54:43 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 2 00:02:38 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 2 00:10:20 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 2 00:12:25 2007 From: wmorgan-sup at 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 at quintic.co.uk Fri Nov 2 06:01:16 2007 From: marcus-sup at 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 at baillet.name Fri Nov 2 07:21:30 2007 From: pierre at 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 at quintic.co.uk Fri Nov 2 08:18:19 2007 From: marcus-sup at 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 at quintic.co.uk Fri Nov 2 08:55:15 2007 From: marcus-sup at 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 at masanjin.net Fri Nov 2 11:17:58 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 2 11:23:48 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 2 15:07:37 2007 From: wmorgan-sup at 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 at gslab.com Sat Nov 3 06:39:21 2007 From: manish at 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 at bar-coded.net Sat Nov 3 16:20:48 2007 From: marcus-sup at 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 at masanjin.net Sat Nov 3 17:17:27 2007 From: wmorgan-sup at 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 at bar-coded.net Sat Nov 3 17:35:55 2007 From: marcus-sup at 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 at masanjin.net Sat Nov 3 18:12:07 2007 From: wmorgan-sup at 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 at masanjin.net Sat Nov 3 18:23:23 2007 From: wmorgan-sup at 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 at masanjin.net Sat Nov 3 18:25:36 2007 From: wmorgan-sup at 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 at masanjin.net Sun Nov 4 21:40:58 2007 From: wmorgan-sup at 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 at masanjin.net Sun Nov 4 21:46:21 2007 From: wmorgan-sup at 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 at masanjin.net Sun Nov 4 22:15:51 2007 From: wmorgan-sup at 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 at masanjin.net Sun Nov 4 22:17:57 2007 From: wmorgan-sup at 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 at bar-coded.net Mon Nov 5 04:54:17 2007 From: marcus-sup at 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 at baibell.org Mon Nov 5 05:01:31 2007 From: col at 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 at bar-coded.net Mon Nov 5 10:03:40 2007 From: marcus-sup at 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 at masanjin.net Mon Nov 5 10:38:45 2007 From: wmorgan-sup at 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 at masanjin.net Mon Nov 5 10:44:12 2007 From: wmorgan-sup at 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 at uark.edu Mon Nov 5 13:26:24 2007 From: itaylor at 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 at masanjin.net Mon Nov 5 13:37:17 2007 From: wmorgan-sup at 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 at uark.edu Mon Nov 5 14:27:23 2007 From: itaylor at 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 at deri.org Mon Nov 5 15:37:07 2007 From: eyal.oren at 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 at masanjin.net Mon Nov 5 19:24:32 2007 From: wmorgan-sup at 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 at masanjin.net Mon Nov 5 19:42:11 2007 From: wmorgan-sup at 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 at brainsware.org Tue Nov 6 03:57:36 2007 From: alexander.panek at 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 at gslab.com Tue Nov 6 04:37:27 2007 From: manish at 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 at bar-coded.net Tue Nov 6 05:00:00 2007 From: marcus-sup at 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 at bar-coded.net Tue Nov 6 05:02:13 2007 From: marcus-sup at 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 at bar-coded.net Tue Nov 6 05:05:42 2007 From: marcus-sup at 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 at bar-coded.net Tue Nov 6 05:25:04 2007 From: marcus-sup at 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 at bar-coded.net Tue Nov 6 08:39:49 2007 From: marcus-sup at 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 at timvaughan.co.uk Tue Nov 6 08:52:27 2007 From: tim at 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 at bar-coded.net Tue Nov 6 09:10:12 2007 From: marcus-sup at 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 at deri.org Tue Nov 6 09:19:29 2007 From: eyal.oren at 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 at bar-coded.net Tue Nov 6 10:05:28 2007 From: marcus-sup at 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 at masanjin.net Tue Nov 6 17:41:37 2007 From: wmorgan-sup at 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 at uark.edu Tue Nov 6 17:57:25 2007 From: itaylor at 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 at masanjin.net Tue Nov 6 17:59:37 2007 From: wmorgan-sup at 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 at masanjin.net Tue Nov 6 19:18:41 2007 From: wmorgan-sup at 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 at masanjin.net Tue Nov 6 20:55:22 2007 From: wmorgan-sup at 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 at masanjin.net Tue Nov 6 20:55:37 2007 From: wmorgan-sup at 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 at masanjin.net Tue Nov 6 20:55:53 2007 From: wmorgan-sup at 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 at masanjin.net Tue Nov 6 20:56:31 2007 From: wmorgan-sup at 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 at masanjin.net Tue Nov 6 21:09:46 2007 From: wmorgan-sup at 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 at baibell.org Tue Nov 6 22:55:17 2007 From: col at 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 at bar-coded.net Wed Nov 7 03:53:35 2007 From: marcus-sup at 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 at deri.org Wed Nov 7 04:21:57 2007 From: eyal.oren at 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 at gslab.com Wed Nov 7 04:32:59 2007 From: manish at 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 at gslab.com Wed Nov 7 04:35:07 2007 From: manish at 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 at bar-coded.net Wed Nov 7 04:43:47 2007 From: marcus-sup at 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 at bar-coded.net Wed Nov 7 04:53:16 2007 From: marcus-sup at 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 at baibell.org Wed Nov 7 05:29:03 2007 From: col at 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 at linkswarm.com Wed Nov 7 09:25:27 2007 From: vasudeva at 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 at bar-coded.net Wed Nov 7 11:34:32 2007 From: marcus-sup at 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 at masanjin.net Wed Nov 7 12:35:11 2007 From: wmorgan-sup at 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 at masanjin.net Wed Nov 7 12:41:36 2007 From: wmorgan-sup at 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 at rice.edu Wed Nov 7 13:38:19 2007 From: chrisw at 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 at masanjin.net Wed Nov 7 15:08:50 2007 From: wmorgan-sup at 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 at masanjin.net Wed Nov 7 15:38:30 2007 From: wmorgan-sup at 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 at masanjin.net Wed Nov 7 15:39:26 2007 From: wmorgan-sup at 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 at masanjin.net Wed Nov 7 15:41:46 2007 From: wmorgan-sup at 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 at bar-coded.net Wed Nov 7 16:05:58 2007 From: marcus-sup at 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 at bar-coded.net Wed Nov 7 16:09:10 2007 From: marcus-sup at 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 at baibell.org Wed Nov 7 16:56:21 2007 From: col at 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 at masanjin.net Wed Nov 7 18:12:03 2007 From: wmorgan-sup at 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 at masanjin.net Wed Nov 7 20:40:48 2007 From: wmorgan-sup at 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 at masanjin.net Wed Nov 7 21:08:00 2007 From: wmorgan-sup at 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 at gslab.com Thu Nov 8 00:15:09 2007 From: manish at 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 at bar-coded.net Thu Nov 8 03:31:35 2007 From: marcus-sup at 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 at verizon.net Thu Nov 8 03:49:10 2007 From: kevin.mark at 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 at baillet.name Thu Nov 8 05:22:29 2007 From: pierre at 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 at bar-coded.net Thu Nov 8 05:44:44 2007 From: marcus-sup at 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 at bar-coded.net Thu Nov 8 06:18:51 2007 From: marcus-sup at 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 at bar-coded.net Thu Nov 8 06:21:06 2007 From: marcus-sup at 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 at linkswarm.com Thu Nov 8 07:10:27 2007 From: vasudeva at 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 at deri.org Thu Nov 8 10:47:30 2007 From: eyal.oren at 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 at deri.org Thu Nov 8 10:51:30 2007 From: eyal.oren at 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 at gurski.org Thu Nov 8 11:57:26 2007 From: sup-talk at 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 at gurski.org Thu Nov 8 09:56:38 2007 From: sup-talk at 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 at bar-coded.net Fri Nov 9 02:40:32 2007 From: marcus-sup at 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 at bar-coded.net Fri Nov 9 10:33:35 2007 From: marcus-sup at 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 at masanjin.net Fri Nov 9 13:46:52 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 9 14:04:43 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 9 14:07:05 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 9 14:09:17 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 9 14:10:05 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 9 14:13:45 2007 From: wmorgan-sup at 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 at masanjin.net Fri Nov 9 14:17:21 2007 From: wmorgan-sup at 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 at bar-coded.net Fri Nov 9 15:29:58 2007 From: marcus-sup at 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 at bar-coded.net Fri Nov 9 15:44:08 2007 From: marcus-sup at 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 at bar-coded.net Fri Nov 9 16:20:33 2007 From: marcus-sup at 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 at masanjin.net Sun Nov 11 18:57:55 2007 From: wmorgan-sup at 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