From david.guibert@cdcsp.univ-lyon1.fr Wed Apr 1 04:41:00 2009 From: david.guibert@cdcsp.univ-lyon1.fr (David Guibert) Date: Wed, 01 Apr 2009 10:41:00 +0200 Subject: [sup-talk] Config in VCS In-Reply-To: <1238234052-sup-2032@ausone.home> References: <49CD0B3E.9010002@cs.rpi.edu> <1238234052-sup-2032@ausone.home> Message-ID: <1238574341-sup-4744@orsine> Hi, >From Nicolas Pouillard: > Excerpts from Ethan Glasser-Camp's message of Fri Mar 27 18:22:06 +0100 2009: > > Hi, long time reader, first time caller. > > > > Many years ago I used fetchmail+Mutt to handle my mail, but all my > > configuration was lost in a hard drive crash and I didn't have the > > energy to recreate it. So as I look at sup, I am judging how difficult > > it is to keep its configuration in a git repo (for easier replication > > and backup). > > About backups, I recommend sup users to make regular sup-dump's, not only > because sup still have bugs but also because it's the only (meta)data > needed to reconstruct your index. For backup, I keep my configuration files into a git repository. I create the following pre-commit hook to create automatically sup-dump's on each commit. $ cat > .git/hooks/pre-commit < sup.dump git add -f sup.dump EOF For replication, you can also define the post-update hook as $ cat > .git/hooks/post-update < Hi all, What about adding such a read only mode to sup? I see to important usages: * Running sup in an environment that we don't want to change, like a backup or synchronized index. * Running a second instance of sup to make searches while we are editing a mail. Best regards, -- Nicolas Pouillard From ismith@MIT.EDU Tue Apr 7 19:29:04 2009 From: ismith@MIT.EDU (Ian Smith) Date: Tue, 07 Apr 2009 19:29:04 -0400 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239128578-sup-6684@ausone.local> References: <1239128578-sup-6684@ausone.local> Message-ID: <1239146860-sup-6624@baad> Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > What about adding such a read only mode to sup? > * Running a second instance of sup to make searches > while we are editing a mail. This use case already works using buffers - you can switch between them fairly easily. I need to rewrite my reflexes still, but I run sup in screen, so it can't be that hard. Ian -- Ian Smith ismith at mit.edu ismith at bostonaccess.org From nicolas.pouillard@gmail.com Wed Apr 8 04:36:23 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 08 Apr 2009 10:36:23 +0200 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239146860-sup-6624@baad> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> Message-ID: <1239179745-sup-912@ausone.inria.fr> Excerpts from Ian Smith's message of Wed Apr 08 01:29:04 +0200 2009: > Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > > What about adding such a read only mode to sup? > > * Running a second instance of sup to make searches > > while we are editing a mail. > > This use case already works using buffers - you can switch between them > fairly easily. I need to rewrite my reflexes still, but I run sup in > screen, so it can't be that hard. Even when you are editing a mail? -- Nicolas Pouillard From ismith@MIT.EDU Wed Apr 8 08:30:05 2009 From: ismith@MIT.EDU (Ian Smith) Date: Wed, 08 Apr 2009 08:30:05 -0400 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239179745-sup-912@ausone.inria.fr> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239179745-sup-912@ausone.inria.fr> Message-ID: <1239193758-sup-8985@baad> Excerpts from Nicolas Pouillard's message of Wed Apr 08 04:36:23 -0400 2009: > Excerpts from Ian Smith's message of Wed Apr 08 01:29:04 +0200 2009: > > Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > > > What about adding such a read only mode to sup? > > > * Running a second instance of sup to make searches > > > while we are editing a mail. > > > > This use case already works using buffers - you can switch between them > > fairly easily. I need to rewrite my reflexes still, but I run sup in > > screen, so it can't be that hard. > > Even when you are editing a mail? Oh, you're right - you have to switch into reply-mode, out of the editor. Hmm. -- Ian Smith ismith at mit.edu ismith at bostonaccess.org From andrew@pimlott.net Wed Apr 8 13:01:08 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Wed, 8 Apr 2009 10:01:08 -0700 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239193758-sup-8985@baad> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239179745-sup-912@ausone.inria.fr> <1239193758-sup-8985@baad> Message-ID: <20090408170108.GW11701@pimlott.net> On Wed, Apr 08, 2009 at 08:30:05AM -0400, Ian Smith wrote: > Excerpts from Nicolas Pouillard's message of Wed Apr 08 04:36:23 -0400 2009: > > Excerpts from Ian Smith's message of Wed Apr 08 01:29:04 +0200 2009: > > > This use case already works using buffers - you can switch between them > > > fairly easily. I need to rewrite my reflexes still, but I run sup in > > > screen, so it can't be that hard. > > > > Even when you are editing a mail? > > Oh, you're right - you have to switch into reply-mode, out of the > editor. Hmm. I've always wondered, could a mailer use job control, like a shell, to allow it to have multiple sub-processes and switch among them? Then, you could suspend your editor and get back to sup, and later resume your editor. Andrew From marka@pobox.com Wed Apr 8 13:32:29 2009 From: marka@pobox.com (Mark Alexander) Date: Wed, 8 Apr 2009 10:32:29 -0700 Subject: [sup-talk] More about those lost messages Message-ID: I've been using sup (next branch) for a week or so, and no crashes so far. But I'm still having problems with occasional lost messages. Messages that were definitely in the index in the evening are gone when I start sup again the next morning. I've recovered them by doing a sup-sync --all, but I'm still puzzled by what's going on. This has happened twice that I've noticed, and in both cases the message that got lost was part of a thread in which I was participating, and was in the inbox. It could be that other messages got lost in other threads that I was ignoring, but I didn't notice it because I was ignoring those threads :-) . When I first noticed this a couple of weeks ago, I thought it might have something to do with fetchmail running in the background. I changed things around so that fetchmail is only running in the background when sup is not running. When sup is running, it invokes fetchmail via the poll hook. But this doesn't seem to have had any effect on the lost message problem. This is just idle, uninformed speculation, but maybe some records that were in the in-memory index didn't get written to disk when sup exited? Would neglecting to use the '$' command do this? From wirtwolff@gmail.com Wed Apr 8 15:03:07 2009 From: wirtwolff@gmail.com (Wirt Wolff) Date: Wed, 08 Apr 2009 13:03:07 -0600 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239146860-sup-6624@baad> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> Message-ID: <1239217190-sup-5981@chigamba> Excerpts from Ian Smith's message of Tue Apr 07 17:29:04 -0600 2009: > Excerpts from Nicolas Pouillard's message of Tue Apr 07 14:26:58 -0400 2009: > > What about adding such a read only mode to sup? > > * Running a second instance of sup to make searches > > while we are editing a mail. > > This use case already works using buffers - you can switch between them > fairly easily. I need to rewrite my reflexes still, but I run sup in > screen, so it can't be that hard. In my situation buffers aren't enough sometimes. Aside from having to exit the editor, unless I'm mistaken there's no way to view more than one buffer at once. Mostly I've appreciated relaxing into that way of working, and even found it helpful to concentration and productivity. However, when for example, composing reviews of unapplied patches, each with one or more discussion threads, I often find myself wishing I could toggle back and forth between a couple of search buffers and their thread views in one frame, while composing in another. There are surely other solutions, hopefully simpler ones, but I've not gotten motivated enough to work them out yet. A read-only second sup would get daily usage here. It would be great to not have to switch to and from "sup mode" while completing tasks referencing multiple threads. -- regards, wmw From bm@bjornmichelsen.com Wed Apr 8 16:44:34 2009 From: bm@bjornmichelsen.com (=?UNKNOWN?Q?Bj=C3=B8rn?= Michelsen) Date: Wed, 08 Apr 2009 22:44:34 +0200 Subject: [sup-talk] Saving status of merged threads with '#' on next branch Message-ID: <1239177702-sup-8165@snowstorm> Hi all, For some reason, the '#' command isn't saving the status of tagged threads being forced to merge. I get a visual feedback that the threads have been put into the same one, but when I come back to the view after killing the buffer, they're separated again. I'm currently running sup from the next branch. But, I also checked the command on the 0.7 gem version without any luck. I'm a bit lost as to where I should begin troubleshooting, so I'm wondering if someone else have had the same problem? Maybe I have misinterpreted the command? -- Mvh. Bj?rn Michelsen MOB: +47 934 55 474 From wmorgan-sup@masanjin.net Wed Apr 8 17:49:47 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 08 Apr 2009 14:49:47 -0700 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239217190-sup-5981@chigamba> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239217190-sup-5981@chigamba> Message-ID: <1239226676-sup-7216@entry> Reformatted excerpts from Wirt Wolff's message of 2009-04-08: > However, when for example, composing reviews of unapplied patches, > each with one or more discussion threads, I often find myself wishing > I could toggle back and forth between a couple of search buffers and > their thread views in one frame, while composing in another. The curses code was designed to support splitting the screen into multiple buffers/frames/windows. I, too, found the initial implementation of one buffer at a time to be surprisingly useful, so I never took it the rest of the way. I'm certainly open to someone fighting curses and making this possible. As possibly an easier step, I, too, too, find the current buffer- switching to be pretty onerous, and would love to hear suggestions on how to improve it. One easy thing to comes to mind would be to have buffer-list-mode (which is what you get when you hit B) sort the buffer list by last access. Remap that to something like ";" and you have one-handed buffer- switching with minimal keystrokes. > A read-only second sup would get daily usage here. It would be great > to not have to switch to and from "sup mode" while completing tasks > referencing multiple threads. I think this would be fine and not too hard to implement. In fact, I think it might not be too much harder to have multiple simultaneous read/write Sups, by locking ~/.sup on a per-operation rather than per-process basis. Of course you'd have to be cognizant of the fact that they wouldn't be sharing any state except via $ and @. It would be like editing a wiki page across multiple tabs. There's no merge, there's only overwrite. -- William From wmorgan-sup@masanjin.net Wed Apr 8 18:18:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 08 Apr 2009 15:18:14 -0700 Subject: [sup-talk] Read only mode for sup In-Reply-To: <20090408170108.GW11701@pimlott.net> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239179745-sup-912@ausone.inria.fr> <1239193758-sup-8985@baad> <20090408170108.GW11701@pimlott.net> Message-ID: <1239227396-sup-782@entry> Reformatted excerpts from Andrew Pimlott's message of 2009-04-08: > I've always wondered, could a mailer use job control, like a shell, to > allow it to have multiple sub-processes and switch among them? Then, > you could suspend your editor and get back to sup, and later resume > your editor. The problem is that when the editor is in the foreground, it has control. So I don't think Sup would be able to suspend it. But it might be possible to do something like catch SIGTSTP signals when the editor is running, and file those process ids away for later resumption. You'd have to suspend from within the editor, but the rest of the behavior might be close to what you want. Interesting idea. -- William From wmorgan-sup@masanjin.net Wed Apr 8 18:34:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 08 Apr 2009 15:34:06 -0700 Subject: [sup-talk] More about those lost messages In-Reply-To: References: Message-ID: <1239229590-sup-7235@entry> Reformatted excerpts from Mark Alexander's message of 2009-04-08: > This has happened twice that I've noticed, and in both cases the > message that got lost was part of a thread in which I was > participating, and was in the inbox. Just to confirm: you saw the message in Sup, you quit Sup, and when you started Sup again, the message wasn't there? The next time this happens, would you mind trying this? Before running sup-sync --all, find the message id of the missing message (i.e. from the mbox file), and run: devel/console.sh # start the debug console Index.index.search("message_id:XXX").total_hits # from within the console where XXX is the message id, without the angle brackets. E.g. Index.index.search("message_id:a412e2a70904081032x3438abedw3a23d87973f56d35 at mail.gmail.com") This will tell us whether it's in the index or not, without anything of Sup's curses interface getting in the way. If it is in the index (the total_hits is > 0), then try finding the labels: docid = Index.index.search("message_id:XXX").hits.first.doc Index.build_message(docid).labels > This is just idle, uninformed speculation, but maybe some records that > were in the in-memory index didn't get written to disk when sup > exited? Would neglecting to use the '$' command do this? Sup saves all state when you quit. That's why I'm wondering whether the messages actually are in the index, or somehow are just hidden from the curses interface. -- William From nicolas.pouillard@gmail.com Thu Apr 9 07:55:56 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 09 Apr 2009 13:55:56 +0200 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239226676-sup-7216@entry> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239217190-sup-5981@chigamba> <1239226676-sup-7216@entry> Message-ID: <1239278036-sup-7327@ausone.inria.fr> Excerpts from William Morgan's message of Wed Apr 08 23:49:47 +0200 2009: > Reformatted excerpts from Wirt Wolff's message of 2009-04-08: > > However, when for example, composing reviews of unapplied patches, > > each with one or more discussion threads, I often find myself wishing > > I could toggle back and forth between a couple of search buffers and > > their thread views in one frame, while composing in another. > > The curses code was designed to support splitting the screen into > multiple buffers/frames/windows. I, too, found the initial > implementation of one buffer at a time to be surprisingly useful, so I > never took it the rest of the way. I'm certainly open to someone > fighting curses and making this possible. > > As possibly an easier step, I, too, too, find the current buffer- > switching to be pretty onerous, and would love to hear suggestions on > how to improve it. > > One easy thing to comes to mind would be to have buffer-list-mode (which > is what you get when you hit B) sort the buffer list by last access. > Remap that to something like ";" and you have one-handed buffer- > switching with minimal keystrokes. Or some kind of historic like with "cd -42". It could be "b1" for the last one, "b2" for the previous... I actually use these bindings in my window manager. > > A read-only second sup would get daily usage here. It would be great > > to not have to switch to and from "sup mode" while completing tasks > > referencing multiple threads. > > I think this would be fine and not too hard to implement. > > In fact, I think it might not be too much harder to have multiple > simultaneous read/write Sups, by locking ~/.sup on a per-operation > rather than per-process basis. Of course you'd have to be cognizant of > the fact that they wouldn't be sharing any state except via $ and @. > It would be like editing a wiki page across multiple tabs. There's no > merge, there's only overwrite. Simultaneous read/write Sups would be great too! -- Nicolas Pouillard From marka@pobox.com Thu Apr 9 11:36:54 2009 From: marka@pobox.com (Mark Alexander) Date: Thu, 9 Apr 2009 08:36:54 -0700 Subject: [sup-talk] More about those lost messages In-Reply-To: <1239229590-sup-7235@entry> References: <1239229590-sup-7235@entry> Message-ID: I'm starting to think it may be a user error on my part. It looks as if I might have used the 'd' (delete) command on some messages, perhaps accidentally or carelessly in some cases, and that prevented them from showing up in threads later. I'll continue studying this. From marka@pobox.com Thu Apr 9 11:39:39 2009 From: marka@pobox.com (Mark Alexander) Date: Thu, 9 Apr 2009 08:39:39 -0700 Subject: [sup-talk] Saving status of merged threads with '#' on next branch In-Reply-To: <1239177702-sup-8165@snowstorm> References: <1239177702-sup-8165@snowstorm> Message-ID: 2009/4/8 Bj?rn Michelsen : > For some reason, the '#' command isn't saving the status of tagged > threads being forced to merge. I get a visual feedback that the threads > have been put into the same one, but when I come back to the view after > killing the buffer, they're separated again. I've noticed this as well. I figured it was a feature, not a bug :-) . From wmorgan-sup@masanjin.net Thu Apr 9 13:30:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 09 Apr 2009 10:30:09 -0700 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239226676-sup-7216@entry> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239217190-sup-5981@chigamba> <1239226676-sup-7216@entry> Message-ID: <1239297831-sup-5831@entry> Reformatted excerpts from William Morgan's message of 2009-04-08: > One easy thing to comes to mind would be to have buffer-list-mode > (which is what you get when you hit B) sort the buffer list by last > access. Remap that to something like ";" and you have one-handed > buffer- switching with minimal keystrokes. Ok, I've done this on branch 'better-buffer-list', which I've merged into next. Pull and see how you guys like it. Summary: 1. 'b' rolls the buffer forward as usual. 2. 'B' now rolls the buffer backwards like in the olden days. 3. ';' pulls up the buffer list, which is now sorted by access time, colorized to show "system" vs non-"system" buffers, and has little stars for buffers with unsaved content. 4. '+' is now the apply-to-tagged command. Sorry for changing so many keymappings, but I really wanted ';' so that, with 'j' and 'k', you can swap buffers really quickly with just one hand. Since that freed up B, I figured I'd reenable the old behavior, and '+' kinda makes sense for apply-to-tagged anyways. Nicolas, I had to revert your "Buffer switching, 'bn' for the next one and 'bp' for the previous" change in next. I hope you're not offended! :) -- William From vikrambkumar@gmail.com Thu Apr 9 13:34:23 2009 From: vikrambkumar@gmail.com (Vikram Kumar) Date: Thu, 9 Apr 2009 13:34:23 -0400 Subject: [sup-talk] Sup and Cygwin Message-ID: <89041090904091034i420d33e1k6c53440229019039@mail.gmail.com> Has anybody tried it before? $ sup /usr/lib/ruby/1.8/dl/import.rb:29:in `initialize': No such file or directory (RuntimeError) from /usr/lib/ruby/1.8/dl/import.rb:29:in `dlopen' from /usr/lib/ruby/1.8/dl/import.rb:29:in `dlload' from /usr/lib/ruby/1.8/dl/import.rb:27:in `each' from /usr/lib/ruby/1.8/dl/import.rb:27:in `dlload' from /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:17 from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' from /usr/lib/ruby/gems/1.8/gems/sup-0.7/bin/sup:9 from /usr/bin/sup:19:in `load' from /usr/bin/sup:19 I do have all the requirements available in cygwin ruby + gems. *** LOCAL GEMS *** ferret (0.11.6) ncurses (0.9.1) rmail (1.0.0) highline (1.5.0, 1.4.0) net-ssh (2.0.11, 1.1.2) net-ssh-gateway (1.0.1) trollop (1.13) lockfile (1.4.3) mime-types (1.16, 1.15) Vikram P.S - I couldn't find a way to search the message list archives. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wmorgan-sup@masanjin.net Thu Apr 9 13:53:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 09 Apr 2009 10:53:32 -0700 Subject: [sup-talk] brief master update Message-ID: <1239299514-sup-1793@entry> I've merged these branches into master: - dont-canonicalize-email-addresses - multi-remove-labels - merge-labels - encoding-misspellings - background-save I'd like to do a little more work on undo, and fix the From problem, and then we can start thinking about an 0.8 release! -- William From wmorgan-sup@masanjin.net Thu Apr 9 14:02:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 09 Apr 2009 11:02:08 -0700 Subject: [sup-talk] Saving status of merged threads with '#' on next branch In-Reply-To: <1239177702-sup-8165@snowstorm> References: <1239177702-sup-8165@snowstorm> Message-ID: <1239299963-sup-5933@entry> Reformatted excerpts from =?UNKNOWN?Q?Bj=C3=B8rn?= Michelsen's message of 2009-04-08: > I'm a bit lost as to where I should begin troubleshooting, so I'm > wondering if someone else have had the same problem? It's a known problem. I'm not sure why it isn't saved. If you want to start investigating, ThreadSet#join_threads in lib/sup/threads.rb is the joining code. Maybe the call to Message#add_ref is wrong somehow. I'm also curious about your From: line, which is RFC2047-encoded but with the "UNKNOWN" charset. What produces that? Surely not Sup! -- William From marka@pobox.com Thu Apr 9 14:37:40 2009 From: marka@pobox.com (Mark Alexander) Date: Thu, 9 Apr 2009 11:37:40 -0700 Subject: [sup-talk] Sup and Cygwin In-Reply-To: <89041090904091034i420d33e1k6c53440229019039@mail.gmail.com> References: <89041090904091034i420d33e1k6c53440229019039@mail.gmail.com> Message-ID: On Thu, Apr 9, 2009 at 10:34 AM, Vikram Kumar wrote: > P.S - I couldn't find a way to search the message list archives. Try the archive here: http://www.nabble.com/SUP-Talk-f27890.html From wmorgan-sup@masanjin.net Thu Apr 9 15:11:33 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 09 Apr 2009 12:11:33 -0700 Subject: [sup-talk] Sup and Cygwin In-Reply-To: <89041090904091034i420d33e1k6c53440229019039@mail.gmail.com> References: <89041090904091034i420d33e1k6c53440229019039@mail.gmail.com> Message-ID: <1239304198-sup-9672@entry> Reformatted excerpts from Vikram Kumar's message of 2009-04-09: > Has anybody tried it before? > > $ sup > /usr/lib/ruby/1.8/dl/import.rb:29:in `initialize': No such file or directory > (RuntimeError) Oh, that's a bug. I think you should be able to get around it by changing the 'libc.so.6' on this line: > from /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:17 to 'cygwin1.dll'. I'd be interested to know if that works. If so I'll fix it in git. -- William From nicolas.pouillard@gmail.com Fri Apr 10 04:36:16 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Fri, 10 Apr 2009 10:36:16 +0200 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239297831-sup-5831@entry> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239217190-sup-5981@chigamba> <1239226676-sup-7216@entry> <1239297831-sup-5831@entry> Message-ID: <1239352575-sup-724@ausone.inria.fr> Excerpts from William Morgan's message of Thu Apr 09 19:30:09 +0200 2009: > Reformatted excerpts from William Morgan's message of 2009-04-08: > > One easy thing to comes to mind would be to have buffer-list-mode > > (which is what you get when you hit B) sort the buffer list by last > > access. Remap that to something like ";" and you have one-handed > > buffer- switching with minimal keystrokes. > > Ok, I've done this on branch 'better-buffer-list', which I've merged > into next. Pull and see how you guys like it. Summary: > > 1. 'b' rolls the buffer forward as usual. > 2. 'B' now rolls the buffer backwards like in the olden days. > 3. ';' pulls up the buffer list, which is now sorted by access time, > colorized to show "system" vs non-"system" buffers, and has little > stars for buffers with unsaved content. > 4. '+' is now the apply-to-tagged command. > > Sorry for changing so many keymappings, but I really wanted ';' so that, > with 'j' and 'k', you can swap buffers really quickly with just one > hand. Since that freed up B, I figured I'd reenable the old behavior, > and '+' kinda makes sense for apply-to-tagged anyways. > > Nicolas, I had to revert your "Buffer switching, 'bn' for the next one > and 'bp' for the previous" change in next. I hope you're not offended! :) I'm not offended, I just wanted to tend to more scalable bindings, where a meaningful letter is kept to be the leading one for more advanced bindings on a particular topic. Moreover optimizing bindings for QUERTY keymap does not make sense for other people... Personally I use and prefer DVORAK. -- Nicolas Pouillard From nicolas.pouillard@gmail.com Fri Apr 10 04:40:00 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Fri, 10 Apr 2009 10:40:00 +0200 Subject: [sup-talk] brief master update In-Reply-To: <1239299514-sup-1793@entry> References: <1239299514-sup-1793@entry> Message-ID: <1239352712-sup-3931@ausone.inria.fr> Excerpts from William Morgan's message of Thu Apr 09 19:53:32 +0200 2009: > I've merged these branches into master: > - dont-canonicalize-email-addresses > - multi-remove-labels > - merge-labels > - encoding-misspellings > - background-save > > I'd like to do a little more work on undo, and fix the From problem, and > then we can start thinking about an 0.8 release! Great! Just a small administrative question... Do we consider branches merged into master as dead. That is making a new one if we want to improve again on this topic? -- Nicolas Pouillard From wmorgan-sup@masanjin.net Fri Apr 10 08:23:02 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 10 Apr 2009 05:23:02 -0700 Subject: [sup-talk] brief master update In-Reply-To: <1239352712-sup-3931@ausone.inria.fr> References: <1239299514-sup-1793@entry> <1239352712-sup-3931@ausone.inria.fr> Message-ID: <1239365949-sup-627@entry> Reformatted excerpts from Nicolas Pouillard's message of 2009-04-10: > Just a small administrative question... Do we consider branches merged > into master as dead. That is making a new one if we want to improve > again on this topic? Yes... I don't see a real point in adding more commits to the branch and remerging once it's in master. I'm happy to apply trivial changes directly to master, and anything non-trivial I prefer to test out in next first. -- William From wmorgan-sup@masanjin.net Fri Apr 10 08:24:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 10 Apr 2009 05:24:15 -0700 Subject: [sup-talk] Read only mode for sup In-Reply-To: <1239352575-sup-724@ausone.inria.fr> References: <1239128578-sup-6684@ausone.local> <1239146860-sup-6624@baad> <1239217190-sup-5981@chigamba> <1239226676-sup-7216@entry> <1239297831-sup-5831@entry> <1239352575-sup-724@ausone.inria.fr> Message-ID: <1239366212-sup-2213@entry> Reformatted excerpts from Nicolas Pouillard's message of 2009-04-10: > Moreover optimizing bindings for QUERTY keymap does not make sense for > other people... Personally I use and prefer DVORAK. Uh oh. Well, time to get working on that configurable keymap patch... -- William From lee@writequit.org Fri Apr 10 15:04:58 2009 From: lee@writequit.org (Lee Hinman) Date: Fri, 10 Apr 2009 13:04:58 -0600 Subject: [sup-talk] Display size of message or attachments? Message-ID: <1239390142-sup-9102@black> Hey Sup'ers Is there a way to display the total size of the message in your inbox? (Including attachments). I wasn't able to find a way (other than saving everything and doing it manually). On the same note, is there a way I can see how big an attachment is on an email? I know it shows up when sending email, but not on a retrieved email. Thanks, Lee From wmorgan-sup@masanjin.net Mon Apr 13 10:56:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 13 Apr 2009 07:56:08 -0700 Subject: [sup-talk] Display size of message or attachments? In-Reply-To: <1239390142-sup-9102@black> References: <1239390142-sup-9102@black> Message-ID: <1239634495-sup-2172@entry> Reformatted excerpts from Lee Hinman's message of 2009-04-10: > Is there a way to display the total size of the message in your inbox? > (Including attachments). I wasn't able to find a way (other than > saving everything and doing it manually). This wouldn't be too hard but I'm not sure what the right UI would be. Suggestions, anyone? > On the same note, is there a way I can see how big an attachment is on > an email? I know it shows up when sending email, but not on a > retrieved email. I've added this in git. -- William From lee@writequit.org Mon Apr 13 11:23:23 2009 From: lee@writequit.org (Lee Hinman) Date: Mon, 13 Apr 2009 09:23:23 -0600 Subject: [sup-talk] Display size of message or attachments? In-Reply-To: <1239634495-sup-2172@entry> References: <1239390142-sup-9102@black> <1239634495-sup-2172@entry> Message-ID: <1239636103-sup-6606@black> Excerpts from William Morgan's message of Mon Apr 13 08:56:08 -0600 2009: > Reformatted excerpts from Lee Hinman's message of 2009-04-10: > > Is there a way to display the total size of the message in your inbox? > > (Including attachments). I wasn't able to find a way (other than > > saving everything and doing it manually). > > This wouldn't be too hard but I'm not sure what the right UI would be. > Suggestions, anyone? How about this?: 8:56am [213k] me,William (2) >[sup-talk] Display size of message or attachments? +list +sup This wouldn't b... > > On the same note, is there a way I can see how big an attachment is on > > an email? I know it shows up when sending email, but not on a > > retrieved email. > > I've added this in git. Thanks! - Lee From lee@writequit.org Mon Apr 13 12:00:56 2009 From: lee@writequit.org (Lee Hinman) Date: Mon, 13 Apr 2009 10:00:56 -0600 Subject: [sup-talk] Suggestion for '.' keybinding Message-ID: <1239638279-sup-6990@black> Sup, Since Sup already emulates vi-bindings, I was wondering if it'd be possible to have '.' bound to "do-it-again". So if I added a label to a mail, then wanted to apply it to a different mail, I could go to the mail and use '.' to apply whatever the last change was. (I know I could tag all the messages ahead of time and label them all at once, but sometimes I want to do it a different way). Is this possible with Sup right now? Does it store what the last action was? (it might for the undo patch, I haven't looked at it) - Lee From wmorgan-sup@masanjin.net Mon Apr 13 19:19:34 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 13 Apr 2009 16:19:34 -0700 Subject: [sup-talk] Display size of message or attachments? In-Reply-To: <1239636103-sup-6606@black> References: <1239390142-sup-9102@black> <1239634495-sup-2172@entry> <1239636103-sup-6606@black> Message-ID: <1239664684-sup-2594@entry> Reformatted excerpts from Lee Hinman's message of 2009-04-13: > 8:56am [213k] me,William (2) >[sup-talk] Display size of message or > attachments? +list +sup This wouldn't b... What does the 213k refer to? The first message in this thread? The newest message? All messages together? If you want per-message sizes, it's going to have to go somewhere in thread-view-mode, methinks... -- William From rhomunuq+ml_sup@gmail.com Tue Apr 14 19:52:13 2009 From: rhomunuq+ml_sup@gmail.com (Iain) Date: Wed, 15 Apr 2009 00:52:13 +0100 Subject: [sup-talk] Display size of message or attachments? In-Reply-To: <1239664684-sup-2594@entry> References: <1239390142-sup-9102@black> <1239634495-sup-2172@entry> <1239636103-sup-6606@black> <1239664684-sup-2594@entry> Message-ID: <49E521AD.9070507@gmail.com> Long time reader; first time poster. Massive thanks to everyone who's worked on sup (in particular to William). I'm dabbling in sup again now with the release of 0.7, which hasn't crashed on me at all so far, hooray! > What does the 213k refer to? The first message in this thread? The > newest message? All messages together? If you want per-message sizes, > it's going to have to go somewhere in thread-view-mode, methinks... Sounds like a potentially neat feature. I'd suggest: - When viewing lists of threads (inbox-mode, search-results-mode, etc), the combined size of all messages together in the thread. - When viewing a particular thread (thread-view-mode), showing individually for each message. Alternatively (or in addition?), perhaps even better would be the ability to do searches like size:>200k, which would show all messages (or all threads?) over 200k in size. This would be useful for people like me who prune excessively large attachments from disk occasionally. (Which at present is a little fiddly, involving messing with the Maildir-stored messages then sup-sync'ing, but that's another story...) Cheers, ~Iain From bm@bjornmichelsen.com Wed Apr 15 11:58:03 2009 From: bm@bjornmichelsen.com (Bjorn Michelsen) Date: Wed, 15 Apr 2009 17:58:03 +0200 Subject: [sup-talk] Saving status of merged threads with '#' on next branch In-Reply-To: <1239299963-sup-5933@entry> References: <1239177702-sup-8165@snowstorm> <1239299963-sup-5933@entry> Message-ID: <1239810733-sup-5572@snowstorm> Excerpts from William Morgan's message of to. april 09 20:02:08 +0200 2009: > > I'm a bit lost as to where I should begin troubleshooting, so I'm > > wondering if someone else have had the same problem? > > It's a known problem. I'm not sure why it isn't saved. If you want to > start investigating, ThreadSet#join_threads in lib/sup/threads.rb is the > joining code. Maybe the call to Message#add_ref is wrong somehow. Thanks for clearing that up, as well as the additional information regarding where to start looking. > I'm also curious about your From: line, which is RFC2047-encoded but > with the "UNKNOWN" charset. What produces that? Surely not Sup! I haven't replied earlier because I've been trying to figure out what causes the strange From: address. locale outputs the following: LANG=nb_NO.UTF-8 LC_CTYPE=nb_NO.UTF-8 LC_NUMERIC="nb_NO.UTF-8" LC_TIME="nb_NO.UTF-8" LC_COLLATE="nb_NO.UTF-8" LC_MONETARY="nb_NO.UTF-8" LC_MESSAGES=en_US.UTF-8 LC_PAPER="nb_NO.UTF-8" LC_NAME="nb_NO.UTF-8" LC_ADDRESS="nb_NO.UTF-8" LC_TELEPHONE="nb_NO.UTF-8" LC_MEASUREMENT="nb_NO.UTF-8" LC_IDENTIFICATION="nb_NO.UTF-8" LC_ALL= And Vim is saying that all files related to sup is encoded as utf8. So, at the moment I don't know why this is happening. Maybe someone using special characters can let me in on their secret? -- Mvh. Bj?rn Michelsen MOB: +47 934 55 474 From rhomunuq+ml_sup@gmail.com Wed Apr 15 13:29:15 2009 From: rhomunuq+ml_sup@gmail.com (Iain) Date: Wed, 15 Apr 2009 18:29:15 +0100 Subject: [sup-talk] Lost Maildir Messages In-Reply-To: References: <1237224356-sup-1941@entry> <1237383823-sup-8242@entry> <1237490703-sup-4095@entry> Message-ID: <49E6196B.504@gmail.com> > Hm, that would be bad. The right way to debug this is to wait for it to > happen again (!) and examine the contents of the poll-mode and log-mode > buffers, which should describe what Sup thinks it was doing at the time. I've noticed what seems to be the same problem. I've been using getmail (no procmail or fetchmail), to grab messages into Maildir folders. Occasionally, messages don't show up in Sup. They appear only when I do a manual sup-sync --changed. I discovered by accident (by impatiently trying to read an email that I knew was being delivered by getmail into Sup) that I can reliably replicate the problem, or at least a similar problem. It seems to occur when Sup polls the Maildir at the same time as getmail is retrieving the message. I can replicate the problem by pressing P repeatedly in Sup to manually poll for messages, while getmail is in the process of retrieving. (It takes about 4 seconds for getmail to go from initialising a retrieval to dropping the mail in the Maildir, so there is a big window for when I press P, and I can replicate the problem reliably.) Every time, Sup doesn't retrieve the new messages. The log-mode buffer doesn't show anything relevant in my artifically-produced replication of the problem, because it doesn't log when you manually poll. The poll-mode buffer for the source in question displays the exact same message on every poll of the source (before getmail runs, during the getmail run, after the getmail run) when repeatedly polling before and during the getmail run: Loading from maildir:///home/user/Mail/address at example.com/... Found message at 12398138490002177 with labels {mylabel} -- the timestamp never changes. If I had to guess, I'd say that it looks like the shortcut taken (looking at the mtime of the directory to see if scanning for a new Maildir message is required) has a race condition. A weird race condition, because I've verified (ls -l --time-style=+%s) that the "new" and "tmp" folders are indeed having their timestamps updated when the mail drops in (they are). This might explain the infrequent lost messages: when not hitting P repeatedly, this race condition is unlikely to occur, only happening when the Sup poll occurs within the few seconds window during which getmail is working and working with a new message to deliver. ~Iain From wmorgan-sup@masanjin.net Wed Apr 15 13:33:24 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 15 Apr 2009 10:33:24 -0700 Subject: [sup-talk] Saving status of merged threads with '#' on next branch In-Reply-To: <1239810733-sup-5572@snowstorm> References: <1239177702-sup-8165@snowstorm> <1239299963-sup-5933@entry> <1239810733-sup-5572@snowstorm> Message-ID: <1239816596-sup-2531@entry> Reformatted excerpts from Bjorn Michelsen's message of 2009-04-15: > I haven't replied earlier because I've been trying to figure out what > causes the strange From: address. Is the weird encoding also present in the files in ~/.sup/sent.mbox? If so, it's could be Rubymail... AFAICT, Rubymail doesn't do anything with rfc2047, but I could have missed it. If not, are you using some funky sendmail? -- William From bm@bjornmichelsen.com Thu Apr 16 05:53:31 2009 From: bm@bjornmichelsen.com (Bjorn Michelsen) Date: Thu, 16 Apr 2009 11:53:31 +0200 Subject: [sup-talk] Saving status of merged threads with '#' on next branch In-Reply-To: <1239816596-sup-2531@entry> References: <1239177702-sup-8165@snowstorm> <1239299963-sup-5933@entry> <1239810733-sup-5572@snowstorm> <1239816596-sup-2531@entry> Message-ID: <1239875483-sup-5697@snowstorm> Excerpts from William Morgan's message of on. april 15 19:33:24 +0200 2009: > > I haven't replied earlier because I've been trying to figure out what > > causes the strange From: address. > > Is the weird encoding also present in the files in ~/.sup/sent.mbox? If > so, it's could be Rubymail... AFAICT, Rubymail doesn't do anything with > rfc2047, but I could have missed it. No, everything is encoded correctly in ~/.sup/sent.mbox > If not, are you using some funky sendmail? I'm using sSMTP at the moment. Maybe it has something to do with the following bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341952#10 ? -- Mvh. Bj?rn Michelsen MOB: +47 934 55 474 From nicolas.pouillard@gmail.com Thu Apr 16 15:47:31 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Thu, 16 Apr 2009 21:47:31 +0200 Subject: [sup-talk] Suggestion for '.' keybinding In-Reply-To: <1239638279-sup-6990@black> References: <1239638279-sup-6990@black> Message-ID: <1239911250-sup-9394@ausone> Excerpts from Lee Hinman's message of Mon Apr 13 18:00:56 +0200 2009: > Sup, > Since Sup already emulates vi-bindings, I was wondering if it'd be possible to > have '.' bound to "do-it-again". So if I added a label to a mail, then wanted > to apply it to a different mail, I could go to the mail and use '.' to apply > whatever the last change was. (I know I could tag all the messages ahead of > time and label them all at once, but sometimes I want to do it a different > way). > > Is this possible with Sup right now? Does it store what the last action was? > (it might for the undo patch, I haven't looked at it) I greatly support this idea! -- Nicolas Pouillard From marka@pobox.com Thu Apr 16 18:05:59 2009 From: marka@pobox.com (Mark Alexander) Date: Thu, 16 Apr 2009 15:05:59 -0700 Subject: [sup-talk] Possible problem with maildir ID generation Message-ID: I've been studying maildir.rb (and adding some debug code) while trying to figure out my lost message problem. I think there may be a problem with the way the internal message IDs are generated. The make_id method glues together the file timestamp and size. But I think this could lead to an out-of-order problem in the @ids array. Consider two messages that arrive in the same second, but the second message is smaller than the first. Because the message size makes up the low seven (decimal) digits of the ID, the second message, even though it arrived later, will have an ID that is less than the first message. Then suppose that sup polls the maildir directory after the first message arrives, but before the second message arrives, and sets the cur_offset to the ID of the first message. Then, the next time it polls, it will see the second message, but because its ID is less than that of the first message, it will appear before the first in the @ids array after it is sorted. So then the each method will skip the second message, because cur_offset (the ID of the first message) will be found in @ids after it. Does this scenario make sense? I have seen what appears to be one instance of this happening, though I'm still watching closely and adding more debugging code to make sure that it explains all of the lost messages. From reid.thompson@ateb.com Fri Apr 17 15:41:12 2009 From: reid.thompson@ateb.com (Reid Thompson) Date: Fri, 17 Apr 2009 15:41:12 -0400 Subject: [sup-talk] Two questions Message-ID: <1239997272.5948.104.camel@localhost> >From the readme: Note that Sup never changes the contents of any mailboxes; it only indexes in to them. So it shouldn't ever corrupt your mail. The flip side is that if you change a mailbox (e.g. delete messages, or, in the case of mbox files, read an unread message) then Sup will be unable to load messages from that source and will ask you to run sup-sync --changed. So, in order to actually manage my email, I have to utilize a different email client to delete unwanted mail - essentially doing the same work twice, or am I missing something? Could sup-sync --changed be incorporated into sup, and triggered automatically by sup itself? From btricha@gmail.com Mon Apr 20 17:52:24 2009 From: btricha@gmail.com (Bryan Richardson) Date: Mon, 20 Apr 2009 15:52:24 -0600 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> Message-ID: <3f81a4240904201452u78abe68bj2a4b9863b850e8a@mail.gmail.com> BUMP!!! So... no one uses Sup with Microsoft Exchange?! :( -- Bryan On 4/14/09, Bryan Richardson wrote: > Hello all, > > Has anyone had success using Sup with Microsoft Exchange 2007? I'm able to > download email no problem, and I'm also able to send email through my > exchange server. However, my problem lies in the fact that when I send an > email from Sup, it doesn't show up in the Sent Items folder of my exchange > account. I'm not that familiar with IMAP, but I'm guessing this is maybe > due to the fact that I haven't subscribed to the Sent Items folder in Sup. > In response to this, another hurdle I'm trying to get over is how to even > tell what folders are available on my exchange account for subscribing to. > Is there a way to use Sup to query for available folders? > > Thanks in advance! > > -- > Bryan > From marka@pobox.com Mon Apr 20 18:54:57 2009 From: marka@pobox.com (Mark Alexander) Date: Mon, 20 Apr 2009 15:54:57 -0700 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <3f81a4240904201452u78abe68bj2a4b9863b850e8a@mail.gmail.com> References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <3f81a4240904201452u78abe68bj2a4b9863b850e8a@mail.gmail.com> Message-ID: <1240267632-sup-2023@r50p> Excerpts from Bryan Richardson's message of Mon Apr 20 14:52:24 -0700 2009: > So... no one uses Sup with Microsoft Exchange?! :( Unfortunately, we use Exchange at work. But I hide that unpleasant fact from myself by using fetchmail and postfix on a Linux box. I have never used Outlook or the web interface that Exchange provides. Instead, I've always used mutt -- and more recently, sup. So I have no idea if I'm having the same problem you are. Sorry! From wmorgan-sup@masanjin.net Tue Apr 21 09:02:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 21 Apr 2009 06:02:35 -0700 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <3f81a4240904201638v94a7dbdpce0d865cd83d8873@mail.gmail.com> References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <3f81a4240904201452u78abe68bj2a4b9863b850e8a@mail.gmail.com> <1240267632-sup-2023@r50p> <3f81a4240904201638v94a7dbdpce0d865cd83d8873@mail.gmail.com> Message-ID: <1240318807-sup-3080@entry> Hi Bryan, Reformatted excerpts from Bryan Richardson's message of 2009-04-20: > Is it possible to specify where my sent mail gets saved? I'd like to > be able to specify that it gets saved in one of my IMAP folders ('Sent > Items' in my Microsoft Exchange account). This way, if for some > reason I do ever have to access my mail via Microsoft Exchange Web > Access, I'll still have access to all my sent emails. This is currently not possible with Sup, which as a rule doesn't play nicely with other mail clients. It wouldn't be terribly hard to add if you were so inclined (we have an IMAP library in there already) and I'd be happy to point you in the right direction, but it's not on my near-term list of things to do. -- William From wmorgan-sup@masanjin.net Tue Apr 21 09:06:24 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 21 Apr 2009 06:06:24 -0700 Subject: [sup-talk] Two questions In-Reply-To: <1239997272.5948.104.camel@localhost> References: <1239997272.5948.104.camel@localhost> Message-ID: <1240318974-sup-6743@entry> Reformatted excerpts from Reid Thompson's message of 2009-04-17: > So, in order to actually manage my email, I have to utilize a > different email client to delete unwanted mail - essentially doing the > same work twice, or am I missing something? For the two special cases of "physically" removing messages marked as deleted or spam, you can use sup-sync-back, which is a batch operation operating on an entire mail source at a time. Currently it only applies to mbox sources and can't be run while Sup is also running. > Could sup-sync --changed be incorporated into sup, and triggered > automatically by sup itself? You could certainly do that via Sup's hook mechanism, but it's a very slow operation (it has to scan over the entire mailbox). -- William From reid.thompson@ateb.com Tue Apr 21 09:13:54 2009 From: reid.thompson@ateb.com (Reid Thompson) Date: Tue, 21 Apr 2009 09:13:54 -0400 Subject: [sup-talk] Two questions In-Reply-To: <1240318974-sup-6743@entry> References: <1239997272.5948.104.camel@localhost> <1240318974-sup-6743@entry> Message-ID: <1240319634.11793.11.camel@localhost> On Tue, 2009-04-21 at 06:06 -0700, William Morgan wrote: > Reformatted excerpts from Reid Thompson's message of 2009-04-17: > > So, in order to actually manage my email, I have to utilize a > > different email client to delete unwanted mail - essentially doing the > > same work twice, or am I missing something? > > For the two special cases of "physically" removing messages marked as > deleted or spam, you can use sup-sync-back, which is a batch operation > operating on an entire mail source at a time. Currently it only applies > to mbox sources and can't be run while Sup is also running. > > > Could sup-sync --changed be incorporated into sup, and triggered > > automatically by sup itself? > > You could certainly do that via Sup's hook mechanism, but it's a very > slow operation (it has to scan over the entire mailbox). OK -- so to 'manage' an imap store, i'd need to setup a mechanism to fetch all the email to a local store, deleting from the imap store, and then do something like schedule an overnight run of sup-sync-back, From wmorgan-sup@masanjin.net Tue Apr 21 09:28:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 21 Apr 2009 06:28:41 -0700 Subject: [sup-talk] Saving status of merged threads with '#' on next branch In-Reply-To: <1239875483-sup-5697@snowstorm> References: <1239177702-sup-8165@snowstorm> <1239299963-sup-5933@entry> <1239810733-sup-5572@snowstorm> <1239816596-sup-2531@entry> <1239875483-sup-5697@snowstorm> Message-ID: <1240320083-sup-2514@entry> Reformatted excerpts from Bjorn Michelsen's message of 2009-04-16: > No, everything is encoded correctly in ~/.sup/sent.mbox Then this is almost definitely your MTA, not Sup. But you could also try sending a message to yourself with another MUA and see what happens. (Probably what will happen is that the MUA will RFC2047-encode your headers, and sSMTP will see that and leave them alone, and this problem will be hidden. So the right answer is really for Sup to RFC2047-encode headers in outgoing email.) > I'm using sSMTP at the moment. Maybe it has something to do with the > following bug > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341952#10 ? The problem could be someone trying to fix that bug (which is basically "we should add RFC2047 support"). Somehow it's not picking up your locale settings. -- William From andrew@pimlott.net Tue Apr 21 09:48:39 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Tue, 21 Apr 2009 06:48:39 -0700 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com> References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <3f81a4240904201452u78abe68bj2a4b9863b850e8a@mail.gmail.com> <1240267632-sup-2023@r50p> <3f81a4240904201638v94a7dbdpce0d865cd83d8873@mail.gmail.com> <1240318807-sup-3080@entry> <3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com> Message-ID: <20090421134839.GY11701@pimlott.net> On Tue, Apr 21, 2009 at 07:42:42AM -0600, Bryan Richardson wrote: > One question I do have though is why my sent messages get saved to my 'Sent > Mail' folder on my GMail account automatically (without the patch I > mentioned above) when I use Sup with GMail... GMail's SMTP server does this. Andrew From wmorgan-sup@masanjin.net Tue Apr 21 10:00:30 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 21 Apr 2009 07:00:30 -0700 Subject: [sup-talk] Possible problem with maildir ID generation In-Reply-To: References: Message-ID: <1240320547-sup-6957@entry> Reformatted excerpts from Mark Alexander's message of 2009-04-16: > Consider two messages that arrive in the same second, but the second > message is smaller than the first. Because the message size makes up > the low seven (decimal) digits of the ID, the second message, even > though it arrived later, will have an ID that is less than the first > message. I think you could be right. Using the size as part of the ID was supposed to differentiate messages with the same timestamp, but it would result in exactly the behavior you describe when polling. I think there's a much simpler scheme we can use that will also fix this. I'll post a patch soon and we can see if it addresses the problem. -- William From wmorgan-sup@masanjin.net Tue Apr 21 10:13:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 21 Apr 2009 07:13:48 -0700 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com> References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <3f81a4240904201452u78abe68bj2a4b9863b850e8a@mail.gmail.com> <1240267632-sup-2023@r50p> <3f81a4240904201638v94a7dbdpce0d865cd83d8873@mail.gmail.com> <1240318807-sup-3080@entry> <3f81a4240904210642o9c74049o27e164e317d0842e@mail.gmail.com> Message-ID: <1240323082-sup-1515@entry> Reformatted excerpts from Bryan Richardson's message of 2009-04-21: > First off, I want to say 'Thank You' for creating such a great > application here. Text-based is the way to go! :) Glad you like it! > As for saving sent mail in an IMAP folder, I did find a patch that I > was able to use to provide me with this functionality. Interesting. Would you mind reposting it here, if you get a chance? > One question I do have though is why my sent messages get saved to my > 'Sent Mail' folder on my GMail account automatically (without the > patch I mentioned above) when I use Sup with GMail... As someone else pointed out, this is because GMail's MTA is clever. > As a side note, does Sup have any sort of plugin architecture? I'm > thinking of maybe developing a text-based calendar app in Ruby at some > point... :) It doesn't have plugins per se. It has a pretty good hook system, but that's probably not useful to you. What are you interested in using? The ncurses interface? The full-text search index? -- William From wmorgan-sup@masanjin.net Tue Apr 21 10:26:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 21 Apr 2009 07:26:20 -0700 Subject: [sup-talk] Two questions In-Reply-To: <1240319634.11793.11.camel@localhost> References: <1239997272.5948.104.camel@localhost> <1240318974-sup-6743@entry> <1240319634.11793.11.camel@localhost> Message-ID: <1240323252-sup-1276@entry> Reformatted excerpts from Reid Thompson's message of 2009-04-21: > OK -- so to 'manage' an imap store, i'd need to setup a mechanism to > fetch all the email to a local store, deleting from the imap store, > and then do something like schedule an overnight run of sup-sync-back, There are a couple issues at play. First, if you're serious about Sup with IMAP, many people have gone the route of mirroring their IMAP folders locally using something like offlineimap. The Ruby IMAP libraries, and possibly IMAP itself, is otherwise too slow for how Sup likes to treat its mailstores. But that's not strictly necessary. Second, if you're serious about deleting email from your IMAP server (as opposed to just letting it stay there forever, since storage is cheap and the too-fleeting moments of your precious mortality are not), you'll need to periodically run sup-sync-back with the appropriate flags. This all stems from design decisions around Sup's target environment, which is that you have too much email to scan every message except in an offline manner. I have 229k emails in my inbox. Sup's the only client I know of that can scale to that. (Besides GMail of course.) -- William From bdwalton@gmail.com Tue Apr 21 10:37:25 2009 From: bdwalton@gmail.com (Ben Walton) Date: Tue, 21 Apr 2009 10:37:25 -0400 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <3f81a4240904210732k11366cf7naec562af54ecabac@mail.gmail.com> References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <3f81a4240904201452u78abe68bj2a4b9863b850e8a@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> Message-ID: I abandoned that patch for my own use after a while. [I moved my .sup to local storage from nfs and now use the mbox sent folder.] I still like the idea, but that patch would need much work before it became integration worthy. If there is sufficient interest, I'd invest the time. William, what requirements would need to be met from your side to see this added? Thanks -Ben On Tue, Apr 21, 2009 at 10:32 AM, Bryan Richardson wrote: > The patch for what the author (Ben Walton) calls 'Flexible Sent Source' can > be found at the following URL.? It would be nice to have this integrated > into the official Sup source code... :) > > http://www.nabble.com/-PATCH--flexible-sent-source-td16960901.html#a16960901 > > One more question: I noticed when I use Sup with my Exchange account that it > marks all my messages on the Exchange server as read when it syncs.? Is this > normal? > > On Tue, Apr 21, 2009 at 8:29 AM, Bryan Richardson wrote: >> >> Yeah, I'll find the patch and post it here. >> >> As for the calendaring app, I figured having it integrated with Sup might >> be kinda cool.? The search index might help too. :) >> >> On Tue, Apr 21, 2009 at 8:13 AM, William Morgan >> wrote: >>> >>> Reformatted excerpts from Bryan Richardson's message of 2009-04-21: >>> > First off, I want to say 'Thank You' for creating such a great >>> > application here. ?Text-based is the way to go! :) >>> >>> Glad you like it! >>> >>> > As for saving sent mail in an IMAP folder, I did find a patch that I >>> > was able to use to provide me with this functionality. >>> >>> Interesting. Would you mind reposting it here, if you get a chance? >>> >>> > One question I do have though is why my sent messages get saved to my >>> > 'Sent Mail' folder on my GMail account automatically (without the >>> > patch I mentioned above) when I use Sup with GMail... >>> >>> As someone else pointed out, this is because GMail's MTA is clever. >>> >>> > As a side note, does Sup have any sort of plugin architecture? ?I'm >>> > thinking of maybe developing a text-based calendar app in Ruby at some >>> > point... :) >>> >>> It doesn't have plugins per se. It has a pretty good hook system, but >>> that's probably not useful to you. What are you interested in using? The >>> ncurses interface? The full-text search index? >>> -- >>> William >>> _______________________________________________ >>> sup-talk mailing list >>> sup-talk at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/sup-talk >> > > > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > > -- --------------------------------------------------------------------------------------------------------------------------- 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 marka@pobox.com Tue Apr 21 11:33:17 2009 From: marka@pobox.com (Mark Alexander) Date: Tue, 21 Apr 2009 08:33:17 -0700 Subject: [sup-talk] Possible problem with maildir ID generation In-Reply-To: <1240320547-sup-6957@entry> References: <1240320547-sup-6957@entry> Message-ID: On Tue, Apr 21, 2009 at 7:00 AM, William Morgan wrote: > I think you could be right. Using the size as part of the ID was > supposed to differentiate messages with the same timestamp, but it would > result in exactly the behavior you describe when polling. > > I think there's a much simpler scheme we can use that will also fix > this. I'll post a patch soon and we can see if it addresses the > problem. I'd be very interested in this patch. In the meantime, I made some minor changes to maildir.rb, without changing the ID scheme. One problem was every time a maildir was polled, the most recent message (i.e., the one at cur_offset) would be treated as a new message again. I also changed last_offset to return an ID that would be one second later than the last message seen. These changes seem to have mostly fixed the lost message problem I was having, though I'm not exactly sure why. I've only had one lost message over the last couple of days, instead of the expected 10 or 20. I can't explain this one lost message, but I think it must be due to a different problem, unrelated to maildir handling. I was able to get sup to see this message again by doing a 'touch' on both the message itself and the containing maildir. I doubt that my changes would fix the race condition I described earlier, but I've avoided this problem by not running fetchmail in the background while sup is running. I'll send out my patch in a separate email. From marka@pobox.com Tue Apr 21 11:43:44 2009 From: marka@pobox.com (Mark Alexander) Date: Tue, 21 Apr 2009 08:43:44 -0700 Subject: [sup-talk] [PATCH] Bug fixes and speed improvements for maildir handling. Message-ID: --- lib/sup/maildir.rb | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/lib/sup/maildir.rb b/lib/sup/maildir.rb index 3d584f7..d74279a 100644 --- a/lib/sup/maildir.rb +++ b/lib/sup/maildir.rb @@ -10,6 +10,7 @@ module Redwood class Maildir < Source SCAN_INTERVAL = 30 # seconds + TIME_SCALE = 10000000 ## remind me never to use inheritance again. yaml_properties :uri, :cur_offset, :usual, :archived, :id, :labels, :mtimes @@ -123,8 +124,11 @@ class Maildir < Source return unless start_offset start = @ids.index(cur_offset || start_offset) or raise OutOfSyncSourceError, "Unknown message id #{cur_offset || start_offset}." # couldn't find the most recent email + if cur_offset + start += 1 + end - start.upto(@ids.length - 1) do |i| + (start... at ids.length).each do |i| id = @ids[i] self.cur_offset = id yield id, @labels + (seen?(id) ? [] : [:unread]) + (trashed?(id) ? [:deleted] : []) + (flagged?(id) ? [:starred] : []) @@ -138,7 +142,7 @@ class Maildir < Source def end_offset scan_mailbox :rescan => true - @ids.last + 1 + ((@ids.last / TIME_SCALE) + 1) * TIME_SCALE end def pct_done; 100.0 * (@ids.index(cur_offset) || 0).to_f / (@ids.length - 1).to_f; end @@ -164,7 +168,7 @@ private #makes a noticeable difference on nfs. stat = File.stat(fn) # use 7 digits for the size. why 7? seems nice. - sprintf("%d%07d", stat.mtime, stat.size % 10000000).to_i + (stat.mtime.to_i * TIME_SCALE) + (stat.size % TIME_SCALE) end def with_file_for id -- 1.6.1.28.gc32f76 From reid.thompson@ateb.com Tue Apr 21 12:15:59 2009 From: reid.thompson@ateb.com (Reid Thompson) Date: Tue, 21 Apr 2009 12:15:59 -0400 Subject: [sup-talk] Two questions In-Reply-To: <1240323252-sup-1276@entry> References: <1239997272.5948.104.camel@localhost> <1240318974-sup-6743@entry> <1240319634.11793.11.camel@localhost> <1240323252-sup-1276@entry> Message-ID: <1240330559.11793.52.camel@localhost> On Tue, 2009-04-21 at 07:26 -0700, William Morgan wrote: > Reformatted excerpts from Reid Thompson's message of 2009-04-21: > > OK -- so to 'manage' an imap store, i'd need to setup a mechanism to > > fetch all the email to a local store, deleting from the imap store, > > and then do something like schedule an overnight run of sup-sync-back, > > There are a couple issues at play. First, if you're serious about Sup > with IMAP, many people have gone the route of mirroring their IMAP > folders locally using something like offlineimap. The Ruby IMAP > libraries, and possibly IMAP itself, is otherwise too slow for how Sup > likes to treat its mailstores. > > But that's not strictly necessary. > > Second, if you're serious about deleting email from your IMAP server (as > opposed to just letting it stay there forever, since storage is cheap > and the too-fleeting moments of your precious mortality are not), you'll > need to periodically run sup-sync-back with the appropriate flags. > > This all stems from design decisions around Sup's target environment, > which is that you have too much email to scan every message except in an > offline manner. I have 229k emails in my inbox. Sup's the only client > I know of that can scale to that. (Besides GMail of course.) for 'fun', i setup a fastmail.fm account, to which i'm using rss2email to push a number of feeds to. I setup offlineimap to pull these feeds down for sup, so that I could 'manage' the imap store via sup. Why is it expecting mbox format? rthompso at raker ~/.sup $ sup-sync-back -d maildir:~/.fastmaildotfm/INBOX [Tue Apr 21 12:10:07 -0400 2009] using character set encoding "UTF-8" [Tue Apr 21 12:10:08 -0400 2009] crypto: detected gpg binary in /usr/bin/gpg [Tue Apr 21 12:10:08 -0400 2009] locking /home/rthompso/.sup/lock... [Tue Apr 21 12:10:08 -0400 2009] loading index... [Tue Apr 21 12:10:08 -0400 2009] loaded index of 920 messages Error: maildir:~/.fastmaildotfm/INBOX is not an mbox source. [Tue Apr 21 12:10:08 -0400 2009] unlocking /home/rthompso/.sup/lock... offlineimap is populating ~/.fastmaildotfm/INBOX rthompso at raker ~/.sup $ cat sources.yaml --- .... - !masanjin.net,2006-10-01/Redwood/Maildir uri: maildir:~/.fastmaildotfm/INBOX cur_offset: 12403255620003971 usual: true archived: false id: 4 labels: - rssmail mtimes: cur: 2009-04-21 11:47:05 -04:00 new: 2009-04-21 11:47:08 -04:00 - !masanjin.net,2006-10-01/Redwood/SentLoader cur_offset: 19809 - !masanjin.net,2006-10-01/Redwood/DraftLoader cur_offset: 0 rthompso at raker ~ $ find .fastmaildotfm/ .fastmaildotfm/ .fastmaildotfm/INBOX.Trash .fastmaildotfm/INBOX.Trash/cur .fastmaildotfm/INBOX.Trash/new .fastmaildotfm/INBOX.Trash/tmp .fastmaildotfm/INBOX.Sent Items .fastmaildotfm/INBOX.Sent Items/cur .fastmaildotfm/INBOX.Sent Items/new .fastmaildotfm/INBOX.Sent Items/tmp .fastmaildotfm/INBOX .fastmaildotfm/INBOX/cur .fastmaildotfm/INBOX/cur/1240328825_0.15391.raker,U=1,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,S .fastmaildotfm/INBOX/new .fastmaildotfm/INBOX/new/1240328827_7.15391.raker,U=29,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328825_5.15391.raker,U=6,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_6.15391.raker,U=28,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_0.15391.raker,U=8,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_5.15391.raker,U=27,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_9.15391.raker,U=17,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_4.15391.raker,U=26,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_8.15391.raker,U=16,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328825_6.15391.raker,U=7,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_3.15391.raker,U=25,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_7.15391.raker,U=15,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_2.15391.raker,U=24,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_1.15391.raker,U=9,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_6.15391.raker,U=14,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_1.15391.raker,U=23,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_13.15391.raker,U=21,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_5.15391.raker,U=13,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328825_1.15391.raker,U=2,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_0.15391.raker,U=22,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_12.15391.raker,U=20,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_4.15391.raker,U=12,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_3.15391.raker,U=11,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_2.15391.raker,U=10,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328825_2.15391.raker,U=3,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_11.15391.raker,U=19,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328828_0.15391.raker,U=32,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328826_10.15391.raker,U=18,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328825_3.15391.raker,U=4,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_9.15391.raker,U=31,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328825_4.15391.raker,U=5,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/new/1240328827_8.15391.raker,U=30,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2, .fastmaildotfm/INBOX/tmp .fastmaildotfm/INBOX.Drafts .fastmaildotfm/INBOX.Drafts/cur .fastmaildotfm/INBOX.Drafts/new .fastmaildotfm/INBOX.Drafts/tmp From saku@ytti.fi Wed Apr 22 03:29:56 2009 From: saku@ytti.fi (Saku Ytti) Date: Wed, 22 Apr 2009 00:29:56 -0700 (PDT) Subject: [sup-talk] IMAP folder/label integration and playing better with changed sources? Message-ID: <0c334e4c-0480-4def-b64a-b4996431f5c9@x3g2000yqa.googlegroups.com> First, thank you for sup-mail. I thought I just wanted mutt with indexed searches, but turns out the stuff copied from gmail are brilliant and the novel(?) idea of buffers really makes things simpler. Problem for me is, I want to use also mobile phone email client and webmail, so I'm kinda stuck with mutt. Is it likely that this could be addressed in future? And for the actual subject related matter, could it be possible to store labels as folders optionally? This would play along really well for those who use gmail, as you would essentially get synchronised labeling between sup and webclient. Thanks again. From wmorgan-sup@masanjin.net Wed Apr 22 11:02:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 22 Apr 2009 08:02:15 -0700 Subject: [sup-talk] sup crashes when starting, here is the exception-log In-Reply-To: <20090414165314.GA19668@gmail.com> References: <20090414165314.GA19668@gmail.com> Message-ID: <1240412232-sup-8540@entry> Hi Sean, Reformatted excerpts from Sean Escriva's message of 2009-04-14: > --- NoMethodError from thread: call #connect on > mbox+ssh://optimus//var/mail/seane > undefined method `synchronize' for nil:NilClass > /home/webframp/.gem/ruby/1.8/gems/sup-0.7/lib/sup/mbox/ssh-file.rb:181:in Sorry to report this, but the mbox-ssh stuff hasn't been working for a while and fixing it is pretty low priority at the moment. You're welcome to investigate, of course, or you might consider another source type. (mbox+ssh was never was quite fast enough IMO anyways.) -- William From wmorgan-sup@masanjin.net Wed Apr 22 11:07:22 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 22 Apr 2009 08:07:22 -0700 Subject: [sup-talk] Suggestion for '.' keybinding In-Reply-To: <1239638279-sup-6990@black> References: <1239638279-sup-6990@black> Message-ID: <1240412747-sup-2285@entry> Reformatted excerpts from Lee Hinman's message of 2009-04-13: > Is this possible with Sup right now? Does it store what the last > action was? (it might for the undo patch, I haven't looked at it) It's not possible right now, but the undo patch does something similar to this. The best approach might be to extend UndoManager to be able to redo as well as undo. -- William From wmorgan-sup@masanjin.net Wed Apr 22 11:12:40 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 22 Apr 2009 08:12:40 -0700 Subject: [sup-talk] Two questions In-Reply-To: <1240330559.11793.52.camel@localhost> References: <1239997272.5948.104.camel@localhost> <1240318974-sup-6743@entry> <1240319634.11793.11.camel@localhost> <1240323252-sup-1276@entry> <1240330559.11793.52.camel@localhost> Message-ID: <1240412894-sup-3091@entry> Reformatted excerpts from Reid Thompson's message of 2009-04-21: > Why is it expecting mbox format? Sorry, I gave you kind of a crappy answer above. sup-sync-back currently only works on mbox files, though not for any reason other than no one's gotten around to extending it yet. Deleting files from a Maildir is significantly easier than removing them from an mbox, so the bar's not very high on this one. -- William From ezyang@MIT.EDU Wed Apr 22 11:56:30 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 22 Apr 2009 11:56:30 -0400 Subject: [sup-talk] First time user of sup; some questions Message-ID: <1240415555-sup-5859@javelin> Hello all, I recently switched over to Sup, and I have a favorable first impression. However, I have a few questions: 1. How do I get date searches to work? I've tried the strings on the wiki, namely before:, on:, after: and during:, and they consistently return no results. I'm using sup v0.7. 2. I'd like to archive all of my email older than two weeks (in an attempt to keep my inbox "as clean as possible"). How might I go about doing this? 3. I am currently running sup client-side, but it seems to me that, given its index-centric operation nature, and the fact that this index does not get propagated back to the mailserver, it would be more appropriate to run this on a server (this also seems to jive with the recent "Sup as a Service" postings). Should I toss sup on a remote machine I have SSH access to, and if I do, how might I migrate the index I already have? Cheers, Edward -- From ezyang@MIT.EDU Wed Apr 22 16:40:06 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 22 Apr 2009 16:40:06 -0400 Subject: [sup-talk] First time user of sup; some questions In-Reply-To: <1240415555-sup-5859@javelin> References: <1240415555-sup-5859@javelin> Message-ID: <1240432739-sup-2328@javelin> Excerpts from Edward Z. Yang's message of Wed Apr 22 11:56:30 -0400 2009: > 2. I'd like to archive all of my email older than two weeks (in an > attempt to keep my inbox "as clean as possible"). How might I > go about doing this? Ended up fixing this by !!, T, t (for messages I didn't want to remove), and then ;a Kind of took a while, since I had 5000+ conversations in my inbox. Cheers, Edward -- From wmorgan-sup@masanjin.net Wed Apr 22 18:26:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 22 Apr 2009 15:26:43 -0700 Subject: [sup-talk] First time user of sup; some questions In-Reply-To: <1240415555-sup-5859@javelin> References: <1240415555-sup-5859@javelin> Message-ID: <1240439191-sup-6622@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-04-22: > 1. How do I get date searches to work? I've tried the strings on the > wiki, namely before:, on:, after: and during:, and they consistently > return no results. I'm using sup v0.7. Do you have the chronic gem installed? It's an optional gem but the date search stuff requires it. > 2. I'd like to archive all of my email older than two weeks (in an > attempt to keep my inbox "as clean as possible"). How might I go about > doing this? Check out sup-tweak-labels for a way to do this offline (which is really what you want). With chronic installed, you should be able to pass the date range query and have it remove the inbox label from all matching messages. You might want to limit the query a bit so that you don't do this to every message in your index, over and over. Something like "+before(two weeks ago) +after(15 days ago)" maybe. > 3. I am currently running sup client-side, but it seems to me that, > given its index-centric operation nature, and the fact that this > index does not get propagated back to the mailserver, it would > be more appropriate to run this on a server (this also seems to > jive with the recent "Sup as a Service" postings). Should I toss > sup on a remote machine I have SSH access to, and if I do, how might > I migrate the index I already have? Until Sup the Service is ready (and believe it or not, I have actually been working on it recently), running it on a globally-accessible server is what I do. You should be able to simply copy your .sup directory over. (Although if you're migrating from Windows to a Linux box, I'm not entirely certain that will work... I'd be interested to hear if it does.) -- William From ezyang@MIT.EDU Wed Apr 22 19:21:11 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 22 Apr 2009 19:21:11 -0400 Subject: [sup-talk] First time user of sup; some questions In-Reply-To: <1240439191-sup-6622@entry> References: <1240415555-sup-5859@javelin> <1240439191-sup-6622@entry> Message-ID: <1240442350-sup-9277@javelin> Excerpts from William Morgan's message of Wed Apr 22 18:26:43 -0400 2009: > Do you have the chronic gem installed? It's an optional gem but the date > search stuff requires it. Nope. Installing the chronic gem fixed things. I've updated the wiki article accordingly. > Check out sup-tweak-labels for a way to do this offline (which is really > what you want). With chronic installed, you should be able to pass the > date range query and have it remove the inbox label from all matching > messages. You might want to limit the query a bit so that you don't do > this to every message in your index, over and over. Something like > "+before(two weeks ago) +after(15 days ago)" maybe. Since I'm pretty good about archiving email when it's no longer relevant, this is not strictly necessary, but it's good to know the existence of sup-tweak-labels. > Until Sup the Service is ready (and believe it or not, I have actually > been working on it recently), running it on a globally-accessible server > is what I do. You should be able to simply copy your .sup directory > over. (Although if you're migrating from Windows to a Linux box, I'm > not entirely certain that will work... I'd be interested to hear if it > does.) Excellent. I'm running on Ubuntu Linux and am thinking of setting up a little bit of replication framework to make my index accessible on multiple machines. Cheers, Edward From jdugan@es.net Wed Apr 22 21:35:00 2009 From: jdugan@es.net (Jon Dugan) Date: Wed, 22 Apr 2009 18:35:00 -0700 Subject: [sup-talk] GSoC Project of Interest Message-ID: <1240449619-sup-9301@junction.es.net> There's an GSoC project that may be of interest to folks on this list. It's aim is to add Gmail/sup like features to the Plan 9 mail system called upas. This might end up creating something an awful lot like Sup the Service Not identical for sure, but there is at least some overlap in terms of aims and ideas. Most services on Plan 9 are implemented as synthetic file systems. The synthetic filesystem that represents email on Plan 9 is known as upas. upas provides a filesytem view of mail boxes regardless of their backend storage medium (eg, POP, IMAP, etc) which provides a nice clean separation between the code that you use to do useful things to your mail and the code that deals with the mail store itself. To quote the man page: The mailbox itself becomes a directory under /mail/fs. Each message in the mailbox becomes a numbered directory in the mailbox directory, and each attachment becomes a numbered directory in the message directory. Since an attachment may itself be a mail message, this structure can recurse ad nauseam. Each message and attachment directory contains the files: body the message minus the RFC822 style headers cc the address(es) from the CC: header date the date in the message, or if none, the time of delivery digest an SHA1 digest of the message contents subject the contents of the subject line . . etc . Here's the manpage for upas: http://plan9.bell-labs.com/magic/man2html/4/upasfs The GSoC project: http://socghop.appspot.com/student_project/show/google/gsoc2009/plan9/t124024225207 There's a ton of interesting and powerful stuff in Plan 9. I'm hoping this will provide some useful ideas for Sup the Service. Jon -- Jon M. Dugan | GTalk: jdugan.esnet ESnet Network Engineering Group | http://www.es.net/ Lawrence Berkeley National Laboratory | http://www.lbl.gov/ From jdugan@es.net Wed Apr 22 21:11:40 2009 From: jdugan@es.net (Jon Dugan) Date: Wed, 22 Apr 2009 18:11:40 -0700 Subject: [sup-talk] mime-view hook Message-ID: <1240448213-sup-1757@junction.es.net> I'm running the mainline sup from git. I have a mime-view.rb hook like this: case content_type when "text/html" Redwood::log("w3m: " + '/opt/local/bin/w3m -dump -T ' + content_type + ' ' + filename) IO.popen('-') {|f| f ? f.read : exec('/opt/local/bin/w3m', '-dump', '-T', content_type, filename)} else Redwood::log("dumbplumb: " + filename) system '/Users/jdugan/projects/dumbplumb/dumbplumb', filename end It's supposed to render HTML in the SUP window and hand everything else off to dumbplumb. It does hand everything else off to dumbplub, however it doesn't do what I expect for the HTML attachments. Whatever gets returned from the hook should be displayed, right? I am a Ruby noob so maybe it's my Ruby that's bad. (Although I've got a lot of experience with Python, Perl, etc...) If I send the output of the IO.popen to Redwood::log I see what I'd expect in the log buffer, so I have confidence in the part that is using w3m to render the HTML. Why didn't I use backticks (`) instead of the calls to system and exec? To sidestep shell quoting issues. I started with backticks but attachments with spaces and other shell meta characters were problematic. Thanks for any suggestions, Jon PS: dumbplumb may be of interest. Here's the README: dumbplumb is a simple mechanism for displaying files from remote systems locally. it is a brain dead hack that implements something which is something like the Plan 9 plumber but not really. Eventually it may be reworked to actually use the plan9 port plumber, but for now it's just dumb. dumbplumbd listens on port 9937 on your local system for requests. dumbplumb sends requests to dumbplumbd. ssh port forwarding is used to proxy the two together, eg: ssh -R 9937:localhost:9937 remotehost You can find dumbplumb at http://bitbucket.org/jdugan/dumbplumb/ -- Jon M. Dugan | GTalk: jdugan.esnet ESnet Network Engineering Group | http://www.es.net/ Lawrence Berkeley National Laboratory | http://www.lbl.gov/ From wmorgan-sup@masanjin.net Thu Apr 23 08:47:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 23 Apr 2009 05:47:59 -0700 Subject: [sup-talk] mime-view hook In-Reply-To: <1240448213-sup-1757@junction.es.net> References: <1240448213-sup-1757@junction.es.net> Message-ID: <1240489722-sup-3696@entry> Reformatted excerpts from Jon Dugan's message of 2009-04-22: > It's supposed to render HTML in the SUP window and hand everything > else off to dumbplumb. It does hand everything else off to dumbplub, > however it doesn't do what I expect for the HTML attachments. > > Whatever gets returned from the hook should be displayed, right? Not exactly. There are two MIME hooks, and you'll need them both for what you're trying to do: mime-decode, for turning an attachment into text (displayed directly in Sup), and mime-view, for launching third-party applications to view an attachment. I've updated the docs on these two in git to make their relationship a little more clear, but in summary: mime-decode should return a string, or nil if uncovertable, and mime-view should return true if the application was successful, and false otherwise. Note that by default Sup calls run-mailcap to view attachments it can't convert to text, so you can make the dumbplumb behavior global by changing your mailcap instead. (If you desire that.) > dumbplumb is a simple mechanism for displaying files from remote > systems locally. it is a brain dead hack that implements something > which is something like the Plan 9 plumber but not really. That's awesome. Very useful for Sup. -- William From wmorgan-sup@masanjin.net Thu Apr 23 08:52:56 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 23 Apr 2009 05:52:56 -0700 Subject: [sup-talk] GSoC Project of Interest In-Reply-To: <1240449619-sup-9301@junction.es.net> References: <1240449619-sup-9301@junction.es.net> Message-ID: <1240490917-sup-3402@entry> Reformatted excerpts from Jon Dugan's message of 2009-04-22: > Most services on Plan 9 are implemented as synthetic file systems. > The synthetic filesystem that represents email on Plan 9 is known as > upas. upas provides a filesytem view of mail boxes regardless of > their backend storage medium (eg, POP, IMAP, etc) which provides a > nice clean separation between the code that you use to do useful > things to your mail and the code that deals with the mail store > itself. Very interesting and that's a great abstraction. Definitely lots of overlap with STS. I suspect the primary differences will be that STS uses fielded, full-text search as its primary access mechanism, and there's no notion of any kind of filesystem-like mailbox or directory hierarchy. -- William From andrew@pimlott.net Thu Apr 23 13:53:36 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Thu, 23 Apr 2009 10:53:36 -0700 Subject: [sup-talk] mime-view hook In-Reply-To: <1240448213-sup-1757@junction.es.net> References: <1240448213-sup-1757@junction.es.net> Message-ID: <20090423175336.GX11701@pimlott.net> On Wed, Apr 22, 2009 at 06:11:40PM -0700, Jon Dugan wrote: > dumbplumbd listens on port 9937 on your local system for requests. dumbplumb > sends requests to dumbplumbd. ssh port forwarding is used to proxy the two > together, eg: > > ssh -R 9937:localhost:9937 remotehost You probably realize this, but... A well-known port doesn't work for this, because you need one plumber per display session. So the SSH forwarding needs to use the right plumber on this end and establish a corresponding session on the other end. The obvious model for this is SSH agent forwarding. You'd have a PLUMBER_SOCK variable containing the path to a unix socket, and ssh would create a unix socket on the other end, forward it there, and set a new PLUMBER_SOCK variable. The obstacle is, the SSH developers haven't shown any interest in making the SSH agent forward mechanism availble to others. See for example http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148 If you don't do this, you'll have plumbers stepping on each other, or you'll have to manage ports manually. Andrew From jdugan@es.net Thu Apr 23 14:14:48 2009 From: jdugan@es.net (Jon Dugan) Date: Thu, 23 Apr 2009 11:14:48 -0700 Subject: [sup-talk] mime-view hook In-Reply-To: <20090423175336.GX11701@pimlott.net> References: <1240448213-sup-1757@junction.es.net> <20090423175336.GX11701@pimlott.net> Message-ID: <1240509574-sup-3576@junction.es.net> Excerpts from Andrew Pimlott's message of Thu Apr 23 10:53:36 -0700 2009: > On Wed, Apr 22, 2009 at 06:11:40PM -0700, Jon Dugan wrote: > > dumbplumbd listens on port 9937 on your local system for requests. dumbplumb > > sends requests to dumbplumbd. ssh port forwarding is used to proxy the two > > together, eg: > > > > ssh -R 9937:localhost:9937 remotehost > > You probably realize this, but... A well-known port doesn't work for > this, because you need one plumber per display session. So the SSH > forwarding needs to use the right plumber on this end and establish a > corresponding session on the other end. That is definitely and issue and I should probably add that to the README. However in practice it doesn't seem to be a problem for me, I only forward the port for the first connection to my sup box. When I leave a display I log out of the sup box thus freeing the well known port for the next display I sit at. (Or if I forget I can log in and kill that ssh process by hand.) However, this whole fiasco is part of the reason I call it dumb. There is also a significant security issue which is anyone on the sup box can send a dumbplumb request if they know what port to talk to. In my case this is a fairly minor risk as I am the only person who uses my sup box. This too is part of the reason I call it dumb. > The obvious model for this is SSH agent forwarding. You'd have a > PLUMBER_SOCK variable containing the path to a unix socket, and ssh > would create a unix socket on the other end, forward it there, and set a > new PLUMBER_SOCK variable. The obstacle is, the SSH developers haven't > shown any interest in making the SSH agent forward mechanism availble to > others. See for example > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=294148 > > If you don't do this, you'll have plumbers stepping on each other, or > you'll have to manage ports manually. I've wanted this kind of forwarding for a long, long time. I was unaware of the patch listed there. I'll have to take a look. This would be especially cool if it was forwardable like the agent socket, since sometimes I have to ssh through intermediate boxes. (But see my ssh-gw script for a cute trick for getting around this: http://bitbucket.org/jdugan/ssh-gw/). The unix socket forwarding would make the whole thing much, much cleaner. One hack to work around the port collision problem is to enable environment variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically choose a port per session. This could be used to forward unix domain sockets by combining this with something like socat. This, however, starts to become a huge tangle of duct tape and bailing wire... Also SendEnv has some security implications. In short I'd love something less dumb, but for now this scratches an itch. Jon -- Jon M. Dugan | GTalk: jdugan.esnet ESnet Network Engineering Group | http://www.es.net/ Lawrence Berkeley National Laboratory | http://www.lbl.gov/ From andrew@pimlott.net Thu Apr 23 18:59:13 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Thu, 23 Apr 2009 15:59:13 -0700 Subject: [sup-talk] mime-view hook In-Reply-To: <1240509574-sup-3576@junction.es.net> References: <1240448213-sup-1757@junction.es.net> <20090423175336.GX11701@pimlott.net> <1240509574-sup-3576@junction.es.net> Message-ID: <20090423225913.GY11701@pimlott.net> On Thu, Apr 23, 2009 at 11:14:48AM -0700, Jon Dugan wrote: > I've wanted this kind of forwarding for a long, long time. I was unaware of > the patch listed there. I'll have to take a look. This would be especially > cool if it was forwardable like the agent socket, since sometimes I have to > ssh through intermediate boxes. (But see my ssh-gw script for a cute trick > for getting around this: http://bitbucket.org/jdugan/ssh-gw/). > > The unix socket forwarding would make the whole thing much, much cleaner. It's sad that this hasn't been picked up. I looked into it a while back, and I can't remember exactly what the impediment is. It would be an extension to the SecSH protocol, and nobody on the ssh side seems to get the need for it (baffling to me, given ssh-agent). Even the code that exists (AFAICT) only connects explicitly-named ports on either end. > One hack to work around the port collision problem is to enable environment > variable forwarding (see SendEnv in ssh_config(5)) and use that to dynamically > choose a port per session. Even then, you're manually managing the ports: You have to assign a port number to every session you use; if others use the same machines (which is unthinkable in the first place for lack of access control), everyone's numbers have to be unique. That's just dumb--but you know that. :-) > In short I'd love something less dumb, but for now this scratches an itch. Credit to you for writing it. As soon as I saw it, I knew the plumber was the right thing, but when I ran into the forwarding problem, I gave up. I'm glad you didn't! Andrew From ezyang@MIT.EDU Sat Apr 25 20:47:23 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 25 Apr 2009 20:47:23 -0400 Subject: [sup-talk] Exception Message-ID: <1240706801-sup-2126@javelin> Hello, sup gets an uncaught exception if you x out a buffer window while it is loading messages: ---------------------------------------------------------------- I'm very sorry. It seems that an error occurred in Sup. Please accept my sincere apologies. If you don't mind, please send the contents of ~/.sup/exception-log.txt and a brief report of the circumstances to sup-talk at rubyforge dot orgs so that I might address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- ArgumentError from thread: load messages for thread-view-mode buffer not on stack: #: "New message in forum" /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/buffer.rb:395:in `kill_buffer' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/buffer.rb:386:in `kill_buffer_safely' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/util.rb:499:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:452:in `dispatch' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:114:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:114:in `select' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:85:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:83:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:83:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup.rb:83:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:94:in `select' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:144:in `launch_another_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-index-mode.rb:126:in `launch_next_thread_after' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:457:in `dispatch' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:429:in `delete_and_then' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/modes/thread-view-mode.rb:404:in `delete_and_next' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/mode.rb:49:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/mode.rb:49:in `handle_input' /usr/lib/ruby/gems/1.8/gems/sup-0.7/lib/sup/buffer.rb:240:in `handle_input' /usr/lib/ruby/gems/1.8/gems/sup-0.7/bin/sup:207 /var/lib/gems/1.8/bin/sup:19:in `load' /var/lib/gems/1.8/bin/sup:19 Cheers, Edward From wmorgan-sup@masanjin.net Sun Apr 26 20:07:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 26 Apr 2009 17:07:36 -0700 Subject: [sup-talk] message add speedup Message-ID: <1240790767-sup-9896@entry> I've merged a branch 'scanning-speedup' into next that doubles the speed of adding messages to the index. There was a lot of time wasted in parsing the email headers, which I fixed, and I tweaked a couple other things. Various other operations that load data from the message source, like viewing a message thread, should now be slightly faster. I'm able to index around 70 messages/s on my home computer, which is still slow, but hey, twice as fast as 35. Time is split about 50/50 between scanning/parsing and Ferret index writing. Sadly, Ruby has a GIL, so I don't think threading these two operations will buy very much. (Though there might be complicated ways of getting around that.) -- William From johnbent@lanl.gov Sun Apr 26 23:28:27 2009 From: johnbent@lanl.gov (John Bent) Date: Sun, 26 Apr 2009 21:28:27 -0600 Subject: [sup-talk] scary exception Message-ID: <1240802707-sup-2069@tangerine.lanl.gov> On Friday, sup stopped loading and crashed with an exception, I also couldn't run sup-sync. At first I was a little scared, but then I remembered that sup doesn't actually modify mail data so that I could revert to pine, and then I got very, very scared. I though I would have to do weird things at a ruby prompt but I just waited two days and now it works again. Somewhat strange since I tried about five times on Friday. Oh well, I'm running sup in screen so I'll just never quit again. :) Here's the error message in case there's something obvious to someone else: tangerine:~/mail>sup-sync [Fri Apr 24 16:43:10 -0600 2009] using character set encoding "US-ASCII" [Fri Apr 24 16:43:11 -0600 2009] crypto: no gpg binary detected [Fri Apr 24 16:43:11 -0600 2009] locking /Users/johnbent/.sup/lock... [Fri Apr 24 16:43:11 -0600 2009] loading index... [Fri Apr 24 16:43:11 -0600 2009] loaded index of 79908 messages Scanning mbox:/Users/johnbent/mail/mbox... [Fri Apr 24 16:43:11 -0600 2009] unlocking /Users/johnbent/.sup/lock... /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in `search': IO Error occured at :93 in xraise (IOError) Error occured in fs_store.c:284 - fsi_read_i couldn't read 1024 chars from : from /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in `do_search' from /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:339:in `search' from /opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:338:in `search' from /opt/local/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:422:in `load_entry_for_id' from /opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /opt/local/lib/ruby/gems/1.8/gems/sup-999/lib/sup/index.rb:421:in `load_entry_for_id' from /opt/local/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:499:in `send' ... 10 levels... from /opt/local/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:131:in `each' from /opt/local/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:131 from /opt/local/bin/sup-sync:16:in `load' from /opt/local/bin/sup-sync:16 Thanks, JOHn From wmorgan-sup@masanjin.net Mon Apr 27 13:25:19 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Apr 2009 10:25:19 -0700 Subject: [sup-talk] scary exception In-Reply-To: <1240802707-sup-2069@tangerine.lanl.gov> References: <1240802707-sup-2069@tangerine.lanl.gov> Message-ID: <1240852818-sup-1006@entry> Hi John, Reformatted excerpts from John Bent's message of 2009-04-26: > /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in > `search': IO Error occured at :93 in xraise (IOError) > Error occured in fs_store.c:284 - fsi_read_i > couldn't read 1024 chars from : It appears that you're running off a gem generated directly from the git repo. How recently did you do that? This Ferret error is something I though we had kicked quite a while ago, so if you are running from a recent git, I'll be worried. -- William From johnbent@lanl.gov Mon Apr 27 13:34:54 2009 From: johnbent@lanl.gov (John Bent) Date: Mon, 27 Apr 2009 11:34:54 -0600 Subject: [sup-talk] scary exception In-Reply-To: <1240852818-sup-1006@entry> References: <1240802707-sup-2069@tangerine.lanl.gov> <1240852818-sup-1006@entry> Message-ID: <1240853542-sup-4778@tangerine.lanl.gov> Excerpts from William Morgan's message of Mon Apr 27 11:25:19 -0600 2009: > Hi John, > > Reformatted excerpts from John Bent's message of 2009-04-26: > > /opt/local/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:768:in > > `search': IO Error occured at :93 in xraise (IOError) > > Error occured in fs_store.c:284 - fsi_read_i > > couldn't read 1024 chars from : > > It appears that you're running off a gem generated directly from the git > repo. How recently did you do that? This Ferret error is something I > though we had kicked quite a while ago, so if you are running from a > recent git, I'll be worried. > I'm sorry. I don't remember. The timestamp on my sup executable says Jan 13 2009. I'll try to upgrade and see if I ever see this again. John From wmorgan-sup@masanjin.net Mon Apr 27 13:46:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Apr 2009 10:46:43 -0700 Subject: [sup-talk] scary exception In-Reply-To: <1240853542-sup-4778@tangerine.lanl.gov> References: <1240802707-sup-2069@tangerine.lanl.gov> <1240852818-sup-1006@entry> <1240853542-sup-4778@tangerine.lanl.gov> Message-ID: <1240854270-sup-8870@entry> Reformatted excerpts from John Bent's message of 2009-04-27: > I'm sorry. I don't remember. The timestamp on my sup executable says > Jan 13 2009. I'll try to upgrade and see if I ever see this again. Yeah, I think it was around March that things got merged in. Try it with the latest & greatest and see if it happens again. -- William From wmorgan-sup@masanjin.net Mon Apr 27 14:18:27 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Apr 2009 11:18:27 -0700 Subject: [sup-talk] IMAP folder/label integration and playing better with changed sources? In-Reply-To: <0c334e4c-0480-4def-b64a-b4996431f5c9@x3g2000yqa.googlegroups.com> References: <0c334e4c-0480-4def-b64a-b4996431f5c9@x3g2000yqa.googlegroups.com> Message-ID: <1240856180-sup-6270@entry> Reformatted excerpts from Saku Ytti's message of 2009-04-22: > Problem for me is, I want to use also mobile phone email client and > webmail, so I'm kinda stuck with mutt. Is it likely that this could be > addressed in future? One thing I'd like to do with Sup the Service would be to provide an IMAP server interface to it. Then you could use with standard IMAP clients. But that's probably a ways off. > And for the actual subject related matter, could it be possible to > store labels as folders optionally? This would play along really well > for those who use gmail, as you would essentially get synchronised > labeling between sup and webclient. Sounds like a good idea but a lot of work... -- William From nicolas.pouillard@gmail.com Mon Apr 27 15:47:00 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 27 Apr 2009 21:47:00 +0200 Subject: [sup-talk] redo ideas In-Reply-To: <200904271244.n3RCi1VO027803@smtp6.server.rpi.edu> References: <200904271244.n3RCi1VO027803@smtp6.server.rpi.edu> Message-ID: <1240861270-sup-8603@ausone.local> Excerpts from Mike S's message of Mon Apr 27 14:43:46 +0200 2009: > I'm graduating in a few weeks, so I'll have some free time I can dedicate > to sup again. > > Recently redo functionality was suggested, I believe this was meant to be > a solution for something, but I have been thinking about it for a while. > I'd like to register Ctrl-R to keep with the vim bindings. Just some thoughts about this... I was more thinking about the repeat feature of Vi/Vim (the '.' command) than the redo one. Two other ways of doing the undo/redo: 1/ Save the actions using a data type that we can inverse. Example in Ruby syntax a = Action.add_labels(:foo, :bar) a.apply # actually do the job a.invert # equals to Action.remove_labels(:foo, :bar) 2/ Save the state (has to be defined) at each action. This solution would be limited to actions where the state is manageable. Best regards, -- Nicolas Pouillard From helgedt@tihlde.org Mon Apr 27 16:00:44 2009 From: helgedt@tihlde.org (Helge Titlestad) Date: Mon, 27 Apr 2009 22:00:44 +0200 Subject: [sup-talk] UTF-8 message sending patch Message-ID: <1240861799-sup-787@colargol.tihlde.org> Hi, I just installed sup and noticed that it didn't play extremely well with utf-8 out of the box. http://sup.rubyforge.org/wiki/wiki.pl?UTF8 together with the String hack from http://www.nabble.com/UTF-8-woes-td21598658.html#a21598658 fixed the viewing parts (I think), but it's still unacceptable to send raw utf-8 in email headers. So I fixed it with another little hack (to edit-message-mode.rb), which sets Content-Transfer-Encoding to 8-bit and more importantly tries to convert any utf-8 headers to quoted printable. I think the patch (attached) fixes my problems, but it's probably far from complete. It doesn't detect non-utf8-but-still-illegal-strings, it assumes every header except Subject is an address, and so on. Any feedback is welcome. (: -- alge -------------- next part -------------- A non-text attachment was scrubbed... Name: sup-utf8-message-sending.patch Type: application/octet-stream Size: 1904 bytes Desc: not available URL: From mailinglist@flasht.de Tue Apr 28 13:49:04 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 28 Apr 2009 19:49:04 +0200 Subject: [sup-talk] New to Sup and some imap sync questions Message-ID: <1240940037-sup-2915@bakkdoor-ubuntu> Hi! I'm new to using Sup and I really like it. I know that it works a little different than most mail clients I've used before. I'be been using Thunderbird but I#ve always missed a way to view my mails in one big inbox with multiple accounts. Fortunately, Sup does this just the way I want it to. And since I like Ruby as well, it's definately another plus to be able to customize it with Ruby. I do have one question though: Are there any plans on making it sync changes back to the imap server somehow? I'm used to having different mail clients on different machines dealing with the same accounts on several imap servers. I'm so used to having all the changes happening on the server itself, that it's something I'm really missing with Sup. Just wondering if this is ever planned? Since now, even if I have Sup installed on my different machines, I still need to sync all the settings when I change something (e.g. adding a hook-script or something else). Or is there an easy way to sync my Sup settings etc? I'm new to it, but it seems very promising... Thanks for any help and keep up the good work! Christopher. From sgoldman@tower-research.com Tue Apr 28 15:19:26 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Tue, 28 Apr 2009 15:19:26 -0400 Subject: [sup-talk] Inconsistent inbox after restart Message-ID: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> This only started happening after I upgraded to the latest version... Oftentimes when I quit sup and then restart, my inbox looks different. Messages that I had previously archived are back in the inbox. Has anyone else seen this? I'm losing sleep over it. Thanks. -- Steve Goldman sgoldman at tower-research.com T: 212.219.6014 F: 212.219.6007 Tower Research Capital, LLC 377 Broadway, 11th Fl. New York, NY 10013 From marka@pobox.com Tue Apr 28 19:29:46 2009 From: marka@pobox.com (Mark Alexander) Date: Tue, 28 Apr 2009 19:29:46 -0400 Subject: [sup-talk] Possible problem with maildir ID generation In-Reply-To: <20090428191822.GB10581@cabinet.hsd1.ma.comcast.net> References: <1240320547-sup-6957@entry> <20090428191822.GB10581@cabinet.hsd1.ma.comcast.net> Message-ID: On Tue, Apr 28, 2009 at 3:18 PM, Marc Hartstein wrote: > Isn't part of the maildir scheme that the filenames are guaranteed to be > unique? ?It's been a while since I looked at this part of the sup > source, but would it be possible to simply use the filename as the ID > when working with maildir, rather than generating a new ID? ?Or is there > an additional constraint (like ordering?) that needs to be satisfied and > isn't by maildir? Maildir filenames are unique, but they would need to be ordered by time, since sup depends on that ordering (look in maildir.rb for where it uses sort). I'm not sure if mail delivery programs (I use procmail) guarantee that the filenames are ordered that way. I will say that the patch I sent out for maildir.rb has made my life a lot happier, but it's still not ideal because of the race condition I mentioned. William was talking about using some other scheme to generate IDs. We should see what he has to say about this. From nicolas.pouillard@gmail.com Wed Apr 29 04:40:13 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 29 Apr 2009 10:40:13 +0200 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> Message-ID: <1240994294-sup-8386@ausone.inria.fr> Excerpts from Steve Goldman's message of Tue Apr 28 21:19:26 +0200 2009: > This only started happening after I upgraded to the latest version... > > Oftentimes when I quit sup and then restart, my inbox looks different. > Messages that I had previously archived are back in the inbox. Has > anyone else seen this? I'm losing sleep over it. From time to time I also encounter this issue: previously archived emails come back to the inbox. -- Nicolas Pouillard From tyberius_prime@coonabibba.de Wed Apr 29 04:37:08 2009 From: tyberius_prime@coonabibba.de (Tyberius Prime) Date: Wed, 29 Apr 2009 10:37:08 +0200 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1240994294-sup-8386@ausone.inria.fr> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> <1240994294-sup-8386@ausone.inria.fr> Message-ID: <1240994200-sup-9656@h984274.serverkompetenz.net> I should add, the read status is being kept for me. Excerpts from Nicolas Pouillard's message of Wed Apr 29 10:40:13 +0200 2009: > Excerpts from Steve Goldman's message of Tue Apr 28 21:19:26 +0200 2009: > > This only started happening after I upgraded to the latest version... > > > > Oftentimes when I quit sup and then restart, my inbox looks different. > > Messages that I had previously archived are back in the inbox. Has > > anyone else seen this? I'm losing sleep over it. > > From time to time I also encounter this issue: previously archived emails > come back to the inbox. > From tyberius_prime@coonabibba.de Wed Apr 29 04:17:23 2009 From: tyberius_prime@coonabibba.de (Tyberius Prime) Date: Wed, 29 Apr 2009 10:17:23 +0200 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> Message-ID: <1240992967-sup-2852@h984274.serverkompetenz.net> Hi, yes, I see the same, haven't dug into it so far either, simply never restart sup if I can avoid it... (yeah, great conflict strategy, but life's short). So long, Tyberius Prime Excerpts from Steve Goldman's message of Tue Apr 28 21:19:26 +0200 2009: > This only started happening after I upgraded to the latest version... > > Oftentimes when I quit sup and then restart, my inbox looks different. > Messages that I had previously archived are back in the inbox. Has > anyone else seen this? I'm losing sleep over it. > > Thanks. > -- > > Steve Goldman > sgoldman at tower-research.com > > T: 212.219.6014 > F: 212.219.6007 > > Tower Research Capital, LLC > 377 Broadway, 11th Fl. > New York, NY 10013 From ezyang@MIT.EDU Wed Apr 29 13:04:40 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 29 Apr 2009 13:04:40 -0400 Subject: [sup-talk] New to Sup and some imap sync questions In-Reply-To: <1240940037-sup-2915@bakkdoor-ubuntu> References: <1240940037-sup-2915@bakkdoor-ubuntu> Message-ID: <1241024581-sup-9014@javelin> Excerpts from Christopher Bertels's message of Tue Apr 28 13:49:04 -0400 2009: > Just wondering if this is ever planned? Since now, even if I have Sup installed > on my different machines, I still need to sync all the settings when I change > something (e.g. adding a hook-script or something else). Or is there an easy > way to sync my Sup settings etc? Hello Christopher, My current understanding is that William is not interested in mucking around with IMAP any more than he has to, so unless someone steps up and submits some patches there will not be syncing back to IMAP. As for handling Sup on multiple machines, I think the current best practice is "don't"; pick one machine, make it ssh'able into, and use that to handle all of your mail. Cheers, Edward From wmorgan-sup@masanjin.net Wed Apr 29 14:02:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 11:02:06 -0700 Subject: [sup-talk] possible mbox "initial From" fix Message-ID: <1241027916-sup-7642@entry> After a lot of toying with RubyMail, hoping I could get it to behave well, I finally gave up and just tweaked the regexp that determines whether a line is an mbox separator or not, and bypassed RubyMail mbox splitting entirely. It might still be too lenient---I have it looking for /^From \S+@\S+ /, so it's not even bothering to parse a date, etc. I'm hoping to strike somewhat of a balance between strict and liberal. So, please try it out and see if it solves your mbox problems. -- William From wmorgan-sup@masanjin.net Wed Apr 29 14:09:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 11:09:16 -0700 Subject: [sup-talk] New to Sup and some imap sync questions In-Reply-To: <1241024581-sup-9014@javelin> References: <1240940037-sup-2915@bakkdoor-ubuntu> <1241024581-sup-9014@javelin> Message-ID: <1241028139-sup-8070@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-04-29: > My current understanding is that William is not interested in mucking > around with IMAP any more than he has to, so unless someone steps up > and submits some patches there will not be syncing back to IMAP. That's pretty much the case, but I hope it's ameliorated by the fact that I do plan to get sup-sync-back working with Maildir ("any day now"), and then you can use offlineimap to really sync between IMAP and Sup. > As for handling Sup on multiple machines, I think the current best > practice is "don't"; pick one machine, make it ssh'able into, and use > that to handle all of your mail. Correct. Recently I've been thinking about the possibility of storing one's mbox/Maildir in git, syncing it between machines (Maildir would probably work best for this, as mbox will generate spurious conflicts when deleting+adding), and maintaining the Ferret index locally on each machine. If we add a notion of an outbound message queue to Sup (i.e. each machine knows whether it has the ability to send mail or not), and also synchronize that and the drafts and sent folders between machines, you could use Sup for completely offline, distributed email. Crazy? -- William From wmorgan-sup@masanjin.net Wed Apr 29 14:10:53 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 11:10:53 -0700 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> Message-ID: <1241028590-sup-8155@entry> Reformatted excerpts from Steve Goldman's message of 2009-04-28: > Oftentimes when I quit sup and then restart, my inbox looks different. > Messages that I had previously archived are back in the inbox. Has > anyone else seen this? I'm losing sleep over it. I see it periodically too (I think I also see read messages turned unread again) and have been trying to find a pattern---is it email that's autosaved when I quit Sup, etc.? -- William From wmorgan-sup@masanjin.net Wed Apr 29 14:22:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 11:22:41 -0700 Subject: [sup-talk] redo ideas In-Reply-To: <200904271244.n3RCi1VO027803@smtp6.server.rpi.edu> References: <200904271244.n3RCi1VO027803@smtp6.server.rpi.edu> Message-ID: <1241028879-sup-6375@entry> Reformatted excerpts from Mike S's message of 2009-04-27: > I'm graduating in a few weeks, so I'll have some free time I can > dedicate to sup again. Congrats! Great! > I'd like to register Ctrl-R to keep with the vim bindings. Sure. > Ugly method 2: write code in duplicate, register a redo and call redo > This saves duplication of code, but it seems unnecessarily complex. > > * create undo lambda > * create redo lambda > * register undo and redo, but 'queue up' redo > * UndoManager.redo Redo is actually a slightly different operation from do. Do has to ask for user input (what label do you want to apply?), redo just reuses it. Maybe that's not such a big deal though; do/redo can just check to see if it already has the value from the user, and ask if not. > Slightly clever method: have primitives return their own undo/redo. > This can be seen in toggle_starred where actually_toggle_starred > returns its inverse. This shifts the complexity down and keeps higher > level code clean. That sounds eminently reasonable to me. -- William From ezyang@MIT.EDU Wed Apr 29 14:38:13 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 29 Apr 2009 14:38:13 -0400 Subject: [sup-talk] New to Sup and some imap sync questions In-Reply-To: <1241028139-sup-8070@entry> References: <1240940037-sup-2915@bakkdoor-ubuntu> <1241024581-sup-9014@javelin> <1241028139-sup-8070@entry> Message-ID: <1241030207-sup-8690@javelin> Excerpts from William Morgan's message of Wed Apr 29 14:09:16 -0400 2009: > Recently I've been thinking about the possibility of storing one's > mbox/Maildir in git, syncing it between machines (Maildir would probably > work best for this, as mbox will generate spurious conflicts when > deleting+adding), and maintaining the Ferret index locally on each > machine. If we add a notion of an outbound message queue to Sup (i.e. > each machine knows whether it has the ability to send mail or not), and > also synchronize that and the drafts and sent folders between machines, > you could use Sup for completely offline, distributed email. Crazy? I was under the impression that the interesting stuff (e.g. tags) was stored in the index, so you would have to sync that too? Cheers, Edward From wmorgan-sup@masanjin.net Wed Apr 29 16:16:30 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 13:16:30 -0700 Subject: [sup-talk] New to Sup and some imap sync questions In-Reply-To: <1241030207-sup-8690@javelin> References: <1240940037-sup-2915@bakkdoor-ubuntu> <1241024581-sup-9014@javelin> <1241028139-sup-8070@entry> <1241030207-sup-8690@javelin> Message-ID: <1241036141-sup-3541@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-04-29: > I was under the impression that the interesting stuff (e.g. tags) was > stored in the index, so you would have to sync that too? That would have to be update to include all new messages every time you synced. And the flags would have to be synced too. Not a trivial undertaking, but within the realm of possibility. -- William From mailinglist@flasht.de Wed Apr 29 16:48:35 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Wed, 29 Apr 2009 22:48:35 +0200 Subject: [sup-talk] New to Sup and some imap sync questions In-Reply-To: <1241028139-sup-8070@entry> References: <1240940037-sup-2915@bakkdoor-ubuntu> <1241024581-sup-9014@javelin> <1241028139-sup-8070@entry> Message-ID: <1241037842-sup-8569@bakkdoor-ubuntu> Excerpts from William Morgan's message of Mi Apr 29 20:09:16 +0200 2009: > Recently I've been thinking about the possibility of storing one's > mbox/Maildir in git, syncing it between machines (Maildir would probably > work best for this, as mbox will generate spurious conflicts when > deleting+adding), and maintaining the Ferret index locally on each > machine. If we add a notion of an outbound message queue to Sup (i.e. > each machine knows whether it has the ability to send mail or not), and > also synchronize that and the drafts and sent folders between machines, > you could use Sup for completely offline, distributed email. Crazy? Actually, that's something I've thought about as well. Seems kinda crazy, but since I don't switch between machines too often (mainly laptop & desktop machine - maybe switching once a day) this could be an optoin. Or I'll use my server and ssh into it to view my mail. Anyhow, I guess I'll stick with Sup - I just like it too much already ;) Christopher. From wmorgan-sup@masanjin.net Wed Apr 29 16:58:01 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 13:58:01 -0700 Subject: [sup-talk] New to Sup and some imap sync questions In-Reply-To: <1241036141-sup-3541@entry> References: <1240940037-sup-2915@bakkdoor-ubuntu> <1241024581-sup-9014@javelin> <1241028139-sup-8070@entry> <1241030207-sup-8690@javelin> <1241036141-sup-3541@entry> Message-ID: <1241038425-sup-3748@entry> Reformatted excerpts from William Morgan's message of 2009-04-29: > That would have to be update to include all new messages every time > you synced. And the flags would have to be synced too. Not a trivial > undertaking, but within the realm of possibility. That wasn't very clear. Let me try again. The Ferret index (a scary binary thing) would not be synced. Individual sources would be synced, along with some version of the message flags (probably as a newline-separated text file, to allow conflict resolution (!)), and then the index would be updated on the local machine to reflect those changes. Kinda tantamount to rsyncing your .sup directory and all your sources across different machines, but a little more refined. -- William From wmorgan-sup@masanjin.net Wed Apr 29 18:31:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 15:31:52 -0700 Subject: [sup-talk] Possible problem with maildir ID generation In-Reply-To: References: <1240320547-sup-6957@entry> <20090428191822.GB10581@cabinet.hsd1.ma.comcast.net> Message-ID: <1241038730-sup-2939@entry> Reformatted excerpts from Mark Alexander's message of 2009-04-28: > Maildir filenames are unique, but they would need to be ordered by > time, since sup depends on that ordering (look in maildir.rb for where > it uses sort). I'm not sure if mail delivery programs (I use > procmail) guarantee that the filenames are ordered that way. That's correct; the name is not sufficient as ids because Sup needs a single pointer into the Maildir as a marker for what it has already processed, so we have to use something ordinal. But it can't just be any old ordinal, it has to be something that corresponds with the way messages are written to the Maildir, in order to be able to divide newer messages from older ones. A timestamp is the obvious choice, but messages can have the same timestamp, so then what do you do? The current approach is to sort by another arbitrary field (in this cae, message size), which gives a unique ordering, but doesn't match up (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.) > I will say that the patch I sent out for maildir.rb has made my life a > lot happier, but it's still not ideal because of the race condition I > mentioned. > > William was talking about using some other scheme to generate IDs. We > should see what he has to say about this. Well I haven't quite started on it yet, but my plan is to: a) Sort files by timestamp, and then by something else (maybe name), and use the position in that array instead of the timestamp. This doesn't solve anything, but it will make the ids prettier, and removes the hideous "%7d" thing. b) When polling, if the current "offset" is N, return all messages that have a timestamp >= the Nth message. So this will mean that we'll rescan messages on occasion, but we shouldn't miss any. Any obvious flaws? -- William From wmorgan-sup@masanjin.net Wed Apr 29 18:38:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 15:38:23 -0700 Subject: [sup-talk] UTF-8 message sending patch In-Reply-To: <1240861799-sup-787@colargol.tihlde.org> References: <1240861799-sup-787@colargol.tihlde.org> Message-ID: <1241044621-sup-9157@entry> Reformatted excerpts from Helge Titlestad's message of 2009-04-27: > I think the patch (attached) fixes my problems, but it's probably far > from complete. It doesn't detect non-utf8-but-still-illegal-strings, > it assumes every header except Subject is an address, and so on. Thanks! Good timing on this; it was near the top of my todo list. I will probably edit this a bit and merge it in as part of a bigger utf-8 fixing branch. -- William From wmorgan-sup@masanjin.net Wed Apr 29 18:39:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 15:39:31 -0700 Subject: [sup-talk] Possible problem with maildir ID generation In-Reply-To: <1241038730-sup-2939@entry> References: <1240320547-sup-6957@entry> <20090428191822.GB10581@cabinet.hsd1.ma.comcast.net> <1241038730-sup-2939@entry> Message-ID: <1241044743-sup-2889@entry> Reformatted excerpts from William Morgan's message of 2009-04-29: > A timestamp is the obvious choice, but messages can have the same > timestamp, so then what do you do? The current approach is to sort by > another arbitrary field (in this cae, message size), which gives a > unique ordering, but doesn't match up Sigh. Doesn't match up with that procmail, or whatever MUA, is giving us. -- William From wmorgan-sup@masanjin.net Wed Apr 29 18:45:29 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Apr 2009 15:45:29 -0700 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: References: <3f81a4240904140559ubd286a5x2f026d6b875dd091@mail.gmail.com> <3f81a4240904201452u78abe68bj2a4b9863b850e8a@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> Message-ID: <1241045035-sup-1534@entry> Reformatted excerpts from Ben Walton's message of 2009-04-21: > William, what requirements would need to be met from your side to see > this added? As far as I'm concerned, if it works, I'll add it. I'd love to have this functionality in Sup, and it is frequently requested. -- William From barton.schaefer@gmail.com Wed Apr 29 20:51:15 2009 From: barton.schaefer@gmail.com (Bart Schaefer) Date: Wed, 29 Apr 2009 17:51:15 -0700 Subject: [sup-talk] possible mbox "initial From" fix In-Reply-To: <1241027916-sup-7642@entry> References: <1241027916-sup-7642@entry> Message-ID: <6bb609560904291751n3cc62f46g6a4edcba1f97d6f7@mail.gmail.com> On Wed, Apr 29, 2009 at 11:02 AM, William Morgan wrote: > After a lot of toying with RubyMail, hoping I could get it to behave > well, I finally gave up and just tweaked the regexp that determines > whether a line is an mbox separator or not, and bypassed RubyMail mbox > splitting entirely. It might still be too lenient---I have it looking > for /^From \S+@\S+ /, so it's not even bothering to parse a date, etc. > I'm hoping to strike somewhat of a balance between strict and liberal. Offering a geezer perspective on this, as one of the primary programmers on an old Unix mail reader that originally didn't understand any kind of folder *except* mbox ... the "match separator" method that worked best for us back in the early '90s went like this: (1) Check for "From " at start of line; if not found, return "not a separator". (2) Skip 5 characters, then skip any whitespace. (3) Remember this location. (4) Skip everything that is NOT whitespace, ignoring syntax for now. (5) Skip any whitespace. (6) Attempt to parse a date string in any of a variety of formats. (6a) If successful, return "is a separator" (6b) If unsuccessful, rewind to the location saved at (3) (7) Attempt to parse an email address in full RFC822 (now 5322) syntax, including comments, phrases, etc; if unsuccessful, return "not a separator" (8) Skip any whitespace following the parsed email address (9) Attempt again to parse a date; if successful, return "is a separator" (10) Return "not a separator" 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. If you want details on the variety of date formats that we recognized, let me know ... From tyberius_prime@coonabibba.de Thu Apr 30 03:11:29 2009 From: tyberius_prime@coonabibba.de (Tyberius Prime) Date: Thu, 30 Apr 2009 09:11:29 +0200 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1241028590-sup-8155@entry> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> <1241028590-sup-8155@entry> Message-ID: <1241075456-sup-909@h984274.serverkompetenz.net> For me it seems to be messages that have been saved 'hours' ago by pressing $. Excerpts from William Morgan's message of Wed Apr 29 20:10:53 +0200 2009: > Reformatted excerpts from Steve Goldman's message of 2009-04-28: > > Oftentimes when I quit sup and then restart, my inbox looks different. > > Messages that I had previously archived are back in the inbox. Has > > anyone else seen this? I'm losing sleep over it. > > I see it periodically too (I think I also see read messages turned > unread again) and have been trying to find a pattern---is it email > that's autosaved when I quit Sup, etc.? From sgoldman@tower-research.com Thu Apr 30 08:51:42 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Thu, 30 Apr 2009 08:51:42 -0400 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1241075456-sup-909@h984274.serverkompetenz.net> References: <1240945125-sup-8484@sgoldmanlinux.tower-research.com> <1241028590-sup-8155@entry> <1241075456-sup-909@h984274.serverkompetenz.net> Message-ID: <1241095872-sup-9569@sgoldmanlinux.tower-research.com> Excerpts from Tyberius Prime's message of Thu Apr 30 03:11:29 -0400 2009: > For me it seems to be messages that have been saved 'hours' ago by pressing $. > > Excerpts from William Morgan's message of Wed Apr 29 20:10:53 +0200 2009: > > Reformatted excerpts from Steve Goldman's message of 2009-04-28: > > > Oftentimes when I quit sup and then restart, my inbox looks different. > > > Messages that I had previously archived are back in the inbox. Has > > > anyone else seen this? I'm losing sleep over it. > > > > I see it periodically too (I think I also see read messages turned > > unread again) and have been trying to find a pattern---is it email > > that's autosaved when I quit Sup, etc.? I have confirmed that 0.7 is fine, but master is not. So we just have to track down which commit(s) in between broke it... -- 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 bdwalton@gmail.com Thu Apr 30 09:10:20 2009 From: bdwalton@gmail.com (Ben Walton) Date: Thu, 30 Apr 2009 09:10:20 -0400 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1241095872-sup-9569@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> Message-ID: On Thu, Apr 30, 2009 at 8:51 AM, Steve Goldman wrote: > Excerpts from Tyberius Prime's message of Thu Apr 30 03:11:29 -0400 2009: >> For me it seems to be messages that have been saved 'hours' ago by pressing $. > > I have confirmed that 0.7 is fine, but master is not. ?So we just have > to track down which commit(s) in between broke it... git-bisect to the rescue? Anyone experiencing this and comfortable with git that wants to track down where the problem was introduced? It may take a little while, unless the problem can be recreated at will, but the bisect tool is awesome for situations like this. -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 wmorgan-sup@masanjin.net Thu Apr 30 09:19:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 30 Apr 2009 06:19:20 -0700 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1241095872-sup-9569@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> Message-ID: <1241097437-sup-8272@entry> Reformatted excerpts from Steve Goldman's message of 2009-04-30: > I have confirmed that 0.7 is fine, but master is not. So we just have > to track down which commit(s) in between broke it... Ok, now we're onto something! As an educated guess, I've published a branch revert-background-save, which is identical to master except that the commits on the background-save branch have been reverted. Can you try that branch please? -- William From wmorgan-sup@masanjin.net Thu Apr 30 09:36:22 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 30 Apr 2009 06:36:22 -0700 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> Message-ID: <1241098531-sup-1508@entry> Reformatted excerpts from Ben Walton's message of 2009-04-30: > git-bisect to the rescue? Anyone experiencing this and comfortable > with git that wants to track down where the problem was introduced? > It may take a little while, unless the problem can be recreated at > will, but the bisect tool is awesome for situations like this. If the educated guesses fall through, then we'll punish Steve for his insulin by making him binary search through all commits since 0.7. -- William From bdwalton@gmail.com Thu Apr 30 10:07:57 2009 From: bdwalton@gmail.com (Ben Walton) Date: Thu, 30 Apr 2009 10:07:57 -0400 Subject: [sup-talk] Sup with Microsoft Exchange 2007 In-Reply-To: <1241045035-sup-1534@entry> 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: On Wed, Apr 29, 2009 at 6:45 PM, William Morgan wrote: > As far as I'm concerned, if it works, I'll add it. I'd love to have this > functionality in Sup, and it is frequently requested. Ok. I started cleaning up the original patch last night. I think it was decent for the most part. The bad parts were the integration into sup-config. I'll have something ready in a day or two, hopefully. 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. -Ben > -- > William > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > -- --------------------------------------------------------------------------------------------------------------------------- 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 Thu Apr 30 10:23:25 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Thu, 30 Apr 2009 10:23:25 -0400 Subject: [sup-talk] Inconsistent inbox after restart In-Reply-To: <1241098531-sup-1508@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> Message-ID: <1241101364-sup-9621@sgoldmanlinux.tower-research.com> Excerpts from William Morgan's message of Thu Apr 30 09:36:22 -0400 2009: > Reformatted excerpts from Ben Walton's message of 2009-04-30: > > git-bisect to the rescue? Anyone experiencing this and comfortable > > with git that wants to track down where the problem was introduced? > > It may take a little while, unless the problem can be recreated at > > will, but the bisect tool is awesome for situations like this. > > If the educated guesses fall through, then we'll punish Steve for his > insulin by making him binary search through all commits since 0.7. Bad news. This new branch is also buggy. Time to apply the force of brute. -- 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