From bwalton@artsci.utoronto.ca Fri May 1 12:54:47 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 1 May 2009 12:54:47 -0400 Subject: [sup-talk] [PATCH] Keymap: make new + (apply to tagged) behaviour nicer Message-ID: <1241196888-16400-1-git-send-email-bwalton@artsci.utoronto.ca> Ok, so I updated to the next branch to work on updating/polishing the flexible sent source patch and the new + key for apply to tagged behaviour is driving me nuts. I had a lot of muscle memory built up around the semi-colon, so it's a tough adjustment for me. I'm willing to make it, of course, since I think the overall reasoning is sound. That being said, mapping = to do the same thing as + will save having to hold shift to access this. I hope this is ok. Patch to follow. Thanks -Ben From bwalton@artsci.utoronto.ca Fri May 1 12:54:48 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 1 May 2009 12:54:48 -0400 Subject: [sup-talk] [PATCH] Keymap: make new + (apply to tagged) behaviour nicer In-Reply-To: <1241196888-16400-1-git-send-email-bwalton@artsci.utoronto.ca> References: <1241196888-16400-1-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1241196888-16400-2-git-send-email-bwalton@artsci.utoronto.ca> Make = a synonym for + in the thread index mode so that shift isn't required to apply an action to all tagged messages. --- lib/sup/modes/thread-index-mode.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 7b87bf6..b44dc18 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -42,7 +42,7 @@ EOS k.add :toggle_tagged, "Tag/untag selected thread", 't' k.add :toggle_tagged_all, "Tag/untag all threads", 'T' k.add :tag_matching, "Tag matching threads", 'g' - k.add :apply_to_tagged, "Apply next command to all tagged threads", '+' + k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '=' k.add :join_threads, "Force tagged threads to be joined into the same thread", '#' k.add :undo, "Undo the previous action", 'u' end -- 1.6.2.1 From sgoldman@tower-research.com Fri May 1 16:23:53 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Fri, 01 May 2009 16:23:53 -0400 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> <1241028590-sup-8155@entry> <1241075456-sup-909@h984274.serverkompetenz.net> <1241095872-sup-9569@sgoldmanlinux.tower-research.com> <1241098531-sup-1508@entry> <1241101364-sup-9621@sgoldmanlinux.tower-research.com> Message-ID: <1241209146-sup-3561@sgoldmanlinux.tower-research.com> I have found the offensive commit... Whoever was working on this, can you take a look and figure out where the bug is? (And for all you perl bashers out there, given this ridiculous line of ruby, you officially can't talk any more shit.) 063ec996a24b13b5dc9a59e21aa42ba629ab510a --- a/lib/sup/poll.rb +++ b/lib/sup/poll.rb @@ -97,7 +97,7 @@ EOS numi = 0 add_messages_from source do |m, offset, entry| ## always preserve the labels on disk. - m.labels = entry[:label].split(/\s+/).map { |x| x.intern } if entry + m.labels = ((m.labels - [:unread, :inbox]) + entry[:label].split(/\s+/).map { |x| x.intern }).uniq if entry yield "Found message at #{offset} with labels {#{m.labels * ', '}}" unless entry num += 1 -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From wmorgan-sup@masanjin.net Mon May 4 08:59:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 05:59:49 -0700 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <1240267632-sup-2023@r50p> <3f81a4240904201638v94a7dbdpce0d865cd83d8873@mail.gmail.com> <1240318807-sup-3080@entry> <3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com> <1240323082-sup-1515@entry> <3f81a4240904210729h74ac436bn9e1140cf7021c5ad@mail.gmail.com> <3f81a4240904210732k11366cf7naec562af54ecabac@mail.gmail.com> <1241045035-sup-1534@entry> Message-ID: <1241441484-sup-8964@entry> Reformatted excerpts from Ben Walton's message of 2009-04-30: > Since I'm back into mucking with this bit, are you open to having the > maildir scanning code move messages from new/ to cur/? This could > help with the unique id vs directory scanning issue. Would it really help? I'd be willing if so, but I don't see how. Maybe I'm missing something. I've avoided moving new/ to cur/ because I didn't see any benefit to Sup, and it conflicts with the hands-off philosophy, so it just seemed like one more thing we could screw up. But if there is a real reason to do it, I'd probably be willing. -- William From wmorgan-sup@masanjin.net Mon May 4 09:32:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 06:32:04 -0700 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1241209146-sup-3561@sgoldmanlinux.tower-research.com> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> <1241028590-sup-8155@entry> <1241075456-sup-909@h984274.serverkompetenz.net> <1241095872-sup-9569@sgoldmanlinux.tower-research.com> <1241098531-sup-1508@entry> <1241101364-sup-9621@sgoldmanlinux.tower-research.com> <1241209146-sup-3561@sgoldmanlinux.tower-research.com> Message-ID: <1241443759-sup-9889@entry> Reformatted excerpts from Steve Goldman's message of 2009-05-01: > I have found the offensive commit... Interesting. I think I see the problem. Were all the messages that magically reappeared in your inbox messages that were sent to mailing lists, or otherwise messages that somehow appeared twice in your inbox? > (And for all you perl bashers out there, given this ridiculous line > of ruby, you officially can't talk any more shit.) No one here has bashed Perl. Personally I prefer bashing Python (when I'm not too busy bashing Java (when I'm not too busy bashing C++)), and credit Perl for much of what I like about Ruby. -- William From bdwalton@gmail.com Mon May 4 09:41:17 2009 From: bdwalton@gmail.com (Ben Walton) Date: Mon, 4 May 2009 09:41:17 -0400 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <1241441484-sup-8964@entry> References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <1240318807-sup-3080@entry> <3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com> <1240323082-sup-1515@entry> <3f81a4240904210729h74ac436bn9e1140cf7021c5ad@mail.gmail.com> <3f81a4240904210732k11366cf7naec562af54ecabac@mail.gmail.com> <1241045035-sup-1534@entry> <1241441484-sup-8964@entry> Message-ID: On Mon, May 4, 2009 at 8:59 AM, William Morgan wrote: > Reformatted excerpts from Ben Walton's message of 2009-04-30: >> Since I'm back into mucking with this bit, are you open to having the >> maildir scanning code move messages from new/ to cur/? This could >> help with the unique id vs directory scanning issue. > > Would it really help? I'd be willing if so, but I don't see how. Maybe > I'm missing something. Scan both folders (cur/, new/) on startup or sup-sync. After that, scan only new. Since mail is moved out of new/ into cur/ after detection, the time stamp stuff could be dropped since it would be redundant anyway. I think I'd confused myself about the id generation issue, so it wouldn't likely be of benefit there. > I've avoided moving new/ to cur/ because I didn't see any benefit to > Sup, and it conflicts with the hands-off philosophy, so it just seemed > like one more thing we could screw up. But if there is a real reason to > do it, I'd probably be willing. Sup would be a better Maildir citizen, since this is the intended way to access/use a maildir source. -Ben -- --------------------------------------------------------------------------------------------------------------------------- Ben Walton "With or without religion, good people can behave well and bad people can do evil; but for good people to do evil?that takes religion. " -Steven Weinberg --------------------------------------------------------------------------------------------------------------------------- From sgoldman@tower-research.com Mon May 4 09:46:35 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Mon, 04 May 2009 09:46:35 -0400 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1241443759-sup-9889@entry> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> <1241028590-sup-8155@entry> <1241075456-sup-909@h984274.serverkompetenz.net> <1241095872-sup-9569@sgoldmanlinux.tower-research.com> <1241098531-sup-1508@entry> <1241101364-sup-9621@sgoldmanlinux.tower-research.com> <1241209146-sup-3561@sgoldmanlinux.tower-research.com> <1241443759-sup-9889@entry> Message-ID: <1241444694-sup-9120@sgoldmanlinux.tower-research.com> Excerpts from William Morgan's message of Mon May 04 09:32:04 -0400 2009: > Reformatted excerpts from Steve Goldman's message of 2009-05-01: > > I have found the offensive commit... > > Interesting. I think I see the problem. Were all the messages that > magically reappeared in your inbox messages that were sent to mailing > lists, or otherwise messages that somehow appeared twice in your inbox? Most of the messages I archive come from lists, so this is possible. The lists I'm on are smart enough to not deliver messages twice, most of the time. > > (And for all you perl bashers out there, given this ridiculous line > > of ruby, you officially can't talk any more shit.) > > No one here has bashed Perl. Personally I prefer bashing Python (when > I'm not too busy bashing Java (when I'm not too busy bashing C++)), and > credit Perl for much of what I like about Ruby. Live and let live!! -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From wmorgan-sup@masanjin.net Mon May 4 10:24:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 07:24:15 -0700 Subject: [sup-talk] [PATCH] Keymap: make new + (apply to tagged) behaviour nicer In-Reply-To: <1241196888-16400-2-git-send-email-bwalton@artsci.utoronto.ca> References: <1241196888-16400-1-git-send-email-bwalton@artsci.utoronto.ca> <1241196888-16400-2-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1241446972-sup-1257@entry> Reformatted excerpts from Ben Walton's message of 2009-05-01: > Make = a synonym for + in the thread index mode so that shift isn't > required to apply an action to all tagged messages. Good idea. Can you make this change against the better-buffer-list branch instead of next? It's not applying as is. -- William From wmorgan-sup@masanjin.net Mon May 4 10:28:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 07:28:43 -0700 Subject: [sup-talk] [PATCH] Bug fixes and speed improvements for maildir handling. In-Reply-To: References: Message-ID: <1241447258-sup-9435@entry> Reformatted excerpts from Mark Alexander's message of 2009-04-21: > --- > lib/sup/maildir.rb | 10 +++++++--- > 1 files changed, 7 insertions(+), 3 deletions(-) I think I'm going to drop this patch, as the Maildir code is going to get changed in other ways very shortly. -- William From wmorgan-sup@masanjin.net Mon May 4 10:35:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 07:35:20 -0700 Subject: [sup-talk] possible mbox "initial From" fix In-Reply-To: <6bb609560904291751n3cc62f46g6a4edcba1f97d6f7@mail.gmail.com> References: <1241027916-sup-7642@entry> <6bb609560904291751n3cc62f46g6a4edcba1f97d6f7@mail.gmail.com> Message-ID: <1241447393-sup-7632@entry> Reformatted excerpts from Bart Schaefer's message of 2009-04-29: > We found that in most cases this failed at (1) or succeeded very > quickly at (6a). Only obscure cases proceed to (7), but if you're > dealing with anything like old USENET news archives or folders written > by '80s-era mail clients you need either step (4) or step (7) to get > past the cruft. > > Note that the key is finding "From ... DATE" rather than "From ADDRESS > ..." if you really want to distinguish message separators from stuff > people type in a message body. I'm not sure you can do this with a > regular expression. Thanks! This is really helpful. I am a little worried about the current fix, since there's no real requirement that an email address have an @ sign in it for local users, and that will result in false negatives, and there's a non-trivial potential for false positives. If we went this route (which wouldn't require a big changeset), I may punt on parsing the date myself and just rely on Time.parse. Speed shouldn't really be affected (except in weird pathological cases) since the date parsing will be a second step. I like it. -- William From bwalton@artsci.utoronto.ca Mon May 4 10:44:11 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 4 May 2009 10:44:11 -0400 Subject: [sup-talk] [PATCH] Keymap: improve behaviour of apply to tagged in thread index Message-ID: <1241448251-21371-1-git-send-email-bwalton@artsci.utoronto.ca> Make = a synonym for + in the thread index mode so that shift isn't required to apply an action to all tagged messages. Signed-off-by: Ben Walton --- This is the requeste resend against better-buffer-list. -Ben lib/sup/modes/thread-index-mode.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 0bce0de..a45175d 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -42,7 +42,7 @@ EOS k.add :toggle_tagged, "Tag/untag selected thread", 't' k.add :toggle_tagged_all, "Tag/untag all threads", 'T' k.add :tag_matching, "Tag matching threads", 'g' - k.add :apply_to_tagged, "Apply next command to all tagged threads", '+' + k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '=' k.add :join_threads, "Force tagged threads to be joined into the same thread", '#' end -- 1.6.2.1 From wmorgan-sup@masanjin.net Mon May 4 10:48:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 07:48:23 -0700 Subject: [sup-talk] [PATCH] Keymap: improve behaviour of apply to tagged in thread index In-Reply-To: <1241448251-21371-1-git-send-email-bwalton@artsci.utoronto.ca> References: <1241448251-21371-1-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1241448496-sup-8476@entry> Reformatted excerpts from Ben Walton's message of 2009-05-04: > Make = a synonym for + in the thread index mode so that shift isn't > required to apply an action to all tagged messages. Applied, thanks! -- William From wmorgan-sup@masanjin.net Mon May 4 12:10:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 09:10:23 -0700 Subject: [sup-talk] Possible problem with maildir ID generation In-Reply-To: <20090429233820.GA14143@cabinet.hsd1.ma.comcast.net> References: <1240320547-sup-6957@entry> <20090428191822.GB10581@cabinet.hsd1.ma.comcast.net> <1241038730-sup-2939@entry> <20090429233820.GA14143@cabinet.hsd1.ma.comcast.net> Message-ID: <1241451919-sup-8970@entry> Reformatted excerpts from Marc Hartstein's message of 2009-04-29: > On Wed, Apr 29, 2009 at 03:31:52PM -0700, William Morgan wrote: > > (All this rigamarole about ordinals and blah blah blah is necessary > > because I don't want Sup to rescan the entire Maildir unless absolutely > > necessary. One day I'll convert my mbox to a Maildir with 250k files in > > it, and a rescan will kill me, especially at Ruby speed.) > > How are we defining 'rescan' here? I can think of a couple of possible > meanings, and I'm not sure where you are: > > 1. Open every file in the maildir and read from it, every poll. > 2. Visit every filename in the maildir to consider whether it is a new > file, every poll. > 3. Something else I'm not thinking of this instant. You're probably confused because what I said was wrong. Here's what I should have said: Rescanning the entire directory to check for new mail is unavoidable in Maildir. What I *do* have some control over, i.e. can try to optimize, is the following operation: given a file in the directory, does it represent a new message? One way to do this would be to maintain a set of all filenames representing read messages, and to check for existence within the set, for every file. Sup doesn't do this; instead it defines an ordering on filenames, such that newer filenames are "larger" than older filenames under that ordering, and maintains a threshold representing the dividing point between new and old. The idea being that performing that comparison is quick, and that storing the set of read messages is also quick. (And again, I care about the case where you have 500k messages, and so doing set existence is painful. Although perhaps Bloom filters are the solution... that would be interesting!) > So the only way you're going to get a timestamp collision (on the > filename timestamp, perhaps not on the actual ctime) is if you have > multiple processes delivering mail simultaneously, or if you're > synchronizing mail delivered on multiple hosts. In the case of the > latter, a timestamp-based heuristic for finding new messages isn't > going to work. I think the collisions we are seeing are due to timestamp granularity. A little research suggests that e.g. ext2fs ctimes are 1-second granular. It seems quite easy to get more than one email per second. > Would it suffice to keep track of the filename of the most recent > message added for each maildir source, and check everything with a > time portion of the filename equal to or greater than that message for > whether it needs to be added? [although see above about whether that > gains anything] Yes, I think that's the solution. Basically switch from > to >= when comparing timestamps, and realize that you're going to get some dupes. > Having looked into this more closely, I'm starting to seriously > reconsider whether maildir is really what I want to be using for storing > my mail. There are some weird timing issues. Well, mbox has the advantage of being nice and linear so this problem goes away, but is horribly broken in other ways (c.f. the recent thread about the "From problem"). IMAP is a ridiculous PITA to deal with (at least as a client), so you're kinda screwed in every direction here. If anything, Maildir is less broken than the other alternatives. Plus Maildir works really well with git. :) -- William From wmorgan-sup@masanjin.net Mon May 4 12:22:45 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 04 May 2009 09:22:45 -0700 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <1240318807-sup-3080@entry> <3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com> <1240323082-sup-1515@entry> <3f81a4240904210729h74ac436bn9e1140cf7021c5ad@mail.gmail.com> <3f81a4240904210732k11366cf7naec562af54ecabac@mail.gmail.com> <1241045035-sup-1534@entry> <1241441484-sup-8964@entry> Message-ID: <1241453755-sup-6000@entry> Reformatted excerpts from Ben Walton's message of 2009-05-04: > Scan both folders (cur/, new/) on startup or sup-sync. After that, > scan only new. Since mail is moved out of new/ into cur/ after > detection, the time stamp stuff could be dropped since it would be > redundant anyway. Crap, I think you're right. Polling will be trivial and no more messing around with timestamps. In fact I don't even have to scan cur/ on startup; I can just assume it's unchanged. If you screw with the Maildir via another MUA you have to run sup-sync --changed, just like with every other source. For this to work, the "offset" for each message will have to be its filename. I wonder how many implicit assumptions that will violate. -- William From marka@pobox.com Mon May 4 13:24:10 2009 From: marka@pobox.com (Mark Alexander) Date: Mon, 4 May 2009 13:24:10 -0400 Subject: [sup-talk] Possible problem with maildir ID generation In-Reply-To: <20090504165224.GA15815@cabinet.hsd1.ma.comcast.net> References: <1240320547-sup-6957@entry> <20090428191822.GB10581@cabinet.hsd1.ma.comcast.net> <1241038730-sup-2939@entry> <20090429233820.GA14143@cabinet.hsd1.ma.comcast.net> <1241451919-sup-8970@entry> <20090504165224.GA15815@cabinet.hsd1.ma.comcast.net> Message-ID: On Mon, May 4, 2009 at 12:52 PM, Marc Hartstein wrote: > On Mon, May 04, 2009 at 09:10:23AM -0700, William Morgan wrote: >> I think the collisions we are seeing are due to timestamp granularity. >> A little research suggests that e.g. ext2fs ctimes are 1-second >> granular. It seems quite easy to get more than one email per second. > > It does, but as I mentioned somewhere in that email, the reference > implementation of maildir (qmail) says that it will only deliver one > message per second. ?However, I definitely concede that relying on this > behavior would be setting things up for something to go wrong down the > line. Just a data point: in my setup (postfix+procmail) I'm seeing multiple messages being delivered to the same maildir in the same second. That was what motivated my patch. From bdwalton@gmail.com Wed May 6 20:02:26 2009 From: bdwalton@gmail.com (Ben Walton) Date: Wed, 6 May 2009 20:02:26 -0400 Subject: [sup-talk] sent source Message-ID: Hi All, I wanted to poll for thoughts on how to handle a generic mbox as the sent source. My concern is how to deal with file locking...this is one of the nastier aspects of mbox files. The cop-out approach is to allow the user to select any mbox source configured as the outbox and admonish them not to use it for incoming mail too...that puts us in the same place as ~/.sup/sent.mbox is now. Doing this does open sup to user error though and the potential for trashed mboxes. The next option is to play with locks, but that's not straight forward at all. Dovecot, as an example, allows a configuration knob for the admin to set the order in which the different mechanisms are used. This works as long as all of the mbox consumers use the same sequence. There is still lots of room for error here (NFS, etc). Option 3 is to simply limit the mbox sent source to the SentLoader class which means that 'regular' mbox files available to the user can't be a destination for sent mail. None of these solutions is perfect, and all suck compared to their maildir or imap counterparts (I'm not even going to bother with ssh+mbox). What do other 'suppers' think about this? Thanks -Ben -- --------------------------------------------------------------------------------------------------------------------------- Ben Walton "With or without religion, good people can behave well and bad people can do evil; but for good people to do evil?that takes religion. " -Steven Weinberg --------------------------------------------------------------------------------------------------------------------------- From bdwalton@gmail.com Wed May 6 23:11:09 2009 From: bdwalton@gmail.com (Ben Walton) Date: Wed, 6 May 2009 23:11:09 -0400 Subject: [sup-talk] flexible sent (wip) Message-ID: Hi All, For those interested in the ability to store mail in places other than the sent.mbox file in the $SUP_BASE directory, you can see my work in progress by checking out the bw/flexible_sent branch available from: git://code.chass.utoronto.ca/bwalton-sup.git This code is branched from a very recent next on WIlliam's mainline. The present state of the code is working in my tests (I've played with IMAP and Maildir, but mbox is also a possibility if you're brave...see my previous message). I haven't added the sup-config part yet, so you're still required to add a :sent_source: line to your config.yaml to enable it. You can setup a testing area (eg separate ferret index, config, etc) by running sup with SUP_BASE=/some/alternate/.sup/dir if you want to get a feel for it without touching your working setup. Comments and feedback are welcome. Thanks -Ben -- --------------------------------------------------------------------------------------------------------------------------- Ben Walton "With or without religion, good people can behave well and bad people can do evil; but for good people to do evil?that takes religion. " -Steven Weinberg --------------------------------------------------------------------------------------------------------------------------- From flips@luminated.net Thu May 7 06:38:47 2009 From: flips@luminated.net (Filip Stokkeland) Date: Thu, 7 May 2009 12:38:47 +0200 Subject: [sup-talk] IMAP questions (n00b) :) Message-ID: <24cc29320905070338u1e23c6d3sa78c20dd0da60b19@mail.gmail.com> Hi! I just discovered and started testing Sup. And it looks great! I tried browsing through some of the mailing list archives, and I found postings saying Sup does not sync back to IMAP(S). So I take it then, that when I mark mail as read or as spam, nothing happens on the IMAP server, but only in the local Sup index? And another thing. I have my main work email today sorted on the server, using Sieve, so I get new email sorted into 40 different IMAP folders. In Sup, can I get it to automatically fetch from all subscribed IMAP folders? Or maybe I should rather fetch all this email into my own local server using fetchmail or something and then either put it all in one big inbox or multiple mboxes locally and then add this as source? Best regards -- Filip From flips@luminated.net Thu May 7 07:58:02 2009 From: flips@luminated.net (Filip Stokkeland) Date: Thu, 7 May 2009 13:58:02 +0200 Subject: [sup-talk] /usr/bin/run-mailcap Message-ID: <24cc29320905070458g7b970ea4rbfcc469d6afc3a3d@mail.gmail.com> In Sup, installed on a RHEL 5.1 with EPEL, using gems, when I select f.ex. html attachments, I just get an error that view doesn't work and I get the plain text. A quick grep in the code reveals this: lib/sup/message-chunks.rb: cmd = "/usr/bin/run-mailcap --action=view '#{@content_type}:#{path}' 2>/dev/null" I can't find run-mailcap on this RedHat installation. "yum whatprovides" didn't help and the mailcap package had no such file installed: # rpm -ql mailcap /etc/mailcap /etc/mime.types /usr/share/man/man4/mailcap.4.gz Maybe run-mailcap a Debian/Ubuntu thing? (I'll be back on my regular ubuntu installation soon enough anyway, just using a lab machine right now.) In Mutt I don't believe I did anything except use my default .mailcap ... Cheers. -- Filip From wmorgan-sup@masanjin.net Thu May 7 09:07:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 07 May 2009 06:07:32 -0700 Subject: [sup-talk] /usr/bin/run-mailcap In-Reply-To: <24cc29320905070458g7b970ea4rbfcc469d6afc3a3d@mail.gmail.com> References: <24cc29320905070458g7b970ea4rbfcc469d6afc3a3d@mail.gmail.com> Message-ID: <1241701545-sup-3821@entry> Reformatted excerpts from Filip Stokkeland's message of 2009-05-07: > Maybe run-mailcap a Debian/Ubuntu thing? (I'll be back on my regular > ubuntu installation soon enough anyway, just using a lab machine right > now.) In Mutt I don't believe I did anything except use my default > .mailcap ... It could very well be a Debianism. Is there a good alternative for RedHat, or does Sup have to start manually parsing ~/.mailcap, /etc/mailcap/, etc? -- William From wmorgan-sup@masanjin.net Thu May 7 09:23:33 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 07 May 2009 06:23:33 -0700 Subject: [sup-talk] sent source In-Reply-To: References: Message-ID: <1241702060-sup-3211@entry> Reformatted excerpts from Ben Walton's message of 2009-05-06: > The next option is to play with locks, but that's not straight forward > at all. This is my favorite option, because sup-sync-back also has to do mbox locking, so I don't think we can avoid the issue in general. > Dovecot, as an example, allows a configuration knob for the admin to > set the order in which the different mechanisms are used. This works > as long as all of the mbox consumers use the same sequence. There is > still lots of room for error here (NFS, etc). Currently sup-sync-back just says, "hey, you can use this program /usr/bin/dotlockfile if you have it" and pushes the details of locking to that. I think that's at least a vaguely reasonable approach. Ideally it would be more configurable, would fall back to other locking programs, etc., but I think it's significantly better than not doing any locking at all. (Eventually these two mbox writers should share the same locking code, but don't feel obligated to refactor as part of your patch if it's already getting too hairy.) -- William From wmorgan-sup@masanjin.net Thu May 7 09:12:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 07 May 2009 06:12:31 -0700 Subject: [sup-talk] IMAP questions (n00b) :) In-Reply-To: <24cc29320905070338u1e23c6d3sa78c20dd0da60b19@mail.gmail.com> References: <24cc29320905070338u1e23c6d3sa78c20dd0da60b19@mail.gmail.com> Message-ID: <1241701676-sup-657@entry> Reformatted excerpts from Filip Stokkeland's message of 2009-05-07: > Hi! I just discovered and started testing Sup. And it looks great! Thanks! > I tried browsing through some of the mailing list archives, and I > found postings saying Sup does not sync back to IMAP(S). So I take it > then, that when I mark mail as read or as spam, nothing happens on the > IMAP server, but only in the local Sup index? That's correct. I'm not opposed to pushing those flags back to the IMAP server in principle, at least in batch mode (there's a tool that does that now for mbox, and I'm working on Maildir), but writing that code pretty low on my personal priority queue at the moment. > And another thing. I have my main work email today sorted on the > server, using Sieve, so I get new email sorted into 40 different IMAP > folders. In Sup, can I get it to automatically fetch from all > subscribed IMAP folders? There's not a good automatic way of doing this. If you can generate the list of folders, then you can run sup-add on each one. > Or maybe I should rather fetch all this email into my own local server > using fetchmail or something and then either put it all in one big > inbox or multiple mboxes locally and then add this as source? Current best practice for IMAP is to sync it locally with a program like offlineimap. That also speeds things up, e.g. when you open a thread with 100 messages, Sup wants to download them all at once, and IMAP is much slower than Maildir for that. -- William From marka@pobox.com Thu May 7 11:29:30 2009 From: marka@pobox.com (Mark Alexander) Date: Thu, 7 May 2009 11:29:30 -0400 Subject: [sup-talk] /usr/bin/run-mailcap In-Reply-To: <1241701545-sup-3821@entry> References: <24cc29320905070458g7b970ea4rbfcc469d6afc3a3d@mail.gmail.com> <1241701545-sup-3821@entry> Message-ID: On Thu, May 7, 2009 at 9:07 AM, William Morgan wrote: > Reformatted excerpts from Filip Stokkeland's message of 2009-05-07: >> Maybe run-mailcap a Debian/Ubuntu thing? ?(I'll be back on my regular >> ubuntu installation soon enough anyway, just using a lab machine right >> now.) In Mutt I don't believe I did anything except use my default >> .mailcap ... > > It could very well be a Debianism. Is there a good alternative for > RedHat, or does Sup have to start manually parsing ~/.mailcap, > /etc/mailcap/, etc? For my Fedora 4 system, I found the run-mailcap script somewhere (I forget where now, but I probably used Google to find it), and manually installed it in /usr/bin. From bwalton@artsci.utoronto.ca Thu May 7 09:21:21 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 07 May 2009 09:21:21 -0400 Subject: [sup-talk] /usr/bin/run-mailcap In-Reply-To: <1241701545-sup-3821@entry> References: <24cc29320905070458g7b970ea4rbfcc469d6afc3a3d@mail.gmail.com> <1241701545-sup-3821@entry> Message-ID: <1241702388-sup-6440@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu May 07 09:07:32 -0400 2009: > It could very well be a Debianism. Is there a good alternative for > RedHat, or does Sup have to start manually parsing ~/.mailcap, > /etc/mailcap/, etc? I just copied the script onto my box (rhel5.3) and it works fine. Maybe a config knob for those that can't stick it in /usr/bin (or a less hardcoded way of calling it to allow for $PATH). -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Thu May 7 17:57:22 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 07 May 2009 17:57:22 -0400 Subject: [sup-talk] sent source In-Reply-To: <1241702060-sup-3211@entry> References: <1241702060-sup-3211@entry> Message-ID: <1241733359-sup-131@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009: > Reformatted excerpts from Ben Walton's message of 2009-05-06: > > The next option is to play with locks, but that's not straight forward > > at all. > > This is my favorite option, because sup-sync-back also has to do mbox > locking, so I don't think we can avoid the issue in general. Ok. This is the direction I'll go. This will be the most difficult part of the whole thing. > Currently sup-sync-back just says, "hey, you can use this program > /usr/bin/dotlockfile if you have it" and pushes the details of locking > to that. I think that's at least a vaguely reasonable approach. Ideally > it would be more configurable, would fall back to other locking > programs, etc., but I think it's significantly better than not doing any > locking at all. Wouldn't it be nicer to handle this internally? > (Eventually these two mbox writers should share the same locking code, > but don't feel obligated to refactor as part of your patch if it's > already getting too hairy.) Ok. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Thu May 7 18:01:16 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 07 May 2009 18:01:16 -0400 Subject: [sup-talk] flexible sent source (update) Message-ID: <1241733502-sup-26@ntdws12.chass.utoronto.ca> Hi All, I've pushed a few new changes to the bw/flexible_sent branch at git://code.chass.utoronto.ca/bwalton-sup.git. It is now possible to use sup-config to choose which (valid) mail source to store messages in and I tweaked how the special sent label is applied. I'd appreciate it if those interested in the topic played with this branch. William, I'd also appreciate any feedback you have on it at this point. (Do you mind pulling my branch, or would you prefer a git-send-email stack of patches?) I still need to tackle mbox locking... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andrew@pimlott.net Fri May 8 12:42:26 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Fri, 8 May 2009 09:42:26 -0700 Subject: [sup-talk] sup-sync dies; memory limit? Message-ID: <20090508164226.GA28854@pimlott.net> I have been running sup-sync on a new mailbox, and it tends to get partway through and then die, but not in the same place each time. Twice, the error has been like /var/lib/gems/1.8/gems/sup-0.7/lib/sup/crypto.rb:162:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/28751-0-redwood.signature /tmp/28751-0-redwood.payload 2> /dev/null (Errno::ENOMEM) followed by a backtrace. Another time, it was just zsh: killed /var/lib/gems/1.8/bin/sup-sync --all-sources I monitored the sup-sync process the last time. It's memory use grew slowly, and the process died at around 64M of virtual memory. I don't have any memory limits set. Is it possible that sup-sync or ruby uses some itself? Any other ideas? Andrew From bwalton@artsci.utoronto.ca Fri May 8 22:10:55 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 08 May 2009 22:10:55 -0400 Subject: [sup-talk] sent source In-Reply-To: <1241702060-sup-3211@entry> References: <1241702060-sup-3211@entry> Message-ID: <1241834800-sup-1443@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009: > Currently sup-sync-back just says, "hey, you can use this program > /usr/bin/dotlockfile if you have it" and pushes the details of locking > to that. I think that's at least a vaguely reasonable approach. Ideally > it would be more configurable, would fall back to other locking > programs, etc., but I think it's significantly better than not doing any > locking at all. ...Ok, what about implementing the dotlockfile functionality inside a LockManager singleton? I'm thinking about something that would accept a list of required locks before allowing read and write. It would then provide with_readlock(file, &block) and with_writelock(file, &block) methods that obtain required locks and yield to the caller to do the actual work. > (Eventually these two mbox writers should share the same locking code, > but don't feel obligated to refactor as part of your patch if it's > already getting too hairy.) sup-sync-back could make use of this LockManager too. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Sat May 9 09:01:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 09 May 2009 06:01:04 -0700 Subject: [sup-talk] sent source In-Reply-To: <1241834800-sup-1443@ntdws12.chass.utoronto.ca> References: <1241702060-sup-3211@entry> <1241834800-sup-1443@ntdws12.chass.utoronto.ca> Message-ID: <1241873892-sup-9543@entry> Reformatted excerpts from Ben Walton's message of 2009-05-08: > ...Ok, what about implementing the dotlockfile functionality inside a > LockManager singleton? I'm thinking about something that would accept > a list of required locks before allowing read and write. It would > then provide with_readlock(file, &block) and with_writelock(file, > &block) methods that obtain required locks and yield to the caller to > do the actual work. That sounds good to me and is very much in the spirit of the current Sup codebase. I'd like to also have a non-yield mechanism (e.g. #lock and #unlock methods), similar to the interface Mutex exposes, because sometimes it's irritating to use the block form, but that's icing on the cake. > sup-sync-back could make use of this LockManager too. Yes, definitely they should all share the same code path. -- William From andrew@pimlott.net Mon May 11 14:26:15 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Mon, 11 May 2009 11:26:15 -0700 Subject: [sup-talk] sup-sync dies; memory limit? In-Reply-To: <20090508164226.GA28854@pimlott.net> References: <20090508164226.GA28854@pimlott.net> Message-ID: <20090511182615.GI28854@pimlott.net> I forgot to mention, this was the latest release (0.7) installed with gem. I just tried the current git mainline (clearing all my .sup state first), and it got through my whole mailbox without a problem. Andrew On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote: > I have been running sup-sync on a new mailbox, and it tends to get > partway through and then die, but not in the same place each time. > Twice, the error has been like > > /var/lib/gems/1.8/gems/sup-0.7/lib/sup/crypto.rb:162:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/28751-0-redwood.signature /tmp/28751-0-redwood.payload 2> /dev/null (Errno::ENOMEM) > > followed by a backtrace. Another time, it was just > > zsh: killed /var/lib/gems/1.8/bin/sup-sync --all-sources > > I monitored the sup-sync process the last time. It's memory use grew > slowly, and the process died at around 64M of virtual memory. I don't > have any memory limits set. Is it possible that sup-sync or ruby uses > some itself? Any other ideas? > > Andrew > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk From wmorgan-sup@masanjin.net Tue May 12 13:19:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 12 May 2009 10:19:48 -0700 Subject: [sup-talk] sup-sync dies; memory limit? In-Reply-To: <20090511182615.GI28854@pimlott.net> References: <20090508164226.GA28854@pimlott.net> <20090511182615.GI28854@pimlott.net> Message-ID: <1242148438-sup-9068@entry> Reformatted excerpts from Andrew Pimlott's message of 2009-05-11: > On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote: > > I don't have any memory limits set. Is it possible that sup-sync or > > ruby uses some itself? Any other ideas? Very mysterious. Sup-sync doesn't do anything fancy with memory; it's a fairly straight-forward Ruby script. Maybe one of the C extensions (like Ferret) has a memory leak. > I forgot to mention, this was the latest release (0.7) installed with > gem. I just tried the current git mainline (clearing all my .sup > state first), and it got through my whole mailbox without a problem. Evey more mysterious. The differences between these two versions are trivial: diff --git a/origin/release-0.7:bin/sup-sync b/origin/master:bin/sup-sync index ac5caf6..91710d4 100644 --- a/origin/release-0.7:bin/sup-sync +++ b/origin/master:bin/sup-sync @@ -143,12 +143,7 @@ begin next if target == :changed && entry && entry[:source_id].to_i == source.id && entry[:source_info].to_i == offset ## get the state currently in the index - index_state = - if entry - entry[:label].split(/\s+/).map { |x| x.intern } - else - nil - end + index_state = entry[:label].split(/\s+/).map { |x| x.intern } if entry ## skip if we're operating on restored messages, and this one ## ain't. @@ -163,7 +158,7 @@ begin ## assign message labels based on the operation we're performing case op when :asis - m.labels = index_state if index_state + m.labels = ((m.labels - [:unread, :inbox]) + index_state).uniq if index_state when :restore ## if the entry exists on disk if restored_state[m.id] I'm at a loss. -- William From andrew@pimlott.net Tue May 12 14:31:58 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Tue, 12 May 2009 11:31:58 -0700 Subject: [sup-talk] sup-sync dies; memory limit? In-Reply-To: <1242148438-sup-9068@entry> References: <20090508164226.GA28854@pimlott.net> <20090511182615.GI28854@pimlott.net> <1242148438-sup-9068@entry> Message-ID: <20090512183158.GO28854@pimlott.net> On Tue, May 12, 2009 at 10:19:48AM -0700, William Morgan wrote: > Reformatted excerpts from Andrew Pimlott's message of 2009-05-11: > > On Fri, May 08, 2009 at 09:42:26AM -0700, Andrew Pimlott wrote: > > > I don't have any memory limits set. Is it possible that sup-sync or > > > ruby uses some itself? Any other ideas? > > Very mysterious. I cannot reproduce the problem anymore, but as far as I know, nothing changed on my system (other than the inbox I am testing with evolving routinely). sup-sync from the 0.7 gem now runs to completion and never uses more than ~36M virtual memory (before it got up around 60M before crashing). It doesn't seem possible that the git copy of sup affected the installed gem. So I'm at a complete loss too. Andrew From wmorgan-sup@masanjin.net Tue May 12 15:54:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 12 May 2009 12:54:35 -0700 Subject: [sup-talk] sup-sync dies; memory limit? In-Reply-To: <20090512183158.GO28854@pimlott.net> References: <20090508164226.GA28854@pimlott.net> <20090511182615.GI28854@pimlott.net> <1242148438-sup-9068@entry> <20090512183158.GO28854@pimlott.net> Message-ID: <1242158027-sup-1409@entry> Reformatted excerpts from Andrew Pimlott's message of 2009-05-12: > It doesn't seem possible that the git copy of sup affected the > installed gem. So I'm at a complete loss too. Let's just pretend this never happened. -- William From damon.conway@alchemysystems.com Tue May 12 13:18:45 2009 From: damon.conway@alchemysystems.com (Damon Conway) Date: Tue, 12 May 2009 12:18:45 -0500 Subject: [sup-talk] sup crash when doing search Message-ID: <1242148324-sup-9511@case> I installed the chronic gem with "sudo gem install chronic", and then tried a search by date. I did "before:(1st apr)" in a global search, and sup crashed. I have included the exception log below. My guess is that I'm missing a gem, but I'm not quite sure which one. I just installed sup yesterday after I found it when looking around for any news on imap support in nmh so it's very likely that I've missed something. So far sup is quite impressive. Keep up the good work, and thanks for the mail client. Thanks, Damon Some system details: Ubuntu 9.04 Dell XPS 1210 ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux] gnome-terminal 2.26.0 Screen version 4.00.03jw4 (FAU) 2-May-06 --- NoMethodError from thread: main private method `gsub' called for nil:NilClass /var/lib/gems/1.8/gems/sup-0.7/lib/sup/index.rb:568:in `parse_user_query_string' /var/lib/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `send' /var/lib/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `method_missing' /var/lib/gems/1.8/gems/sup-0.7/lib/sup/modes/search-results-mode.rb:29:in `spawn_from_query' /var/lib/gems/1.8/gems/sup-0.7/bin/sup:239 /var/lib/gems/1.8/bin/sup:19:in `load' /var/lib/gems/1.8/bin/sup:19 From andrew@pimlott.net Tue May 12 19:33:03 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Tue, 12 May 2009 16:33:03 -0700 Subject: [sup-talk] inconsistencies and new user confusion Message-ID: <20090512233303.GU28854@pimlott.net> I'm making my second try at switching to sup (though the first was pretty half-assed). I'm in that state where too many things are happening that I don't understand, so I need some clarification on how things are supposed to work. I'm using the mainline as of a few days ago, where the last checkin is may 4. There seem to be serious consistency issues. For example, I applied a label "cal" to a thread. I press "L" to list labels, and it's not there. I sync the mailbox, unsure if this is needed. (It shouldn't be, of course--if it is, I hope this is intended to be fixed, perhaps with the undo work.) Now, "cal" shows up in the label list, but with a message count less than the number I labeled. At some point down the line, after more activity, it gets the count right. Similarly, I have now a mailbox in which I deleted a thread of 2 messages, then added a reply to that mailbox (from outside sup). In my inbox, I only see the reply, and the labels are "inbox". Shouldn't the thread always "stick together"? If I switch to the "deleted" label, I see the expected thread of three messages, but on all three the labels are "deleted, inbox". I had another case recently in all messages in a thread had labels "deleted, inbox", but the thread still showed up in my inbox. Any idea what's going on? Andrew From ezyang@MIT.EDU Wed May 13 01:23:49 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 13 May 2009 01:23:49 -0400 Subject: [sup-talk] inconsistencies and new user confusion In-Reply-To: <20090513042345.GB18461@cabinet.hsd1.ma.comcast.net> References: <20090512233303.GU28854@pimlott.net> <20090513042345.GB18461@cabinet.hsd1.ma.comcast.net> Message-ID: <1242192198-sup-9446@javelin> Excerpts from marc.hartstein's message of Wed May 13 00:23:45 -0400 2009: > 'deleted' means "don't show this to me even if there are new messages in > the thread. I was under the impression that "killing" a thread was what did that? Cheers, Edward From marcus-sup@bar-coded.net Wed May 13 03:14:12 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Wed, 13 May 2009 08:14:12 +0100 Subject: [sup-talk] sup crash when doing search In-Reply-To: <1242148324-sup-9511@case> References: <1242148324-sup-9511@case> Message-ID: <1242198767-sup-3140@tomsk> On 12.5.2009, Damon Conway wrote: > I did "before:(1st apr)" in a global search, and sup crashed. I have included > the exception log below. I can reproduce this, although this used to work. Not sure whats happening offhand but I'll poke around and see if I can fix it. Marcus From marcus-sup@bar-coded.net Wed May 13 04:50:24 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Wed, 13 May 2009 09:50:24 +0100 Subject: [sup-talk] sup crash when doing search In-Reply-To: <1242198767-sup-3140@tomsk> References: <1242148324-sup-9511@case> <1242198767-sup-3140@tomsk> Message-ID: <1242204467-sup-6823@tomsk> On 13.5.2009, I wrote: > I can reproduce this, although this used to work. Not sure whats > happening offhand but I'll poke around and see if I can fix it. Ok, the crash doesnt happen in master only in next. The reason for the crash is the new "limit" search option that doesnt check if chronic has failed. Patch for that to follow (against next). Theres also another bug in that Chronic should default to date searches in the past as email is almost always dated earlier than your current time (except spam). So theres a patch for that following as well (against master) Marcus From marcus-sup@bar-coded.net Wed May 13 05:00:31 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Wed, 13 May 2009 10:00:31 +0100 Subject: [sup-talk] [PATCH] limit option parser nil check Message-ID: <1242205071-sup-2484@tomsk> The limit search option doesnt check if the current search term is nil (when chronic has failed for instance). This patch (against next) adds the check. --- lib/sup/index.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/index.rb b/lib/sup/index.rb index c66a24e..4ebc966 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -584,7 +584,7 @@ protected BufferManager.flash "Can't understand limit #{lim.inspect}!" subs = nil end - end + end unless subs.nil? if subs [@qparser.parse(subs), extraopts] -- 1.5.4.1 From marcus-sup@bar-coded.net Wed May 13 05:02:31 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Wed, 13 May 2009 10:02:31 +0100 Subject: [sup-talk] [PATCH] Chronic context fix Message-ID: <1242205240-sup-5042@tomsk> Chronic should use a context of :past for email date searches as emails tend to be in the past. This fixes a problem when the wrong year is guessed. To search for emails in the future you now need to be less ambiguous (1 apr 2099 instead of 1 apr). --- lib/sup/index.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/index.rb b/lib/sup/index.rb index 235a18c..779bf02 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -506,7 +506,7 @@ protected subs = subs.gsub(/\b(before|on|in|during|after):(\((.+?)\)\B|(\S+)\b)/) do break if chronic_failure field, datestr = $1, ($3 || $4) - realdate = Chronic.parse(datestr, :guess => false, :context => :none) + realdate = Chronic.parse(datestr, :guess => false, :context => :past) if realdate case field when "after" -- 1.5.4.1 From marcus-sup@bar-coded.net Wed May 13 05:31:36 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Wed, 13 May 2009 10:31:36 +0100 Subject: [sup-talk] sup crash when doing search In-Reply-To: <1242204467-sup-6823@tomsk> References: <1242148324-sup-9511@case> <1242198767-sup-3140@tomsk> <1242204467-sup-6823@tomsk> Message-ID: <1242207018-sup-4894@tomsk> On 13.5.2009, I wrote: > Theres also another bug in that Chronic should default to date > searches in the past as email is almost always dated earlier than your > current time (except spam). So theres a patch for that following as > well (against master) I should also have added that chronic doesnt understand dates like "1st apr" strangely, but it should have told you (the patches fix this problem). "1 apr", "apr 1st" are ok I think. Marcus From henri.ducrocq@gmail.com Wed May 13 07:37:04 2009 From: henri.ducrocq@gmail.com (Henri Ducrocq) Date: Wed, 13 May 2009 12:37:04 +0100 Subject: [sup-talk] Notification tools Message-ID: <1242213878-sup-4217@ptoseis> (First of alli: Thanks William for that very gorgeous piece of software!) I would like to use mail-notification (or an equivalent) to display the status of my inbox in my system tray, I mean the number of unread emails. But of course that program isn't aware of what messages have been read inside sup. What can I do to fix this? I thought about having the after-poll hook dump all new messages into a dummy mbox file, which would be monitored by mail-notification.. But there must be a simpler way? From andrew@pimlott.net Wed May 13 10:53:11 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Wed, 13 May 2009 07:53:11 -0700 Subject: [sup-talk] inconsistencies and new user confusion In-Reply-To: <20090513042345.GB18461@cabinet.hsd1.ma.comcast.net> References: <20090512233303.GU28854@pimlott.net> <20090513042345.GB18461@cabinet.hsd1.ma.comcast.net> Message-ID: <20090513145311.GX28854@pimlott.net> On Wed, May 13, 2009 at 12:23:45AM -0400, Marc Hartstein wrote: > 'deleted' means "don't show this to me even if there are new messages in > the thread. Is this the intended behavior? Unfortunately, I'm seeing several variations. I have a thread now, which I deleted then added a new message to, and some but not all of the previously deleted messages are back in my inbox. If I quit sup and restart, only the new message is in my inbox. As I said, the labels shown in the message headers are inconsistent as well. In this case, both the deleted messages and the new message had the deleted label, which contradicts them showing up in my inbox. After a quit and restart, the new message loses the deleted label when viewed from my inbox. But if I do a label search for deleted, the whole thread is there--and even the new message has the deleted label. Andrew From marcus-sup@bar-coded.net Wed May 13 11:28:06 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Wed, 13 May 2009 16:28:06 +0100 Subject: [sup-talk] Strange problem in before-edit hook Message-ID: <1242228484-sup-2569@tomsk> The automatic setting of the from address on a reply works really well in sup, but I've been trying to get new emails do something similar with the hook mechanism. I've got the before-edit hook to do set my from address by picking up the previously used from address from a search using the sent label. Basically this means if I send a new email to someone using a specific from address, it picks up my last used from address as the default the next time I send them an email. This saves having to write something specific for every email/domain I send to. It works really well but I get the odd crash in the hook because the header['To'] sometimes is an array rather than the expected string. I've got around this by doing a to_s on the header but I cant figure out why I'd ever get an array. Anyone got any ideas? Heres the hook: ### start of before-edit fr = nil emailto = "" hdrto = header["To"].to_s hdrto.split(' ').find() { |e| e.include?("@") }.each() do |ee| if ee.include?("<") emailto = ee[1..-2] else emailto = ee end end Index.index.search_each("to:\"#{emailto}\" AND label:sent") { |id, score| m = Index.build_message(id); fr = m.from } header["From"] = fr.full_address unless fr.nil? header["Return-Path"] = header["From"] ### end of before-edit From wmorgan-sup@masanjin.net Wed May 13 14:11:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 13 May 2009 11:11:10 -0700 Subject: [sup-talk] flexible sent source (update) In-Reply-To: <1241733502-sup-26@ntdws12.chass.utoronto.ca> References: <1241733502-sup-26@ntdws12.chass.utoronto.ca> Message-ID: <1242238048-sup-6168@entry> Hi Ben, Reformatted excerpts from Ben Walton's message of 2009-05-07: > I'd appreciate it if those interested in the topic played with this > branch. William, I'd also appreciate any feedback you have on it at > this point. (Do you mind pulling my branch, or would you prefer a > git-send-email stack of patches?) This branch looks great. Thanks! We're going to have to rebase it against master before merging in, but I think that will be easier once I merge a few other branches down from next to master. > I still need to tackle mbox locking... This is puntable for now, if we make it clear to the user that their sent box shouldn't also receive mail. -- William From bwalton@artsci.utoronto.ca Wed May 13 14:50:23 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 13 May 2009 14:50:23 -0400 Subject: [sup-talk] flexible sent source (update) In-Reply-To: <1242238048-sup-6168@entry> References: <1241733502-sup-26@ntdws12.chass.utoronto.ca> <1242238048-sup-6168@entry> Message-ID: <1242240494-sup-9505@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Wed May 13 14:11:10 -0400 2009: > Reformatted excerpts from Ben Walton's message of 2009-05-07: > > I'd appreciate it if those interested in the topic played with this > > branch. William, I'd also appreciate any feedback you have on it at > > this point. (Do you mind pulling my branch, or would you prefer a > > git-send-email stack of patches?) > > This branch looks great. Thanks! We're going to have to rebase it > against master before merging in, but I think that will be easier once I > merge a few other branches down from next to master. Ok. I can do that when you're ready. > > I still need to tackle mbox locking... > > This is puntable for now, if we make it clear to the user that their > sent box shouldn't also receive mail. Well, I'm working on it (slowly) already. It shouldn't be as bad as I'd initially thought it would be. The lockfile library should handle the needs for the dotlocking, and I'll add some fcntl and flock support too, so that it's "stackable" in a similar fashion to the way dovecot works. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Wed May 13 14:54:53 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 13 May 2009 11:54:53 -0700 Subject: [sup-talk] Notification tools In-Reply-To: <1242213878-sup-4217@ptoseis> References: <1242213878-sup-4217@ptoseis> Message-ID: <1242239740-sup-8633@entry> Reformatted excerpts from Henri Ducrocq's message of 2009-05-13: > (First of alli: Thanks William for that very gorgeous piece of > software!) Glad you find it useful! > I would like to use mail-notification (or an equivalent) to display > the status of my inbox in my system tray, I mean the number of unread > emails. But of course that program isn't aware of what messages have > been read inside sup. Sounds great. I'd love to have that too. > What can I do to fix this? I thought about having the after-poll hook > dump all new messages into a dummy mbox file, which would be monitored > by mail-notification.. But there must be a simpler way? Having now read the mail-notification manpage... the problem is mail-notification. It should provide a way for other apps to signal a notification (the whole Unix philosophy of decomposability, etc.) but it does not. Periodically dumping all new messages into a dummy mbox file is a terrible idea, but I think that's your only Sup-specific option. Patching mail-notification is a better idea, though that may not be what you want to hear. If you're using a recent Gnome, you have some other options. If you're running notification-daemon (e.g. Ubuntu 9.04), you can install the libnotify-bin package and having the after-poll hook call notify-bin on new email. (Not quite the same.) You can also look at the indicator-applet: libindicate also has Python bindings, so you could install python-indicate and write a python short program to use that. -- William From wmorgan-sup@masanjin.net Wed May 13 14:55:28 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 13 May 2009 11:55:28 -0700 Subject: [sup-talk] flexible sent source (update) In-Reply-To: <1242238048-sup-6168@entry> References: <1241733502-sup-26@ntdws12.chass.utoronto.ca> <1242238048-sup-6168@entry> Message-ID: <1242240924-sup-7948@entry> Oh yeah: Reformatted excerpts from William Morgan's message of 2009-05-13: > Reformatted excerpts from Ben Walton's message of 2009-05-07: > > (Do you mind pulling my branch, or would you prefer a git-send-email > > stack of patches?) I'm perfectly happy to pull from your branch. -- William From wmorgan-sup@masanjin.net Wed May 13 16:55:51 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 13 May 2009 13:55:51 -0700 Subject: [sup-talk] "interning empty string" from sup-sync In-Reply-To: <20090513190821.GC18461@cabinet.hsd1.ma.comcast.net> References: <20090513190821.GC18461@cabinet.hsd1.ma.comcast.net> Message-ID: <1242248081-sup-5132@entry> Reformatted excerpts from Marc Hartstein's message of 2009-05-13: > /home/magus/src/sup/bin/sup-sync:159:in `intern': interning empty string > (ArgumentError) > from /home/magus/src/sup/bin/sup-sync:159 That's a bug. Turns out String#split doesn't exactly behave how I thought: $ irb >> " a b c ".split => ["a", "b", "c"] >> " a b c ".split(/\s+/) => ["", "a", "b", "c"] I've fixed this in next. -- William From wmorgan-sup@masanjin.net Wed May 13 21:52:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 13 May 2009 18:52:14 -0700 Subject: [sup-talk] Notification tools In-Reply-To: <1242261120-sup-2999@cabinet> References: <1242213878-sup-4217@ptoseis> <1242239740-sup-8633@entry> <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> <1242261120-sup-2999@cabinet> Message-ID: <1242265757-sup-2754@entry> Reformatted excerpts from Marc Hartstein's message of 2009-05-13: > Has anybody done anything like this? Any code snippets? I really need to clean up the code so that all of Sup's special query parsing (chronic, contact aliases, etc.) is accessible, but you can do simple queries directly through the Ferret API with a script like: require 'sup' i = Redwood::Index.new i.load puts "total unread: " + i.ferret.search("label:unread").total_hits puts "inbox unread: " + i.ferret.search("label:unread AND label:inbox").total_hits That gets you the number of messages, not the number of threads. (Sup doesn't store the latter.) -- William From marcus-sup@bar-coded.net Thu May 14 04:37:38 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Thu, 14 May 2009 09:37:38 +0100 Subject: [sup-talk] Notification tools In-Reply-To: <1242273707-sup-1213@cabinet> References: <1242213878-sup-4217@ptoseis> <1242239740-sup-8633@entry> <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> <1242261120-sup-2999@cabinet> <1242265757-sup-2754@entry> <1242273707-sup-1213@cabinet> Message-ID: <1242290067-sup-3675@tomsk> On 14.5.2009, Marc Hartstein wrote: > Although, I just tried this (I seem to have had to append .to_s to each > of the total_hits), and it works, but all my results are exactly 15 > greater than the relevant numbers I see if I go into the label menu with > . Any idea what might cause that? I think the Sup version will by default not include killed or deleted messages so that might be whats causing it. Marcus From nicolas.pouillard@gmail.com Thu May 14 09:04:44 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 14 May 2009 15:04:44 +0200 Subject: [sup-talk] Notification tools In-Reply-To: <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> References: <1242213878-sup-4217@ptoseis> <1242239740-sup-8633@entry> <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> Message-ID: <1242305907-sup-1542@ausone.inria.fr> Excerpts from Henri Ducrocq's message of Thu May 14 02:23:00 +0200 2009: > On Wed, May 13, 2009 at 7:54 PM, William Morgan wrote: > > > Periodically dumping all new messages into a dummy mbox file is a > > terrible idea, but I think that's your only Sup-specific option. > > Patching mail-notification is a better idea, though that may not be what > > you want to hear. > > > It isn't :) > > > If you're using a recent Gnome, you have some other options. If you're > > running notification-daemon (e.g. Ubuntu 9.04), you can install the > > libnotify-bin package and having the after-poll hook call notify-bin on > > new email. (Not quite the same.) You can also look at the > > indicator-applet: libindicate also has Python bindings, so you could > > install python-indicate and write a python short program to use that. > > > I don't use Gnome or KDE (or anything really.) > Re. the notification-daemon tip, that's what I'm doing already (via a python > script of mine, I didn't know about notify-bin!), but sure it isn't the > same. > What I might do: Have after-poll dump the number of unread messages into a > file, > and display that value in my dzen status bar. It might be good enough. I'm doing something quite similar: I have a status-bar-text hook. $ cat ~/.sup/hooks/status-bar-text.rb dir = ENV['HOME']+'/.sup/' state_new = dir+'state.new' File.open(state_new, 'w') do |f| f.puts "SupState { sup_num_inbox_unread = #{num_inbox_unread} }" end File.rename(state_new, dir+'state') rescue nil nil Then I have tweaked my xmonad config to inject the contents of this file in my dzen bar. Best regards, -- Nicolas Pouillard From manselton@googlemail.com Fri May 15 13:37:08 2009 From: manselton@googlemail.com (Maurice McCarthy) Date: Fri, 15 May 2009 17:37:08 +0000 Subject: [sup-talk] gmail login Message-ID: <8c09a1500905151037m351adedyefdde82c244e17c0@mail.gmail.com> Hi I'm a noob user and not a programmer. Thanks for your brilliant efforts. I've asked the grml team to include sup by default. http://grml.org They ought to love it as grml is a Debian based installable live distro for admins and geeks. The sup log tells me that when I log in to my gmail account it ends up logging in using plain text. Fri May 15 17:20:06 +0000 2009: CRAM-MD5 authentication failed: Net::IMAP::NoResponseError. Trying LOGIN auth... Fri May 15 17:20:06 +0000 2009: LOGIN authentication failed: Net::IMAP::NoResponseError. Trying plain-text LOGIN... Fri May 15 17:20:06 +0000 2009: Successfully connected to imaps://imap.googlemail.com:993/INBOX. Have I got something configured wrongly or am I really advertising my password to the world? Or is it going through a secure tunnel anyhow? Many Thanks in advance for your advice If pipermail had been searchable I'd have looked in the archives before bothering you. Sorry for the inconvenience if this has already been asked. Maurice -- Best Wishes From bwalton@artsci.utoronto.ca Fri May 15 13:57:38 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 15 May 2009 13:57:38 -0400 Subject: [sup-talk] gmail login In-Reply-To: <8c09a1500905151037m351adedyefdde82c244e17c0@mail.gmail.com> References: <8c09a1500905151037m351adedyefdde82c244e17c0@mail.gmail.com> Message-ID: <1242409947-sup-5182@ntdws12.chass.utoronto.ca> Excerpts from Maurice McCarthy's message of Fri May 15 13:37:08 -0400 2009: > The sup log tells me that when I log in to my > gmail account it ends up logging in using > plain text. This is normal and just a part of a standard IMAP connection auth sequence. Unless you've got kerberos enabled/SASL auth stuff in place, the standard IMAP auth options are all pretty nasty (pop3 is no better)... > Fri May 15 17:20:06 +0000 2009: CRAM-MD5 authentication failed: > Net::IMAP::NoResponseError. Trying LOGIN auth... > Fri May 15 17:20:06 +0000 2009: LOGIN authentication failed: > Net::IMAP::NoResponseError. Trying plain-text LOGIN... > Fri May 15 17:20:06 +0000 2009: Successfully connected to > imaps://imap.googlemail.com:993/INBOX. You still connected via an ssl secured connection, so even using horrible auth mechanisms like this, you're reasonably protected during transit. Looks good from here. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From david.guibert@gmail.com Fri May 15 08:41:33 2009 From: david.guibert@gmail.com (David Guibert) Date: Fri, 15 May 2009 14:41:33 +0200 Subject: [sup-talk] Notification tools In-Reply-To: <1242331711-sup-4976@cabinet> References: <1242213878-sup-4217@ptoseis> <1242239740-sup-8633@entry> <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> <1242261120-sup-2999@cabinet> <1242265757-sup-2754@entry> <1242273707-sup-1213@cabinet> <1242290067-sup-3675@tomsk> <1242331711-sup-4976@cabinet> Message-ID: <1242391055-sup-4644@orsine> Hi, >From Marc Hartstein: > Excerpts from Marcus Williams's message of Thu May 14 04:37:38 -0400 2009: > > On 14.5.2009, Marc Hartstein wrote: > > > Although, I just tried this (I seem to have had to append .to_s to each > > > of the total_hits), and it works, but all my results are exactly 15 > > > greater than the relevant numbers I see if I go into the label menu with > > > . Any idea what might cause that? > > > > I think the Sup version will by default not include killed or deleted > > messages so that might be whats causing it. > > Deleted Unread messages accounted for 5 of the 15, but there are no > Killed, so the remaining 10 are still a mystery. Spam. I changed sup-biff to contain: #!/bin/bash ruby -I '~/src/sup/lib' < Excerpts from Nicolas Pouillard's message of Thu May 14 14:04:44 +0100 2009: > I have a status-bar-text hook. ... > Then I have tweaked my xmonad config to inject the contents of this > file in my dzen bar. But isn't status-bar-text only triggered by keystrokes? Anyways, I'm updating the file from after-poll.rb, it seems to work. Henri (oops, Nicolas you're gonna receive this email twice) -- -- Henri From kirr@landau.phys.spbu.ru Sat May 16 11:01:14 2009 From: kirr@landau.phys.spbu.ru (Kirill Smelkov) Date: Sat, 16 May 2009 19:01:14 +0400 Subject: [sup-talk] [PATCH] chmod a+x bin/* Message-ID: <1242486074-5822-1-git-send-email-kirr@landau.phys.spbu.ru> The files in there are all executables, and this simplifies running sup in-tree. --- 0 files changed, 0 insertions(+), 0 deletions(-) mode change 100644 => 100755 bin/sup mode change 100644 => 100755 bin/sup-add mode change 100644 => 100755 bin/sup-config mode change 100644 => 100755 bin/sup-dump mode change 100644 => 100755 bin/sup-recover-sources mode change 100644 => 100755 bin/sup-sync mode change 100644 => 100755 bin/sup-sync-back mode change 100644 => 100755 bin/sup-tweak-labels diff --git a/bin/sup b/bin/sup old mode 100644 new mode 100755 diff --git a/bin/sup-add b/bin/sup-add old mode 100644 new mode 100755 diff --git a/bin/sup-config b/bin/sup-config old mode 100644 new mode 100755 diff --git a/bin/sup-dump b/bin/sup-dump old mode 100644 new mode 100755 diff --git a/bin/sup-recover-sources b/bin/sup-recover-sources old mode 100644 new mode 100755 diff --git a/bin/sup-sync b/bin/sup-sync old mode 100644 new mode 100755 diff --git a/bin/sup-sync-back b/bin/sup-sync-back old mode 100644 new mode 100755 diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels old mode 100644 new mode 100755 -- 1.6.3.9.g6345d From bwalton@artsci.utoronto.ca Sat May 16 13:16:14 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 16 May 2009 13:16:14 -0400 Subject: [sup-talk] [PATCH] chmod a+x bin/* In-Reply-To: <1242486074-5822-1-git-send-email-kirr@landau.phys.spbu.ru> References: <1242486074-5822-1-git-send-email-kirr@landau.phys.spbu.ru> Message-ID: <1242494144-sup-9441@ntdws12.chass.utoronto.ca> Excerpts from Kirill Smelkov's message of Sat May 16 11:01:14 -0400 2009: > The files in there are all executables, and this simplifies running sup > in-tree. ' +1 I was about to do the same patch. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From henri.ducrocq@gmail.com Sun May 17 15:23:41 2009 From: henri.ducrocq@gmail.com (Henri Ducrocq) Date: Sun, 17 May 2009 20:23:41 +0100 Subject: [sup-talk] Notification tools In-Reply-To: <1242391055-sup-4644@orsine> References: <1242213878-sup-4217@ptoseis> <1242239740-sup-8633@entry> <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> <1242261120-sup-2999@cabinet> <1242265757-sup-2754@entry> <1242273707-sup-1213@cabinet> <1242290067-sup-3675@tomsk> <1242331711-sup-4976@cabinet> <1242391055-sup-4644@orsine> Message-ID: <1242587689-sup-9833@ptoseis> I'm having a related problem, but this one is totally internal to Sup: After I read a new email, in most cases (possibly always, I can't say) the number of unread emails isn't decremented and stays at 1. I am talking about the number of unread messages shown on the labels page ('L' shortcut.) This is fixed by restarting Sup. I'm using the gem version of Sup, do I need to switch to the development branch? -- Henri From wmorgan-sup@masanjin.net Mon May 18 11:11:58 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 08:11:58 -0700 Subject: [sup-talk] merge activity report Message-ID: <1242659511-sup-4534@entry> Just a brief status report. In next: - I've added some refinements to the undo code on the undo-manager branch and merged that into next. If you're working on something related to this code, you may need to rebase. - I've fixed the mbox "From " line detector to try and only split when a valid date is encountered. (This is on branch various-mbox-fixes.) This seems to work well for me, but who knows what crazy date formats are out there. I have it logging a message whenever it finds a From line and something that it can't parse as a date (and thus decides not to split), so you may want to keep an eye on the log buffer if you're using mbox. You can also add test cases to tests/test_header_parsing.rb, in method test_from_line_splitting, if you have a particular case you're worried about. In master: - I've merged a bunch of stable-seeming features down to master, including the new buffer code, so you will have to retrain your fingers to use '=' or '+' instead of ';', which now brings up the buffer window. -- William From wmorgan-sup@masanjin.net Mon May 18 11:21:40 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 08:21:40 -0700 Subject: [sup-talk] [PATCH] chmod a+x bin/* In-Reply-To: <1242486074-5822-1-git-send-email-kirr@landau.phys.spbu.ru> References: <1242486074-5822-1-git-send-email-kirr@landau.phys.spbu.ru> Message-ID: <1242660088-sup-2297@entry> Reformatted excerpts from Kirill Smelkov's message of 2009-05-16: > The files in there are all executables, and this simplifies running sup > in-tree. Applied, thanks! -- William From wmorgan-sup@masanjin.net Mon May 18 11:22:11 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 08:22:11 -0700 Subject: [sup-talk] [PATCH] Chronic context fix In-Reply-To: <1242205240-sup-5042@tomsk> References: <1242205240-sup-5042@tomsk> Message-ID: <1242660123-sup-512@entry> Reformatted excerpts from Marcus Williams's message of 2009-05-13: > Chronic should use a context of :past for email date searches as > emails tend to be in the past. This fixes a problem when the wrong > year is guessed. To search for emails in the future you now need to be > less ambiguous (1 apr 2099 instead of 1 apr). Applied, thanks! -- William From bwalton@artsci.utoronto.ca Mon May 18 13:19:46 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 18 May 2009 13:19:46 -0400 Subject: [sup-talk] merge activity report In-Reply-To: <1242659511-sup-4534@entry> References: <1242659511-sup-4534@entry> Message-ID: <1242667096-sup-7844@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Mon May 18 11:11:58 -0400 2009: Let me know when you'd like the flexible sent stuff rebased and against which branch. I'm ready with that any time. Still working on the locking stuff, which is proving quite interesting. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon May 18 14:24:54 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 11:24:54 -0700 Subject: [sup-talk] merge activity report In-Reply-To: <1242667096-sup-7844@ntdws12.chass.utoronto.ca> References: <1242659511-sup-4534@entry> <1242667096-sup-7844@ntdws12.chass.utoronto.ca> Message-ID: <1242670748-sup-7451@entry> Reformatted excerpts from Ben Walton's message of 2009-05-18: > Let me know when you'd like the flexible sent stuff rebased and > against which branch. I'm ready with that any time. Ok. It will have to be rebased against master, and probably should wait till I've merged down the scanning-speedups and various-mbox-fixes branches, to avoid unnecessary conflicts. (The former seems stable enough, but the latter I've just updated and needs a little more steeping.) > Still working on the locking stuff, which is proving quite > interesting. Glad to hear it. -- William From wmorgan-sup@masanjin.net Mon May 18 14:26:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 11:26:10 -0700 Subject: [sup-talk] [PATCH] limit option parser nil check In-Reply-To: <1242205071-sup-2484@tomsk> References: <1242205071-sup-2484@tomsk> Message-ID: <1242671123-sup-6919@entry> Reformatted excerpts from Marcus Williams's message of 2009-05-13: > The limit search option doesnt check if the current search term is nil > (when chronic has failed for instance). This patch (against next) adds > the check. I've reworked this code in the parser-user-query-fix branch, currently merged into next, and it should no longer require this fix. -- William From wmorgan-sup@masanjin.net Mon May 18 14:31:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 11:31:35 -0700 Subject: [sup-talk] Notification tools In-Reply-To: <1242265757-sup-2754@entry> References: <1242213878-sup-4217@ptoseis> <1242239740-sup-8633@entry> <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> <1242261120-sup-2999@cabinet> <1242265757-sup-2754@entry> Message-ID: <1242671206-sup-2630@entry> Reformatted excerpts from William Morgan's message of 2009-05-13: > require 'sup' > i = Redwood::Index.new > i.load > puts "total unread: " + i.ferret.search("label:unread").total_hits > puts "inbox unread: " + i.ferret.search("label:unread AND > label:inbox").total_hits In the parser-user-query-fix branch (merged into next), you can now use Index.run_query, which takes a query and returns an array of doc ids. So you can now do this: require 'sup' i = Redwood::Index.new i.load puts "total unread: " + i.run_query("label:unread").size.to_s puts "inbox unread: " + i.run_query("label:unread AND label:inbox").size.to_s which has the same effect as above, but now you should be able to pass in all the fancy options you can use on the search line (from:/to: with contacts, :limit, date options if you have chronic installed, etc). -- William From wmorgan-sup@masanjin.net Mon May 18 14:44:01 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 11:44:01 -0700 Subject: [sup-talk] Notification tools In-Reply-To: <1242587689-sup-9833@ptoseis> References: <1242213878-sup-4217@ptoseis> <1242239740-sup-8633@entry> <391beaa80905131723k4b59090bi5bd541d97d1a75f2@mail.gmail.com> <1242261120-sup-2999@cabinet> <1242265757-sup-2754@entry> <1242273707-sup-1213@cabinet> <1242290067-sup-3675@tomsk> <1242331711-sup-4976@cabinet> <1242391055-sup-4644@orsine> <1242587689-sup-9833@ptoseis> Message-ID: <1242672174-sup-8915@entry> Reformatted excerpts from Henri Ducrocq's message of 2009-05-17: > I'm having a related problem, but this one is totally internal to Sup: > After I read a new email, in most cases (possibly always, I can't say) > the number of unread emails isn't decremented and stays at 1. I am > talking about the number of unread messages shown on the labels page > ('L' shortcut.) Is this still the case after you save state with "$"? -- William From wmorgan-sup@masanjin.net Mon May 18 15:17:33 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 18 May 2009 12:17:33 -0700 Subject: [sup-talk] inconsistencies and new user confusion In-Reply-To: <20090512233303.GU28854@pimlott.net> References: <20090512233303.GU28854@pimlott.net> Message-ID: <1242674066-sup-6463@entry> Reformatted excerpts from Andrew Pimlott's message of 2009-05-12: > There seem to be serious consistency issues. For example, I applied a > label "cal" to a thread. I press "L" to list labels, and it's not > there. Can you try this again? There was a bug with new labels, where they were disappearing from the label list under certain conditions (though not from the index). Note that that list only counts messages. > I sync the mailbox, unsure if this is needed. (It shouldn't be, of > course--if it is, I hope this is intended to be fixed, perhaps with > the undo work.) Currently it is needed. It would be possible to avoid it, with some work (Sup has an event broadcast mechanism for things like this), though I think it will be difficult to maintain the "