From jim@gonzul.net Wed Jul 1 01:20:10 2009 From: jim@gonzul.net (Jim Cheetham) Date: Wed, 1 Jul 2009 17:20:10 +1200 Subject: [sup-talk] Character encoding when displaying quoted-printable messages In-Reply-To: References: Message-ID: On Thu, Jun 18, 2009 at 9:39 AM, Jim Cheetham wrote: > However, I'm coming across some character decoding issues with > quoted-printable that are making some messages hard to read. Any > advice on how to improve things would be welcome ... In the example > below, a NBSP entity is showing up as the characters "M-BM-" Nicely fixed by using the hack ncursesw branch, by the way. http://sup.rubyforge.org/wiki/wiki.pl?UTF8 -jim From ingmar@exherbo.org Wed Jul 1 04:38:36 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Wed, 01 Jul 2009 10:38:36 +0200 Subject: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks search In-Reply-To: References: Message-ID: <1246437271-sup-7636@cannonball> Excerpts from Jim Cheetham's message of Wed Jul 01 07:20:10 +0200 2009: > Nicely fixed by using the hack ncursesw branch, by the way. > http://sup.rubyforge.org/wiki/wiki.pl?UTF8 Has anyone noticed that newer versions of ncurses-ruby plus that ncursesw hack [1] (to link to ncurses with widechar support) breaks search? When I search for 'foo', sup launches a search for a bunch of weird characters, not for 'foo', which obviously returns nothing useful. I can trigger this with ncurses-ruby 1.2.2, 1.2.3. Version 1.1 seems to be unaffected. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52 -- Exherbo KDE, X.org maintainer From helgedt@tihlde.org Wed Jul 1 05:20:05 2009 From: helgedt@tihlde.org (Helge Titlestad) Date: Wed, 01 Jul 2009 11:20:05 +0200 Subject: [sup-talk] Sup crash when adding CC to forwarded message Message-ID: <1246439829-sup-6907@colargol.tihlde.org> Hi, sup 0.8 just crashed on me. What I did was: * From thread-view, hit "f" to forward. * Enter address to forward to. * Just hit "enter" when asked for CC. * Save message (unedited). * Hit "c" to edit CC -> crash This is reproducible (only tried on one message, though.) bt: --- NoMethodError from thread: main undefined method `join' for "":String /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/modes/edit-message-mode.rb:414:in `edit_field' /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/modes/edit-message-mode.rb:119:in `edit_cc' /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/mode.rb:50:in `send' /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/mode.rb:50:in `handle_input' /home/xhs/helgedt/gems/gems/sup-0.8/lib/sup/buffer.rb:249:in `handle_input' /home/xhs/helgedt/gems/gems/sup-0.8/bin/sup:238 /home/xhs/helgedt/gems/bin/sup:19:in `load' /home/xhs/helgedt/gems/bin/sup:19 -- alge From jim@gonzul.net Wed Jul 1 05:48:30 2009 From: jim@gonzul.net (Jim Cheetham) Date: Wed, 1 Jul 2009 21:48:30 +1200 Subject: [sup-talk] sent_source - singular or per-account? Message-ID: It looks like there is only one place that outbound mail can be stored -- sent_source in config.yaml specifies it globally. I'd like to be able to save outgoing email into the mailstore for the matching account; can anyone suggest some way to do this? Hacking code is an option, although I'd appreciate some pointers ... From wmorgan-sup@masanjin.net Wed Jul 1 11:28:46 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 01 Jul 2009 08:28:46 -0700 Subject: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks search In-Reply-To: <1246437271-sup-7636@cannonball> References: <1246437271-sup-7636@cannonball> Message-ID: <1246461233-sup-208@entry> Reformatted excerpts from Ingmar Vanhassel's message of 2009-07-01: > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52 Interesting thread. I disagree with the conclusion that a separate libncursesw-ruby package should be created. Maybe I'll respond. The analysis of Sup is wrong. He says: "Looking at the source code of the mailer I'd say that it is not really suited for UTF-8 encoded strings yet, as it still assumes that the length of a string in bytes is equal to the number of characters in the string." This is not really true. What Sup assumes is that String#length gives the length of the string in characters. This is obviously false in Ruby 1.8 (without monkeypatching), but it is true in Ruby 1.9. What *does* need to happen for Sup to really, actually, correctly display non-ASCII characters, besides having a ncurses library that's linked against ncursesw, is to be able to call the 'wcwidth' and 'wcswidth' functions. The current #display_length function is a hack that's broken for e.g. Chinese characters. One way to do this would be to use dl/import like we do for setlocale(). I've played around with this but haven't really gotten it to work. If someone can get any further than the below, please let me know: require 'dl/import' module LibC extend DL.const_defined?(:Importer) ? DL::Importer : DL::Importable dlload "libc.so.6" extern "void setlocale(int, const char *)" extern "int wcwidth(int)" extern "int wcswidth(const int*, int)" end That "works", as in doesn't throw any exceptions, but then calling LibC.wcswidth doesn't return the right thing, presumably because the Ruby string isn't being converted into an array of ints, or something. I don't really know how this works. > Has anyone noticed that newer versions of ncurses-ruby plus that > ncursesw hack [1] (to link to ncurses with widechar support) breaks > search? I don't have these newer versions available on my system yet (Ubuntu). > When I search for 'foo', sup launches a search for a bunch of weird > characters, not for 'foo', which obviously returns nothing useful. Disturbing. -- William From bachjh@googlemail.com Wed Jul 1 11:42:04 2009 From: bachjh@googlemail.com (Jörg-Hendrik Bach) Date: Wed, 01 Jul 2009 17:42:04 +0200 Subject: [sup-talk] ncurses-ruby-1.2.3 + ncursesw hack breaks search In-Reply-To: <1246437271-sup-7636@cannonball> References: <1246437271-sup-7636@cannonball> Message-ID: <1246462442-sup-1884@BlackMesa> Ingmar Vanhassel, Wed Jul 01 10:38:36 +0200 2009: > Has anyone noticed that newer versions of ncurses-ruby plus that > ncursesw hack [1] (to link to ncurses with widechar support) breaks search? I can confirm the behaviour. > When I search for 'foo', sup launches a search for a bunch of weird > characters, not for 'foo', which obviously returns nothing useful. True. However, with the following workaround, you can get proper search results: - search for foo -> garbled search, no proper results - hit 'x' to destroy the result buffer - hit '\' to search again. - hit uparrow to go to previous search. backspace all the garbled characters there. - repeat the uparrow + remove until it shows your last working search (or until there's no more previous search to go to) - type foo again, hit enter: works. Not that this is the type of thing you'd want to do for a simple search. Guess we'll have to wait for ruby 1.9? cheers, - J?rg-Hendrik > > I can trigger this with ncurses-ruby 1.2.2, 1.2.3. Version 1.1 seems to > be unaffected. > > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477366#52 From ingmar@exherbo.org Wed Jul 1 11:29:22 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Wed, 01 Jul 2009 17:29:22 +0200 Subject: [sup-talk] Sup on Ruby-1.9 Message-ID: <1246461780-sup-5146@cannonball> Has anyone been keeping a TODO list for running sup on ruby-1.9? I haven't had the time to try it myself, but I'd like to have a rough idea of what I'm looking at. -- Exherbo KDE, X.org maintainer From wmorgan-sup@masanjin.net Wed Jul 1 14:11:37 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 01 Jul 2009 11:11:37 -0700 Subject: [sup-talk] Sup on Ruby-1.9 In-Reply-To: <1246461780-sup-5146@cannonball> References: <1246461780-sup-5146@cannonball> Message-ID: <1246471261-sup-3755@entry> Reformatted excerpts from Ingmar Vanhassel's message of 2009-07-01: > Has anyone been keeping a TODO list for running sup on ruby-1.9? The major blocker for a while was the Ferret gem. With the advent of the Xapian branch, I have been toying around with getting Sup + Xapian to work on 1.9.1. So far all the gem dependencies seem to compile except ncurses, which needs some minor code tweaks. The latest Xapian has Ruby 1.9.1-compatible bindings, but unfortunately the API seems to have shifted since Rich's patches. I get: lib/sup/xapian_index.rb:24:in `initialize': Wrong arguments for overloaded method 'WritableDatabase.new'. (ArgumentError) Possible C/C++ prototypes are: WritableDatabase.new() WritableDatabase.new(std::string const &path, int action) WritableDatabase.new(Xapian::WritableDatabase const &other) from lib/sup/xapian_index.rb:24:in `new' from lib/sup/xapian_index.rb:24:in `initialize' from bin/sup:132:in `new' from bin/sup:132:in `' from bin/sup:62:in `
' Moving to 1.9 is highly desirable. It would be a major win for non-ASCII display issues and for speed in general. I would also like to try moving some of the display code from threads to fibers, since there are still weird threading bugs in there that occasionally crop up, and I think it would simplify the implementation. -- William From wmorgan-sup@masanjin.net Wed Jul 1 14:19:27 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 01 Jul 2009 11:19:27 -0700 Subject: [sup-talk] Sup crash when adding CC to forwarded message In-Reply-To: <1246439829-sup-6907@colargol.tihlde.org> References: <1246439829-sup-6907@colargol.tihlde.org> Message-ID: <1246472248-sup-591@entry> Hi Helge, Reformatted excerpts from Helge Titlestad's message of 2009-07-01: > sup 0.8 just crashed on me. What I did was: > * From thread-view, hit "f" to forward. > * Enter address to forward to. > * Just hit "enter" when asked for CC. > * Save message (unedited). > * Hit "c" to edit CC > -> crash > > This is reproducible (only tried on one message, though.) I can't reproduce this. Does it happen on all messages, or just on that one? Does it happen if you specify someting for the cc: header? Thanks! -- William From wmorgan-sup@masanjin.net Wed Jul 1 14:23:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 01 Jul 2009 11:23:09 -0700 Subject: [sup-talk] Delete single message in thread-view? In-Reply-To: <1245415127-sup-2107@thinkpad-ubuntu> References: <1245415127-sup-2107@thinkpad-ubuntu> Message-ID: <1246472570-sup-6752@entry> Reformatted excerpts from Christopher Bertels's message of 2009-06-19: > Is it possible to delete a single message from a thread? I haven't > found a way to do this, but maybe I'm just blind. Not currently. Sorry! It's all or nothing for now. -- William From helgedt@tihlde.org Wed Jul 1 14:54:20 2009 From: helgedt@tihlde.org (Helge Titlestad) Date: Wed, 01 Jul 2009 20:54:20 +0200 Subject: [sup-talk] Sup crash when adding CC to forwarded message In-Reply-To: <1246472248-sup-591@entry> References: <1246439829-sup-6907@colargol.tihlde.org> <1246472248-sup-591@entry> Message-ID: <1246474215-sup-7272@colargol.tihlde.org> Excerpts from William Morgan's message of Wed Jul 01 20:19:27 +0200 2009: >> [Adding CC crash procedure] > > I can't reproduce this. Does it happen on all messages, or just on that > one? Does it happen if you specify someting for the cc: header? It's stopped being reproducible now. \: For the record, there was one "?" in the subject field. Probably shouldn't be related, but you never know with these utf-8 woes. (: -- alge From wmorgan-sup@masanjin.net Wed Jul 1 14:57:55 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 01 Jul 2009 11:57:55 -0700 Subject: [sup-talk] Sup crash when adding CC to forwarded message In-Reply-To: <1246474215-sup-7272@colargol.tihlde.org> References: <1246439829-sup-6907@colargol.tihlde.org> <1246472248-sup-591@entry> <1246474215-sup-7272@colargol.tihlde.org> Message-ID: <1246474654-sup-137@entry> Reformatted excerpts from Helge Titlestad's message of 2009-07-01: > For the record, there was one "?" in the subject field. Probably > shouldn't be related, but you never know with these utf-8 woes. (: I'd be surprised... but yeah, who knows! -- William From wmorgan-sup@masanjin.net Wed Jul 1 15:15:45 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 01 Jul 2009 12:15:45 -0700 Subject: [sup-talk] Sup on Ruby-1.9 In-Reply-To: <1246471261-sup-3755@entry> References: <1246461780-sup-5146@cannonball> <1246471261-sup-3755@entry> Message-ID: <1246475697-sup-7574@entry> Reformatted excerpts from William Morgan's message of 2009-07-01: > The latest Xapian has Ruby 1.9.1-compatible bindings, but unfortunately > the API seems to have shifted since Rich's patches. Hm, AFAIK that isn't an API change. Maybe I compiled my Xapian bindings wrong somehow. Or something. -- William From bwalton@artsci.utoronto.ca Wed Jul 1 15:39:57 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 01 Jul 2009 15:39:57 -0400 Subject: [sup-talk] sent_source - singular or per-account? In-Reply-To: References: Message-ID: <1246476925-sup-5046@ntdws12.chass.utoronto.ca> Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009: > I'd like to be able to save outgoing email into the mailstore for the > matching account; can anyone suggest some way to do this? Hacking code > is an option, although I'd appreciate some pointers ... This is an interesting idea. I think the best way to do it might be to implement a sent_source hook that can override the global default. It would be wise to either a) not use mbox or b) have dedicated mboxes for this purpose...until I finally get around to finishing the lock manager to make shared access safe. The other gotcha with a hook to pick the source for message storage is that not all sources are capable of storing mail presently (mbox, maildir and imap are the only supported types, which admittedly should cover most people). I think this would be quite simple to add. I've also toyed around with the idea of 'patterned' sources so that you could specify a source as maildir:///u/bwalton/Maildir/inbox-%Y%m and have new sources picked up automatically as they're created (possibly by procmail doing autofiling, or something). -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From andrea.fazzi@alcacoop.it Wed Jul 1 16:07:22 2009 From: andrea.fazzi@alcacoop.it (Andrea Fazzi) Date: Wed, 01 Jul 2009 22:07:22 +0200 Subject: [sup-talk] Reconnect command Message-ID: <1246478645-sup-1505@ganimoide> Hi all, finally I found the mail client I was searching for :) So, thanks for this great software. Sometime, it happens that I lost my internet connection (e.g. after a suspend/resume). Occasionally I noticed that, after the connection is restored, sup can't polling for new messages anymore. At the moment, I "fix" the issue restarting sup. In fact, it seems that doing a new login to the imap server solves the problem and I can fetch the new messages. I know I should investigate deeper and I'll do. But now I wonder if a "reconnect" command can be an useful feature. Thoughts? Cheers, Andrea -- Andrea Fazzi @ Alca Societ? Cooperativa Follow me on http://twitter.com/remogatto From jim@gonzul.net Wed Jul 1 22:30:25 2009 From: jim@gonzul.net (Jim Cheetham) Date: Thu, 2 Jul 2009 14:30:25 +1200 Subject: [sup-talk] sent_source - singular or per-account? In-Reply-To: <1246476925-sup-5046@ntdws12.chass.utoronto.ca> References: <1246476925-sup-5046@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton wrote: > Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009: >> I'd like to be able to save outgoing email into the mailstore for the >> matching account; can anyone suggest some way to do this? Hacking code >> is an option, although I'd appreciate some pointers ... > > This is an interesting idea. ?I think the best way to do it might be > to implement a sent_source hook that can override the global default. 'best' or 'simplest'? There already exists logic for determining which account a given outgoing message belongs to, because that's how the :sendmail: target is being used. If you are arguing that having a different sent_source per (outgoing) message is useful, then perhaps a hook makes sense; but the simpler case probably doesn't need it. > It would be wise to either a) not use mbox or b) have dedicated mboxes > for this purpose...until I finally get around to finishing the lock > manager to make shared access safe. Certainly the sent_source mbox shouldn't be subject to something inconvenient like delivery of new mail while we're updating it :-) but I'm not sure that mbox people would be unhappy having sent mail in a separate file ... ? -jim From bwalton@artsci.utoronto.ca Wed Jul 1 23:17:57 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 01 Jul 2009 23:17:57 -0400 Subject: [sup-talk] sent_source - singular or per-account? In-Reply-To: References: <1246476925-sup-5046@ntdws12.chass.utoronto.ca> Message-ID: <1246502666-sup-1295@ntdws12.chass.utoronto.ca> Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009: > On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton wrote: > > Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009: > >> I'd like to be able to save outgoing email into the mailstore for the > >> matching account; can anyone suggest some way to do this? Hacking code > >> is an option, although I'd appreciate some pointers ... > > > > This is an interesting idea. ?I think the best way to do it might be > > to implement a sent_source hook that can override the global default. > > 'best' or 'simplest'? Both? > There already exists logic for determining which account a given > outgoing message belongs to, because that's how the :sendmail: > target is being used. > > If you are arguing that having a different sent_source per (outgoing) > message is useful, then perhaps a hook makes sense; but the simpler > case probably doesn't need it. I'm not arguing anything, and perhaps using sent_source as the (hypothetical) hook name was a bad choice... If I'm understanding you correctly, you want to write to a different source depending on which address is used in the From. You'd either need to make a separate config entry in each account that gets setup (similar to the sendmail that you note) or provide the ability for the user to select the sent box in some other way. In the 'simpler' case where the decision is made based on account used, you've got a chunk of static code making the choice and defaulting as it would now. The hook would simply take the place of the static decision maker. The decision has to be made per message regardless of how it's implemented, so doing it in a hook is a better option, imo. The Hook route would be slightly slower, since there are extra activation records on the stack for the function calls, but it should be negligible. The other advantage to a Hook is that the decision could be made based on more than simply the From:. Maybe other users would prefer to store mail based on who it was sent To...or a combo of From/To? I'm interested in William's thoughts on this. It's not a feature I'd use, but I do think it's a good feature to have. I hope this explains my thinking more clearly. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jim@gonzul.net Thu Jul 2 06:14:23 2009 From: jim@gonzul.net (Jim Cheetham) Date: Thu, 2 Jul 2009 22:14:23 +1200 Subject: [sup-talk] sent_source - singular or per-account? In-Reply-To: <1246502666-sup-1295@ntdws12.chass.utoronto.ca> References: <1246476925-sup-5046@ntdws12.chass.utoronto.ca> <1246502666-sup-1295@ntdws12.chass.utoronto.ca> Message-ID: On Thu, Jul 2, 2009 at 3:17 PM, Ben Walton wrote: > Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009: > If I'm understanding you correctly, you want to write to a different > source depending on which address is used in the From. Almost; what I (could have) said was that I wanted to write to a different source depending on which account is in use for the current message; I wasn't fixating on the From address itself, although with a better understanding of the code you might declare that they are effectively the same anyway :-) > ?You'd either > need to make a separate config entry in each account that gets setup > (similar to the sendmail that you note) or provide the ability for the > user to select the sent box in some other way. Yes; and in either case I think we can't just override the current global sent_source, because this is being used to read messages from, in order to include them in the threads. > In the 'simpler' case where the decision is made based on account > used, you've got a chunk of static code making the choice and > defaulting as it would now. ?The hook would simply take the place of > the static decision maker. ?The decision has to be made per message > regardless of how it's implemented, so doing it in a hook is a better > option, imo. ?The Hook route would be slightly slower, since there are > extra activation records on the stack for the function calls, but it > should be negligible. Mmm, I think the hook route would expose you to a lot of change, because whenever a 'new' source (i.e. one not known about as load time) is declared in the hook, you'll have to remember it so it can be included in the index, and be available next time sup starts too. Whereas requiring sent_sources to be declared at load time only means they can be added as sources just like the current singular one is. I've been browsing the source this evening, I don't have a very good grasp of Ruby idiom but I do find it to be very readable in general :-) However, I've come to a halt in SentManager.write_sent_message, because I haven't figured out how @source.store_message relates to my store URI, and therefore the relevant store_message function. I mean, if :sent_store: is configured, how does @source get created from @source_uri? If we have multiple sent_sources, that contradicts the singleton SentManager, unless @source becomes a hash keyed off from_email ... at which point I'm pushing my Ruby skills too far for the evening. Any comments or specific code pointers welcomed! I'd be happy to attempt a patch for this, but I may need a little help ... -jim From bwalton@artsci.utoronto.ca Thu Jul 2 10:02:56 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 02 Jul 2009 10:02:56 -0400 Subject: [sup-talk] sent_source - singular or per-account? In-Reply-To: References: <1246476925-sup-5046@ntdws12.chass.utoronto.ca> <1246502666-sup-1295@ntdws12.chass.utoronto.ca> Message-ID: <1246542975-sup-7239@ntdws12.chass.utoronto.ca> Excerpts from Jim Cheetham's message of Thu Jul 02 06:14:23 -0400 2009: > Almost; what I (could have) said was that I wanted to write to a > different source depending on which account is in use for the > current message; I wasn't fixating on the From address itself, > although with a better understanding of the code you might declare > that they are effectively the same anyway :-) Ok. I _think_ that difference would come out in the wash, unless I'm overlooking a subtlety. Thanks for clarifying your needs/wants though. > > ?You'd either need to make a separate config entry in each account > > that gets setup (similar to the sendmail that you note) or provide > > the ability for the user to select the sent box in some other way. > > Yes; and in either case I think we can't just override the current > global sent_source, because this is being used to read messages from, > in order to include them in the threads. As long as sup is configured with all sources that might be returned from the hook, including the default source, it should be ok. It'll still poll all sources and thread messages appropriately. > Mmm, I think the hook route would expose you to a lot of change, > because whenever a 'new' source (i.e. one not known about as load > time) is declared in the hook, you'll have to remember it so it can be > included in the index, and be available next time sup starts too. My take on this is that the hook would be constrained to return only existing sources. On the other hand, aside from an initial import of any existing mail in a new folder, I'm not sure that adding new sources on the fly would be that bad. > Whereas requiring sent_sources to be declared at load time only means > they can be added as sources just like the current singular one is. I was picturing the hook return value to be a uri suitable for passing to Index.source_for. If that method call failed, the default would be used. There are of course other (maybe better) ways to do this, but that's what I was thinking last night. Using this technique, you're limited to existing sources and you also have an easy way to back out of a 'hook gone wild.' > I've been browsing the source this evening, I don't have a very good > grasp of Ruby idiom but I do find it to be very readable in general > :-) However, I've come to a halt in SentManager.write_sent_message, It is a beautiful, expressive language! :) > because I haven't figured out how @source.store_message relates to my > store URI, and therefore the relevant store_message function. I mean, > if :sent_store: is configured, how does @source get created from > @source_uri? At startup, SentManager is initialized with a URI. This is either the value of :sent_source: from config.yaml or the default (special) value sup://sent. A little later on, after the Index has been initialized, it is asked for the source that corresponds to the URI value passed to SentManager. If this source is found in the Index, it is assigned to the @source value. Otherwise, the SentManager.default_source method is triggered. So, when one of the message modes calls write_sent_message, it has either a specific source or the default ready to go. Sources usable by SentManager are constrained such that they must respond to store_message. This excludes ssh+mbox URI's from being a valid sent mail source. > If we have multiple sent_sources, that contradicts the singleton > SentManager, unless @source becomes a hash keyed off from_email ... at > which point I'm pushing my Ruby skills too far for the evening. I don't think it precludes it from being a singleton, but it would require some heavy reworking of the initialization logic for it. I just popped into sent.rb and was all set to knock out a patch to add the hook and I discovered that my memory of this wasn't what I thought. SentManager doesn't ever _see_ the message. It simply facilitates calling the store_message method of whatever source is configured and that source object in turn provides an object that acts like an IO object to the edit-message-mode call site. This complicates either approach discussed here since the determination of which source to use can't be constrained to SentManager...presently, it would end up in edit-message-mode, which wouldn't be the right spot for the logic, I don't think. More thinking required, I believe. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ezyang@MIT.EDU Thu Jul 2 13:16:17 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 02 Jul 2009 13:16:17 -0400 Subject: [sup-talk] Sup doesn't respect Reply-To header Message-ID: <1246554940-sup-138@javelin> It doesn't look like Sup respects Reply-To headers. Is this intentional? It breaks some mailing list agents. Cheers, Edward From bachjh@googlemail.com Fri Jul 3 12:05:23 2009 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=) Date: Fri, 3 Jul 2009 18:05:23 +0200 Subject: [sup-talk] colour customisation Message-ID: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com> Hello list, is there any documentation on which parts of the display can be changed via the .sup/colors.yaml? From the wiki entry[1] it is possible to figure out some of the variables, but I haven't got all. cheers, - J?rg-Hendrik [1] http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors From garoth@gmail.com Fri Jul 3 13:13:29 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 03 Jul 2009 13:13:29 -0400 Subject: [sup-talk] colour customisation In-Reply-To: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com> References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com> Message-ID: <1246641077-sup-9945@Longbow> Excerpts from J?rg-Hendrik Bach's message of Fri Jul 03 12:05:23 -0400 2009: > Hello list, > > is there any documentation on which parts of the display can be changed via the > .sup/colors.yaml? From the wiki entry[1] it is possible to figure out some of > the variables, but I haven't got all. I don't really know, but from browsing the source briefly, I've found (formatted as quote): > DEFAULT_COLORS = { > :status => { :fg => "white", :bg => "blue", :attrs => ["bold"] }, > :index_old => { :fg => "white", :bg => "default" }, > :index_new => { :fg => "white", :bg => "default", :attrs => ["bold"] }, > :index_starred => { :fg => "yellow", :bg => "default", :attrs => ["bold"] }, > :index_draft => { :fg => "red", :bg => "default", :attrs => ["bold"] }, > :labellist_old => { :fg => "white", :bg => "default" }, > :labellist_new => { :fg => "white", :bg => "default", :attrs => ["bold"] }, > :twiddle => { :fg => "blue", :bg => "default" }, > :label => { :fg => "yellow", :bg => "default" }, > :message_patina => { :fg => "black", :bg => "green" }, > :alternate_patina => { :fg => "black", :bg => "blue" }, > :missing_message => { :fg => "black", :bg => "red" }, > :attachment => { :fg => "cyan", :bg => "default" }, > :cryptosig_valid => { :fg => "yellow", :bg => "default", :attrs => ["bold"] }, > :cryptosig_unknown => { :fg => "cyan", :bg => "default" }, > :cryptosig_invalid => { :fg => "yellow", :bg => "red", :attrs => ["bold"] }, > :generic_notice_patina => { :fg => "cyan", :bg => "default" }, > :quote_patina => { :fg => "yellow", :bg => "default" }, > :sig_patina => { :fg => "yellow", :bg => "default" }, > :quote => { :fg => "yellow", :bg => "default" }, > :sig => { :fg => "yellow", :bg => "default" }, > :to_me => { :fg => "green", :bg => "default" }, > :starred => { :fg => "yellow", :bg => "default", :attrs => ["bold"] }, > :starred_patina => { :fg => "yellow", :bg => "green", :attrs => ["bold"] }, > :alternate_starred_patina => { :fg => "yellow", :bg => "blue", :attrs => ["bold"] }, > :snippet => { :fg => "cyan", :bg => "default" }, > :option => { :fg => "white", :bg => "default" }, > :tagged => { :fg => "yellow", :bg => "default", :attrs => ["bold"] }, > :draft_notification => { :fg => "red", :bg => "default", :attrs => ["bold"] }, > :completion_character => { :fg => "white", :bg => "default", :attrs => ["bold"] }, > :horizontal_selector_selected => { :fg => "yellow", :bg => "default", :attrs => ["bold"] }, > :horizontal_selector_unselected => { :fg => "cyan", :bg => "default" }, > :search_highlight => { :fg => "black", :bg => "yellow", :attrs => ["bold"] }, > :system_buf => { :fg => "blue", :bg => "default" }, > :regular_buf => { :fg => "white", :bg => "default" }, > :modified_buffer => { :fg => "yellow", :bg => "default", :attrs => ["bold"] }, > } You can probably extrapolate how to do colouring based on this? If you have the energy, please update the wiki to maybe mention this list, etc. Last I saw, the page was fairly out of date. Hope this helps, -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From wmorgan-sup@masanjin.net Fri Jul 3 14:37:46 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 03 Jul 2009 11:37:46 -0700 Subject: [sup-talk] sup In-Reply-To: <20090703173353.GA4117@gmx.de> References: <20090703173353.GA4117@gmx.de> Message-ID: <1246645330-sup-1433@entry> [cc'ing sup-talk] Hi Marc, Reformatted excerpts from Marc Weber's message of 2009-07-03: > I finally managed to package sup on nix. (nixos.org) and I'm ready to > give sup a try. Great! > a) if ferret does save the whole messages you don't really need the > original sources (maildir, mbox files), right? That's basically correct, but: a) Ferret doesn't store the entire message as represented in the mailstore (e.g. it only keeps a subset of the headers). b) Ferret has had corruption problems in the past, which I believe have now been fixed, but I wouldn't bet my mailstore on it. c) It's easy to turn that feature off, i.e., Ferret can index email for search without directly storing the email. The only reason I have Ferret store the email is because it makes changing the message labels quicker. If the Ferret index is too large, you can disable this feature at the expense of some speed. > b) [redacted] on irc told me that ferret has been abandoned in favour of > Xapian ? So are there any plans in replacing Ferret by Xapian as well? It hasn't happened quite yet (the Xapian backend is very recent and experimental), but that's the goal. I'm currently thinking about having the next release of Sup use Xapian as the default index, but still support Ferret, and the release after that not support Ferret at all. But we shall see. I'm also working on a sup server, which will act as yet another index type. > c) I've got about 280MB of mails from the haskelcafe mailinglist or > such. I missed telling sup to mark those old mails as read as well > as adding a "haskell-cafe" tag. It's not a big problem because all > mails contain [haskell-cafe] in the subject. However finding all > threads (using !!) takes ages (more than 20min or so?) so I didn't > wait until it finished. Opening the same maildir in mutt takes less > than a minute. The Xapian backend will speed this up dramatically, because the thread structures are cached, and that's what's expensive in this case. But the best solution is to use sup-tweak-labels, which is an offline tool built for exactly this purpose. > I've seen that ferret does save mails but displays threads. > Would it make sense to index the threads instead of mails? > Then displaying them and querying them could be even faster? See above. Welcome to Sup! -- William From wmorgan-sup@masanjin.net Fri Jul 3 14:54:46 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 03 Jul 2009 11:54:46 -0700 Subject: [sup-talk] colour customisation In-Reply-To: <1246641077-sup-9945@Longbow> References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com> <1246641077-sup-9945@Longbow> Message-ID: <1246646592-sup-3461@entry> Reformatted excerpts from Andrei Thorp's message of 2009-07-03: > I don't really know, but from browsing the source briefly, I've > found (formatted as quote): This is correct. That is the list of parts of the display that can be changed, and their default colors. The possible colors for both foreground and background are the curses palette: black, red, green, yellow, blue, magenta, cyan, white, and "default". The possible attributes are the curses attributes: normal, standout, underline, reverse, blink, dim, bold, protect, invis. (I have no idea what many of those actually do.) Any of those settings can be overwritten by making a ~/.sup/colors.yaml file, which should be a YAML hash of the exact same format as DEFAULT_COLORS. A good way to get started it to do this: ruby -rubygems -rsup -e 'print Redwood::Colormap::DEFAULT_COLORS.to_yaml' > ~/.sup/colors.yaml and then edit the result. A gold star to whoever updates the wiki. -- William From j.bach@uni-oldenburg.de Sat Jul 4 08:01:25 2009 From: j.bach@uni-oldenburg.de (=?utf-8?q?J=C3=B6rg-Hendrik_Bach?=) Date: Sat, 04 Jul 2009 14:01:25 +0200 Subject: [sup-talk] colour customisation In-Reply-To: <1246646592-sup-3461@entry> References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com> <1246641077-sup-9945@Longbow> <1246646592-sup-3461@entry> Message-ID: <1246708626-sup-8076@lambda> I started updating the wiki page on customized colours, http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors I added explanations for the obvious entries, and a few that I found by trial and error. However, a large part of the description is still missing, I didn't have enough time to find all the colours; but at least it's a start. From garoth@gmail.com Mon Jul 6 09:47:42 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 06 Jul 2009 09:47:42 -0400 Subject: [sup-talk] colour customisation In-Reply-To: <1246708626-sup-8076@lambda> References: <91de50e10907030905l6673a7c3n380f6daeccfb14ab@mail.gmail.com> <1246641077-sup-9945@Longbow> <1246646592-sup-3461@entry> <1246708626-sup-8076@lambda> Message-ID: <1246887804-sup-6728@Longbow> Excerpts from J?rg-Hendrik Bach's message of Sat Jul 04 08:01:25 -0400 2009: > I started updating the wiki page on customized colours, > http://sup.rubyforge.org/wiki/wiki.pl?CustomizingColors > > I added explanations for the obvious entries, and a few that I found by > trial and error. However, a large part of the description is still > missing, I didn't have enough time to find all the colours; but at least > it's a start. Daaamn. Fine work you've done there. I'm really impressed with the graphics :) Just from reading over the names of the list and not consulting the source: - index_draft is obviously what colour drafts in the inbox are - cryptosig variables probably have to do with what colours the stuff for signed messages are. - search_highlight is probably the colour for when you search in a buffer and some stuff is highlighted (yellow) Anyway, thanks for all your work. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From jof@thejof.com Tue Jul 7 04:20:51 2009 From: jof@thejof.com (Jonathan Lassoff) Date: Tue, 07 Jul 2009 01:20:51 -0700 Subject: [sup-talk] sup 0.8.1 crash Message-ID: <1246954373-sup-4550@sfo.thejof.com> Yikes! I found a way to crash my sup! I'm running sup 0.8.1 (sourced from whatever's current on rubygems.org, not a git branch), and can get sup to crash on specific searches. I took a little time to poke around in the sup source to try and get an idea what was going on. I'm led to believe this is because I added a source in the past that I later deleted -- but all of the mesages are still in the index. So, when certain searches turn up results that are in that deleted source, the sup index fails to reference the message source in Redwood::Index. Is there a way to delete a source without having to re-index everything? So, I figured I might find a way to search the index for any documents whose source id is the same as the deleted one and remove them from the index, but am having a hard time finding a way to iterate over all documents in the index (no search query). Is there a simple way to iterate over all messages? Here's some example crash output: --- RuntimeError from thread: load threads for thread-index-mode invalid source 1 /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:403:in `build_message' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:399:in `build_message' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in `each_id_by_date' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:330:in `load_n_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:297:in `each_id_by_date' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/index.rb:296:in `each_id_by_date' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/thread.rb:326:in `load_n_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:620:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:604:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads' (eval):12:in `load_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/lib/sup/modes/search-results-mode.rb:34:in `spawn_from_query' /usr/lib/ruby/gems/1.8/gems/sup-0.8.1/bin/sup:270 /usr/bin/sup:19:in `load' /usr/bin/sup:19 Thanks, jonathan From marco-oweber@gmx.de Tue Jul 7 09:08:44 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Tue, 7 Jul 2009 15:08:44 +0200 Subject: [sup-talk] Backups ? Message-ID: <20090707130844.GA23073@gmx.de> Hi, I'd like to setup an automatic backup system cause I don't want to tag my mails twice and I don't want to loose the information about archived mails etc. What do you think about something like this? Is it enough to keep 4 dumps? What about moving this code into sup shutdown? I think everyone wants to have this feature? run_sup(){ # untested draft local dump_dir="/var" sup sup-dump | bzip2 > "$dump_dir/sup-dumps-`date`" ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm } Marc Weber From wagnerdm@seas.upenn.edu Tue Jul 7 11:26:35 2009 From: wagnerdm@seas.upenn.edu (wagnerdm at seas.upenn.edu) Date: Tue, 07 Jul 2009 11:26:35 -0400 Subject: [sup-talk] Backups ? In-Reply-To: <20090707130844.GA23073@gmx.de> References: <20090707130844.GA23073@gmx.de> Message-ID: <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu> Quoting Marc Weber : > ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm "{ read; read; read; read; cat }" could probably better be done as "tail +5"; makes it easier to adjust to people's choice of backup count, too. ;-) - Daniel "Bikeshedder" Wagner From bwalton@artsci.utoronto.ca Tue Jul 7 12:10:42 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 07 Jul 2009 12:10:42 -0400 Subject: [sup-talk] Backups ? In-Reply-To: <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu> References: <20090707130844.GA23073@gmx.de> <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu> Message-ID: <1246982848-sup-5820@ntdws12.chass.utoronto.ca> Excerpts from wagnerdm's message of Tue Jul 07 11:26:35 -0400 2009: > > ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm > > "{ read; read; read; read; cat }" could probably better be done as > "tail +5"; makes it easier to adjust to people's choice of backup Or: DAYS=5 find $dump_dir -mtime +${DAYS} -name "*sup-dumps-*" -print0 | xargs -0 --no-run-if-empty rm (adjust xargs options to suit your environment...I don't think --no-run-if-empty is all that portable.) -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ingmar@exherbo.org Tue Jul 7 12:19:14 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Tue, 07 Jul 2009 18:19:14 +0200 Subject: [sup-talk] Backups ? In-Reply-To: <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu> References: <20090707130844.GA23073@gmx.de> <20090707112635.14736pk1mxi8r9k4@webmail.seas.upenn.edu> Message-ID: <1246983494-sup-6924@cannonball> Excerpts from wagnerdm's message of Tue Jul 07 17:26:35 +0200 2009: > Quoting Marc Weber : > > > ls -1t "$dump_dir"/sup-dumps-* | { read; read; read; read; cat } | xargs rm > > "{ read; read; read; read; cat }" could probably better be done as > "tail +5"; makes it easier to adjust to people's choice of backup > count, too. ;-) > - Daniel "Bikeshedder" Wagner "tail -n+5", which is POSIX compatible -- Exherbo KDE, X.org maintainer From rhomunuq+ml_sup@gmail.com Tue Jul 7 13:44:18 2009 From: rhomunuq+ml_sup@gmail.com (Iain) Date: Tue, 07 Jul 2009 18:44:18 +0100 Subject: [sup-talk] Exception Log Message-ID: <1246988396-sup-8372@leda> I'm using Sup 0.8.1 on Ubuntu 8.10 -- from the .deb kindly put together by Decklin Foster, . A few minutes ago, sup crashed on me. ~/.sup/exception-log.txt : --- NoMethodError from thread: main undefined method `title' for nil:NilClass /usr/lib/ruby/1.8/sup/buffer.rb:747:in `get_status_and_title' /usr/lib/ruby/1.8/sup/buffer.rb:281:in `draw_screen' /usr/bin/sup-mail:306 The crash may have something to do with receiving a new message (from an automatic poll of a Maildir) at the same time as having just read and archived the prior first message in the inbox, using: ".a". From dato@net.com.org.es Thu Jul 9 15:55:17 2009 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=) Date: Thu, 9 Jul 2009 21:55:17 +0200 Subject: [sup-talk] [PATCH] Use /etc/mailname if present to determine the hostname for Message-Id Message-ID: Signed-off-by: Adeodato Sim? --- Hello, on many systems (notably Debian-based systems), the /etc/mailname file can be created to specify the public mail name for a host. If that file exists, it'd be good to use its contents for generating the Message-Id header. I'd be grateful if you'd consider applying this patch. lib/sup/modes/edit-message-mode.rb | 9 ++++++++- 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb index f956d65..a48930a 100644 --- a/lib/sup/modes/edit-message-mode.rb +++ b/lib/sup/modes/edit-message-mode.rb @@ -73,7 +73,14 @@ EOS @attachment_names = [] end - @message_id = "<#{Time.now.to_i}-sup-#{rand 10000}@#{Socket.gethostname}>" + begin + hostname = File.open("/etc/mailname", "r").gets.chomp + rescue + nil + end + hostname = Socket.gethostname if hostname.nil? or hostname.empty? + + @message_id = "<#{Time.now.to_i}-sup-#{rand 10000}@#{hostname}>" @edited = false @selectors = [] @selector_label_width = 0 -- 1.6.3.3 From michael@stapelberg.de Thu Jul 9 20:34:21 2009 From: michael@stapelberg.de (Michael Stapelberg) Date: Fri, 10 Jul 2009 02:34:21 +0200 Subject: [sup-talk] sup opens multiple connections to the same imap-server Message-ID: <1247185833-sup-8539@x200> Hi, for some reason my cyrus-imapd does not handle multiple connections so well. There are 27 processes on my server which are all caused by sup. Probably sup opens one imap connection for each source I configured, which are 28. In my opinion, one connection to the server should be enough. Especially because sup hangs for ages until it manages to talk to my imap server correctly. Is there an easy way to make sup use only one connection? If not, I?ll see if this problem still arises after I re-install my server (probably with dovecot instead of cyrus this time). Best regards, Michael From michael@stapelberg.de Thu Jul 9 20:38:25 2009 From: michael@stapelberg.de (Michael Stapelberg) Date: Fri, 10 Jul 2009 02:38:25 +0200 Subject: [sup-talk] Using sup on multiple computers? Message-ID: <1247186181-sup-1712@x200> Hi, I?d like to use sup on my notebook and on my workstation. Is there any simple/recommended way to synchronize the index? I figured using multiple clients in parallel is one of the big advantages of IMAP and I?d love to keep it that way while using sup. Best regards, Michael From ezyang@MIT.EDU Thu Jul 9 22:57:14 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 09 Jul 2009 22:57:14 -0400 Subject: [sup-talk] Using sup on multiple computers? In-Reply-To: <1247186181-sup-1712@x200> References: <1247186181-sup-1712@x200> Message-ID: <1247194599-sup-5843@javelin> Excerpts from Michael Stapelberg's message of Thu Jul 09 20:38:25 -0400 2009: > I?d like to use sup on my notebook and on my workstation. Is there any > simple/recommended way to synchronize the index? I figured using multiple > clients in parallel is one of the big advantages of IMAP and I?d love to keep > it that way while using sup. The easiest way is to not; since Sup is a command line application, it's trivial to spin it up on a server you have access to and simply SSH in to check your mail. Cheers, Edward From jof@thejof.com Thu Jul 9 23:03:22 2009 From: jof@thejof.com (Jonathan Lassoff) Date: Thu, 09 Jul 2009 20:03:22 -0700 Subject: [sup-talk] Using sup on multiple computers? In-Reply-To: <1247186181-sup-1712@x200> References: <1247186181-sup-1712@x200> Message-ID: <1247194844-sup-6153@sfo.thejof.com> Excerpts from Michael Stapelberg's message of Thu Jul 09 17:38:25 -0700 2009: > Hi, > > I'd like to use sup on my notebook and on my workstation. Is there any > simple/recommended way to synchronize the index? As far as I know, this isn't supported in sup yet. One way I work around this to use sup on two machines is that I know my access is mutually exclusive i.e. I don't use more than one host at once. So, when I switch from one host to another, I quit sup and rsync my ~/.sup to the machine I'm moving to and rysnc it back again when I return. Hacky, but functional enough. Cheers, jonathan From michael+sup@stapelberg.de Fri Jul 10 06:59:42 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Fri, 10 Jul 2009 12:59:42 +0200 Subject: [sup-talk] Using sup on multiple computers? In-Reply-To: <1247194599-sup-5843@javelin> References: <1247186181-sup-1712@x200> <1247194599-sup-5843@javelin> Message-ID: <1247223427-sup-4016@x200> Hi, Excerpts from Edward Z. Yang's message of Fr Jul 10 04:57:14 +0200 2009: > The easiest way is to not; since Sup is a command line application, it's trivial > to spin it up on a server you have access to and simply SSH in to check your > mail. I?ve been using mutt like this for about a year or so but I generally don?t want to continue with this approach. It has the disadvantage of having the need to copy attachments to your computer before being able to display them (think of PDFs) and of not scaling well when on a slow internet connection (IMAP traffic is less than a whole user interface). Best regards, Michael From garoth@gmail.com Fri Jul 10 10:30:40 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 10 Jul 2009 10:30:40 -0400 Subject: [sup-talk] Using sup on multiple computers? In-Reply-To: <1247194844-sup-6153@sfo.thejof.com> References: <1247186181-sup-1712@x200> <1247194844-sup-6153@sfo.thejof.com> Message-ID: <1247236046-sup-9543@Longbow> Excerpts from Jonathan Lassoff's message of Thu Jul 09 23:03:22 -0400 2009: > Excerpts from Michael Stapelberg's message of Thu Jul 09 17:38:25 -0700 2009: > > Hi, > > > > I'd like to use sup on my notebook and on my workstation. Is there any > > simple/recommended way to synchronize the index? > > As far as I know, this isn't supported in sup yet. > > One way I work around this to use sup on two machines is that I know my > access is mutually exclusive i.e. I don't use more than one host at > once. The smarter way of doing this is to keep your .sup on a remote server as a share and mount it onto the right place in your home when you log in. This still has the disadvantage of only being able to use one sup at a time, but at least sup will lock the index using its lockfile, so you can't accidentally run two at once and screw something up. It also prevents you from having to manually rsync stuff. The nicest way to do this would to probably use sshfs. This way, the index is shared, you only need ssh (no NFS nastiness), it can mount automatically, and since sup is actually running on your local machine, it can save attachments just fine. One note: You need to either have _identical_ imap folders on your computers in the identical filesystem paths, or you need to have your mail delivered to the server and share that too. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From dato@net.com.org.es Fri Jul 10 11:00:29 2009 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=) Date: Fri, 10 Jul 2009 17:00:29 +0200 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset Message-ID: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> This is useful, for example, for HTML attachments which are sent in a charset different from the default for the system (eg., ISO-8859-1 on an UTF-8 system), so that the converter program can be told what charset it should be converting from. Signed-off-by: Adeodato Sim? --- lib/sup/message-chunks.rb | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index 0d742d9..ea04ed7 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -50,7 +50,8 @@ directly in Sup. For attachments that you wish to use a separate program to view (e.g. images), you should use the mime-view hook instead. Variables: - content_type: the content-type of the message + content_type: the content-type of the attachment + charset: the charset of the attachment, if applicable filename: the filename of the attachment as saved to disk sibling_types: if this attachment is part of a multipart MIME attachment, an array of content-types for all attachments. Otherwise, @@ -103,6 +104,7 @@ EOS else HookManager.run "mime-decode", :content_type => content_type, :filename => lambda { write_to_disk }, + :charset => encoded_content.charset, :sibling_types => sibling_types end -- 1.6.3.3 From michael+sup@stapelberg.de Fri Jul 10 16:19:14 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Fri, 10 Jul 2009 22:19:14 +0200 Subject: [sup-talk] Validating GPG keys in parallel and in background Message-ID: <1247256988-sup-2799@x200> Hi, it seems like sup is blocking during the validation of GPG signed/encrypted mails. While for encryption it makes some sense to block, for signed mails it would be better to just display the message and add the information about the signature status later. The same approach could be used for encrypted messages: Display "decrypting..." and update it when done. This is especially important for big mailing lists (like debian-devel) which contain many signed mails. Best regards, Michael From dato@net.com.org.es Sat Jul 11 07:57:55 2009 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=) Date: Sat, 11 Jul 2009 13:57:55 +0200 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) Message-ID: Signed-off-by: Adeodato Sim? --- lib/sup/modes/thread-view-mode.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 759191e..737f6f1 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -204,7 +204,7 @@ EOS end end - cmd = case HookManager.run "bounce-command", :from => m.from, :to => to + cmd = case (hookcmd = HookManager.run "bounce-command", :from => m.from, :to => to) when nil, /^$/ then defcmd else hookcmd end + ' ' + to.map { |t| t.email }.join(' ') -- 1.6.3.3 From bwalton@artsci.utoronto.ca Sat Jul 11 10:12:17 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 11 Jul 2009 10:12:17 -0400 Subject: [sup-talk] sup opens multiple connections to the same imap-server In-Reply-To: <1247185833-sup-8539@x200> References: <1247185833-sup-8539@x200> Message-ID: <1247321064-sup-4795@ntdws12.chass.utoronto.ca> Excerpts from Michael Stapelberg's message of Thu Jul 09 20:34:21 -0400 2009: > Is there an easy way to make sup use only one connection? If not, I?ll see > if this problem still arises after I re-install my server (probably with > dovecot instead of cyrus this time). I don't believe there is a way to do this currently. It would require some refactoring of the code. Roughly: The IMAP source would refer to an IMAPManager for a connection. The IMAP manager would handle creating new connections when required or passing a reference to an existing connection if it had already created. A tuple of (imap server, username, password) could be used to determine the uniqueness of the request. The unsafe_connect method of the IMAP source could move to the IMAPManager and calls to unsafe_connect could be rerouted to IMAPManager.connection_for(server, user, password) or some such... It shouldn't be a bad addition to add if you're interested. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Sat Jul 11 10:28:58 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 11 Jul 2009 10:28:58 -0400 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) In-Reply-To: References: Message-ID: <1247322405-sup-1564@ntdws12.chass.utoronto.ca> Excerpts from Adeodato Sim?'s message of Sat Jul 11 07:57:55 -0400 2009: > Signed-off-by: Adeodato Sim? > --- > lib/sup/modes/thread-view-mode.rb | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) +1 for this. Not sure how I managed to submit the original patch like this, since I did test various forms of results returned from the bounce-command hook...anyway, I've applied this and verified it. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael+sup@stapelberg.de Sat Jul 11 11:36:23 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sat, 11 Jul 2009 17:36:23 +0200 Subject: [sup-talk] sup opens multiple connections to the same imap-server In-Reply-To: <1247321064-sup-4795@ntdws12.chass.utoronto.ca> References: <1247185833-sup-8539@x200> <1247321064-sup-4795@ntdws12.chass.utoronto.ca> Message-ID: <1247326506-sup-1002@x200> Hi Ben, Excerpts from Ben Walton's message of Sa Jul 11 16:12:17 +0200 2009: > It shouldn't be a bad addition to add if you're interested. Thanks for pointing out how it could be done. Unfortunately, I?ve never done any ruby code. I?ll have a look at sup?s source in a few weeks and I can try to implement it. Don?t count on it, though (meaning: if you can do it better/faster, go for it). Best regards, Michael From michael+sup@stapelberg.de Sat Jul 11 12:53:35 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sat, 11 Jul 2009 18:53:35 +0200 Subject: [sup-talk] Adding/saving multiple attachments? Message-ID: <1247331130-sup-4923@x200> Hi, I?ve had the same problem with mutt: Isn?t there a way to add or save multiple attachments? Why can?t I add ~/work/foo/* when pressing 'a'? Why doesn?t the file browser save the last directory I?ve been in? Can we please get a binding to save all attachments of a message into a folder? Best regards, Michael From nico-sup@schottelius.org Mon Jul 13 05:01:10 2009 From: nico-sup@schottelius.org (Nico Schottelius) Date: Mon, 13 Jul 2009 11:01:10 +0200 Subject: [sup-talk] Invalid character on import Message-ID: <20090713090110.GA20996@ikn.schottelius.org> Hello! I'm trying to import my current maildir into sup, but it fails with the following error: -------------------------------------------------------------------------------- [Mon Jul 13 09:33:17 +0200 2009] scanning maildir /home/spieler/Maildir/INBOX... [Mon Jul 13 09:33:17 +0200 2009] no poll on cur. mtime on indicates no new messages. [Mon Jul 13 09:33:17 +0200 2009] no poll on new. mtime on indicates no new messages. [Mon Jul 13 09:33:18 +0200 2009] done scanning maildir ## read 13228m (about 84%) @ 6.1m/s. 0:36:04 elapsed, about 0:06:49 remaining ## read 13306m (about 84%) @ 6.1m/s. 0:36:19 elapsed, about 0:06:48 remaining [Mon Jul 13 09:33:34 +0200 2009] unlocking /home/spieler/.sup/lock... /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:647:in `iconv': " " (Iconv::InvalidCharacter) from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:647:in `easy_decode' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/message.rb:430:in `message_to_chunks' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/message.rb:209:in `load_from_source!' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/poll.rb:151:in `add_messages_from' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:130:in `each' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:127:in `upto' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/maildir.rb:127:in `each' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `send' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:140 from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:135:in `each' from /home/spieler/.gem/ruby/1.8/gems/sup-0.8.1/bin/sup-sync:135 from /home/spieler/.gem/ruby/1.8/bin/sup-sync:19:in `load' from /home/spieler/.gem/ruby/1.8/bin/sup-sync:19 -------------------------------------------------------------------------------- Any idea what's wrong here? sup's installed via gem install. Nico From nico-sup@schottelius.org Mon Jul 13 05:15:16 2009 From: nico-sup@schottelius.org (Nico Schottelius) Date: Mon, 13 Jul 2009 11:15:16 +0200 Subject: [sup-talk] Slow import of messages Message-ID: <20090713091516.GA21214@ikn.schottelius.org> Hello! I'm looking at sup as a replacement for mutt. Following the idea of sup, I took a snapshot of my Mails from 2008-2009 (~56k mails) and run sup-sync --all-sources Now the problem is that sup gets about 3 mails per second into its index. That means it takes about 56k/3 ~= 15k; 15000/60 = 250 minutes That import is already from a local Maildir (synced with offlineimap). For me, this is incredibly slow. Using mutt it's way faster, not even comparing the fact the speed improvement you get when dividing into folders. What's your impression? Am I totally wrong or is sup just the wrong tool for handling a lot of messages? Sincerly, Nico From michael+sup@stapelberg.de Mon Jul 13 05:26:14 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Mon, 13 Jul 2009 11:26:14 +0200 Subject: [sup-talk] Slow import of messages In-Reply-To: <20090713091516.GA21214@ikn.schottelius.org> References: <20090713091516.GA21214@ikn.schottelius.org> Message-ID: <1247477044-sup-6433@midna> Hi Nico, Excerpts from Nico Schottelius's message of Mo Jul 13 11:15:16 +0200 2009: > I'm looking at sup as a replacement for mutt. > Following the idea of sup, I took a snapshot of > my Mails from 2008-2009 (~56k mails) and run I have about 33k emails on my IMAP server in my LAN. > Now the problem is that sup gets about 3 mails per > second into its index. That means it takes about I got around 10 MB/s performance using sup-sync. Maybe your mails are all very large, I don?t know. Maybe maildir is just a lot slower than IMAP in sup-sync. > What's your impression? Am I totally wrong or is sup just > the wrong tool for handling a lot of messages? My impression is that sup-sync can definitely be improved regarding its speed. I?m not sure if it is actually doable or if it is some ruby library (Ferret?) which is the limiting factor here. However, it was not as bad for me as it is for you ;-). Best regards, Michael From nicolas.pouillard@gmail.com Mon Jul 13 16:17:26 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 13 Jul 2009 22:17:26 +0200 Subject: [sup-talk] Invalid character on import In-Reply-To: <20090713090110.GA20996@ikn.schottelius.org> References: <20090713090110.GA20996@ikn.schottelius.org> Message-ID: <1247516120-sup-3116@ausone.local> Excerpts from Nico Schottelius's message of Mon Jul 13 11:01:10 +0200 2009: > Hello! Hello, > I'm trying to import my current maildir into sup, but > it fails with the following error: The fix is trivial, I've submitted a merge request for exactly this: http://gitorious.org/~ertai/sup/clone-by-ertai -- Nicolas Pouillard http://nicolaspouillard.fr From jim@gonzul.net Mon Jul 13 17:22:04 2009 From: jim@gonzul.net (Jim Cheetham) Date: Tue, 14 Jul 2009 09:22:04 +1200 Subject: [sup-talk] Slow import of messages In-Reply-To: <20090713091516.GA21214@ikn.schottelius.org> References: <20090713091516.GA21214@ikn.schottelius.org> Message-ID: On Mon, Jul 13, 2009 at 9:15 PM, Nico Schottelius wrote: > What's your impression? Am I totally wrong or is sup just > the wrong tool for handling a lot of messages? No, it's just slow to index for the first time. Unless you receive 1000s of messages per hour, you should be OK ... -jim From lcanas@libresoft.es Mon Jul 13 17:20:22 2009 From: lcanas@libresoft.es (Luis =?ISO-8859-1?Q?Ca=F1as_D=EDaz?=) Date: Mon, 13 Jul 2009 23:20:22 +0200 Subject: [sup-talk] problems with Maildir and IMAP offline Message-ID: <20090713232022.fe1d4839.lcanas@libresoft.es> Hi guys, first things first. Your mail client looks promising, I've been testing many of them (most of them from the kde/gnome world) and yours seems to be perfect to be running in my dear mac mini ;) This afternoon I've been trying to set up a gmail account with offlineimap and I'm having the same problem reported by this guy[1]. I run offlineimap and it creates a Maildir directory with 4hundred read mails and 2hundred unread mails (yes, I should pay more attention to my gmail account;). The problem is that sup sees all of the messages as unread which is not true according to the Maildir structure: [luis at gongbu INBOX]$ ls new/|wc -l;ls cur/|wc -l 210 412 After applying changes with sup, the state is the same. When using sup I "delete" messages and mark them as read. The sup version is: [luis at gongbu ~]$ sup -v [Mon Jul 13 23:14:25 +0200 2009] using character set encoding "UTF-8" sup v0.8.1 Last thing, I haven't seen it written by I guess it's a good idea having the files locally to use the search engine. Am I right? Thanks for your help! :) [1] http://osdir.com/ml/mail.sup.general/2008-08/msg00029.html -- Luis Ca?as D?az | GSyC/LibreSoft Research Lab http://libresoft.es | Grupo de Sistemas y Comunicaciones Tel: (+34) 91 488 85 23 | Universidad Rey Juan Carlos From garoth@gmail.com Tue Jul 14 09:24:32 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 14 Jul 2009 09:24:32 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <20090713232022.fe1d4839.lcanas@libresoft.es> References: <20090713232022.fe1d4839.lcanas@libresoft.es> Message-ID: <1247577490-sup-7098@Longbow> Excerpts from Luis Ca?as D?az's message of Mon Jul 13 17:20:22 -0400 2009: > After applying changes with sup, the state is the same. When using sup I > "delete" messages and mark them as read. I'm somewhat unhappy about this too. It seems to me that sup just plain does not support the read features of maildirs. a) It doesn't import them as read b) sup-sync-back does not mark them as read. The best I could find is manually marking things as read and deleting them, and then using sup-sync-back with the deleted options which it does understand. On the other hand, sup provides hooks to make calling offlineimap and sup-sync-back completely transparent and well-timed. You can call sup-sync-back followed by offlineimap on each sup poll, so that's pretty sweet. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From garoth@gmail.com Tue Jul 14 10:02:11 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 14 Jul 2009 10:02:11 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <20090714134544.GD90157@d228.scdc1.swarthmore.edu> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> Message-ID: <1247580020-sup-9946@Longbow> Excerpts from Tim Gray's message of Tue Jul 14 09:45:44 -0400 2009: > On Tue 14, Jul'09 at 9:24 AM -0400, Andrei Thorp wrote: > > > a) It doesn't import them as read > > b) sup-sync-back does not mark them as read. I'm forwarding a summary of your message with my replies to the mailing list. It seems like you replied to me only by accident? > From my playing around with sup and from what I've read, sup just doesn't > play nicely with other mail clients. Sup will read from your sources, but > the sources never get modified. Again, see sup-sync-back -- it does indeed have _some_ ability to write its state back to the source. > I know sup is slowly moving in the direction of a more locked in design. I > just wish sup added automatic sync back capabilities. Put this in a hook and it's automatic. That's the beauty of the hook/multiple binary design. > As far as OfflineIMAP goes, I didn't think I would do this, but I've been > running it in it's full curses mode with an auto refresh set. I'm not entirely sure why you want this. If you're worried about failures, do they really happen? If you want to see the log, aren't you already piping it? If you want notifications, you could hook them up to happen in your sup hook (the one I described before) rather trivially via notify-send. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From lists+sup@protozoic.com Tue Jul 14 11:00:34 2009 From: lists+sup@protozoic.com (Tim Gray) Date: Tue, 14 Jul 2009 11:00:34 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <1247580020-sup-9946@Longbow> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> <1247580020-sup-9946@Longbow> Message-ID: <20090714150034.GA393@d228.scdc1.swarthmore.edu> On Tue 14, Jul'09 at 10:02 AM -0400, Andrei Thorp wrote: > I'm forwarding a summary of your message with my replies to the mailing > list. It seems like you replied to me only by accident? Whoops. I didn't realize this list didn't have reply-to set. Thanks. > Again, see sup-sync-back -- it does indeed have _some_ ability to write > its state back to the source. To me, this is a vital feature of any mail client. I'll look into it, but I would really like this to be fully integrated into my mail client. And from I've read, this isn't something that's going to happen. Sometimes I need to use mutt/pine. Sometimes webmail. Most importantly, I want all my mail in a form that is easy to backup, human readable, and can be manipulated with standard utilities. Maildir fits the bill. I think it'd be fantastic if there was a mail client that allowed you to sort by folders, but also provided a sup-like view that laid on top if/when you needed. > Put this in a hook and it's automatic. That's the beauty of the > hook/multiple binary design. Honestly, if it's that easy, shouldn't it be configured like that out of the box? > I'm not entirely sure why you want this. If you're worried about > failures, do they really happen? If you want to see the log, aren't you > already piping it? If you want notifications, you could hook them up to > happen in your sup hook (the one I described before) rather trivially > via notify-send. For use with other mail clients for one. It's kind of nice having my IMAP syncing separate from the mail client. I'm sure I could run it automatically via cron, but then you'd have to give up the quick refresh capability (minor) and the IDLE mode. Sure, I could pipe the output somewhere else, but wouldn't that accomplish the same thing as just looking at the output already provided, either curses or one of the other ones? Again, it's running in screen so I don't even have it open on any windows. Of course, that doesn't mean this is the best route to go, but it's been working for me for so far - I am new to it though. It's a nice pretty colored interface too :) Tim From bwalton@artsci.utoronto.ca Tue Jul 14 11:07:46 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 14 Jul 2009 11:07:46 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <20090714150034.GA393@d228.scdc1.swarthmore.edu> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> <1247580020-sup-9946@Longbow> <20090714150034.GA393@d228.scdc1.swarthmore.edu> Message-ID: <1247584002-sup-504@ntdws12.chass.utoronto.ca> Excerpts from Tim Gray's message of Tue Jul 14 11:00:34 -0400 2009: > > Again, see sup-sync-back -- it does indeed have _some_ ability to write > > its state back to the source. > > To me, this is a vital feature of any mail client. I'll look into it, but I > would really like this to be fully integrated into my mail client. And from > I've read, this isn't something that's going to happen. There was some talk a while back about modifying the behaviour of Maildir sources. The issue was that there is an odd scanning bug with Maildir that sometimes sees messages get skipped. A proposed solution was to have sup start 'playing nice' with Maildir so that when new messages were found in new/, they'd be indexed and recorded with a filename in cur/, presumably with the S (seen) flag appended properly. I _think_ William was looking at that, but I'm not sure. It's something I'd like too (not to play nice with other clients, but because it's "just better"). I haven't had much time lately, but if William confirms he's not working on it, I'd be interested in implementing it. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From garoth@gmail.com Tue Jul 14 11:14:50 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 14 Jul 2009 11:14:50 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <20090714150034.GA393@d228.scdc1.swarthmore.edu> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> <1247580020-sup-9946@Longbow> <20090714150034.GA393@d228.scdc1.swarthmore.edu> Message-ID: <1247584404-sup-7126@Longbow> Excerpts from Tim Gray's message of Tue Jul 14 11:00:34 -0400 2009: > On Tue 14, Jul'09 at 10:02 AM -0400, Andrei Thorp wrote: > > Put this in a hook and it's automatic. That's the beauty of the > > hook/multiple binary design. > > Honestly, if it's that easy, shouldn't it be configured like that out of the > box? People perhaps don't want this. It's slower, and a lot of folks probably do no syncing back since all they use is sup anyway. > > I'm not entirely sure why you want this. If you're worried about > > failures, do they really happen? If you want to see the log, aren't you > > already piping it? If you want notifications, you could hook them up to > > happen in your sup hook (the one I described before) rather trivially > > via notify-send. > > For use with other mail clients for one. Understood. Makes sense in your use case. I don't really understand why you'd want to use pine/mutt when you've already got sup though ;) -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From lists+sup@protozoic.com Tue Jul 14 11:28:06 2009 From: lists+sup@protozoic.com (Tim Gray) Date: Tue, 14 Jul 2009 11:28:06 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <1247584002-sup-504@ntdws12.chass.utoronto.ca> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> <1247580020-sup-9946@Longbow> <20090714150034.GA393@d228.scdc1.swarthmore.edu> <1247584002-sup-504@ntdws12.chass.utoronto.ca> Message-ID: <20090714152806.GC393@d228.scdc1.swarthmore.edu> On Tue 14, Jul'09 at 11:07 AM -0400, Ben Walton wrote: > It's something I'd like too (not to play nice with other clients, but > because it's "just better"). This sound like a good thing. In my experience, 'just better' usually equals 'playing nice', since 'playing nice' usually equals following the standards. That's how Maildirs are supposed to work - if everybody followed the spec, we'd be set. Though I don't program for a living, nor do I know any Ruby, it seems like a doable thing. Is there something fundamental blocking per-message sync-back of status as you read/delete/otherwise modify your mail? I would assume there a reference to the original message location in a message's database entry. If a message gets read, write an S at the end of the filename and move it to /cur. If it gets deleted, delete it. Operations on a message should affect the database and the mail store at the same time. Why is something like sup-sync-back even necessary? Anyway, these are just the musings of someone who doesn't have the tools to write something like sup, so I'll be quiet now before I embarrass myself any further. From garoth@gmail.com Tue Jul 14 11:39:09 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 14 Jul 2009 11:39:09 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <20090714152806.GC393@d228.scdc1.swarthmore.edu> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> <1247580020-sup-9946@Longbow> <20090714150034.GA393@d228.scdc1.swarthmore.edu> <1247584002-sup-504@ntdws12.chass.utoronto.ca> <20090714152806.GC393@d228.scdc1.swarthmore.edu> Message-ID: <1247585761-sup-5167@Longbow> Excerpts from Tim Gray's message of Tue Jul 14 11:28:06 -0400 2009: > On Tue 14, Jul'09 at 11:07 AM -0400, Ben Walton wrote: > > It's something I'd like too (not to play nice with other clients, but > > because it's "just better"). > > This sound like a good thing. In my experience, 'just better' usually > equals 'playing nice', since 'playing nice' usually equals following the > standards. That's how Maildirs are supposed to work - if everybody followed > the spec, we'd be set. I'd just like to mention that the reason we tend not to sync back in general isn't because we hate standards and want people to get hurt :) It's roughly because of the extra features in sup: - It keeps a database so it can search for stuff quickly - It implements its own tagging regardless of source (unlike stuff like mutt that just rely on "physical" folders) - It merges sources So while it's possible to do some merging back, it's sometimes awkward because sup's tags do not have to map 1:1 to IMAP folders or anything else. It's otherwise also a bit awkward because we might have mail from many sources in one place, so writing back isn't as simple as just editing files. You also have to _not_ edit files. Anyway, that all said, it's clearly possible and would be very nice to have. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From lists+sup@protozoic.com Tue Jul 14 11:45:07 2009 From: lists+sup@protozoic.com (Tim Gray) Date: Tue, 14 Jul 2009 11:45:07 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <1247584404-sup-7126@Longbow> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> <1247580020-sup-9946@Longbow> <20090714150034.GA393@d228.scdc1.swarthmore.edu> <1247584404-sup-7126@Longbow> Message-ID: <20090714154507.GD393@d228.scdc1.swarthmore.edu> On Tue 14, Jul'09 at 11:14 AM -0400, Andrei Thorp wrote: > People perhaps don't want this. It's slower, and a lot of folks probably > do no syncing back since all they use is sup anyway. I would hope in this day in age we can change a database entry and move a file at the same time without too much of a performance hit. I would think it only gets unbearable when you don't update as you go and you have to do a large batch of messages. But you are right, maybe people don't want that. Personally, and this is a side note, if I was involved in the project, I'd push for canning the built in IMAP capabilities all together. Just run offlineimap or one of the other IMAP syncing utilities. Add to that beefing up the Maildir handling. Just worry about better and more transparent sync-back-to-Maildir capabilities and let offlineimap worry about the server side of the equation. > Understood. Makes sense in your use case. I don't really understand why > you'd want to use pine/mutt when you've already got sup though ;) As you can tell, I'm not quite sold on sup yet. I've switched mail clients enough over the past few years that switching in and of itself is a giant pain. I've settled on Maildir as my 'client' for now. I can serve it via IMAP if I need, I can read it with a couple mail clients, and I can easily convert it to mbox however I want to with some simple Python code. If I switch to sup full time, I would be comforted by the fact that if I choose to change in 2 years, all of my mail is marked read, deleted mail is actually deleted, and even though I was using sup labels for my organization, things are still organized in some fashion by appropriate folders on the file system. The last part could be achievable by some combination of offlineimap + gmail/sieve filtering and fetchmail/getmail + procmail. It'd still be nice to be able to move physical messages around in sup though. Maybe I'm just nuts though. From lists+sup@protozoic.com Tue Jul 14 11:59:16 2009 From: lists+sup@protozoic.com (Tim Gray) Date: Tue, 14 Jul 2009 11:59:16 -0400 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <1247585761-sup-5167@Longbow> References: <20090713232022.fe1d4839.lcanas@libresoft.es> <1247577490-sup-7098@Longbow> <20090714134544.GD90157@d228.scdc1.swarthmore.edu> <1247580020-sup-9946@Longbow> <20090714150034.GA393@d228.scdc1.swarthmore.edu> <1247584002-sup-504@ntdws12.chass.utoronto.ca> <20090714152806.GC393@d228.scdc1.swarthmore.edu> <1247585761-sup-5167@Longbow> Message-ID: <20090714155916.GE393@d228.scdc1.swarthmore.edu> On Tue 14, Jul'09 at 11:39 AM -0400, Andrei Thorp wrote: > I'd just like to mention that the reason we tend not to sync back in > general isn't because we hate standards and want people to get hurt :) Haha. Of course. > It's roughly because of the extra features in sup: I got you. Still, I envisage a mail client that has an underlying structure built on folders. On top of that a database/virtual folder interface is built. Of course, you'd have the ability to access the folder based structure when needed. So you could move a message or a conversation to a given folder if you want. For example, I have work emails for a certain project with a given label. It's wonderful that in sup, those currently in my physical inbox and those currently in an archive folder somewhere show up under the same label in sup. But there's no mechanism to moving those in my physical inbox to the archive folder. Some might say who cares, but I can't leave all my email in my physical inbox forever, which is synced by offlineimap, because people associated with this project have a nasty habit of sending 10-20 mb attachments and I don't want to clutter up my IMAP boxes with hundreds of megs of attachments forever. Heck, I can't do that unless I have an IMAP service with 25 gigs of storage.* Sometimes they just need to be collected in a totally offline box, but somewhere that is still accessible by searching if I need access to it. Sup is pretty close to this already, minus the access to the underlying structure. --- [*] Obviously for those of you using Gmail, this isn't an issue. Who cares about deleting messages? From isra@herraiz.org Tue Jul 14 12:21:45 2009 From: isra@herraiz.org (Israel Herraiz) Date: Tue, 14 Jul 2009 18:21:45 +0200 Subject: [sup-talk] problems with Maildir and IMAP offline In-Reply-To: <20090713232022.fe1d4839.lcanas@libresoft.es> References: <20090713232022.fe1d4839.lcanas@libresoft.es> Message-ID: <1247587742-sup-5619@elly> Excerpts from Luis's message on Jul 13, 2009 about 11 PM: > This afternoon I've been trying to set up a gmail account with offlineimap and > I'm having the same problem reported by this guy[1]. I run offlineimap and it > creates a Maildir directory with 4hundred read mails and 2hundred unread mails > (yes, I should pay more attention to my gmail account;). I have not used IMAP with Sup, but AFAIK, Sup does not touch the original sources of email. For instance, it does not read nor modify messages using IMAP, it just read them using that protocol (or maildir or whatever). Therefore, the only way to get those messages marked as read is using sup-sync with the --read option. That will mark the messages as read in Sup. However there are two problems. If all the messages (unread or read) are in the same source, there is no way to indicate which messages are going to be marked as read and which are not. Moreover, if you read a message in Sup, it still will appear in Gmail as unread. I also use Gmail with Sup, but using POP. I use the web interface of Gmail when I cannnot access my laptop. I use IMAP from my mobile phone. And I download all my email to my laptop using POP. If I get a message in my laptop, it is marked as archived and read in GMail, so it does not appear as unread in the web nor in my phone. However, if I read the message in the phone or the web, it will appear as unread in Sup. Still it is a good solution if you have a "central" node where you store your mail, and do your main work (my laptop), and a couple of "external" agents (phone, web) to be able of reading your email if you do not have your laptop at hand. Another advantage is that you keep a copy of your mail in your laptop. GMail is not going to last forever (of course, it still has a long live) and with this you ensure that you will not loose your old-email in GMail is closed some day, and it is also very handy to make backups of all your email (just copy the mbox file to another location). To get the email I use getmail [1], and msmtp [2] with these scripts [3] (see last section) as a lightweight replacement for sendmail. I can provide you my config scripts if you want. It is not a good solution though if you read your email from several different computers. Cheers, Israel [1] http://pyropus.ca/software/getmail/ [2] http://msmtp.sourceforge.net/ [3] http://wiki.archlinux.org/index.php/Msmtp From johnbent@lanl.gov Tue Jul 14 11:43:01 2009 From: johnbent@lanl.gov (John Bent) Date: Tue, 14 Jul 2009 09:43:01 -0600 Subject: [sup-talk] Using sup on multiple computers? In-Reply-To: <1247186181-sup-1712@x200> References: <1247186181-sup-1712@x200> Message-ID: <1247585908-sup-4190@tangerine.lanl.gov> Excerpts from Michael Stapelberg's message of Thu Jul 09 18:38:25 -0600 2009: > Hi, > > I?d like to use sup on my notebook and on my workstation. Is there any > simple/recommended way to synchronize the index? I figured using > multiple clients in parallel is one of the big advantages of IMAP and > I?d love to keep it that way while using sup. > This won't really answer your exact question but I also use sup on a workstation and a notebook. What I do is run sup in a screen session on the workstation and then connect to it from the laptop. The window size is different on the workstation and the laptop so whenever I switch, I have to do: F : to get screen to resize @ : to get sup to redraw itself Hope that helps, John > Best regards, > Michael From bwalton@artsci.utoronto.ca Tue Jul 14 15:33:36 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 14 Jul 2009 15:33:36 -0400 Subject: [sup-talk] Using sup on multiple computers? In-Reply-To: <1247585908-sup-4190@tangerine.lanl.gov> References: <1247186181-sup-1712@x200> <1247585908-sup-4190@tangerine.lanl.gov> Message-ID: <1247599899-sup-811@ntdws12.chass.utoronto.ca> Excerpts from John Bent's message of Tue Jul 14 11:43:01 -0400 2009: > @ : to get sup to redraw itself Try Ctrl+L for the redraw. Saves having sup do any work at all. This is also good for when the display gets corrupted in screen. It's a pretty standard sequence too, so you may find it applicable elsewhere (eg: it'll clear your terminal for you, redraw and centre a buffer in emacs, etc). HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From michael+sup@stapelberg.de Tue Jul 14 15:35:12 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Tue, 14 Jul 2009 21:35:12 +0200 Subject: [sup-talk] Using sup on multiple computers? In-Reply-To: <1247585908-sup-4190@tangerine.lanl.gov> References: <1247186181-sup-1712@x200> <1247585908-sup-4190@tangerine.lanl.gov> Message-ID: <1247600011-sup-635@midna> Hi John, Excerpts from John Bent's message of Di Jul 14 17:43:01 +0200 2009: > F : to get screen to resize > @ : to get sup to redraw itself > Hope that helps, Thanks, that?s at least a good start to get where I was with mutt. However, it does not solve the other problems (GUI traffic/latency vs. IMAP, opening/adding attachments). Best regards, Michael From rgh@roughage.com.au Fri Jul 17 19:42:07 2009 From: rgh@roughage.com.au (Richard Heycock) Date: Sat, 18 Jul 2009 09:42:07 +1000 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1246022094-sup-3336@entry> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> Message-ID: <1247873980-sup-8574@wrasse> Excerpts from William Morgan's message of Fri Jun 26 23:49:40 +1000 2009: > Reformatted excerpts from Olly Betts's message of 2009-06-25: > > I'll make sure this fix makes it into the next Xapian release (which > > will be 1.0.14). > > Awesome, thanks! > > Though even with SWIG fixed there will still be some tweaking necessary > in Sup because the logistic function used for generating Xapian docids > still has trouble with extreme dates. > > BTW, more kudos to Rich for somehow finding a way to use a logistic > function in an email client. I've been meaning to respond to this the day this was posted. Rich Lane thank you, thank you. Ferret was one of by biggest gripes of using sup. I've used it elsewhere and it's a shocker; I eventually migrated it all to Xapian which has worked flawlessly since. I used to rebuild by ferret index almost on a weekly basis (I'm running debian unstable, which at the moment is really living up to it's name) at one stage something I haven't had to do once since migrating to Xapian. I got it work with 1.9 once but there are some problems that I just haven't had the time to look into but I will do and post any problems to the list. rgh From lee@yun.yagibdah.de Sat Jul 18 03:41:51 2009 From: lee@yun.yagibdah.de (lee) Date: Sat, 18 Jul 2009 01:41:51 -0600 Subject: [sup-talk] trying out sup ... Message-ID: <20090718074151.GF30748@cat.rubenette.is-a-geek.com> Hi, I've started trying out sup on Debian Testing amd64. Searching didn't work, so I installed a replacement library[1] after finding a bug report[2]. Now the search would work, but when I'm trying to enter something to search for or only press enter to see a list of labels I used, no matches are found, and the status line shows some garbage characters as string that has been searched for. This happens when sup is running in an xterm or in rxvt; it doesn't happen when I switch to the console and run sup there. So I had sup running on the console and tried out to search for something while sup was looking for new messages in a maildir. But then it crashed and told me I should send a bug report[3]. Maybe I have created some incompatibilities by installing the replacement library. But is it currently possible to run sup on Debian Testing without too much difficulty? If so, what do I need to do? [1]: http://apt.rupamsunyata.org/sup/libncurses-ruby1.8_1.2.3-0.2_amd64.deb [2]: http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/d79896cacc28e0e8/7a76dece1e5ef6a3?lnk=raot [3]: ~/.sup/exception-log.txt: --- NoMethodError from thread: poll after loading inbox undefined method `content_width' for nil:NilClass /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:747:in `from_width' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:672:in `text_for_thread_at' /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `each' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `each_with_index' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:671:in `text_for_thread_at' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:632:in `regen_text' /usr/lib/ruby/1.8/sup/util.rb:344:in `map_with_index' /usr/lib/ruby/1.8/sup/hook.rb:134:in `each_with_index' /usr/lib/ruby/1.8/sup/util.rb:344:in `each' /usr/lib/ruby/1.8/sup/util.rb:344:in `each_with_index' /usr/lib/ruby/1.8/sup/util.rb:344:in `map_with_index' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:632:in `regen_text' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:219:in `update' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:576:in `add_or_unhide' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:181:in `handle_added_update' /usr/lib/ruby/1.8/sup/update.rb:27:in `send' /usr/lib/ruby/1.8/sup/update.rb:27:in `relay' /usr/lib/ruby/1.8/sup/update.rb:27:in `each' /usr/lib/ruby/1.8/sup/update.rb:27:in `relay' /usr/lib/ruby/1.8/sup/util.rb:499:in `send' /usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing' /usr/lib/ruby/1.8/sup/poll.rb:161:in `add_messages_from' /usr/lib/ruby/1.8/sup/maildir.rb:130:in `each' /usr/lib/ruby/1.8/sup/maildir.rb:127:in `upto' /usr/lib/ruby/1.8/sup/maildir.rb:127:in `each' /usr/lib/ruby/1.8/sup/util.rb:538:in `send' /usr/lib/ruby/1.8/sup/util.rb:538:in `__pass' /usr/lib/ruby/1.8/sup/util.rb:525:in `method_missing' /usr/lib/ruby/1.8/sup/poll.rb:141:in `add_messages_from' /usr/lib/ruby/1.8/sup/poll.rb:98:in `do_poll' /usr/lib/ruby/1.8/sup/poll.rb:86:in `each' /usr/lib/ruby/1.8/sup/poll.rb:86:in `do_poll' /usr/lib/ruby/1.8/sup/poll.rb:85:in `synchronize' /usr/lib/ruby/1.8/sup/poll.rb:85:in `do_poll' /usr/lib/ruby/1.8/sup/util.rb:499:in `send' /usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing' /usr/lib/ruby/1.8/sup/modes/poll-mode.rb:17:in `poll' /usr/lib/ruby/1.8/sup/poll.rb:53:in `poll' /usr/lib/ruby/1.8/sup/util.rb:499:in `send' /usr/lib/ruby/1.8/sup/util.rb:499:in `method_missing' /usr/bin/sup-mail:173 /usr/lib/ruby/1.8/sup.rb:84:in `reporting_thread' /usr/lib/ruby/1.8/sup.rb:82:in `initialize' /usr/lib/ruby/1.8/sup.rb:82:in `new' /usr/lib/ruby/1.8/sup.rb:82:in `reporting_thread' /usr/bin/sup-mail:173 /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:543:in `call' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:543:in `__unprotected_load_threads' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:485:in `call' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:485:in `load_n_threads_background' /usr/lib/ruby/1.8/sup.rb:84:in `reporting_thread' /usr/lib/ruby/1.8/sup.rb:82:in `initialize' /usr/lib/ruby/1.8/sup.rb:82:in `new' /usr/lib/ruby/1.8/sup.rb:82:in `reporting_thread' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:483:in `load_n_threads_background' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:553:in `__unprotected_load_threads' (eval):12:in `load_threads' /usr/bin/sup-mail:173 From michael+sup@stapelberg.de Mon Jul 20 08:34:56 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Mon, 20 Jul 2009 14:34:56 +0200 Subject: [sup-talk] [PATCH] GSSAPI support for net/imap.rb and sup Message-ID: <1248092732-sup-9960@midna> Hi, since I installed my new mailserver with Kerberos auth only, I needed to implement GSSAPI support for Net::IMAP and sup. I found the C bindings called ruby-gss at: http://devel.it.su.se/pub/jsp/polopoly.jsp?d=1047&a=3790 Using them (and adding the wrap/unwrap methods for a context, see 03-ruby-gss.patch), it was relatively easy to implement GSSAPIAuthenticator (see 02-net_imap-gssapi.patch). The addition of the authenticator to sup is trivial (see 01-sup_gssapi.patch). Here comes the catch: As I?m not very much involved in the ruby community (in fact, this is my first piece of ruby code), I need someone to help me get things upstream (for Net::IMAP in the first place, but someone maintaining ruby-gss would be great). As for the sup patch, I think this already is the right place to post it ;-). Short installation instructions for those not so familiar with ruby: $ cd ruby-gss $ ruby extconf.rb $ make $ sudo make install # patch /usr/lib/ruby/1.8/net/imap.rb # patch /usr/lib/ruby/1.8/sup/imap.rb Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 01-sup_gssapi.patch Type: application/octet-stream Size: 1936 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 02-net_imap_gssapi.patch Type: application/octet-stream Size: 2373 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 03-ruby-gss.patch Type: application/octet-stream Size: 2891 bytes Desc: not available URL: From sgoldman@tower-research.com Wed Jul 22 21:10:41 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Wed, 22 Jul 2009 21:10:41 -0400 Subject: [sup-talk] Choose "From:" address based on message content? Message-ID: <1248311332-sup-1053@sgoldmanlinux.tower-research.com> Here's what I want: After I compose an email (new or a reply), I want sup to grep the entire message (recipients, subject, body, etc.) for a single word and choose address A if that word is there and address B otherwise. Can sup do 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 sgoldman@tower-research.com Wed Jul 22 22:51:54 2009 From: sgoldman@tower-research.com (Steve Goldman) Date: Wed, 22 Jul 2009 22:51:54 -0400 Subject: [sup-talk] Choose "From:" address based on message content? In-Reply-To: <1248311332-sup-1053@sgoldmanlinux.tower-research.com> References: <1248311332-sup-1053@sgoldmanlinux.tower-research.com> Message-ID: <1248317360-sup-4094@sgoldmanlinux.tower-research.com> Excerpts from Steve Goldman's message of Wed Jul 22 21:10:41 -0400 2009: > > Here's what I want: > > After I compose an email (new or a reply), I want sup to grep the > entire message (recipients, subject, body, etc.) for a single word and > choose address A if that word is there and address B otherwise. > > Can sup do it? > > Thanks. > I think I answered my own question. I added an "after-edit" hook call in edit-message-mode.rb and wrote a hook that looks like this: require 'eregex' r = Regexp.new('word', Regexp::IGNORECASE); if header.to_s.grep(r).size > 0 or body.to_s.grep(r).size > 0 header["From"] = "Steve Goldman " end -- 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 dato@net.com.org.es Thu Jul 23 05:35:43 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Thu, 23 Jul 2009 11:35:43 +0200 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> Message-ID: <20090723093543.GA2265@chistera.yi.org> + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200): > + :charset => encoded_content.charset, Hm, so apparently encoded_content doesn't always have a charset member... -- - Are you sure we're good? - Always. -- Rory and Lorelai From dato@net.com.org.es Thu Jul 23 06:23:25 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Thu, 23 Jul 2009 12:23:25 +0200 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1247873980-sup-8574@wrasse> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> Message-ID: <20090723102325.GA4291@chistera.yi.org> + Richard Heycock (Sat, 18 Jul 2009 09:42:07 +1000): > I've been meaning to respond to this the day this was posted. Rich Lane > thank you, thank you. Ferret was one of by biggest gripes of using sup. > I've used it elsewhere and it's a shocker; I eventually migrated it all > to Xapian which has worked flawlessly since. I used to rebuild by ferret > index almost on a weekly basis (I'm running debian unstable, which at > the moment is really living up to it's name) at one stage something I > haven't had to do once since migrating to Xapian. Yeah, thanks Rich! However, there seems to be something wrong with the parsing of contacts. After reindexing with Xapian, my contact list has entries like: --- Hello, this is just a RFC, because I can't think of any elegant way to address the issue, given the shortcomings of the RMail API. Please read the lengthy comment in the patch, and let me know if anybody has any ideas about this issue. P.S.: I've created a "sup-dato" repository in Gitorious, in case that's helpful. Should I be creating merge requests? lib/sup/crypto.rb | 19 ++++++++++++++++++- 1 files changed, 18 insertions(+), 1 deletions(-) diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb index 8ec277b..6ef0c0e 100644 --- a/lib/sup/crypto.rb +++ b/lib/sup/crypto.rb @@ -132,8 +132,25 @@ class CryptoManager end end + # This is gross. The decrypted payload could very well be a multipart + # element itself, as opposed to a simple payload; for example, a + # multipart/signed element, like Mutt does when encrypting and signing a + # message (instead of clearsigning it). Supposedly, decrypted_payload + # being a multipart element ought to work out nicely because in + # Message::multipart_encrypted_to_chunks() the decrypted message is run + # though message_to_chunks() again to get any children. However, it does + # not work as intended because this inner payload need not carry a + # MIME-Version header, yet they are fed to RMail as a top-level message, + # for which the MIME-Version header is required, which causes for the + # part not to be detected as multipart. If we detect this is happening, + # force the payload to be interpreted as MIME. + msg = RMail::Parser.read(decrypted_payload) + if msg.header.content_type =~ %r{^multipart/} and not msg.multipart? + decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload + msg = RMail::Parser.read(decrypted_payload) + end notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display" - [RMail::Parser.read(decrypted_payload), sig, notice] + [msg, sig, notice] else notice = Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n") [nil, nil, notice] -- 1.6.3.3 From dato@net.com.org.es Thu Jul 23 13:19:51 2009 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=) Date: Thu, 23 Jul 2009 19:19:51 +0200 Subject: [sup-talk] [PATCH] Fix parsing of encrypted messages that contain further multipart elements In-Reply-To: References: Message-ID: <6fd87965a2e243b190678edb6c4b9cefbde9ae66.1248369563.git.dato@net.com.org.es> --- Amended patch follows, with a better wording that I had seemingly not committed. Sorry for the noise. lib/sup/crypto.rb | 20 +++++++++++++++++++- 1 files changed, 19 insertions(+), 1 deletions(-) diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb index 8ec277b..acbc1d8 100644 --- a/lib/sup/crypto.rb +++ b/lib/sup/crypto.rb @@ -132,8 +132,26 @@ class CryptoManager end end + # This is gross. This decrypted payload could very well be a multipart + # element itself, as opposed to a simple payload. For example, a + # multipart/signed element, like those generated by Mutt when encrypting + # and signing a message (instead of just clearsigning the body). + # Supposedly, decrypted_payload being a multipart element ought to work + # out nicely because Message::multipart_encrypted_to_chunks() runs the + # decrypted message through message_to_chunks() again to get any + # children. However, it does not work as intended because these inner + # payloads need not carry a MIME-Version header, yet they are fed to + # RMail as a top-level message, for which the MIME-Version header is + # required. This causes for the part not to be detected as multipart, + # hence being shown as an attachment. If we detect this is happening, + # we force the decrypted payload to be interpreted as MIME. + msg = RMail::Parser.read(decrypted_payload) + if msg.header.content_type =~ %r{^multipart/} and not msg.multipart? + decrypted_payload = "MIME-Version: 1.0\n" + decrypted_payload + msg = RMail::Parser.read(decrypted_payload) + end notice = Chunk::CryptoNotice.new :valid, "This message has been decrypted for display" - [RMail::Parser.read(decrypted_payload), sig, notice] + [msg, sig, notice] else notice = Chunk::CryptoNotice.new :invalid, "This message could not be decrypted", output.split("\n") [nil, nil, notice] -- 1.6.3.3 From marco-oweber@gmx.de Fri Jul 24 12:35:15 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Fri, 24 Jul 2009 18:35:15 +0200 Subject: [sup-talk] Exception Message-ID: <1248453259-sup-3604@nixos> Hi, when either running sup-sync or sup (without -n) I get this exception: --- NoMethodError from thread: poll after loading inbox undefined method `to_indexable_s' for nil:NilClass /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/index.rb:244:in `sync_message' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:161:in `add_messages_from' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/source.rb:100:in `each' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `send' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:98:in `do_poll' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:86:in `each' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:86:in `do_poll' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:85:in `synchronize' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:85:in `do_poll' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/poll-mode.rb:17:in `poll' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:53:in `poll' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `initialize' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `new' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread' /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:663:in `call' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:663:in `__unprotected_load_threads' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:605:in `call' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:605:in `load_n_threads_background' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:71:in `reporting_thread' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `initialize' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `new' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup.rb:69:in `reporting_thread' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads' (eval):12:in `load_threads' /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup:206 /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-wrapped:19:in `load' /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-wrapped:19 Do you see what's happening here or shall I start debugging? The sup-sync exception trace looks like this: /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/index.rb:244:in `sync_message': undefined method `to_indexable_s' for nil:NilClass (NoMethodError) from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:161:in `add_messages_from' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/source.rb:100:in `each' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `send' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:552:in `__pass' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:539:in `method_missing' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/poll.rb:141:in `add_messages_from' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `send' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/gems/sup-0.8.1/lib/sup/util.rb:513:in `method_missing' from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:140 from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:135:in `each' from /home/marc/.nix-profile/gems/sup-0.8.1/bin/sup-sync:135 from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-sync-wrapped:19:in `load' from /nix/store/cg3g3wyz2bibk8zc5ykhdyr2a166x87l-sup-0.8.1/bin/.sup-sync-wrapped:19 Marc Weber From rlane@club.cc.cmu.edu Fri Jul 24 22:50:54 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 24 Jul 2009 19:50:54 -0700 Subject: [sup-talk] [PATCH] xapian: initialize sources in sup-dump Message-ID: <1248490254-31895-1-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup-dump | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/bin/sup-dump b/bin/sup-dump index 9b0892e..c18a767 100755 --- a/bin/sup-dump +++ b/bin/sup-dump @@ -22,6 +22,7 @@ EOS end index = Redwood::Index.new +Redwood::SourceManager.new index.load index.each_message do |m| -- 1.6.0.4 From rlane@club.cc.cmu.edu Fri Jul 24 23:25:09 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 24 Jul 2009 20:25:09 -0700 Subject: [sup-talk] [PATCH] xapian: fix mk_addrs args in build_message Message-ID: <1248492309-1980-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index d064ffc..23af431 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -68,9 +68,9 @@ class XapianIndex < BaseIndex 'date' => Time.at(entry[:date]), 'subject' => entry[:subject], 'from' => mk_addrs[[entry[:from]]], - 'to' => mk_addrs[[entry[:to]]], - 'cc' => mk_addrs[[entry[:cc]]], - 'bcc' => mk_addrs[[entry[:bcc]]], + 'to' => mk_addrs[entry[:to]], + 'cc' => mk_addrs[entry[:cc]], + 'bcc' => mk_addrs[entry[:bcc]], 'reply-tos' => mk_refs[entry[:replytos]], 'references' => mk_refs[entry[:refs]], } -- 1.6.0.4 From rlane@club.cc.cmu.edu Sat Jul 25 00:53:07 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 25 Jul 2009 00:53:07 -0400 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <20090723102325.GA4291@chistera.yi.org> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> Message-ID: <1248497184-sup-939@pion.club.cc.cmu.edu> > Yeah, thanks Rich! However, there seems to be something wrong with the > parsing of contacts. After reindexing with Xapian, my contact list has > entries like: > > dato at net.com.org.esAdeodato Simo other2 at domain.netother2 surname2 Thanks for the bug report, I've posted a patch (fix-mk_addrs-args) to fix this. You shouldn't need to reindex after applying the patch. > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an > inspection of the code, it doesn't look to me as random negated labels > are being parsed. > > Any hints? You need to specify a non-negated term in the query. "type:mail -label:inbox" should work. From dato@net.com.org.es Sat Jul 25 05:21:16 2009 From: dato@net.com.org.es (=?utf-8?q?Adeodato_Sim=C3=B3?=) Date: Sat, 25 Jul 2009 11:21:16 +0200 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248497184-sup-939@pion.club.cc.cmu.edu> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> Message-ID: <1248513425-sup-2484@chistera.yi.org> + Rich Lane (Sat, 25 Jul 2009 06:53:07 +0200): > Thanks for the bug report, I've posted a patch (fix-mk_addrs-args) to > fix this. You shouldn't need to reindex after applying the patch. Great, thanks. The patch indeed fixes the issue. > > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an > > inspection of the code, it doesn't look to me as random negated labels > > are being parsed. > > Any hints? > You need to specify a non-negated term in the query. > "type:mail -label:inbox" should work. Oh, I see. Yes, that works, thanks. One extra issue I just noticed: after dumping with ferret, reloading into Xapian, and doing a dump again (with Xapian this time), all the messages tagged "deleted" or "spam" do not appear in the dump at all. Any ideas? -- - Are you sure we're good? - Always. -- Rory and Lorelai From ezyang@MIT.EDU Sat Jul 25 14:10:54 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 25 Jul 2009 14:10:54 -0400 Subject: [sup-talk] Reply calculation Message-ID: <1248545266-sup-6886@javelin> I think sup's "To" address calculation algorithm is wrong, and messes up in some important edge-cases. The two edge cases I have in mind are: * When a mailing list sends an unsubscribe/subscribe notification * When someone posts to a mailing list with an explicit Reply-to header. In both of these cases, the mail will commonly have an explicit Reply-to header. However, Sup will by default disregard this header in favor for List-id, which is *wrong*. You can guess, this has bitten me several times. I think the correct behavior is to only use List-id when Reply-to is not explicitly set, since List-id is "magical" whereas Reply-to is commonly explicit. Cheers, Edward From ezyang@MIT.EDU Sat Jul 25 14:24:15 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 25 Jul 2009 14:24:15 -0400 Subject: [sup-talk] Reply calculation In-Reply-To: <1248545266-sup-6886@javelin> References: <1248545266-sup-6886@javelin> Message-ID: <1248546228-sup-9505@javelin> Here is a patch that changes the behavior: >From 58a8d325286703f9057dd5d07094d0c6a061377c Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Sat, 25 Jul 2009 14:17:08 -0400 Subject: [PATCH] Use Reply-to if it is explicitly set. Previously, Sup would ignore an explicit Reply-to in favor of List-id. This is the wrong behavior for the following cases: * List subscribe and unsubscribe messages will commonly have List-id set, but set Reply-to for their own nefarious purposes (the "you should be able to reply to this email and have it work") * People will sometimes send mail to a list with an explicit Reply-to header to get responses offlist. This brings Sup's behavior more inline with traditional mail clients. Since most lists already set Reply-to (and most mail clients don't respect List-id), there will probably be no breakage. Signed-off-by: Edward Z. Yang --- lib/sup/modes/reply-mode.rb | 8 +++----- 1 files changed, 3 insertions(+), 5 deletions(-) diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb index c79c5db..ca423c1 100644 --- a/lib/sup/modes/reply-mode.rb +++ b/lib/sup/modes/reply-mode.rb @@ -81,10 +81,8 @@ EOS AccountManager.default_account end - ## now, determine to: and cc: addressess. we ignore reply-to for list - ## messages because it's typically set to the list address, which we - ## explicitly treat with reply type :list - to = @m.is_list_message? ? @m.from : (@m.replyto || @m.from) + ## if someone overrode reply-to, it was for a good reason + to = (@m.replyto || @m.from) ## next, cc: cc = (@m.to + @m.cc - [from, to]).uniq @@ -115,7 +113,7 @@ EOS } unless not_me_ccs.empty? @headers[:list] = { - "To" => [@m.list_address.full_address], + "To" => [@m.replyto.full_address || @m.list_address.full_address], } if @m.is_list_message? refs = gen_references -- 1.6.3.3 From ezyang@MIT.EDU Sat Jul 25 15:03:31 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 25 Jul 2009 15:03:31 -0400 Subject: [sup-talk] Reply calculation In-Reply-To: <1248546228-sup-9505@javelin> References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin> Message-ID: <1248548497-sup-1158@javelin> Excerpts from Edward Z. Yang's message of Sat Jul 25 14:24:15 -0400 2009: > Here is a patch that changes the behavior: Actually, the patch is not quite correct. Let me think about this some more. Cheers, Edward From ezyang@MIT.EDU Sat Jul 25 15:15:59 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 25 Jul 2009 15:15:59 -0400 Subject: [sup-talk] Reply calculation In-Reply-To: <1248548497-sup-1158@javelin> References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin> <1248548497-sup-1158@javelin> Message-ID: <1248549271-sup-3371@javelin> After thinking about this some, I think that the only way to reasonably handle all corner cases is to explicitly ask the user for a choice in corner cases. Having the default subtly change based on some non-obvious attributes of an email is a great way to break muscle memory. Myself, I have :user in my reply-to.rb hook for now. Cheers, Edward From rlane@club.cc.cmu.edu Sat Jul 25 15:27:08 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 25 Jul 2009 12:27:08 -0700 Subject: [sup-talk] [PATCH] xapian: dont exclude spam/etc in some internal searches Message-ID: <1248550028-9703-1-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup-dump | 2 +- bin/sup-sync | 2 +- bin/sup-sync-back | 2 +- bin/sup-tweak-labels | 1 + 4 files changed, 4 insertions(+), 3 deletions(-) diff --git a/bin/sup-dump b/bin/sup-dump index c18a767..ba36b21 100755 --- a/bin/sup-dump +++ b/bin/sup-dump @@ -25,6 +25,6 @@ index = Redwood::Index.new Redwood::SourceManager.new index.load -index.each_message do |m| +index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m| puts "#{m.id} (#{m.labels * ' '})" end diff --git a/bin/sup-sync b/bin/sup-sync index 270524a..8e37c74 100755 --- a/bin/sup-sync +++ b/bin/sup-sync @@ -213,7 +213,7 @@ begin num_del, num_scanned = 0, 0 sources.each do |source| raise "no source id for #{source}" unless source.id - index.each_message :source_id => source.id do |m| + index.each_message :source_id => source.id, :load_spam => true, :load_deleted => true, :load_killed => true do |m| num_scanned += 1 unless seen[m.id] next unless m.source_info >= opts[:start_at] if opts[:start_at] diff --git a/bin/sup-sync-back b/bin/sup-sync-back index da94bbd..56ac4eb 100755 --- a/bin/sup-sync-back +++ b/bin/sup-sync-back @@ -16,7 +16,7 @@ def die msg exit(-1) end def has_any_from_source_with_label? index, source, label - query = { :source_id => source.id, :label => label, :limit => 1 } + query = { :source_id => source.id, :label => label, :limit => 1, :load_spam => true, :load_deleted => true, :load_killed => true } not Enumerable::Enumerator.new(index, :each_id, query).map.empty? end diff --git a/bin/sup-tweak-labels b/bin/sup-tweak-labels index a8115ea..8ae5c26 100755 --- a/bin/sup-tweak-labels +++ b/bin/sup-tweak-labels @@ -83,6 +83,7 @@ begin query += ' ' + opts[:query] if opts[:query] parsed_query = index.parse_query query + parsed_query.merge! :load_spam => true, :load_deleted => true, :load_killed => true ids = Enumerable::Enumerator.new(index, :each_id, parsed_query).map num_total = ids.size -- 1.6.0.4 From rlane@club.cc.cmu.edu Sat Jul 25 15:59:19 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 25 Jul 2009 15:59:19 -0400 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248513425-sup-2484@chistera.yi.org> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> Message-ID: <1248550384-sup-74@pion.club.cc.cmu.edu> Excerpts from Adeodato Sim?'s message of Sat Jul 25 05:21:16 -0400 2009: > One extra issue I just noticed: after dumping with ferret, reloading > into Xapian, and doing a dump again (with Xapian this time), all the > messages tagged "deleted" or "spam" do not appear in the dump at all. > Any ideas? The patch "xapian: dont exclude spam..." should fix this. One issue I've noticed is that removing labels from messages doesn't always immediately work. For example, label-list-mode shows a label as having some unread messages even though all of them are actually read. This tends to happen only after sup's been running for a while and restarting sup fixes it. From ingmar@exherbo.org Sat Jul 25 19:28:16 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Sun, 26 Jul 2009 01:28:16 +0200 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248550384-sup-74@pion.club.cc.cmu.edu> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> Message-ID: <1248564412-sup-7548@cannonball> Excerpts from Rich Lane's message of Sat Jul 25 21:59:19 +0200 2009: > One issue I've noticed is that removing labels from messages doesn't > always immediately work. For example, label-list-mode shows a label as > having some unread messages even though all of them are actually read. > This tends to happen only after sup's been running for a while and > restarting sup fixes it. I was just about to report that. :) Besides that, the Xapian index works very nicely. So I'd be happy to see it in next when that last regression (as far as my testing showed them) is fixed! -- Exherbo KDE, X.org maintainer From wmorgan-sup@masanjin.net Mon Jul 27 11:46:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 08:46:21 -0700 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248497184-sup-939@pion.club.cc.cmu.edu> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> Message-ID: <1248709366-sup-5856@entry> Reformatted excerpts from Rich Lane's message of 2009-07-24: > > Plus, nor '!label:inbox' or '-label:inbox' work for me. From an > > inspection of the code, it doesn't look to me as random negated > > labels are being parsed. > > > > Any hints? > > You need to specify a non-negated term in the query. "type:mail > -label:inbox" should work. This is a typical restriction for inverted index-based search engines. You need to have at least one positive term or the computation is too expensive (it would have to iterate over every term ever seen.) It's true of Ferret, Google, etc. -- William From wmorgan-sup@masanjin.net Mon Jul 27 11:48:38 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 08:48:38 -0700 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248550384-sup-74@pion.club.cc.cmu.edu> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> Message-ID: <1248709681-sup-4141@entry> Reformatted excerpts from Rich Lane's message of 2009-07-25: > One issue I've noticed is that removing labels from messages doesn't > always immediately work. Is this true even after you sync changes to the index? What about if you reload the label list buffer? ('@') -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:13:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:13:16 -0700 Subject: [sup-talk] xapian merged into next Message-ID: <1248711109-sup-7061@entry> I've merged the xapian branch into next. Users of next need not worry; xapian only enabled when you set the environment variable SUP_INDEX=xapian. (And you'll have to regenerate your index; see my message of a few weeks ago for how.) -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:16:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:16:43 -0700 Subject: [sup-talk] [PATCH] xapian: dont exclude spam/etc in some internal searches In-Reply-To: <1248550028-9703-1-git-send-email-rlane@club.cc.cmu.edu> References: <1248550028-9703-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1248711395-sup-5867@entry> Applied, thanks. -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:17:00 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:17:00 -0700 Subject: [sup-talk] [PATCH] xapian: fix mk_addrs args in build_message In-Reply-To: <1248492309-1980-1-git-send-email-rlane@club.cc.cmu.edu> References: <1248492309-1980-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1248711412-sup-674@entry> Applied, thanks! -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:17:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:17:14 -0700 Subject: [sup-talk] [PATCH] xapian: initialize sources in sup-dump In-Reply-To: <1248490254-31895-1-git-send-email-rlane@club.cc.cmu.edu> References: <1248490254-31895-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1248711426-sup-1184@entry> Aaaand applied. Thanks! -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:22:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:22:48 -0700 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) In-Reply-To: <1247322405-sup-1564@ntdws12.chass.utoronto.ca> References: <1247322405-sup-1564@ntdws12.chass.utoronto.ca> Message-ID: <1248711741-sup-3733@entry> Reformatted excerpts from Ben Walton's message of 2009-07-11: > +1 for this. Not sure how I managed to submit the original patch like > this, since I did test various forms of results returned from the > bounce-command hook...anyway, I've applied this and verified it. I don't see this in your bw/bounce_message branch. I'd like to remerge that. -- William From guillaume.quintard@gmail.com Mon Jul 27 12:16:50 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 27 Jul 2009 18:16:50 +0200 Subject: [sup-talk] xapian merged into next In-Reply-To: <1248711109-sup-7061@entry> References: <1248711109-sup-7061@entry> Message-ID: <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> On Mon, Jul 27, 2009 at 6:13 PM, William Morgan wrote: > I've merged the xapian branch into next. Users of next need not worry; > xapian only enabled when you set the environment variable > SUP_INDEX=xapian. (And you'll have to regenerate your index; see my > message of a few weeks ago for how.) The big question is: is it interesting, as a user, to switch? :-) -- Guillaume From bwalton@artsci.utoronto.ca Mon Jul 27 12:25:52 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 27 Jul 2009 12:25:52 -0400 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) In-Reply-To: <1248711741-sup-3733@entry> References: <1247322405-sup-1564@ntdws12.chass.utoronto.ca> <1248711741-sup-3733@entry> Message-ID: <1248711899-sup-4693@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Mon Jul 27 12:22:48 -0400 2009: > I don't see this in your bw/bounce_message branch. I'd like to remerge > that. Sorry. I didn't publish the change, I thought it would be `git am`'d from the original mail. I applied it to my local running copy of next though, which is what I was referring to. I'll try to remember to push things like this in the future. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon Jul 27 12:27:42 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:27:42 -0700 Subject: [sup-talk] xapian merged into next In-Reply-To: <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> Message-ID: <1248711777-sup-9329@entry> Reformatted excerpts from Guillaume Quintard's message of 2009-07-27: > The big question is: is it interesting, as a user, to switch? :-) Yes. It's noticeably faster than Ferret, especially for loading large threads in thread-index-mode. (Which isn't Xapian per se, but other improvements Rich has made). It's also much larger on disk, though there might be a way to trim that down. At some point I want to deprecate Ferret, since it's unmaintained, so you'll be forced to switch. No timeline on that though. -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:29:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:29:20 -0700 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) In-Reply-To: <1248711899-sup-4693@ntdws12.chass.utoronto.ca> References: <1247322405-sup-1564@ntdws12.chass.utoronto.ca> <1248711741-sup-3733@entry> <1248711899-sup-4693@ntdws12.chass.utoronto.ca> Message-ID: <1248712076-sup-7189@entry> Reformatted excerpts from Ben Walton's message of 2009-07-27: > Sorry. I didn't publish the change, I thought it would be `git am`'d > from the original mail. No problem. We can do it either way. I'll apply this patch directly. -- William From bwalton@artsci.utoronto.ca Mon Jul 27 12:30:20 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 27 Jul 2009 12:30:20 -0400 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) In-Reply-To: <1248711899-sup-4693@ntdws12.chass.utoronto.ca> References: <1247322405-sup-1564@ntdws12.chass.utoronto.ca> <1248711741-sup-3733@entry> <1248711899-sup-4693@ntdws12.chass.utoronto.ca> Message-ID: <1248712092-sup-5843@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Mon Jul 27 12:25:52 -0400 2009: > Sorry. I didn't publish the change, I thought it would be `git am`'d > from the original mail. I applied it to my local running copy of next > though, which is what I was referring to. I'll try to remember to > push things like this in the future. I've now `git am`'d and pushed on my development copy to git://code.chass.utoronto.ca/bwalton-sup.git. You should be able to remerge the bw/bounce_message branch and get Adeodato's fix. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon Jul 27 12:30:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:30:50 -0700 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) In-Reply-To: References: Message-ID: <1248712242-sup-2953@entry> Applied, thanks! -- William From guillaume.quintard@gmail.com Mon Jul 27 12:31:46 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 27 Jul 2009 18:31:46 +0200 Subject: [sup-talk] xapian merged into next In-Reply-To: <1248711777-sup-9329@entry> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> Message-ID: <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> On Mon, Jul 27, 2009 at 6:27 PM, William Morgan wrote: > Yes. It's noticeably faster than Ferret, especially for loading large > threads in thread-index-mode. (Which isn't Xapian per se, but other > improvements Rich has made). Yummy! > It's also much larger on disk, though there might be a way to trim that > down. Less yummy! So, we just export SUP_INDEX=xapian and that's it? We start with an empty sup and we just have to reimport the mbox/maildir/whatever? Means losing the red states and tags, I guess. -- Guillaume From wmorgan-sup@masanjin.net Mon Jul 27 12:41:05 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:41:05 -0700 Subject: [sup-talk] Exception In-Reply-To: <1248453259-sup-3604@nixos> References: <1248453259-sup-3604@nixos> Message-ID: <1248712764-sup-736@entry> Reformatted excerpts from Marc Weber's message of 2009-07-24: > Hi, when either running sup-sync or sup (without -n) I get this > exception: > > --- NoMethodError from thread: poll after loading inbox > undefined method `to_indexable_s' for nil:NilClass Weird. It looks like a date parsing issue, but I'm having a hard time seeing where the logic fails such that no date field is set. Can you try applying the following patch, and then running sup-sync with -v? I'm hoping that the debugging output prefixed with XX will provide a clue. Thanks! --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -92,11 +92,14 @@ class Message begin Time.parse date rescue ArgumentError => e - #Redwood::log "faking mangled date header for #{@id} (orig #{header['da + Redwood::log "faking mangled date header for #{@id} (orig #{header['dat Time.now end - else - #Redwood::log "faking non-existent date header for #{@id}" + end + + @date ||= begin + Redwood::log "XX original header was #{header["date"].inspect}" + Redwood::log "XX faking non-existent date header for #{@id}" Time.now end -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:44:54 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:44:54 -0700 Subject: [sup-talk] xapian merged into next In-Reply-To: <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> Message-ID: <1248712876-sup-1446@entry> Reformatted excerpts from Guillaume Quintard's message of 2009-07-27: > So, we just export SUP_INDEX=xapian and that's it? We start with an > empty sup and we just have to reimport the mbox/maildir/whatever? > Means losing the red states and tags, I guess. Current instructions: 1. install the ruby xapian library and the ruby gdbm library, if you don't have them. These are packaged by your distro, and are not gems. 2. git checkout next 3. git pull 4. cp ~/.sup/sources.yaml /tmp # just in case 5. ruby -Ilib bin/sup-dump > dumpfile 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile 7. SUP_INDEX=xapian ruby -Ilib bin/sup -o 8. Oooh, fast. This should not disturb your Ferret index, so you can switch back and forth between the two. (Message state, of course, is not shared.) However, adding new messages to one index will prevent it from being automatically added to the other, so I recommend running in Xapian mode with -o and not pressing 'P'. Unless, of of course, you're ready to switch permanently, in which case rm -rf ~/.sup/ferret. :) -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:45:17 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:45:17 -0700 Subject: [sup-talk] [PATCH] Unbreak "bounce-command" hook (was referencing an nonexistent variable) In-Reply-To: <1248712092-sup-5843@ntdws12.chass.utoronto.ca> References: <1247322405-sup-1564@ntdws12.chass.utoronto.ca> <1248711741-sup-3733@entry> <1248711899-sup-4693@ntdws12.chass.utoronto.ca> <1248712092-sup-5843@ntdws12.chass.utoronto.ca> Message-ID: <1248713108-sup-884@entry> Reformatted excerpts from Ben Walton's message of 2009-07-27: > I've now `git am`'d and pushed on my development copy to > git://code.chass.utoronto.ca/bwalton-sup.git. You should be able to > remerge the bw/bounce_message branch and get Adeodato's fix. Heh. :) -- William From guillaume.quintard@gmail.com Mon Jul 27 12:47:13 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 27 Jul 2009 18:47:13 +0200 Subject: [sup-talk] xapian merged into next In-Reply-To: <1248712876-sup-1446@entry> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> Message-ID: <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> On Mon, Jul 27, 2009 at 6:44 PM, William Morgan wrote: > Unless, of of course, you're ready to switch permanently, in which case rm -rf > ~/.sup/ferret. :) There's no reason not to, right? /me is following blinding the given instructions :-) -- Guillaume From wmorgan-sup@masanjin.net Mon Jul 27 12:49:11 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:49:11 -0700 Subject: [sup-talk] Reply calculation In-Reply-To: <1248549271-sup-3371@javelin> References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin> <1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin> Message-ID: <1248713182-sup-172@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-07-25: > After thinking about this some, I think that the only way to > reasonably handle all corner cases is to explicitly ask the user for a > choice in corner cases. What was the breakage when favoring reply-to over list-id? I was buying your arguments... Is it possible to identify these corner cases? Is it always when there's a reply-to and a list-id both set? -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:50:12 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:50:12 -0700 Subject: [sup-talk] xapian merged into next In-Reply-To: <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> Message-ID: <1248713360-sup-5448@entry> Reformatted excerpts from Guillaume Quintard's message of 2009-07-27: > There's no reason not to, right? Well, the code isn't quite as well tested... -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:51:17 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:51:17 -0700 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <20090723093543.GA2265@chistera.yi.org> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> Message-ID: <1248713434-sup-4961@entry> Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23: > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200): > > > + :charset => encoded_content.charset, > > Hm, so apparently encoded_content doesn't always have a charset > member... > In which case that value of that variable is nil, right? Is that a problem? The patch still seems useful. -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:52:02 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:52:02 -0700 Subject: [sup-talk] Choose "From:" address based on message content? In-Reply-To: <1248311332-sup-1053@sgoldmanlinux.tower-research.com> References: <1248311332-sup-1053@sgoldmanlinux.tower-research.com> Message-ID: <1248713502-sup-312@entry> Reformatted excerpts from Steve Goldman's message of 2009-07-22: > Can sup do it? Shit yes. These insane requests are exactly why I am favoring hooks over configuration. -- William From wmorgan-sup@masanjin.net Mon Jul 27 12:53:58 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 09:53:58 -0700 Subject: [sup-talk] Choose "From:" address based on message content? In-Reply-To: <1248317360-sup-4094@sgoldmanlinux.tower-research.com> References: <1248311332-sup-1053@sgoldmanlinux.tower-research.com> <1248317360-sup-4094@sgoldmanlinux.tower-research.com> Message-ID: <1248713574-sup-6167@entry> Reformatted excerpts from Steve Goldman's message of 2009-07-22: > require 'eregex' > > r = Regexp.new('word', Regexp::IGNORECASE); > if header.to_s.grep(r).size > 0 or body.to_s.grep(r).size > 0 You can just use body.to_s =~ /word/i || header.join =~ /i/. No need for all the fancy libraries and method calls. -- William From marco-oweber@gmx.de Mon Jul 27 12:55:46 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Mon, 27 Jul 2009 18:55:46 +0200 Subject: [sup-talk] Exception In-Reply-To: <1248712764-sup-736@entry> References: <1248453259-sup-3604@nixos> <1248712764-sup-736@entry> Message-ID: <1248713299-sup-9062@nixos> You're right. I fixed it today by running sup-sync. (I was still reading my mails that's why I didn't respond earlier). I used p m at that location to get a message output saying something about offset is out of sync. Then I tried sup-sync -c. The strange thing is that I didn't open the mbox file using another program such as mutt. Maybe a locking issue or such ? I'm using procmail. I was surprised how easy it was to find the cause after starting looking into it. Thanks for taking the time sending this patch! Marc Weber Excerpts from William Morgan's message of Mon Jul 27 18:41:05 +0200 2009: > Reformatted excerpts from Marc Weber's message of 2009-07-24: > > Hi, when either running sup-sync or sup (without -n) I get this > > exception: > > > > --- NoMethodError from thread: poll after loading inbox > > undefined method `to_indexable_s' for nil:NilClass > > Weird. It looks like a date parsing issue, but I'm having a hard time > seeing where the logic fails such that no date field is set. > > Can you try applying the following patch, and then running sup-sync with > -v? I'm hoping that the debugging output prefixed with XX will provide a > clue. > > Thanks! > > --- a/lib/sup/message.rb > +++ b/lib/sup/message.rb > @@ -92,11 +92,14 @@ class Message > begin > Time.parse date > rescue ArgumentError => e > - #Redwood::log "faking mangled date header for #{@id} (orig #{header['da > + Redwood::log "faking mangled date header for #{@id} (orig #{header['dat > Time.now > end > - else > - #Redwood::log "faking non-existent date header for #{@id}" > + end > + > + @date ||= begin > + Redwood::log "XX original header was #{header["date"].inspect}" > + Redwood::log "XX faking non-existent date header for #{@id}" > Time.now > end > From ingmar@exherbo.org Mon Jul 27 12:56:28 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Mon, 27 Jul 2009 18:56:28 +0200 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248709681-sup-4141@entry> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> <1248709681-sup-4141@entry> Message-ID: <1248713376-sup-5163@cannonball> Excerpts from William Morgan's message of Mon Jul 27 17:48:38 +0200 2009: > Reformatted excerpts from Rich Lane's message of 2009-07-25: > > One issue I've noticed is that removing labels from messages doesn't > > always immediately work. > > Is this true even after you sync changes to the index? What about if you > reload the label list buffer? ('@') It's true in both cases. Even after a sync, 'U' still produces read messages (among unread), and a search for label:foo has threads without that label. If you quit sup & restart it things work as expected for a while. I've also noticed that sup takes a long time to quit with the xapian index. This delay happens after this message: [Mon Jul 27 16:56:01 +0000 2009] unlocking /home/ingmar/.sup/lock... -- Exherbo KDE, X.org maintainer From rlane@club.cc.cmu.edu Mon Jul 27 13:06:34 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 27 Jul 2009 13:06:34 -0400 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248709681-sup-4141@entry> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> <1248709681-sup-4141@entry> Message-ID: <1248710432-sup-1734@pion.club.cc.cmu.edu> Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-07-25: > > One issue I've noticed is that removing labels from messages doesn't > > always immediately work. > > Is this true even after you sync changes to the index? What about if you > reload the label list buffer? ('@') Yes. This is looking like a Xapian bug - I've reproduced it without any Sup code. I'm working on a fix. From ezyang@MIT.EDU Mon Jul 27 13:09:13 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 13:09:13 -0400 Subject: [sup-talk] Reply calculation In-Reply-To: <1248713182-sup-172@entry> References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin> <1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin> <1248713182-sup-172@entry> Message-ID: <1248713591-sup-8324@javelin> Excerpts from William Morgan's message of Mon Jul 27 12:49:11 -0400 2009: > What was the breakage when favoring reply-to over list-id? I was buying > your arguments... First and foremost, s/list-id/list-post/ in my previous posts; I was quoting the wrong field and double checked message.rb just now. I received mail from a mailing list as a call for applications that should not be sent back to the list. The mail was constructed with headers like: From: correct@example.com To: correct at example.com Reply-To: correct at example.com List-Post: mailto:incorrect at example.com Sup detects List-Post, categorizes the message as a list message, and then sets the default reply mode as list, which results in List-Post being used as the to address. > Is it possible to identify these corner cases? Is it always when there's > a reply-to and a list-id both set? Unfortunately, mailing list administrating is notoriously broken. I'm not sure at all what the right solution is. Take for example this other case: From: person@example.com To: list at example.com Reply-To: person at example.com List-Post: mailto:list at example.com Reply-To, in this case, was set by the mailing list server. This makes having Reply-To be the end-all be-all kind of spurious. If we try to make Sup do the Right Thing (TM), you probably want to send mail to the list as a whole, which means you do want to either "reply all" semantics or "list post" magic. ("reply all" semantics are what you see in traditional mail clients when you hit the "reply all" button.) However, consider the next case: From: persona@example.com To: list at example.com Cc: me at example.com Which is when someone else hit "Reply all" and you got CC'ed. This means that the mail never passed through the mailing list agent, the List-Post/Reply-To headers never got set, and the only way to tell that you should reply to the whole list is to explicitly ask for "Reply all" semantics (Sup defaults to "Reply" semantics, which is damn confusing if you're not paying attention). The core problem is that subtle changes in state should not require the user to do things differently; it breaks muscle memory and makes mistakes easy. We could try to make it so that Sup requires /no/ user intervention, but this is seems to be an AI-hard problem. Then, the logical other direction, is to make the interface as consistent as possible. Cheers, Edward PS. Djb wrote an article along these lines: http://cr.yp.to/proto/replyto.html I've skimmed it but I'm kind of skeptical about client support and not sure if it actually gives useful recommendations. From guillaume.quintard@gmail.com Mon Jul 27 13:09:19 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 27 Jul 2009 19:09:19 +0200 Subject: [sup-talk] xapian merged into next In-Reply-To: <1248713360-sup-5448@entry> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> <1248713360-sup-5448@entry> Message-ID: <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> On Mon, Jul 27, 2009 at 6:50 PM, William Morgan wrote: > Well, the code isn't quite as well tested... Someone has to do it, plus I still have my mbox archive... ...and I was getting tired of this mostly bugless mail experience. -- Guillaume From ezyang@MIT.EDU Mon Jul 27 13:13:01 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 13:13:01 -0400 Subject: [sup-talk] Odd key bug Message-ID: <1248714653-sup-6926@javelin> After I finish editing a message and exit out of my editor (vim), if I try to press up arrow in order to move my focus to the reply mode field to toggle it, I get the errors: unknown keypress '^[' for compose-mode unknown keypress 'A' for compose-mode It then works properly. A guess is something is messing with the terminal? This is 100% reproduceable. Cheers, Edward From wmorgan-sup@masanjin.net Mon Jul 27 13:16:02 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:16:02 -0700 Subject: [sup-talk] sup 0.8.1 crash In-Reply-To: <1246954373-sup-4550@sfo.thejof.com> References: <1246954373-sup-4550@sfo.thejof.com> Message-ID: <1248714912-sup-9402@entry> Reformatted excerpts from Jonathan Lassoff's message of 2009-07-07: > I took a little time to poke around in the sup source to try and get > an idea what was going on. I'm led to believe this is because I added > a source in the past that I later deleted -- but all of the mesages > are still in the index. That would do it! > So, when certain searches turn up results that are in that deleted > source, the sup index fails to reference the message source in > Redwood::Index. Is there a way to delete a source without having to > re-index everything? Yes, using devel/console.sh. Are you running master or next? (Or a release?) Details differ depending. -- William From wmorgan-sup@masanjin.net Mon Jul 27 13:19:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:19:14 -0700 Subject: [sup-talk] [PATCH] Use /etc/mailname if present to determine the hostname for Message-Id In-Reply-To: References: Message-ID: <1248715131-sup-8076@entry> Reformatted excerpts from Adeodato Sim?'s message of 2009-07-09: > on many systems (notably Debian-based systems), the /etc/mailname file > can be created to specify the public mail name for a host. If that > file exists, it'd be good to use its contents for generating the > Message-Id header. Excellent idea. Applied directly to master. Thanks! -- William From wmorgan-sup@masanjin.net Mon Jul 27 13:24:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:24:09 -0700 Subject: [sup-talk] Validating GPG keys in parallel and in background In-Reply-To: <1247256988-sup-2799@x200> References: <1247256988-sup-2799@x200> Message-ID: <1248715421-sup-9481@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-07-10: > it seems like sup is blocking during the validation of GPG > signed/encrypted mails. While for encryption it makes some sense to > block, for signed mails it would be better to just display the message > and add the information about the signature status later. The same > approach could be used for encrypted messages: Display "decrypting..." > and update it when done. I agree. This would be great. -- William From wmorgan-sup@masanjin.net Mon Jul 27 13:25:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:25:36 -0700 Subject: [sup-talk] Adding/saving multiple attachments? In-Reply-To: <1247331130-sup-4923@x200> References: <1247331130-sup-4923@x200> Message-ID: <1248715516-sup-4466@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-07-11: > I?ve had the same problem with mutt: Isn?t there a way to add or save > multiple attachments? Why can?t I add ~/work/foo/* when pressing 'a'? > Why doesn?t the file browser save the last directory I?ve been in? > Can we please get a binding to save all attachments of a message into > a folder? All excellent ideas. I too am annoyed when I have more than one attachment to save. -- William From wmorgan-sup@masanjin.net Mon Jul 27 13:26:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:26:06 -0700 Subject: [sup-talk] Invalid character on import In-Reply-To: <1247516120-sup-3116@ausone.local> References: <20090713090110.GA20996@ikn.schottelius.org> <1247516120-sup-3116@ausone.local> Message-ID: <1248715552-sup-271@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-07-13: > The fix is trivial, I've submitted a merge request for exactly this: > > http://gitorious.org/~ertai/sup/clone-by-ertai This has been applied to master. Thanks! -- William From wmorgan-sup@masanjin.net Mon Jul 27 13:31:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:31:09 -0700 Subject: [sup-talk] [PATCH] GSSAPI support for net/imap.rb and sup In-Reply-To: <1248092732-sup-9960@midna> References: <1248092732-sup-9960@midna> Message-ID: <1248715761-sup-5112@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-07-20: > As I?m not very much involved in the ruby community (in fact, this is > my first piece of ruby code), I need someone to help me get things > upstream (for Net::IMAP in the first place, but someone maintaining > ruby-gss would be great). I don't have much advice for you other than find the guy who maintains Net::IMAP, beating him on the head a few times for me, and send him the patch. I believe net/imap is part of core ruby, which means you can probably just take this to the ruby-core mailing list. -- William From wmorgan-sup@masanjin.net Mon Jul 27 13:33:57 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:33:57 -0700 Subject: [sup-talk] Odd key bug In-Reply-To: <1248714653-sup-6926@javelin> References: <1248714653-sup-6926@javelin> Message-ID: <1248715911-sup-4656@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-07-27: > It then works properly. A guess is something is messing with the > terminal? This is 100% reproduceable. This happens to me too. Maybe there's some more curses weirdness that needs to happen when shelling out---you can see the current magic spell at buffer.rb circa line 724, in BufferManager#shell_out. I've just suffered through it for the past three years. -- William From wmorgan-sup@masanjin.net Mon Jul 27 13:34:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:34:59 -0700 Subject: [sup-talk] xapian merged into next In-Reply-To: <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907270947n1866decdoc8a568cc9a2733ae@mail.gmail.com> <1248713360-sup-5448@entry> <1e5fdab70907271009v46639384w4bb3461ccaccf0cc@mail.gmail.com> Message-ID: <1248716073-sup-7443@masanjin.net> Reformatted excerpts from Guillaume Quintard's message of 2009-07-27: > Someone has to do it, plus I still have my mbox archive... > ...and I was getting tired of this mostly bugless mail experience. Ok, you're the official guinea pig then. :) -- William From ezyang@MIT.EDU Mon Jul 27 13:36:10 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 13:36:10 -0400 Subject: [sup-talk] Odd bug with lazy-loaded messages Message-ID: <1248716007-sup-5156@javelin> I've been experiencing an odd bug with the following patch for lazy loading messages: --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -103,7 +103,6 @@ EOS t.each_with_index do |(m, *o), i| next unless m BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1 - m.load_from_source! end end Specifically, the "default" opened message when I open a thread gets a weird misrendering of the headers that looks like: To: foo foo foo And so forth, for all lines in To and Cc. Any ideas what could be causing this? I checked load_from_source! in message.rb but didn't see anything obvious that would prevent this behavior. Cheers, Edward From ezyang@MIT.EDU Mon Jul 27 13:39:27 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 13:39:27 -0400 Subject: [sup-talk] [PATCH] Make logging less chatty Message-ID: <1248716313-sup-1608@javelin> Sup currently generates a lot of logging spew during initial startup when it is threading. This makes it difficult to see other log messages that are more interesting. I propose we turn these messages off. >From 1fc4107013a991f24a62dad54509913bb1270d5d Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Sat, 25 Jul 2009 14:16:40 -0400 Subject: [PATCH] Make logging less chatty. Signed-off-by: Edward Z. Yang --- lib/sup/index.rb | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/sup/index.rb b/lib/sup/index.rb index 9c985d9..fa33baa 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -394,10 +394,10 @@ EOS end if killed - Redwood::log "thread for #{m.id} is killed, ignoring" + #Redwood::log "thread for #{m.id} is killed, ignoring" false else - Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0 + #Redwood::log "ran #{num_queries} queries to build thread of #{messages.size} messages for #{m.id}: #{m.subj}" if num_queries > 0 messages.each { |mid, builder| yield mid, builder } true end -- 1.6.3.3 From ezyang@MIT.EDU Mon Jul 27 13:40:48 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 13:40:48 -0400 Subject: [sup-talk] [PATCH] before-search hook In-Reply-To: <1246035946-sup-7069@javelin> References: <1244612627-sup-982@javelin> <1245087294-sup-6276@entry> <1246035946-sup-7069@javelin> Message-ID: <1248716405-sup-6097@javelin> Excerpts from Edward Z. Yang's message of Fri Jun 26 13:10:01 -0400 2009: > Done. What's the status on getting this patch into the tree? Cheers, Edward From alex@chmrr.net Mon Jul 27 13:27:33 2009 From: alex@chmrr.net (Alex Vandiver) Date: Mon, 27 Jul 2009 13:27:33 -0400 Subject: [sup-talk] Odd key bug In-Reply-To: <1248714653-sup-6926@javelin> References: <1248714653-sup-6926@javelin> Message-ID: <1248715577-sup-4766@utwig> At Mon Jul 27 13:13:01 -0400 2009, Edward Z. Yang wrote: > After I finish editing a message and exit out of my editor (vim), > if I try to press up arrow in order to move my focus to the > reply mode field to toggle it, I get the errors: > > unknown keypress '^[' for compose-mode > unknown keypress 'A' for compose-mode > > It then works properly. A guess is something is messing with the > terminal? This is 100% reproduceable. As another data point, I also see this, with emacs as my editor. - Alex -- Networking -- only one letter away from not working From wmorgan-sup@masanjin.net Mon Jul 27 13:45:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 10:45:32 -0700 Subject: [sup-talk] xapian question Message-ID: <1248716325-sup-7534@masanjin.net> Hey, I finally get to ask a question! One of the mildly irritating things about Ferret was that it was impossible to update the labels of a message without updating the entire entry, i.e. including the body. So updating the labels of a message and saving that to disk required either re-loading the body from the source, or keeping the body explicitly in the index so that it could be loaded without going back to the source. The latter approach is used by the current Ferret index implementation, since it's significantly faster (especially for slow sources like IMAP servers), but at the cost of a lot of disk space. My understanding of Xapian is that this is also the case, since fields are essentially represented as prefixed terms, and so you're basically updating a big blog, but I wanted to confirm this. I ask because the entries.db file is very big. :) -- William From bwalton@artsci.utoronto.ca Mon Jul 27 13:48:05 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 27 Jul 2009 13:48:05 -0400 Subject: [sup-talk] [PATCH] Make logging less chatty In-Reply-To: <1248716313-sup-1608@javelin> References: <1248716313-sup-1608@javelin> Message-ID: <1248716783-sup-6509@ntdws12.chass.utoronto.ca> Excerpts from Edward Z. Yang's message of Mon Jul 27 13:39:27 -0400 2009: > Sup currently generates a lot of logging spew during initial startup > when it is threading. This makes it difficult to see other log > messages that are more interesting. I propose we turn these messages > off. +1 for the idea, but wouldn't a command line verbosity toggle be a better way to do this? Maybe an arg that accepts a numeric value and then debug statements of type foo if $val > bar? Makes debugging this stuff easier, but the output is still optional and presumably below the default threshold. Just a thought. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Mon Jul 27 13:52:02 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 27 Jul 2009 13:52:02 -0400 Subject: [sup-talk] Odd key bug In-Reply-To: <1248715577-sup-4766@utwig> References: <1248714653-sup-6926@javelin> <1248715577-sup-4766@utwig> Message-ID: <1248717027-sup-9556@ntdws12.chass.utoronto.ca> Excerpts from Alex Vandiver's message of Mon Jul 27 13:27:33 -0400 2009: > As another data point, I also see this, with emacs as my editor. And I saw it with vim until I switched to emacs a few months back. I wonder if this is anything to do with how these curses apps interact with the 'alternate' screen buffer or something? For the record, I've always run sup inside of screen... I've just been suffering through it too. Edward, you've given voice to this insidious little annoyance! :) -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ezyang@MIT.EDU Mon Jul 27 14:13:12 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 14:13:12 -0400 Subject: [sup-talk] Odd key bug In-Reply-To: <1248715911-sup-4656@masanjin.net> References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net> Message-ID: <1248718344-sup-1931@javelin> Excerpts from William Morgan's message of Mon Jul 27 13:33:57 -0400 2009: > This happens to me too. Maybe there's some more curses weirdness that > needs to happen when shelling out---you can see the current magic spell > at buffer.rb circa line 724, in BufferManager#shell_out. I've just > suffered through it for the past three years. I tried cargo culting a few extra function calls from the web, to no avail. Man, where's an ncurses expert when you need them... Cheers, Edward From ezyang@MIT.EDU Mon Jul 27 14:30:46 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 14:30:46 -0400 Subject: [sup-talk] Odd key bug In-Reply-To: <1248718344-sup-1931@javelin> References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net> <1248718344-sup-1931@javelin> Message-ID: <1248719342-sup-9126@javelin> I currently suspect that if I send a null character to the stdscr (which would require bin/sup to be rewritten a little to make stdscr globally available) it would serve as a decent workaround. I don't actually know how global variables work in Ruby. (Basically, add stdscr.keypad(0) when we return from the external shell.) Cheers, Edward From tarko@lanparty.ee Mon Jul 27 14:47:00 2009 From: tarko@lanparty.ee (Tarko Tikan) Date: Mon, 27 Jul 2009 21:47:00 +0300 Subject: [sup-talk] Odd key bug In-Reply-To: <1248714653-sup-6926@javelin> References: <1248714653-sup-6926@javelin> Message-ID: <1248720085-sup-7444@valgus> hey, > After I finish editing a message and exit out of my editor (vim), > if I try to press up arrow in order to move my focus to the > reply mode field to toggle it, I get the errors: Running sup in screen and seeing it aswell. As the discussion goes around external editor (and problems switching to and back), I want to throw up an question/idea. Currently, as the external editor is run, there is no way to switch between sup and external editor (for obvious reasons). Is anyone aware of any better idea how to integrate vim (even better, any editor) into sup and still have the excellent buffer system. Currently, going between received emails, and the one being composed, is a real pain. Inventing own editor is ofc one solution but it sounds silly to do it from scratch. -- tarko From ezyang@MIT.EDU Mon Jul 27 15:15:27 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 27 Jul 2009 15:15:27 -0400 Subject: [sup-talk] Odd key bug In-Reply-To: <1248719342-sup-9126@javelin> References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net> <1248718344-sup-1931@javelin> <1248719342-sup-9126@javelin> Message-ID: <1248721402-sup-3517@javelin> Alex Vandiver points out that stdscr is a member variable of Ncurses. As such, this patch appears to fix the issue. However, my rationale in my previous message was completely bogus (I checked the manpage and keypad does NOT send a null key); thus, I have no fucking clue why this works. Perhaps forcibly setting this setting clears some internal buffer. Either 1 or 0 works, we probably want 1 since that's what bin/sup sets. Yay cargo culting! Whoo! >From 61696b6a097a949545db52b4a537d74f8256d807 Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Mon, 27 Jul 2009 15:03:58 -0400 Subject: [PATCH] Fix broken arrow keypresses after shelling out. Signed-off-by: Edward Z. Yang --- lib/sup/buffer.rb | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb index 8eedf96..5f52d1d 100644 --- a/lib/sup/buffer.rb +++ b/lib/sup/buffer.rb @@ -723,6 +723,7 @@ EOS Ncurses.sync do Ncurses.endwin system command + Ncurses.stdscr.keypad 1 Ncurses.refresh Ncurses.curs_set 0 end -- 1.6.3.3 From wmorgan-sup@masanjin.net Mon Jul 27 15:40:05 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 27 Jul 2009 12:40:05 -0700 Subject: [sup-talk] [PATCH] before-search hook In-Reply-To: <1248716405-sup-6097@javelin> References: <1244612627-sup-982@javelin> <1245087294-sup-6276@entry> <1246035946-sup-7069@javelin> <1248716405-sup-6097@javelin> Message-ID: <1248717965-sup-1834@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-07-27: > What's the status on getting this patch into the tree? Thanks for the ping. I've put this on branch custom-search-hook and merged into next. Note that it only applies to Ferret for now. Now that we've split into two indexes, we need to plan out how this hook is going to work going forward, since different indexes have different query languages. Probably the best option is to have the index type be passed as an argument, and let the user special-case on that. -- William From guillaume.quintard@gmail.com Mon Jul 27 16:04:58 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 27 Jul 2009 22:04:58 +0200 Subject: [sup-talk] xapian merged into next In-Reply-To: <1248712876-sup-1446@entry> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> Message-ID: <1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com> On Mon, Jul 27, 2009 at 6:44 PM, William Morgan wrote: all went well until: > 5. ruby -Ilib bin/sup-dump > dumpfile -> produces a empty file (not sure it's normal) > 6. SUP_INDEX=xapian ruby -Ilib bin/sup-sync --all --all-sources --restore dumpfile -> error [Mon Jul 27 22:01:35 +0200 2009] using character set encoding "UTF-8" ./lib/sup/xapian_index.rb:17:in `at': bignum too big to convert into `long' (RangeError) from ./lib/sup/xapian_index.rb:17 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from ./lib/sup/index.rb:217 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from ./lib/sup.rb:269 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from bin/sup-sync:6 l17 of xapian_index.rb is MAX_DATE = Time.at(2**31) -- Guillaume From andrew@pimlott.net Mon Jul 27 16:11:53 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Mon, 27 Jul 2009 13:11:53 -0700 Subject: [sup-talk] Odd key bug In-Reply-To: <1248720085-sup-7444@valgus> References: <1248714653-sup-6926@javelin> <1248720085-sup-7444@valgus> Message-ID: <20090727201153.GI14010@pimlott.net> On Mon, Jul 27, 2009 at 09:47:00PM +0300, Tarko Tikan wrote: > Currently, as the external editor is run, there is no way to switch between sup and external editor (for obvious reasons). Is anyone aware of any better idea how to integrate vim (even better, any editor) into sup and still have the excellent buffer system. My idea is to make sup act like a shell and implement job control, so when you ctrl-z out of your editor, you're back in sup. You can have multiple editors stopped in the background, and resume any of them at any point. Andrew From rgh@roughage.com.au Mon Jul 27 20:33:16 2009 From: rgh@roughage.com.au (Richard Heycock) Date: Tue, 28 Jul 2009 10:33:16 +1000 Subject: [sup-talk] xapian merged into next In-Reply-To: <1248711777-sup-9329@entry> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> Message-ID: <1248740968-sup-759@wrasse> Excerpts from William Morgan's message of Tue Jul 28 02:27:42 +1000 2009: > Reformatted excerpts from Guillaume Quintard's message of 2009-07-27: > > The big question is: is it interesting, as a user, to switch? :-) > > Yes. It's noticeably faster than Ferret, especially for loading large > threads in thread-index-mode. (Which isn't Xapian per se, but other > improvements Rich has made). > > It's also much larger on disk, though there might be a way to trim that > down. > > At some point I want to deprecate Ferret, since it's unmaintained, so > you'll be forced to switch. No timeline on that though. Just to add to Williams answer not only is it faster it's also *significantly* more robust. I'm running Debian unstable which, at the moment is really living up to it's name, consequently my machine is dying a lot more times than it should and I haven't had to rebuild the index once. Compare that to ferret where I pretty much has to rebuild the index every time; I even wrote myself a one line script to do it. William there is work being done on the next xapian "engine" which aims to reduce the disc size. rgh From rlane@club.cc.cmu.edu Mon Jul 27 23:19:29 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 27 Jul 2009 20:19:29 -0700 Subject: [sup-talk] [PATCH 1/2] xapian: fix MAX_DATE Message-ID: <1248751170-4102-1-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/xapian_index.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 303b4d0..6358a20 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -14,7 +14,7 @@ class XapianIndex < BaseIndex ## so we must ensure they're reasonably valid. this typically only affect ## spam. MIN_DATE = Time.at 0 - MAX_DATE = Time.at(2**31) + MAX_DATE = Time.at(2**31-1) def initialize dir=BASE_DIR super -- 1.6.0.4 From rlane@club.cc.cmu.edu Mon Jul 27 23:19:30 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 27 Jul 2009 20:19:30 -0700 Subject: [sup-talk] [PATCH 2/2] xapian: fix issue with empty ferret query In-Reply-To: <1248751170-4102-1-git-send-email-rlane@club.cc.cmu.edu> References: <1248751170-4102-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1248751170-4102-2-git-send-email-rlane@club.cc.cmu.edu> --- lib/sup/ferret_index.rb | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/sup/ferret_index.rb b/lib/sup/ferret_index.rb index f2bb2a0..5473814 100644 --- a/lib/sup/ferret_index.rb +++ b/lib/sup/ferret_index.rb @@ -442,6 +442,7 @@ private def build_ferret_query query q = Ferret::Search::BooleanQuery.new + q.add_query Ferret::Search::MatchAllQuery.new, :must q.add_query query[:qobj], :must if query[:qobj] labels = ([query[:label]] + (query[:labels] || [])).compact labels.each { |t| q.add_query Ferret::Search::TermQuery.new("label", t.to_s), :must } -- 1.6.0.4 From rlane@club.cc.cmu.edu Mon Jul 27 23:33:16 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 27 Jul 2009 23:33:16 -0400 Subject: [sup-talk] xapian merged into next In-Reply-To: <1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com> Message-ID: <1248751256-sup-4491@pion.club.cc.cmu.edu> Excerpts from Guillaume Quintard's message of Mon Jul 27 16:04:58 -0400 2009: > > 5. ruby -Ilib bin/sup-dump > dumpfile > -> produces a empty file (not sure it's normal) > > ./lib/sup/xapian_index.rb:17:in `at': bignum too big to convert into Oops, breaking sup-dump would make switching to Xapian a little difficult. I've posted patches for both these issues. We really should have more tests to catch this sort of thing... From rlane@club.cc.cmu.edu Tue Jul 28 01:02:29 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 27 Jul 2009 22:02:29 -0700 Subject: [sup-talk] [PATCH] explicitly load messages in testcase Message-ID: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu> --- test/test_message.rb | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/test/test_message.rb b/test/test_message.rb index 0a7db45..675b81d 100644 --- a/test/test_message.rb +++ b/test/test_message.rb @@ -73,6 +73,7 @@ EOS source_info = 0 sup_message = Message.new( {:source => source, :source_info => source_info } ) + sup_message.load_from_source! # see how well parsing the header went @@ -222,6 +223,7 @@ EOS source_info = 0 sup_message = Message.new( {:source => source, :source_info => source_info } ) + sup_message.load_from_source! # read the message body chunks @@ -271,6 +273,7 @@ EOS source_info = 0 sup_message = Message.new( {:source => source, :source_info => source_info } ) + sup_message.load_from_source! to = sup_message.to @@ -316,6 +319,7 @@ EOS source_info = 0 sup_message = Message.new( {:source => source, :source_info => source_info } ) + sup_message.load_from_source! # read the message body chunks: no errors should reach this level @@ -414,6 +418,7 @@ EOS source_info = 0 sup_message = Message.new( {:source => source, :source_info => source_info } ) + sup_message.load_from_source! # read the message body chunks @@ -504,6 +509,7 @@ EOS source_info = 0 sup_message = Message.new( {:source => source, :source_info => source_info } ) + sup_message.load_from_source! # See how well parsing the message ID went. id = sup_message.id -- 1.6.0.4 From olly@survex.com Tue Jul 28 09:47:07 2009 From: olly@survex.com (Olly Betts) Date: Tue, 28 Jul 2009 13:47:07 +0000 (UTC) Subject: [sup-talk] [PATCH 0/18] Xapian-based index References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> Message-ID: William Morgan writes: > Reformatted excerpts from Olly Betts's message of 2009-06-25: > > I'll make sure this fix makes it into the next Xapian release (which > > will be 1.0.14). > > Awesome, thanks! Just to update, Xapian 1.0.14 was released last week with this fix. I tested with a distilled micro-testcase rather than sup and these patches, so if you still see problems please open a ticket on http://trac.xapian.org/ Cheers, Olly From wmorgan-sup@masanjin.net Tue Jul 28 11:06:34 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 08:06:34 -0700 Subject: [sup-talk] trying out sup ... In-Reply-To: <20090718074151.GF30748@cat.rubenette.is-a-geek.com> References: <20090718074151.GF30748@cat.rubenette.is-a-geek.com> Message-ID: <1248793474-sup-9541@masanjin.net> Hi Lee, Reformatted excerpts from lee's message of 2009-07-18: > So I had sup running on the console and tried out to search for > something while sup was looking for new messages in a maildir. But > then it crashed and told me I should send a bug report[3]. > > Maybe I have created some incompatibilities by installing the > replacement library. But is it currently possible to run sup on Debian > Testing without too much difficulty? If so, what do I need to do? That particular crash is a transient thing, I think---there is some race condition with the display logic that occasionally manifests itself as such. I would just retry. I have tentative plans to rewrite a lot of the display stuff without threads once we're Ruby 1.9 ready. I don't know why display is corrupt in rxvt. Do other ncurses apps display ok? -- William From wmorgan-sup@masanjin.net Tue Jul 28 11:07:11 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 08:07:11 -0700 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> Message-ID: <1248793614-sup-5597@masanjin.net> Reformatted excerpts from Olly Betts's message of 2009-07-28: > Just to update, Xapian 1.0.14 was released last week with this fix. > > I tested with a distilled micro-testcase rather than sup and these patches, > so if you still see problems please open a ticket on http://trac.xapian.org/ Excellent. Thank you. -- William From wmorgan-sup@masanjin.net Tue Jul 28 11:12:51 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 08:12:51 -0700 Subject: [sup-talk] [PATCH] explicitly load messages in testcase In-Reply-To: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu> References: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1248793905-sup-2227@masanjin.net> Hi Rich, Not to be a pain, but can you give a little more context for this patch (and the other two you sent recently)? I'm just trying to understand what this fixes. -- William From wmorgan-sup@masanjin.net Tue Jul 28 11:13:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 08:13:52 -0700 Subject: [sup-talk] xapian merged into next In-Reply-To: <1248751256-sup-4491@pion.club.cc.cmu.edu> References: <1248711109-sup-7061@entry> <1e5fdab70907270916o2f8e1768vbe7e3bcc1c807e39@mail.gmail.com> <1248711777-sup-9329@entry> <1e5fdab70907270931t7dfbe285h67197a7355b611d6@mail.gmail.com> <1248712876-sup-1446@entry> <1e5fdab70907271304xcc52d55pb745cb85d258fdc4@mail.gmail.com> <1248751256-sup-4491@pion.club.cc.cmu.edu> Message-ID: <1248793998-sup-5987@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-07-27: > We really should have more tests to catch this sort of thing... Agreed. Mostly my fault, I'm afraid. -- William From wmorgan-sup@masanjin.net Tue Jul 28 11:17:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 08:17:52 -0700 Subject: [sup-talk] Odd key bug In-Reply-To: <1248721402-sup-3517@javelin> References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net> <1248718344-sup-1931@javelin> <1248719342-sup-9126@javelin> <1248721402-sup-3517@javelin> Message-ID: <1248794177-sup-3810@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-07-27: > Alex Vandiver points out that stdscr is a member variable of Ncurses. > As such, this patch appears to fix the issue. Applied with great relish direct to master. Thanks! > I have no fucking clue why this works. Perhaps forcibly setting this > setting clears some internal buffer. Either 1 or 0 works, we probably > want 1 since that's what bin/sup sets. Welcome to ncurses programming. Much like fortran, everyone who once knew what this stuff meant has since died. -- William From wmorgan-sup@masanjin.net Tue Jul 28 11:25:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 08:25:23 -0700 Subject: [sup-talk] [PATCH] Make logging less chatty In-Reply-To: <1248716783-sup-6509@ntdws12.chass.utoronto.ca> References: <1248716313-sup-1608@javelin> <1248716783-sup-6509@ntdws12.chass.utoronto.ca> Message-ID: <1248794676-sup-7855@masanjin.net> Reformatted excerpts from Ben Walton's message of 2009-07-27: > +1 for the idea, but wouldn't a command line verbosity toggle be a > better way to do this? I've applied the patch, but yes, the whole Redwood::log thing is crufty and needs to be replaced with a logger that's aware of levels. -- William From bwalton@artsci.utoronto.ca Tue Jul 28 11:31:24 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 28 Jul 2009 11:31:24 -0400 Subject: [sup-talk] Odd key bug In-Reply-To: <1248794177-sup-3810@masanjin.net> References: <1248714653-sup-6926@javelin> <1248715911-sup-4656@masanjin.net> <1248718344-sup-1931@javelin> <1248719342-sup-9126@javelin> <1248721402-sup-3517@javelin> <1248794177-sup-3810@masanjin.net> Message-ID: <1248795045-sup-4556@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Tue Jul 28 11:17:52 -0400 2009: > Welcome to ncurses programming. Much like fortran, everyone who once > knew what this stuff meant has since died. ...or is making a 'mint' maintaining crap^H^H^H^Hcode from the 80's? -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Tue Jul 28 11:39:16 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 28 Jul 2009 11:39:16 -0400 Subject: [sup-talk] [PATCH] explicitly load messages in testcase In-Reply-To: <1248793905-sup-2227@masanjin.net> References: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu> <1248793905-sup-2227@masanjin.net> Message-ID: <1248794785-sup-1840@pion.club.cc.cmu.edu> Excerpts from William Morgan's message of Tue Jul 28 11:12:51 -0400 2009: > Hi Rich, > > Not to be a pain, but can you give a little more context for this patch > (and the other two you sent recently)? I'm just trying to understand > what this fixes. Sure. The commit "don't automatically parse header on Message#new" broke test_message because the message id/etc fields are nil until load_from_source! is called. This patch just calls load_from_source! whenever we create a message in the testcase. The other two are fixes for problems reported by Guillaume Quintard. Ferret sup-dump was failing because the query passed to each_id didn't have any positive terms. The date-ceiling code was broken on 32 bit machines because the maximum signed long is 2**31-1, not 2**31. From wmorgan-sup@masanjin.net Tue Jul 28 11:48:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 08:48:48 -0700 Subject: [sup-talk] Reply calculation In-Reply-To: <1248713591-sup-8324@javelin> References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin> <1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin> <1248713182-sup-172@entry> <1248713591-sup-8324@javelin> Message-ID: <1248794955-sup-3347@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-07-27: > From: correct at example.com > To: correct at example.com > Reply-To: correct at example.com > List-Post: mailto:incorrect at example.com > > Sup detects List-Post, categorizes the message as a list message, and then > sets the default reply mode as list, which results in List-Post being used > as the to address. So in this case, following reply-to is correct. > Unfortunately, mailing list administrating is notoriously broken. I'm not > sure at all what the right solution is. Take for example this other case: > > From: person at example.com > To: list at example.com > Reply-To: person at example.com > List-Post: mailto:list at example.com > > Reply-To, in this case, was set by the mailing list server. In this case, I'd argue that this means the list administrator wants the default reply behavior to be to the individual and not the list. So I'd again prefer Sup default to the reply-to address rather than the list address. (With the caveat that this is overrideable by hooks on a per-list basis, so if it's a matter of an incompetent list administrator, or simply disagreeing with them, one can override this behavior for this list.) > However, consider the next case: > > From: persona at example.com > To: list at example.com > Cc: me at example.com > > Which is when someone else hit "Reply all" and you got CC'ed. This means > that the mail never passed through the mailing list agent, the > List-Post/Reply-To > headers never got set, and the only way to tell that you should reply to the > whole list is to explicitly ask for "Reply all" semantics (Sup defaults to > "Reply" semantics, which is damn confusing if you're not paying attention). There's not much to be done in this case, EXCEPT that if you receive more than one copy of the message, you should keep the list header around. Then the only time you're in a funny situation is when you've received the first but not the other. This is presumably why Mutt had you register your mailing list addresses explicitly, which I always found a little irritating. (Or to have Sup keep around email addresses known to belong to lists, and match those in the To: field against that, which seems significantly more complicated.) > The core problem is that subtle changes in state should not require the user > to do things differently; it breaks muscle memory and makes mistakes easy. I agree with this in principle, but I see addressing a message as a fundamental part of composing it. You can remove the notion of a smart default reply-to address from your Sup, if you like, by using the reply-to hook. And as for the default, I think I'm of the opinion that setting the default reply address so as to obey the reply-to is correcter than anything else (including whatever Sup does currently). -- William From rlane@club.cc.cmu.edu Tue Jul 28 11:57:56 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 28 Jul 2009 11:57:56 -0400 Subject: [sup-talk] xapian question In-Reply-To: <1248716325-sup-7534@masanjin.net> References: <1248716325-sup-7534@masanjin.net> Message-ID: <1248795865-sup-6634@pion.club.cc.cmu.edu> Excerpts from William Morgan's message of Mon Jul 27 13:45:32 -0400 2009: > Hey, I finally get to ask a question! > > One of the mildly irritating things about Ferret was that it was > impossible to update the labels of a message without updating the entire > entry, i.e. including the body. So updating the labels of a message and > saving that to disk required either re-loading the body from the source, > or keeping the body explicitly in the index so that it could be loaded > without going back to the source. > > The latter approach is used by the current Ferret index implementation, > since it's significantly faster (especially for slow sources like IMAP > servers), but at the cost of a lot of disk space. > > My understanding of Xapian is that this is also the case, since fields > are essentially represented as prefixed terms, and so you're basically > updating a big blog, but I wanted to confirm this. I ask because the > entries.db file is very big. :) Xapian actually provides add_term and remove_term for documents. I'd definitely like to use these for label updates, but we need a way to tell if only the labels have changed in sync_message. Or, we update the index in Message#add_label/etc and get rid of the need to save buffers. That might not be an option for the Ferret index, though. We don't store the body in entries.db, just enough info for thread-index-mode. It's only about 800 bytes/message for me, but I don't have snippets enabled so yours would be larger. From wmorgan-sup@masanjin.net Tue Jul 28 12:04:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 09:04:20 -0700 Subject: [sup-talk] [PATCH] explicitly load messages in testcase In-Reply-To: <1248794785-sup-1840@pion.club.cc.cmu.edu> References: <1248757349-11301-1-git-send-email-rlane@club.cc.cmu.edu> <1248793905-sup-2227@masanjin.net> <1248794785-sup-1840@pion.club.cc.cmu.edu> Message-ID: <1248796949-sup-4949@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-07-28: > Sure. The commit "don't automatically parse header on Message#new" broke > test_message because the message id/etc fields are nil until > load_from_source! is called. This patch just calls load_from_source! > whenever we create a message in the testcase. Got it. Applied, thanks! > The other two are fixes for problems reported by Guillaume Quintard. > Ferret sup-dump was failing because the query passed to each_id didn't > have any positive terms. Hah. > The date-ceiling code was broken on 32 bit machines because the > maximum signed long is 2**31-1, not 2**31. Ok, both applied. Thanks! -- William From olly@survex.com Tue Jul 28 12:53:46 2009 From: olly@survex.com (Olly Betts) Date: Tue, 28 Jul 2009 16:53:46 +0000 (UTC) Subject: [sup-talk] [PATCH 0/18] Xapian-based index References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248709366-sup-5856@entry> Message-ID: William Morgan writes: > Reformatted excerpts from Rich Lane's message of 2009-07-24: > > You need to specify a non-negated term in the query. "type:mail > > -label:inbox" should work. > > This is a typical restriction for inverted index-based search engines. > You need to have at least one positive term or the computation is too > expensive (it would have to iterate over every term ever seen.) It's > true of Ferret, Google, etc. Actually, Xapian supports this - Xapian.Query.new("") is a "magic" query which matches all documents. It doesn't need to iterate over every term, just all documents. But if you want the top ten documents without a particular filter, there's no relevance ranking, so it can stop after it has found ten matches, which should be pretty quick. This isn't currently supported by the QueryParser when using "-" on terms (the reasoning was that it was too easy to accidentally invoke when pasting text), but 'NOT label:inbox' will work if you enable it using QueryParser.FLAG_PURE_NOT. Cheers, Olly From wmorgan-sup@masanjin.net Tue Jul 28 13:01:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 10:01:43 -0700 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248709366-sup-5856@entry> Message-ID: <1248800452-sup-1121@masanjin.net> Reformatted excerpts from Olly Betts's message of 2009-07-28: > Actually, Xapian supports this - Xapian.Query.new("") is a "magic" > query which matches all documents. Yeah, I think Rich Lane just taught me how Ferret supports this too. -- William From marka@pobox.com Tue Jul 28 12:57:57 2009 From: marka@pobox.com (Mark Alexander) Date: Tue, 28 Jul 2009 12:57:57 -0400 Subject: [sup-talk] [PATCH] Make logging less chatty In-Reply-To: <1248794676-sup-7855@masanjin.net> References: <1248716313-sup-1608@javelin> <1248716783-sup-6509@ntdws12.chass.utoronto.ca> <1248794676-sup-7855@masanjin.net> Message-ID: On 7/28/09, William Morgan wrote: > ... but yes, the whole Redwood::log thing is crufty > and needs to be replaced with a logger that's aware of levels. Or maybe something combining types and levels that you could configure like this in config.yaml: :logging: :mbox: 2 :maildir: 3 :ferret: 0 ...etc... From ezyang@MIT.EDU Tue Jul 28 14:34:46 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Tue, 28 Jul 2009 14:34:46 -0400 Subject: [sup-talk] Reply calculation In-Reply-To: <1248794955-sup-3347@masanjin.net> References: <1248545266-sup-6886@javelin> <1248546228-sup-9505@javelin> <1248548497-sup-1158@javelin> <1248549271-sup-3371@javelin> <1248713182-sup-172@entry> <1248713591-sup-8324@javelin> <1248794955-sup-3347@masanjin.net> Message-ID: <1248805830-sup-2383@javelin> Excerpts from William Morgan's message of Tue Jul 28 11:48:48 -0400 2009: > > Unfortunately, mailing list administrating is notoriously broken. I'm not > > sure at all what the right solution is. Take for example this other case: > > > > From: person at example.com > > To: list at example.com > > Reply-To: person at example.com > > List-Post: mailto:list at example.com > > > > Reply-To, in this case, was set by the mailing list server. > > In this case, I'd argue that this means the list administrator wants the > default reply behavior to be to the individual and not the list. So I'd > again prefer Sup default to the reply-to address rather than the list > address. (With the caveat that this is overrideable by hooks on a > per-list basis, so if it's a matter of an incompetent list > administrator, or simply disagreeing with them, one can override this > behavior for this list.) Nods. > > However, consider the next case: > > > > From: persona at example.com > > To: list at example.com > > Cc: me at example.com > > > > Which is when someone else hit "Reply all" and you got CC'ed. This means > > that the mail never passed through the mailing list agent, the > > List-Post/Reply-To > > headers never got set, and the only way to tell that you should reply to the > > whole list is to explicitly ask for "Reply all" semantics (Sup defaults to > > "Reply" semantics, which is damn confusing if you're not paying attention). > > There's not much to be done in this case, EXCEPT that if you receive > more than one copy of the message, you should keep the list header > around. Then the only time you're in a funny situation is when you've > received the first but not the other. This situation is not that uncommon; many mailing list software will notice that someone is on a CC list and will purposely omit them. > I agree with this in principle, but I see addressing a message as a > fundamental part of composing it. You can remove the notion of a smart > default reply-to address from your Sup, if you like, by using the > reply-to hook. This is true. However, when you compose a non-reply message, Sup prompts you for To, Cc and Subject, because they are such fundamental components of all messages you would write (well, maybe not so much Cc) and the user always has to make a judgment call there. > And as for the default, I think I'm of the opinion that setting the > default reply address so as to obey the reply-to is correcter than > anything else (including whatever Sup does currently). Fair enough. You may get some complaints because this /will/ break muscle memory, and still presents the possibility for messages to have different behavior in subtle ways, as detailed in the Cc versus mailing list example from above. Cheers, Edward From kkourt@cslab.ece.ntua.gr Tue Jul 28 12:58:23 2009 From: kkourt@cslab.ece.ntua.gr (Kornilios Kourtis) Date: Tue, 28 Jul 2009 19:58:23 +0300 Subject: [sup-talk] [PATCH] handle malformed multiplart messages Message-ID: <20090728165823.GA29533@solar.cslab.ece.ntua.gr> Hi, I've tried to use sup-mail, but sup-sync blows up due to some malformed messages I keep in my mailbox. Below is a quick patch that seems to fix the above issue for me. Thanks, -- Kornilios Kourtis diff --git a/lib/sup/message.rb b/lib/sup/message.rb index ded577a..c6e6baf 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -385,11 +385,15 @@ private chunks elsif m.header.content_type == "message/rfc822" - payload = RMail::Parser.read(m.body) - from = payload.header.from.first - from_person = from ? Person.from_address(from.format) : nil - [Chunk::EnclosedMessage.new(from_person, payload.to_s)] + - message_to_chunks(payload, encrypted) + if m.body + payload = RMail::Parser.read(m.body) + from = payload.header.from.first + from_person = from ? Person.from_address(from.format) : nil + [Chunk::EnclosedMessage.new(from_person, payload.to_s)] + + message_to_chunks(payload, encrypted) + else + [Chunk::EnclosedMessage.new(nil, "")] + end else filename = ## first, paw through the headers looking for a filename From wmorgan-sup@masanjin.net Tue Jul 28 14:55:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 11:55:50 -0700 Subject: [sup-talk] error with Sup while sending mails In-Reply-To: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com> References: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com> Message-ID: <1248807059-sup-8075@masanjin.net> Hi Flo, Reformatted excerpts from paro 462's message of 2009-07-21: > --- NoMethodError from thread: poll after loading inbox > undefined method `to_indexable_s' for nil:NilClass > ./lib/sup/index.rb:243:in `sync_message' Interesting. You're the second person who's reported this. It has something to do with parsing a particular date. I'm not sure if it's locale-related... maybe. Can you try applying the following patch? I'm hoping that the debugging output prefixed with XX will provide a clue. --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -92,11 +92,14 @@ class Message begin Time.parse date rescue ArgumentError => e - #Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].inspect} gave error: #{e.message})" + Redwood::log "faking mangled date header for #{@id} (orig #{header['date'].inspect} gave error: #{e.message})" Time.now end - else - #Redwood::log "faking non-existent date header for #{@id}" + end + + @date ||= begin + Redwood::log "XX original header was #{header["date"].inspect}" + Redwood::log "XX faking non-existent date header for #{@id}" Time.now end -- William From wmorgan-sup@masanjin.net Tue Jul 28 15:05:39 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 12:05:39 -0700 Subject: [sup-talk] xapian question In-Reply-To: <1248795865-sup-6634@pion.club.cc.cmu.edu> References: <1248716325-sup-7534@masanjin.net> <1248795865-sup-6634@pion.club.cc.cmu.edu> Message-ID: <1248807365-sup-4965@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-07-28: > Xapian actually provides add_term and remove_term for documents. Excellent. > I'd definitely like to use these for label updates, but we need a way > to tell if only the labels have changed in sync_message. I've been running into this same issue with my sup-server experiments, so I think we should split the API into, say, three separate calls: something like add_new_message, update_labels, and update_body. (AFAIK the only client of update_body is in some of the draft editing stuff.) WDYT? > Or, we update the index in Message#add_label/etc and get rid of the > need to save buffers. That might not be an option for the Ferret > index, though. I think that would actually be fine for Ferret, and it's a direction that's often been discussed. (Especially now that we have undo.) If we do the above, we can certainly do this as a later step. > We don't store the body in entries.db, just enough info for > thread-index-mode. It's only about 800 bytes/message for me, but I > don't have snippets enabled so yours would be larger. On second glance, it's a little smaller than I remembered. For my sample 212m mbox, it's about 20m with snippets enabled. The total index size under Xapian (the xapian/ dir and all gdbm files) is larger than the original mbox file, which seems a little insane. But hey, disk space is cheap. -- William From wmorgan-sup@masanjin.net Tue Jul 28 15:10:57 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 28 Jul 2009 12:10:57 -0700 Subject: [sup-talk] Slow import of messages In-Reply-To: <20090713091516.GA21214@ikn.schottelius.org> References: <20090713091516.GA21214@ikn.schottelius.org> Message-ID: <1248808053-sup-5358@masanjin.net> Hi Nico, Reformatted excerpts from Nico Schottelius's message of 2009-07-13: > Now the problem is that sup gets about 3 mails per second into its > index. As others have pointed out, messages only have to be indexed once, so this isn't ultimately that big of a deal. But 3m/s seems very slow for a Maildir source. With my mbox on my reasonably-fast laptop, I start with around 50m/s using Ferret, and at 80m/s using Xapian. (These numbers degrade slightly as the index gets fuller.) I would expect similar numbers from Maildir. So something weird is happening for you. Do you have a notion of whether it's disk or CPU that's the bottleneck? -- William From iny+dev@iki.fi Wed Jul 29 02:09:42 2009 From: iny+dev@iki.fi (Ilpo =?iso-8859-1?Q?Nyyss=F6nen?=) Date: Wed, 29 Jul 2009 09:09:42 +0300 Subject: [sup-talk] Handling big mailing lists Message-ID: I'm searching alternatives for my Gnus email + news setup. I don't expect Sup to be able to do everything Gnus can yet, but maybe in future? :) Note that I have never used Gmail. I tried to test Sup, but I wasn't able to get any emails because Sup failed to login to my IMAP server. This happened because the server requires client certificates and it looks like Sup doesn't support those. The bigger question is about handling big amount of mailing list mail. I'm reading many small mailing lists and some big ones. Biggest is linux-kernel. I can split this to two: daily reading routine and expiration. How would my daily reading routine work with Sup? I want to read things in priority order: 1. Personal email 2. Emails related to my programming hobby 3. Emails related to some associations like user groups 4. Mailing lists, also in priority order The order is such that if I need to stop reading, I have read the most important ones already. The order is not static, I want to be able to change it. I have understood that labels are way to get this kind of grouping. Can I get a view where the labels are sorted like this? And can I continue reading the next label in that order after I have finished the one before? Then about the expiration. The linux-kernel mailing list gets so much email that some kind of expiration is a must. Can Sup do such automatic deleting of old emails? Can Sup handle some other process doing such automatic deletion? (I would actually prefer some other process do it.) I'm mostly reading just only few authors from linux-kernel and skipping rest, but I do like to see the rest in the thread view as sometimes some subject is interesting and sometimes some thread gets big and is interesting because of that. How would this work? I would actually recommend reading linux-kernel to test Sup. :) -- Ilpo Nyyss?nen # biny # /* :-) */ From marco-oweber@gmx.de Wed Jul 29 06:27:06 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Wed, 29 Jul 2009 12:27:06 +0200 Subject: [sup-talk] error with Sup while sending mails In-Reply-To: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com> References: <956dbab30907210305s1127ace3s315c8505c9c38141@mail.gmail.com> Message-ID: <1248863105-sup-6533@nixos> > undefined method `to_indexable_s' for nil:NilClass > ./lib/sup/index.rb:243:in `sync_message' > ./lib/sup/util.rb:519:in `send' sup-sync -c did it for me. I don't know what was wrong at all though. This will take some time. If you open index.rb:243 you may want to add a p m where m is the message object? Maybe the output will give you more insight as well. I hope sync helps you as well. Marc Weber From marco-oweber@gmx.de Wed Jul 29 08:54:11 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Wed, 29 Jul 2009 14:54:11 +0200 Subject: [sup-talk] Handling big mailing lists In-Reply-To: References: Message-ID: <1248871866-sup-9988@nixos> You can use hooks to add labels: my "~/.sup/hooks/before-add-message.rb": def matchR(email) not message.recipients.find{ |to| /^#{email}$/i =~ to.email}.nil? end def matchRAddLabel(email, label, inbox = 0) if matchR email then message.add_label label message.remove_label :inbox unless inbox end end def importantFrom(email) message.add_label :Starred if message.from.email == email end importantFrom "info at webkos.de" matchRAddLabel("mod_python at modpython.org","mod-python", 1) matchRAddLabel("mod_python at modpython.org","mod-python", 0) if message.subj =~ /^Project Notification$/ && message.from.email == "info at guru.com" then message.add_label "GURU_PROJECT_NOTIFICATION" message.add_label "delete_after_one_month" end if message.subj =~ /^WEBKOS_/ then message.remove_label :inbox message.add_label "WEBKOS_" end So adding labels onle if a contsraint is met is easy. About deleting mails: There is sup-sync-back. So there must be a way to delete "old" / whatever mails. I haven't used it yet. I'm new to sup myself. Yours Marc Weber From wmorgan-sup@masanjin.net Wed Jul 29 09:46:19 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 29 Jul 2009 06:46:19 -0700 Subject: [sup-talk] Handling big mailing lists In-Reply-To: References: Message-ID: <1248874122-sup-3830@masanjin.net> Hi, Excellent set of questions. Handling large volumes of mail is one of my main goals with Sup. Reformatted excerpts from iny+dev's message of 2009-07-28: > I tried to test Sup, but I wasn't able to get any emails because Sup > failed to login to my IMAP server. This happened because the server > requires client certificates and it looks like Sup doesn't support > those. As far as IMAP goes, Sup supports whatever authentication the Ruby IMAP libraries supports, which is probably not much. Any serious use of Sup with IMAP is best done via an intermediate like offlineimap, which syncs an IMAP folder to a local Maildir folder. The Ruby IMAP libraries, and possibly IMAP itself, is a little too slow for how Sup likes to work. > How would my daily reading routine work with Sup? I want to read > things in priority order: > > 1. Personal email > 2. Emails related to my programming hobby > 3. Emails related to some associations like user groups > 4. Mailing lists, also in priority order Sup gives you two tools: search and labels. Sup will present a list of threads that match any search query. So, each of those steps is possible, to the extent that you can compose a search query that reflects it. You can automatically add labels via arbitrary code, so you have a fair amount of flexibility here. > The order is such that if I need to stop reading, I have read the most > important ones already. The order is not static, I want to be able to > change it. I have understood that labels are way to get this kind of > grouping. Can I get a view where the labels are sorted like this? Sup currently only orders chronologically. It would not be difficult to add a second level of user-defined sorting *on top* of the chronological one, but it would be difficult, if not impossible, to order all email in the index by an arbitrary function. (To be pedantic, if you can come up with a single number for each email, which never changes, and which is known at add time, you can order by that, with some work. But it doesn't sound like that's what you want.) > And can I continue reading the next label in that order after I have > finished the one before? Certainly, but not automatically. You can view one label, and then pick another label to view, etc. I suppose if the above second-round of ordering were implemented, you could view both labels at once and make an ordering function that placed one above the other. > Then about the expiration. The linux-kernel mailing list gets so much > email that some kind of expiration is a must. You don't want to just buy a bigger hard drive? > Can Sup do such automatic deleting of old emails? Can Sup handle some > other process doing such automatic deletion? (I would actually prefer > some other process do it.) That's best left to another process. You'll then have to tell Sup which messages were deleted so that it can remove them from the index. Let me know when you're at this point and I can help you---it will require a brief Ruby script. > I would actually recommend reading linux-kernel to test Sup. :) I read ruby-talk, which is probably not too far off. One last comment: large threads are irritatingly slow to create in thread-view-mode with the Ferret index, but there's a new Xapian index which is fast for this. It's still slightly experimental. -- William From iny+dev@iki.fi Wed Jul 29 13:24:43 2009 From: iny+dev@iki.fi (Ilpo =?iso-8859-1?Q?Nyyss=F6nen?=) Date: Wed, 29 Jul 2009 20:24:43 +0300 Subject: [sup-talk] Handling big mailing lists References: <1248874122-sup-3830@masanjin.net> Message-ID: William Morgan writes: > Sup currently only orders chronologically. It would not be difficult to > add a second level of user-defined sorting *on top* of the chronological > one, but it would be difficult, if not impossible, to order all email in > the index by an arbitrary function. I'm not talking about ordering of emails, I'm talking about ordering of the labels. When I start my daily routine, I want to see a list of labels with numbers telling how many unread emails each has. Labels containing nothing new must be hidden. And this list must be sorted to priority order. Then I want to read those labels through in that order. How many labels would I have? At least tens, probably over hundred. >> And can I continue reading the next label in that order after I have >> finished the one before? > > Certainly, but not automatically. You can view one label, and then pick > another label to view, etc. Picking one from alphabetically sorted list or writing it is not usable. I don't remember the order, I just want to get the next one. >> Then about the expiration. The linux-kernel mailing list gets so much >> email that some kind of expiration is a must. > > You don't want to just buy a bigger hard drive? It's not a disk space problem. The problem is that many things would get slow (or I would need to configure exceptions) and I just do not have any need for them. They are all in searchable mailing list archives anyway. And another point is that I actually prefer not to order mailing lists. It is much easier to just get them with nntp from news.gmane.org. How? I have a nntp to imap gateway and I use it to read also from other nntp servers. The thing here is that nntp servers usually do expire messages and so to be able to use that with Sup, it would need to tolerate the expiration. > That's best left to another process. You'll then have to tell Sup which > messages were deleted so that it can remove them from the index. So, I don't do the expiration. I guess it should be possible to find out the ones that went away when checking for new ones. > Let me know when you're at this point and I can help you---it will > require a brief Ruby script. Well, it is looking like in current state I won't even start trying. >> I would actually recommend reading linux-kernel to test Sup. :) > > I read ruby-talk, which is probably not too far off. Hmm, http://dir.gmane.org/gmane.comp.lang.ruby.general http://dir.gmane.org/gmane.linux.kernel I guess so. How long it takes to index few months of ruby-talk? Could Sup use IMAP search features? -- Ilpo Nyyss?nen # biny # /* :-) */ From dato@net.com.org.es Thu Jul 30 11:56:56 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Thu, 30 Jul 2009 17:56:56 +0200 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <1248713434-sup-4961@entry> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry> Message-ID: <20090730155656.GA20442@chistera.yi.org> + William Morgan (Mon, 27 Jul 2009 09:51:17 -0700): > Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23: > > + Adeodato Sim? (Fri, 10 Jul 2009 17:00:29 +0200): > > > + :charset => encoded_content.charset, > > Hm, so apparently encoded_content doesn't always have a charset > > member... > In which case that value of that variable is nil, right? Is that a > problem? The patch still seems useful. Yes, I took a closer look and you're right the result of encoded_content.charset is nil in that case. I also saw (I think) where the traceback I was seeing is coming from: apparently it's not possible to pass to HookContext a local that is nil, since then "super" will get called in HookContext::method_missing() as far as I can see. So, perhaps, to fix this patch, one could do: :charset => encoded_content.charset || '' But then, I think it would be better to fix HookContext to allow for @__locals to contain nil. I'm not very familiar with that class, but it seems easy enough to fix, see upcoming patch (also found in ~dato/sup/sup-dato:fixes at Gitorious, if you prefer that). With it, this improvement to mime-decode seems to work without any further trouble. Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai From dato@net.com.org.es Thu Jul 30 11:57:16 2009 From: dato@net.com.org.es (=?utf-8?q?Adeodato=20Sim=C3=B3?=) Date: Thu, 30 Jul 2009 17:57:16 +0200 Subject: [sup-talk] [PATCH] HookContext::method_missing(): allow locals to be nil In-Reply-To: <20090730155656.GA20442@chistera.yi.org> References: <20090730155656.GA20442@chistera.yi.org> Message-ID: With the previous implementation of method_missing() in HookContext, it was not possible to set the value of a local to nil, since that would be assumed to mean "that local does not exist" and super would get called. Now we use has_key? to check whether the local exists or not, and nil will be returned normally from method_missing if that's the value of the @__locals[name]. Signed-off-by: Adeodato Sim? --- lib/sup/hook.rb | 12 +++++++----- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb index 0a0a2f6..8a52a96 100644 --- a/lib/sup/hook.rb +++ b/lib/sup/hook.rb @@ -20,13 +20,15 @@ class HookManager attr_writer :__locals def method_missing m, *a - case @__locals[m] - when Proc - @__locals[m] = @__locals[m].call(*a) # only call the proc once - when nil + if not @__locals.has_key? m super else - @__locals[m] + case @__locals[m] + when Proc + @__locals[m] = @__locals[m].call(*a) # only call the proc once + else + @__locals[m] + end end end -- 1.6.3.3 From tom@dbservice.com Thu Jul 30 14:31:12 2009 From: tom@dbservice.com (Tomas Carnecky) Date: Thu, 30 Jul 2009 20:31:12 +0200 Subject: [sup-talk] sup on opensolaris Message-ID: Kids, don't try this at home, it kills kittens! Well, not directly, but trying to get sup running will drive you so mad you will try to kill everything that moves. In other words: it doesn't work and the fact that I'm trying this on opensolaris doesn't make it any easier. The biggest issue is that the ruby binary from the package manager is linked against the ancient solaris curses.so but ruby-ncurses needs ncurses.so (which, to make the issue even more complicated, is in /usr/ gnu/lib). When both libraries are liked into one application, they don't play along well (=segfaults). I had to compile ruby from source and make sure it's not liked with curses.so, and also patch ruby- ncurses slightly. I then managed to get sup to start up and read my mails. However, there is one issue left that I'm not able to fix: Ncurses.field.field_buffer() is returning garbage, and that makes is impossible to write mails, search and set tags etc. The problem is somewhere inside sup, as the ruby-ncurses example form2.rb is working just fine (maybe it has something to do with encoding/locale?). I have an ugly patch for lib/sup/textfield.rb that uses its own string buffer instead of relying on field_buffer(). It's not perfect, but it at least allows me to write emails and assign tags. Other issues: - strftime("%P") is a GNU extension, I work around this by using strftime("%p").downcase. - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "// IGNORE" is causing an InvalidEncoding exception, removing it didn't seem to cause any regressions tom From garoth@gmail.com Fri Jul 31 11:17:28 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 31 Jul 2009 11:17:28 -0400 Subject: [sup-talk] Smooth Paging Message-ID: <1249053249-sup-9884@Longbow> Hello, One thing's that I've found a bit suboptimal in Sup has been the paging ie. scrolling of e-mails. When you reach the bottom, it scrolls the whole page up, rather than scrolling smoothly as might be the default behaviour of Vim for example. I find this really awkward at times, since I can't see what I just read while reading the next line. It's also just kind of jumpy. One main use case that his damages is when I'm doing patch review on mailing lists and stuff. I'll open a long e-mail with diffs in it, and I will be scrolling to see the patch. Then, as I reach the bottom, it jumps and hides what I just read, making understanding code logic painful at times. So then I have to jump up and down some more to figure it out, but that sucks because I have to look between the top and bottom of the screen. What do you guys think? -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From garoth@gmail.com Fri Jul 31 11:23:07 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 31 Jul 2009 11:23:07 -0400 Subject: [sup-talk] Sup Resource Usage Message-ID: <1249053483-sup-9050@Longbow> This isn't a serious complaint, but I'd just like to bring a couple things with respect to Sup resource usage to the light. According to top, Sup uses a fair bit of ram: about 30 MB at any point. For comparison, pidgin uses about that much, and firefox uses 4x more. That's generally acceptable, but more than I'd expect from a CLI app. This is probably unavoidable. What I find a bit more curious is Sup's wakeups. According to powertop, sup is actually one of the top power munchers on my computers. I don't understand why it has to wake up as often as it does: it's responsible for 20% of all wakeups, with a rating of ~115. By comparison, firefox does almost exactly the same amount of wakeups, and sup is the third thing on my list, way above my window manager/de which does considerably more. I wonder what could be up here. Anyway, I'm fine with it if it's un-investigated. Cheers. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From ezyang@MIT.EDU Fri Jul 31 11:38:00 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 31 Jul 2009 11:38:00 -0400 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249053249-sup-9884@Longbow> References: <1249053249-sup-9884@Longbow> Message-ID: <1249054651-sup-1510@javelin> Excerpts from Andrei Thorp's message of Fri Jul 31 11:17:28 -0400 2009: > One thing's that I've found a bit suboptimal in Sup has been the paging > ie. scrolling of e-mails. When you reach the bottom, it scrolls the > whole page up, rather than scrolling smoothly as might be the default > behaviour of Vim for example. I agree with this assessment and think smoother scrolling would be a nice extra touch. Cheers, Edward From wmorgan-sup@masanjin.net Fri Jul 31 11:43:26 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 31 Jul 2009 08:43:26 -0700 Subject: [sup-talk] Sup Resource Usage In-Reply-To: <1249053483-sup-9050@Longbow> References: <1249053483-sup-9050@Longbow> Message-ID: <1249054758-sup-9479@masanjin.net> Reformatted excerpts from Andrei Thorp's message of 2009-07-31: > What I find a bit more curious is Sup's wakeups. According to > powertop, sup is actually one of the top power munchers on my > computers. I don't understand why it has to wake up as often as it > does: it's responsible for 20% of all wakeups, with a rating of ~115. What's the wakeup behavior of "ruby -esleep"? What's the behavior of this Ruby program: require 'rubygems' require 'ncurses' Ncurses.initscr c = Ncurses.getch Ncurses.endwin puts c I'd also be curious if things change under Ruby 1.9.1, since I'd like to move to that as soon as feasible. -- William From wmorgan-sup@masanjin.net Fri Jul 31 11:44:25 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 31 Jul 2009 08:44:25 -0700 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249053249-sup-9884@Longbow> References: <1249053249-sup-9884@Longbow> Message-ID: <1249055039-sup-8105@masanjin.net> Reformatted excerpts from Andrei Thorp's message of 2009-07-31: > What do you guys think? Have you tried J and K vs j and k to scroll? -- William From ezyang@MIT.EDU Fri Jul 31 11:46:40 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 31 Jul 2009 11:46:40 -0400 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249055039-sup-8105@masanjin.net> References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net> Message-ID: <1249055175-sup-4619@javelin> Excerpts from William Morgan's message of Fri Jul 31 11:44:25 -0400 2009: > Have you tried J and K vs j and k to scroll? In general, I use PgUp and PgDn to scroll. I didn't realize those keybindings existed. :-) Cheers, Edward From wmorgan-sup@masanjin.net Fri Jul 31 11:56:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 31 Jul 2009 08:56:52 -0700 Subject: [sup-talk] sup on opensolaris In-Reply-To: References: Message-ID: <1249055178-sup-7149@masanjin.net> Hi Tom, Thanks for the report! It's nice to have another system "supported", at least technically. Reformatted excerpts from Tomas Carnecky's message of 2009-07-30: > However, there is one issue left that I'm not able to fix: > Ncurses.field.field_buffer() is returning garbage, and that makes is > impossible to write mails, search and set tags etc. The problem is > somewhere inside sup, as the ruby-ncurses example form2.rb is working > just fine (maybe it has something to do with encoding/locale?). The ncurses field stuff is some hellish bullshit that I hate with all my heart. It may very well be a locale problem... I really don't want to debug it. > I have an ugly patch for lib/sup/textfield.rb that uses its own string > buffer instead of relying on field_buffer(). It's not perfect, but it > at least allows me to write emails and assign tags. If it's not too much work to clean up, I'd be interested in this patch. The field buffer stuff is broken in weird ways anyways (the history never seems to be quite right), and anything that reduces the reliance on ncurses is always the right approach. > - strftime("%P") is a GNU extension, I work around this by using > strftime("%p").downcase. Submit a patch! I'm fine with this. > - Iconv.iconv(target + "//IGNORE", charset, text + " ") <- the "// > IGNORE" is causing an InvalidEncoding exception, removing it didn't > seem to cause any regressions Hm, this is a trickier one. Allegedly the //IGNORE reduces the exceptions thrown by Iconv, but since we're catching them all anyways, we might be able to get away with removing this. Or we could special-case it to your arch. -- William From wmorgan-sup@masanjin.net Fri Jul 31 11:57:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 31 Jul 2009 08:57:43 -0700 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249055175-sup-4619@javelin> References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net> <1249055175-sup-4619@javelin> Message-ID: <1249055837-sup-9394@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-07-31: > In general, I use PgUp and PgDn to scroll. I didn't realize those > keybindings existed. :-) Ctrl-e and ctrl-y work as well, if you're a vi addict. -- William From garoth@gmail.com Fri Jul 31 12:00:00 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 31 Jul 2009 12:00:00 -0400 Subject: [sup-talk] Sup Resource Usage In-Reply-To: <1249054758-sup-9479@masanjin.net> References: <1249053483-sup-9050@Longbow> <1249054758-sup-9479@masanjin.net> Message-ID: <1249055796-sup-2690@Longbow> Excerpts from William Morgan's message of Fri Jul 31 11:43:26 -0400 2009: > What's the wakeup behavior of "ruby -esleep"? Well, you can easily test this yourself with powertop, but just running this command does not cause a lot of wakeups. (It's not in the top causes list.) > What's the behavior of this Ruby program: > > require 'rubygems' > require 'ncurses' > > Ncurses.initscr > c = Ncurses.getch > Ncurses.endwin > > puts c This program exits right away, so I don't really know how to test it. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From garoth@gmail.com Fri Jul 31 12:01:08 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 31 Jul 2009 12:01:08 -0400 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249055039-sup-8105@masanjin.net> References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net> Message-ID: <1249056026-sup-1964@Longbow> Excerpts from William Morgan's message of Fri Jul 31 11:44:25 -0400 2009: > Reformatted excerpts from Andrei Thorp's message of 2009-07-31: > > What do you guys think? > > Have you tried J and K vs j and k to scroll? No I haven't, but I'm glad to know they exist :) Thanks. -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From garoth@gmail.com Fri Jul 31 12:11:29 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 31 Jul 2009 12:11:29 -0400 Subject: [sup-talk] Smooth Paging In-Reply-To: <1249055837-sup-9394@masanjin.net> References: <1249053249-sup-9884@Longbow> <1249055039-sup-8105@masanjin.net> <1249055175-sup-4619@javelin> <1249055837-sup-9394@masanjin.net> Message-ID: <1249056674-sup-2428@Longbow> Excerpts from William Morgan's message of Fri Jul 31 11:57:43 -0400 2009: > Reformatted excerpts from Edward Z. Yang's message of 2009-07-31: > > In general, I use PgUp and PgDn to scroll. I didn't realize those > > keybindings existed. :-) > > Ctrl-e and ctrl-y work as well, if you're a vi addict. I didn't even know that one o_0. (in vim) -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) From rlane@club.cc.cmu.edu Fri Jul 31 12:20:41 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 31 Jul 2009 12:20:41 -0400 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248710432-sup-1734@pion.club.cc.cmu.edu> References: <1245531017-9907-1-git-send-email-rlane@club.cc.cmu.edu> <1245854803-sup-4481@entry> <1245864733-sup-1216@entry> <1246022094-sup-3336@entry> <1247873980-sup-8574@wrasse> <20090723102325.GA4291@chistera.yi.org> <1248497184-sup-939@pion.club.cc.cmu.edu> <1248513425-sup-2484@chistera.yi.org> <1248550384-sup-74@pion.club.cc.cmu.edu> <1248709681-sup-4141@entry> <1248710432-sup-1734@pion.club.cc.cmu.edu> Message-ID: <1249056691-sup-9011@pion.club.cc.cmu.edu> Excerpts from Rich Lane's message of Mon Jul 27 13:06:34 -0400 2009: > Excerpts from William Morgan's message of Mon Jul 27 11:48:38 -0400 2009: > > Reformatted excerpts from Rich Lane's message of 2009-07-25: > > > One issue I've noticed is that removing labels from messages doesn't > > > always immediately work. > > > > Is this true even after you sync changes to the index? What about if you > > reload the label list buffer? ('@') > > Yes. This is looking like a Xapian bug - I've reproduced it without any > Sup code. I'm working on a fix. I've fixed this, it should be released in Xapian 1.0.15. Or, grab Xapian SVN and you can try out the Chert backend too (XAPIAN_PREFER_CHERT=1). From bwalton@artsci.utoronto.ca Fri Jul 31 12:59:16 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 31 Jul 2009 12:59:16 -0400 Subject: [sup-talk] sup on opensolaris In-Reply-To: <1249055178-sup-7149@masanjin.net> References: <1249055178-sup-7149@masanjin.net> Message-ID: <1249059493-sup-7953@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Fri Jul 31 11:56:52 -0400 2009: > Thanks for the report! It's nice to have another system "supported", at > least technically. I'm the ruby maintainer for OpenCSW, which provides binary packages for solaris 8+ linked against a modern curses. Everything lives in /opt/csw/, so it's self contained except where linking to system stuff. I _think_ this should all work on opensolaris (but I don't use it) if you're interested in trying it. That won't help things like %P (%z is another common offender I come across), but it may make part of your life easier. You'll get a modern libiconv too, although the version in opensolaris shouldn't be that old? http://www.opencsw.org/ HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: