From ingmar@exherbo.org Tue Sep 1 04:07:27 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Tue, 01 Sep 2009 10:07:27 +0200 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1248713376-sup-5163@cannonball> 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> <1248713376-sup-5163@cannonball> Message-ID: <1251792282-sup-2057@cannonball> Excerpts from Ingmar Vanhassel's message of Mon Jul 27 18:56:28 +0200 2009: > 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 can still reproduce this for a more specific case, with xapian 1.0.15. Searching for is:unread (hit U), works as expected. When I filter that with threads having a second label (hit |, label:foo), then it shows threads with label:foo, but it loses the is:unread constraint. Same for immediately doing is:unread label:foo, which gives me unread threads, but not always with the foo label. -- Exherbo KDE, X.org maintainer From israel.herraiz@gmail.com Tue Sep 1 04:51:28 2009 From: israel.herraiz@gmail.com (Israel Herraiz) Date: Tue, 01 Sep 2009 10:51:28 +0200 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post is not present In-Reply-To: <1251773879-sup-5227@masanjin.net> References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net> Message-ID: <1251794935-sup-3802@elly> Excerpts from William Morgan's message of Tue Sep 01 04:58:47 +0200 2009: > Does this patch work for you? Yes, although list-id is not an address (it does not contain the "@" symbol for instance). But I am happy with that patch :-). Cheers, Israel From wmorgan-sup@masanjin.net Tue Sep 1 16:59:56 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 01 Sep 2009 13:59:56 -0700 Subject: [sup-talk] [PATCH] add xapian-specific hack to quickly create a Person In-Reply-To: <1251250991-sup-3593@zyrg.net> References: <1250965695-31073-1-git-send-email-rlane@club.cc.cmu.edu> <1250967263-31292-1-git-send-email-rlane@club.cc.cmu.edu> <1251156216-sup-5563@masanjin.net> <1251250991-sup-3593@zyrg.net> Message-ID: <1251838745-sup-376@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-25: > The slow part is the processing in Person#initialize, which > QuickPerson overrides. You might also be able to avoid that by moving > the initialize() code into Person.from_address. Yeah, I think that's a better approach. There's no need for the constructor to do all that work. I'll work on this when I get a chance, or feel free to beat me to it. -- William From rlane@club.cc.cmu.edu Tue Sep 1 23:59:57 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 01 Sep 2009 23:59:57 -0400 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks In-Reply-To: <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu> <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1251863327-sup-8206@zyrg.net> Just making sure these patches don't drop off your radar. I know searching is supposed to make scrolling obsolete, but some Mutt users asked for this. They'll see the light eventually. From wmorgan-sup@masanjin.net Wed Sep 2 09:50:13 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 02 Sep 2009 06:50:13 -0700 Subject: [sup-talk] Nobody told me In-Reply-To: <1e5fdab70908281401k7f0b59ectb38ce7dfe7280569@mail.gmail.com> References: <1e5fdab70908270518k3f349191jb5e780e0e0555461@mail.gmail.com> <1251491725-sup-284@masanjin.net> <1e5fdab70908281401k7f0b59ectb38ce7dfe7280569@mail.gmail.com> Message-ID: <1251899343-sup-1025@masanjin.net> Reformatted excerpts from Guillaume Quintard's message of 2009-08-28: > arg, when I try to restore, I get this: > ./lib/sup/crypto.rb:157:in ``': Cannot allocate memory - /usr/bin/gpg --quiet --batch --no-verbose --logger-fd 1 --use-agent --verify /tmp/31666-0-redwood.signature /tmp/31666-0-redwood.payload 2> /dev/null (Errno::ENOMEM) If anyone else has been having memory usage problems on the next branch recently (probably when sup-syncing a large mbox file), they should be fixed now. I've unmerged the after-add hook, which was the culprit. -- William From wmorgan-sup@masanjin.net Wed Sep 2 09:53:17 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 02 Sep 2009 06:53:17 -0700 Subject: [sup-talk] [PATCH] Add an after-add-message hook In-Reply-To: <1251153881-sup-1538@masanjin.net> References: <1250707991-sup-5429@masanjin.net> <1250819862-4858-1-git-send-email-kevinr@free-dissociation.com> <1251153881-sup-1538@masanjin.net> Message-ID: <1251899447-sup-1658@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-08-24: > Branch after-add-message-hook, merged into next. Thanks! I've had to unmerge this, because keeping all the messages around led to memory problems with large mailboxes. What about just using the before-add hook and either backgrounding the process (if it's a separate process) or doing the processing in a Thread (if it's Ruby code)? -- William From marco-oweber@gmx.de Thu Sep 3 10:24:32 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Thu, 03 Sep 2009 16:24:32 +0200 Subject: [sup-talk] Trouble loading dump into Xapian index Message-ID: <1251987692-sup-9940@nixos> I've used this sh script to get a new SUP_BASE using xapian only: However somehow i couldn't import the tags? What have I done wrong? dump2: The dump file created from the xapian index. set -x OLD=~/.sup-old/ NEW=~/.sup-new-test DUMP=/tmp/dump-file-new DUMP2=/tmp/dump-file-new2 SYNC_LOG=/tmp/sup-sync-log GIT_REPO=~/managed_repos/sup_mainline rm -fr $NEW export SUP_BASE=$OLD sup-dump > $DUMP # from now on operate on the new base only export SUP_BASE=$NEW cp -r $OLD $NEW rm -fr $NEW/ferret mv $NEW/{hooks,hooks-disabled} # echo loading stuff.. export SUP_INDEX=xapian cd $GIT_REPO echo "syncing.. this will take long. use tail -f $SYNC_LOG to watch progress" ruby -Ilib bin/sup-sync --all --all-sources --restore $DUMP &> $SYNC_LOG echo "writing dump" ruby -Ilib bin/sup-dump > $DUMP2 dump: (first line after sorting) 000001c9fe57$346bf530$9d43df90$@com.au (unread openeeg) dump2: (first line after sorting) 000001c9fe57$346bf530$9d43df90$@com.au (inbox unread) Marc Weber From amit.kucheria@gmail.com Thu Sep 3 10:26:40 2009 From: amit.kucheria@gmail.com (Amit Kucheria) Date: Thu, 3 Sep 2009 17:26:40 +0300 Subject: [sup-talk] Dynamic list of maildir folders as sources Message-ID: <20090903142640.GB4465@matterhorn.verdurent.com> Hi, I've been watching sup for a while and finally decided to take the plunge today. Apologies for the long-winded explanation before the real question, but I guess if something in my workflow could be optimised, someone might be able to point it out here. I'll be running sup on a bunch of maildir folders downloaded via offlineimap. All my mail comes as IMAP from 3 gmail accounts. When I subscribe to a new mailing list, I simply create a new filter in gmail to add a new tag to email from that list and skip the inbox. This shows up as a new maildir folder on my local machine. Mutt finds this new folder using the following folder-hook hack I have in my .muttrc: folder-hook +foo.* mailboxes `find ~/Mail/foo -type d -name cur -type d -printf '%h\n' | sort | tr '\012' ' '` , where foo is one of my mailboxes. So I have ~/Mail/bar and ~/Mail/foobar for my other accounts. Each of these have several maildir folder in them. I've run sup-config and it seems to expect that I list every maildir folder I've got. Is there a way to generate this dynamically? Regards, Amit p.s. sup-sync has been at it on my lkml folder with ~40K mail messages for 30mins now. -- ------------------------------------------------------------ Amit Kucheria ------------------------------------------------------------ From wmorgan-sup@masanjin.net Thu Sep 3 11:25:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 08:25:50 -0700 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1251987692-sup-9940@nixos> References: <1251987692-sup-9940@nixos> Message-ID: <1251991420-sup-3869@masanjin.net> Reformatted excerpts from Marc Weber's message of 2009-09-03: > I've used this sh script to get a new SUP_BASE using xapian only: > However somehow i couldn't import the tags? What have I done wrong? This *might* be related to a patch that Rich sent that I thought I had applied, but apparently did not. Can you try once more with the latest master? If it still doesn't work we'll take it from there. (Also, check that the number of messages sup-sync reports it has restored state on is the number of messages you'd expect, e.g. roughly the number of lines in the dumpfile.) -- William From wmorgan-sup@masanjin.net Thu Sep 3 11:37:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 08:37:50 -0700 Subject: [sup-talk] Dynamic list of maildir folders as sources In-Reply-To: <20090903142640.GB4465@matterhorn.verdurent.com> References: <20090903142640.GB4465@matterhorn.verdurent.com> Message-ID: <1251991617-sup-9735@masanjin.net> Reformatted excerpts from Amit Kucheria's message of 2009-09-03: > I've been watching sup for a while and finally decided to take the > plunge today. Welcome! > I've run sup-config and it seems to expect that I list every maildir > folder I've got. Is there a way to generate this dynamically? If you can generate the list (e.g. with the find command you cited), you can add maildir sources with sup-add directly, instead of having to go through sup-config. If you want to automatically detect and add new folders, we could d something similar in the startup hook. Something like (completely untested): dirs = `find ~/Mail/whatever...` dirs.each do |d| uri = "maildir:#{d}" log "trying #{uri}..." unless SourceManager.source_for uri source = Maildir.new uri SourceManager.add_source source log "Added #{uri}" end end > p.s. sup-sync has been at it on my lkml folder with ~40K mail messages > for 30mins now. Yep, indexing stuff is slow. FWIW, you only have to do it once, and there are new index backends that are significantly faster. (But still far from instantaneous.) -- William From marco-oweber@gmx.de Thu Sep 3 12:21:31 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Thu, 03 Sep 2009 18:21:31 +0200 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1251991420-sup-3869@masanjin.net> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> Message-ID: <1251994802-sup-8575@nixos> Hi William. I guess it was. The second dump looks very similar to the first one now. Only the order of flags is different now which doesn't matter. However threads which have been killed do show up in inbox: http://mawercer.de/~marc/sup.png All seven mails of the first thread are labeled by killed inbox deleted So they shouldn't appear, should they? Same happens to thread where all mails are labeled by killed, inbox Did the view behaviour change here? Sincerly Marc From mzulak@gmail.com Thu Sep 3 12:38:53 2009 From: mzulak@gmail.com (Matt Zulak) Date: Thu, 3 Sep 2009 12:38:53 -0400 Subject: [sup-talk] [PATCH] decrypt returns 3 elem array if gpg is unavailable Message-ID: <1251995933-2252-1-git-send-email-mzulak@gmail.com> CryptoManager's decrypt method returns a CryptoNotice if the GPG binary can't be found on the path; however, the Message class expects a 3 element array with either a RMail::Message or nil at index 0. This patch ensures sup plays nice when importing encrypted messages from a mail-store on an environment that does not have GPG. --- lib/sup/crypto.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb index 7f044b9..afbc445 100644 --- a/lib/sup/crypto.rb +++ b/lib/sup/crypto.rb @@ -105,7 +105,7 @@ class CryptoManager ## returns decrypted_message, status, desc, lines def decrypt payload # a RubyMail::Message object - return unknown_status(cant_find_binary) unless @cmd + return [nil, nil, unknown_status(cant_find_binary)] unless @cmd payload_fn = Tempfile.new "redwood.payload" payload_fn.write payload.to_s -- 1.6.2.1 From rlane@club.cc.cmu.edu Thu Sep 3 12:42:55 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 03 Sep 2009 12:42:55 -0400 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1251994802-sup-8575@nixos> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> <1251994802-sup-8575@nixos> Message-ID: <1251995984-sup-7983@zyrg.net> Excerpts from Marc Weber's message of Thu Sep 03 12:21:31 -0400 2009: > However threads which have been killed do show up in inbox: > http://mawercer.de/~marc/sup.png > All seven mails of the first thread are labeled by > killed inbox deleted > > So they shouldn't appear, should they? > > Same happens to thread where all mails are labeled by > killed, inbox > > Did the view behaviour change here? I added support for thread killing in 4d82ef88, which hasn't been merged to master yet. If you'd like to use the Xapian index I suggest using next for now. From rlane@club.cc.cmu.edu Thu Sep 3 12:52:27 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 03 Sep 2009 12:52:27 -0400 Subject: [sup-talk] [PATCH 0/18] Xapian-based index In-Reply-To: <1251792282-sup-2057@cannonball> 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> <1248713376-sup-5163@cannonball> <1251792282-sup-2057@cannonball> Message-ID: <1251996241-sup-5112@zyrg.net> Excerpts from Ingmar Vanhassel's message of Tue Sep 01 04:07:27 -0400 2009: > Excerpts from Ingmar Vanhassel's message of Mon Jul 27 18:56:28 +0200 2009: > > 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 can still reproduce this for a more specific case, with xapian 1.0.15. > > Searching for is:unread (hit U), works as expected. When I filter > that with threads having a second label (hit |, label:foo), then it > shows threads with label:foo, but it loses the is:unread constraint. > > Same for immediately doing is:unread label:foo, which gives me unread > threads, but not always with the foo label. I've reproduced this and it looks like a query parsing problem. Multiple terms on the same field are OR'd together instead of AND [1]. Adding an explicit AND works. I'll see if Xapian::QueryParser can be convinced to do what we want here. [1] http://trac.xapian.org/ticket/157 From wmorgan-sup@masanjin.net Thu Sep 3 13:12:25 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 10:12:25 -0700 Subject: [sup-talk] [PATCH] Be less overzealous in moving text to the left column In-Reply-To: <1251323127-sup-5162@yoom.home.cworth.org> References: <1250749447-sup-1744@yoom.home.cworth.org> <1251050007-sup-9740@masanjin.net> <1251323127-sup-5162@yoom.home.cworth.org> Message-ID: <1251997795-sup-8368@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-26: > And I still haven't figured out what loose_alignment means and which > actions will cause loose vs. non-loose layout. Yeah, it's not really clear where I was going with that. The whole thing was in need of some rethinking and additional comments. I've made a branch 'alignment-tweaks', merged into next, which I think has the behavior you were looking for: left-column movement is minimized when using 'n' and 'p' to jump between messages. You can also use 'z' to align the left column with the current message. Check it out and let me know what you think. If this bugs people, also let me know. :) -- William From wmorgan-sup@masanjin.net Thu Sep 3 13:13:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 10:13:59 -0700 Subject: [sup-talk] sup crashed: NoMethodError In-Reply-To: <20090828225041.GA22963@gmail.com> References: <20090827200317.GA3065@gmail.com> <1251492008-sup-6128@masanjin.net> <20090828225041.GA22963@gmail.com> Message-ID: <1251997975-sup-8342@masanjin.net> Reformatted excerpts from Sean Escriva's message of 2009-08-28: > was my install process wrong for switching to the git -next branch? Nope, it was fine. Transitioning between master and next should generally be painless. -- William From wmorgan-sup@masanjin.net Thu Sep 3 13:16:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 10:16:41 -0700 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1251995984-sup-7983@zyrg.net> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> <1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net> Message-ID: <1251998177-sup-3432@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-03: > I added support for thread killing in 4d82ef88, which hasn't been > merged to master yet. If you'd like to use the Xapian index I suggest > using next for now. If you feel it's reasonably stable, I can merge it into master. -- William From marco-oweber@gmx.de Thu Sep 3 13:26:59 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Thu, 03 Sep 2009 19:26:59 +0200 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1251995984-sup-7983@zyrg.net> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> <1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net> Message-ID: <1251998504-sup-6794@nixos> > I added support for thread killing in 4d82ef88, which hasn't been merged > to master yet. If you'd like to use the Xapian index I suggest using > next for now. Hi Rich, using next I get the following error: + ruby -Ilib bin/sup-sync --all --all-sources --restore /tmp/dump-file-new ./lib/sup/crypto.rb:17: warning: Insecure world writable dir /pr/webkos in PATH, mode 040777 Loading state dump from /tmp/dump-file-new... Read 39048 entries from dump file. ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects a v1 index, but you have an existing v0 index. Please downgrade to your previous version and dump your labels before upgrading to this version (then run sup-sync --restore). (RuntimeError) from ./lib/sup/index.rb:67:in `load' from bin/sup-sync:117 I looked at strace to and noticed that sup only accessed the new ~/.sup-new-test direcotry which was empty. So there is no v0 at all) Marc Weber From wmorgan-sup@masanjin.net Thu Sep 3 13:58:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 10:58:16 -0700 Subject: [sup-talk] [PATCH 2/2] ui responsiveness tweaks In-Reply-To: <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> References: <1251053171-11450-1-git-send-email-rlane@club.cc.cmu.edu> <1251053171-11450-2-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1252000456-sup-1452@masanjin.net> Both of these patches are on the branch preemptive-loading, merged into next. Thanks! It's a nice touch. I didn't really notice any differe from thread prioritization and Thread.pass call, but maybe that's my setup. Regardless, it can't hurt. I also reworked the load-more callback mechanism to be a little more thread safe and a little less insane. Now it uses a queue and has a dedicated loader thread pulling things off of it. Message thread loading is currently configured to just drop concurrent calls, so it should work fine. Now, all we need is a faster cursor in thread-index-mode. I will grant a Sup medal to anyone who can make that happen! -- William From wmorgan-sup@masanjin.net Thu Sep 3 14:06:55 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 11:06:55 -0700 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1251325542-sup-3105@yoom.home.cworth.org> References: <1251325542-sup-3105@yoom.home.cworth.org> Message-ID: <1252000831-sup-9922@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-26: > These behave identically to the existing ",a" and ",d" commands, (that > is they archive or delete the current thread and then view the next). Sorry it's taken me so long to look at this. Thanks for the patch! I'm curious what other people think about this. On the one hand, it's only additional keybindings, so it's not going to adversely affect anyone. On the other hand, there is a nice balance with the ".", "," and "]" commands which this disrupts, and it can't be extended to the other commands from thread-index-mode. And on the third hand, I'm happy to have keybinding hooks. I guess if most people primarily closes their thread-view-modes using ",a" and ",d", then I'm fine with this. -- William From wmorgan-sup@masanjin.net Thu Sep 3 14:32:54 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 11:32:54 -0700 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar In-Reply-To: <1251323747-sup-1595@yoom.home.cworth.org> References: <1251323747-sup-1595@yoom.home.cworth.org> Message-ID: <1252002193-sup-3879@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-26: > So what I want is for anytime a message is changed such that it no > longer meets the current search criteria, it is immediately removed > from the search results. I think that means simply implementing the > is_relevant? method for SearcResultsMode is_relevant? is currently only used for determining when to add messages to a thread-index-mode (e.g. when a new message is picked up during a poll). Determining whether to drop a message is currently done "manually" by inbox-mode, and not at all by search-results-mode. > That single-message index and search sounds exactly like what I want, > and not insane at all. Hm. Well, you could certainly try it. I've assumed it would be too slow, but it's possible it'd be fast enough. I think it's the only option though, if you want this to work with arbitrary queries. > (In which case, I'll try, and I'll be glad for any pointers that > anyone can give me on how to go about creating an in-memory index and > searching on it.) Excellent, ask Rich. :) > The command I would find natural for putting a thread back into the > inbox would be to simply add the inbox label to the thread. Oddly this > is currently not allowed as "inbox" is a reserved label. Yeah, there's no good reason for this. I was just being overly protective. :) -- William From rlane@club.cc.cmu.edu Thu Sep 3 14:35:05 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 03 Sep 2009 14:35:05 -0400 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1251998504-sup-6794@nixos> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> <1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net> <1251998504-sup-6794@nixos> Message-ID: <1252002797-sup-6522@zyrg.net> Excerpts from Marc Weber's message of Thu Sep 03 13:26:59 -0400 2009: > > > I added support for thread killing in 4d82ef88, which hasn't been merged > > to master yet. If you'd like to use the Xapian index I suggest using > > next for now. > > Hi Rich, using next I get the following error: > > + ruby -Ilib bin/sup-sync --all --all-sources --restore /tmp/dump-file-new > ./lib/sup/crypto.rb:17: warning: Insecure world writable dir /pr/webkos > in PATH, mode 040777 > Loading state dump from /tmp/dump-file-new... > Read 39048 entries from dump file. > ./lib/sup/xapian_index.rb:32:in `load_index': This Sup version expects a > v1 index, but you have an existing v0 index. Please downgrade to your > previous version and dump your labels before upgrading to this version > (then run sup-sync --restore). (RuntimeError) > from ./lib/sup/index.rb:67:in `load' > from bin/sup-sync:117 > > I looked at strace to and noticed that sup only accessed the new > ~/.sup-new-test direcotry which was empty. So there is no v0 at all) That's strange, because this codepath (xapian_index.rb:32) is only hit when the xapian directory already exists. Can you add a log message to output the "path" variable and see if it looks correct? From wmorgan-sup@masanjin.net Thu Sep 3 14:36:42 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 11:36:42 -0700 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar In-Reply-To: <1251341286-sup-9400@zyrg.net> References: <1251323747-sup-1595@yoom.home.cworth.org> <1251341286-sup-9400@zyrg.net> Message-ID: <1252002783-sup-3659@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-08-26: > We had a thread a while back about applying label changes immediately > and I think the consensus was that that's a good idea. Doing this > could simplify a great deal of thread-index-mode code because a fast > is_relevant? could be implemented using existing index operations > without the special cases for archiving/etc and without creating an > inmemory database. But it's not just a label issue. Determining whether a given message belongs in a general search buffer requires the full engine. And even if the query is just on labels, it can contain arbitrary boolean expressions, and I don't want to be the one having to parse that, and parse it in such a way that it matches what the search engine is doing. > I have a patch I plan to mail out soon that makes changing labels with > Xapian much quicker, so that should help. This is definitely good, either way. -- William From wmorgan-sup@masanjin.net Thu Sep 3 14:39:58 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 11:39:58 -0700 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar In-Reply-To: <1251327030-sup-7342@yoom.home.cworth.org> References: <1251323747-sup-1595@yoom.home.cworth.org> <1251327030-sup-7342@yoom.home.cworth.org> Message-ID: <1252003008-sup-8596@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-08-26: > Excerpts from Carl Worth's message of Wed Aug 26 15:24:36 -0700 2009: > > + text = BufferManager.ask :search, "refine query: ", "label:inbox > > -label:spam -label:deleted -label:killed " > > Is that even the right syntax for searching for threads with the inbox > label but excluding threades with the spam, deleted, or killed labels? Instead of -label:killed, you want to specify :skip_killed to #load_thread. Killed messages require special semantics. > I took a guess at the syntax and I thought I saw it working, but it > doesn't appear to be now. Can someone tell me the actual syntax? (Or > better, is there a writeup somewhere of the general search syntax > accepted by sup?) There is not a consistent one, though there might be something useful on the wiki. The general answer is, whatever Ferret/Xapian supports, plus the tweaks in #parse_query. -- William From rlane@club.cc.cmu.edu Thu Sep 3 14:44:06 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 03 Sep 2009 14:44:06 -0400 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar In-Reply-To: <1252002783-sup-3659@masanjin.net> References: <1251323747-sup-1595@yoom.home.cworth.org> <1251341286-sup-9400@zyrg.net> <1252002783-sup-3659@masanjin.net> Message-ID: <1252003316-sup-2379@zyrg.net> Excerpts from William Morgan's message of Thu Sep 03 14:36:42 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-08-26: > > We had a thread a while back about applying label changes immediately > > and I think the consensus was that that's a good idea. Doing this > > could simplify a great deal of thread-index-mode code because a fast > > is_relevant? could be implemented using existing index operations > > without the special cases for archiving/etc and without creating an > > inmemory database. > > But it's not just a label issue. Determining whether a given message > belongs in a general search buffer requires the full engine. And even if > the query is just on labels, it can contain arbitrary boolean > expressions, and I don't want to be the one having to parse that, and > parse it in such a way that it matches what the search engine is doing. You're right that it require the full engine. If we're immediately saving the label changes to the (on-disk) index, we can simply query it and get the correct answer. From marka@pobox.com Thu Sep 3 14:37:34 2009 From: marka@pobox.com (Mark Alexander) Date: Thu, 03 Sep 2009 14:37:34 -0400 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252000831-sup-9922@masanjin.net> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> Message-ID: <1252002852-sup-8688@r50p> Excerpts from William Morgan's message of Thu Sep 03 14:06:55 -0400 2009: > I guess if most people primarily closes their thread-view-modes using > ",a" and ",d", then I'm fine with this. Those are perhaps my most-commonly used commands in sup, so having them shortened is a very nice improvement. From wmorgan-sup@masanjin.net Thu Sep 3 14:47:19 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 11:47:19 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1251387376-sup-7180@javelin> References: <1251387376-sup-7180@javelin> Message-ID: <1252003380-sup-272@masanjin.net> I'm not sure how I feel about this patch. The semantics of being killed are very tied to the inbox. I'm reluctant to start spreading them to other types of buffers. -- William From wmorgan-sup@masanjin.net Thu Sep 3 14:50:25 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 11:50:25 -0700 Subject: [sup-talk] On making inbox-mode and search-results-mode more similar In-Reply-To: <1252003316-sup-2379@zyrg.net> References: <1251323747-sup-1595@yoom.home.cworth.org> <1251341286-sup-9400@zyrg.net> <1252002783-sup-3659@masanjin.net> <1252003316-sup-2379@zyrg.net> Message-ID: <1252003719-sup-1602@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-03: > You're right that it require the full engine. If we're immediately > saving the label changes to the (on-disk) index, we can simply query > it and get the correct answer. Oh, as opposed to a new in-memory index. Yeah. -- William From ezyang@MIT.EDU Thu Sep 3 14:57:14 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 03 Sep 2009 14:57:14 -0400 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252003380-sup-272@masanjin.net> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> Message-ID: <1252004144-sup-6662@javelin> Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009: > I'm not sure how I feel about this patch. The semantics of being killed > are very tied to the inbox. I'm reluctant to start spreading them to > other types of buffers. The reason why I request this is because I have a distinction between unread messages in my inbox and unread messages not in my inbox and unread messages that are killed. The 1st is for messages that I should read (or at least ack), the second is for mailing list messages and the third is for "I don't actually ever want to see this again, no really". Cheers, Edward From me@nicholasbs.net Thu Sep 3 14:58:45 2009 From: me@nicholasbs.net (Nicholas Bergson-Shilcock) Date: Thu, 03 Sep 2009 14:58:45 -0400 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252002852-sup-8688@r50p> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> <1252002852-sup-8688@r50p> Message-ID: <1252004295-sup-6234@twoface> Excerpts from Mark Alexander's message of Thu Sep 03 14:37:34 -0400 2009: > Excerpts from William Morgan's message of Thu Sep 03 14:06:55 -0400 2009: > > I guess if most people primarily closes their thread-view-modes using > > ",a" and ",d", then I'm fine with this. > > Those are perhaps my most-commonly used commands in sup, so having > them shortened is a very nice improvement. +1. These would be quite helpful for me. From wmorgan-sup@masanjin.net Thu Sep 3 14:58:55 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 03 Sep 2009 11:58:55 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252004144-sup-6662@javelin> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> Message-ID: <1252004285-sup-476@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-09-03: > The 1st is for messages that I should read (or at least ack), the > second is for mailing list messages and the third is for "I don't > actually ever want to see this again, no really". What if you just delete messages in the the third condition? -- William From ezyang@MIT.EDU Thu Sep 3 15:01:55 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Thu, 03 Sep 2009 15:01:55 -0400 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252004285-sup-476@masanjin.net> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net> Message-ID: <1252004504-sup-3189@javelin> Excerpts from William Morgan's message of Thu Sep 03 14:58:55 -0400 2009: > Reformatted excerpts from Edward Z. Yang's message of 2009-09-03: > > The 1st is for messages that I should read (or at least ack), the > > second is for mailing list messages and the third is for "I don't > > actually ever want to see this again, no really". > > What if you just delete messages in the the third condition? Then replies show up. :-) Cheers, Edward From bwalton@artsci.utoronto.ca Thu Sep 3 15:13:15 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 03 Sep 2009 15:13:15 -0400 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252003380-sup-272@masanjin.net> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> Message-ID: <1252005121-sup-3946@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu Sep 03 14:47:19 -0400 2009: > I'm not sure how I feel about this patch. The semantics of being killed > are very tied to the inbox. I'm reluctant to start spreading them to > other types of buffers. The 'U' key binding just drives a preset search. This wouldn't be spreading the special status of killed into other buffer types more than a manual search using the same terms. -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 Thu Sep 3 15:25:03 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 03 Sep 2009 15:25:03 -0400 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1251388546-sup-7744@javelin> References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin> Message-ID: <1252005520-sup-9555@zyrg.net> Excerpts from Edward Z. Yang's message of Thu Aug 27 11:56:32 -0400 2009: > Excerpts from Edward Z. Yang's message of Thu Aug 27 11:36:28 -0400 2009: > > - SearchResultsMode.spawn_from_query "is:unread" > > + SearchResultsMode.spawn_from_query "is:unread !label:killed" > > I might have one legitimate objection to this patch, which is > that searches should ignore killed tags unless explicitly told > not to. By default Index#load_messages_in_thread_for does skip killed threads, so you should already have the behavior you want without modifying the query (unless you're using an old xapian-index version that doesn't support killed threads). Adding a !label:killed term will actually cause threads that are "killed" (have at least one message labeled killed) but also have a message not labeled killed that matches the query to be displayed, which I don't think is the behavior you're looking for. From cworth@cworth.org Thu Sep 3 19:06:50 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 03 Sep 2009 16:06:50 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252005520-sup-9555@zyrg.net> References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin> <1252005520-sup-9555@zyrg.net> Message-ID: <1252010283-sup-4453@yoom.home.cworth.org> Excerpts from Rich Lane's message of Thu Sep 03 12:25:03 -0700 2009: > By default Index#load_messages_in_thread_for does skip killed threads, > so you should already have the behavior you want without modifying the > query (unless you're using an old xapian-index version that doesn't > support killed threads). Adding a !label:killed term will actually cause > threads that are "killed" (have at least one message labeled killed) but > also have a message not labeled killed that matches the query to be > displayed, which I don't think is the behavior you're looking for. Wow, that's surprising! But thanks for explaining that since that's the exact behavior I've been getting since I starting using queries with "!label:killed" in them, (I'm trying to get views that act like filtered versions of the inbox). Excerpts from William Morgan's message of Thu Sep 03: > I'm not sure how I feel about this patch. The semantics of being killed > are very tied to the inbox. I'm reluctant to start spreading them to > other types of buffers. William, perhaps you can take this chance to explain something to me. I've been trying to figure out the philosophy and the mechanics of sup labels and searching. >From the point-of-view of a naive user it has seemed to me like the philosophy is that threads are the primary objects so all labels apply to a thread as a whole, and all searches return results consisting of entire threads. And this all seems very good to me. But the above discussion of "killed" suggests that the mechanics aren't at all like that. But that instead, labels are applied to individual messages, and searches match individual messages and then construct threads from the results. Is that more or less how things work? So is there a mismatch between the philosophy and the mechanics, or did I just misunderstand the philosophy? That is, do current users of sup ever distinguish between searching for messages with specific labels as opposed to searching for threads that contain messages with specific labels? If not, it seems like it would be possible for a query like "!label:killed" to do exactly what is wanted without needing any special treatment for killed internally. And I'd like this, because I would sometimes want to do a similar negative filter based on my own custom labels. Does that make sense? -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From richard@infoarts.info Thu Sep 3 19:08:11 2009 From: richard@infoarts.info (Richard Sandilands) Date: Fri, 4 Sep 2009 09:08:11 +1000 Subject: [sup-talk] Can't add source when tracking next Message-ID: <20090903230808.GA2983@114.73.135.126.optusnet.com.au> Hi there I'm tracking next via git and am having trouble adding a mail source. I've removed any existing ~/.sup directory, then run sup-config and all is OK until sup-config runs sup-add maildir when I get this message: "Ok, trying to run "/Users/richard/src/sup/bin/sup-add maildir:/Users/richard/mail/gmail/INBOX"... /Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for false:FalseClass (NoMethodError) from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require' from /Users/richard/src/sup/lib/sup.rb:277 from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require' from /Users/richard/src/sup/bin/sup-add:7 So I'm thinking this might have something to do with my environment setup on OS X. I'm running sup from ~/src/sup and am mirroring my gmail mail to ~/mail/gmail via offlineimap - this all seems fine. I've added: 'export RUBYLIB="~/src/sup/lib" ' to my .bash_profile but it still fails on the 'require "sup"' line in sup-add I've checked that I have all the required gem dependencies and that seems fine too. And I installed the sup-999 gems. What could I be missing here? Any clues appreciated... -- Richard From bwalton@artsci.utoronto.ca Thu Sep 3 22:13:11 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 03 Sep 2009 22:13:11 -0400 Subject: [sup-talk] more xapian/label woes Message-ID: <1252030139-sup-6351@ntdws12.chass.utoronto.ca> Hi All, I've tried the xapian conversion again and am now back in ferret land. In this case, I don't think the issues are xapian related...it seems to the labels that are biting me again. I get exceptions with non-Symbol labels being passed around again. To finish the import of my ferret dumpfile, I had to do the following: --snip-- diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 1395601..4b3b022 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -111,7 +111,7 @@ class XapianIndex < BaseIndex :replytos => (entry[:replytos] || m.replytos), } - labels.each { |l| LabelManager << l } + labels.each { |l| LabelManager << l.to_sym } --snip-- This got me to the point where I could fire up sup with SUP_INDEX=xapian, but the initial poll caused the attached exception. I wonder if LabelManager should simply call .to_sym (.intern) on everything passed to it? That's a big hammer, I realize...maybe .to_sym/.intern in cases where the unexpected object is a String? Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exception-log.txt URL: -------------- 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 Fri Sep 4 09:56:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 04 Sep 2009 06:56:41 -0700 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post is not present In-Reply-To: <1251794935-sup-3802@elly> References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net> <1251794935-sup-3802@elly> Message-ID: <1252072500-sup-8128@masanjin.net> Reformatted excerpts from Israel Herraiz's message of 2009-09-01: > Yes, although list-id is not an address (it does not contain the "@" > symbol for instance). But I am happy with that patch :-). Actually you're right. I think I prefer your patch. But based on the code, it seems like reply-mode would crash if it got a message that claims it's a list message but doesn't have a list address. Does it actually work? -- William From wmorgan-sup@masanjin.net Fri Sep 4 10:34:11 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 04 Sep 2009 07:34:11 -0700 Subject: [sup-talk] [PATCH] decrypt returns 3 elem array if gpg is unavailable In-Reply-To: <1251995933-2252-1-git-send-email-mzulak@gmail.com> References: <1251995933-2252-1-git-send-email-mzulak@gmail.com> Message-ID: <1252074791-sup-9657@masanjin.net> Reformatted excerpts from Matt Zulak's message of 2009-09-03: > CryptoManager's decrypt method returns a CryptoNotice if the GPG > binary can't be found on the path; however, the Message class expects > a 3 element array with either a RMail::Message or nil at index 0. Thanks. I've fixed this in a slightly different way, by returning the notice as the first element. I think the code is a little easier to read that way. Let me know if it doesn't work. -- William From wmorgan-sup@masanjin.net Fri Sep 4 10:41:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 04 Sep 2009 07:41:49 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252010283-sup-4453@yoom.home.cworth.org> References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin> <1252005520-sup-9555@zyrg.net> <1252010283-sup-4453@yoom.home.cworth.org> Message-ID: <1252074924-sup-1994@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-09-03: > But the above discussion of "killed" suggests that the mechanics > aren't at all like that. But that instead, labels are applied to > individual messages, and searches match individual messages and then > construct threads from the results. Is that more or less how things > work? Yes. That's why killed is special; it requires work at threading time to drop threads in which any message has a killed label, regardless of whether that's the message that matched the query. > So is there a mismatch between the philosophy and the mechanics, or > did I just misunderstand the philosophy? Not sure. Maybe both. :) The philosophy is more about the UI, IMO, than specific implementation details (though obviosuly there's some trickle-up). The other way to implement this, FWIW, is to have labels automatically spread to all messages in a thread when they're applied. I think that is probably a better implementation, though it increases the cost at labeling time. I've been toying with this idea in the sup server code. > If not, it seems like it would be possible for a query like > "!label:killed" to do exactly what is wanted without needing any > special treatment for killed internally. I think the above implementation would allow this. -- William From cworth@cworth.org Fri Sep 4 11:12:01 2009 From: cworth@cworth.org (Carl Worth) Date: Fri, 04 Sep 2009 08:12:01 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252074924-sup-1994@masanjin.net> References: <1251387376-sup-7180@javelin> <1251388546-sup-7744@javelin> <1252005520-sup-9555@zyrg.net> <1252010283-sup-4453@yoom.home.cworth.org> <1252074924-sup-1994@masanjin.net> Message-ID: <1252076900-sup-274@yoom.home.cworth.org> Excerpts from William Morgan's message of Fri Sep 04 07:41:49 -0700 2009: > Yes. That's why killed is special; it requires work at threading time to > drop threads in which any message has a killed label, regardless of > whether that's the message that matched the query. Good. I'm glad I'm at least understanding how things work here. > The other way to implement this, FWIW, is to have labels automatically > spread to all messages in a thread when they're applied. I think that is > probably a better implementation, though it increases the cost at > labeling time. I've been toying with this idea in the sup server code. > > > If not, it seems like it would be possible for a query like > > "!label:killed" to do exactly what is wanted without needing any > > special treatment for killed internally. > > I think the above implementation would allow this. Yes, that would do the trick. It would require extra work both at the time a label is attached to a message and then again at the time a new message is associated with an existing thread. But it would give me the behavior I want "for free" after that. If such an implementation would be acceptable, then it would seem that a better long-term solution would be to apply labels only to "thread objects" and to index and search for those rather than individuals messages (at least as far as label searching goes). Of course, I'm talking from an entirely naive point-of-view with regard to the implementation impact of such a change, but I would imagine it wouldn't be trivial. -Carl From wmorgan-sup@masanjin.net Fri Sep 4 11:22:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 04 Sep 2009 08:22:21 -0700 Subject: [sup-talk] Can't add source when tracking next In-Reply-To: <20090903230808.GA2983@114.73.135.126.optusnet.com.au> References: <20090903230808.GA2983@114.73.135.126.optusnet.com.au> Message-ID: <1252077695-sup-9520@masanjin.net> Reformatted excerpts from Richard Sandilands's message of 2009-09-03: > "Ok, trying to run "/Users/richard/src/sup/bin/sup-add > maildir:/Users/richard/mail/gmail/INBOX"... > /Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for > false:FalseClass (NoMethodError) Whoops, this was a bug. I've fixed it in next, if you want to try again. You may have to delete your ~/.sup/config.yaml file (it will yell at you if so.) -- William From wmorgan-sup@masanjin.net Fri Sep 4 11:30:11 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 04 Sep 2009 08:30:11 -0700 Subject: [sup-talk] more xapian/label woes In-Reply-To: <1252030139-sup-6351@ntdws12.chass.utoronto.ca> References: <1252030139-sup-6351@ntdws12.chass.utoronto.ca> Message-ID: <1252077954-sup-8898@masanjin.net> Reformatted excerpts from Ben Walton's message of 2009-09-03: > I get exceptions with non-Symbol labels being passed around again. To > finish the import of my ferret dumpfile, I had to do the following: Is this with a recent next, and after deleting any vestigal ~/.sup/xapian directory and .db files? If so, there really shouldn't be any label issues. If there are, can you attach the original exception? Also, does your sources.yaml file have something weird for labels? > This got me to the point where I could fire up sup with > SUP_INDEX=xapian, but the initial poll caused the attached exception. > I wonder if LabelManager should simply call .to_sym (.intern) on > everything passed to it? Certainly an option, but I'm hoping to keep the "fail fast" behavior for now since it is revealing underlying problems. -- William From wmorgan-sup@masanjin.net Fri Sep 4 11:53:12 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 04 Sep 2009 08:53:12 -0700 Subject: [sup-talk] [PATCH] handle malformed multiplart messages In-Reply-To: <20090728165823.GA29533@solar.cslab.ece.ntua.gr> References: <20090728165823.GA29533@solar.cslab.ece.ntua.gr> Message-ID: <1252079569-sup-6888@masanjin.net> Reformatted excerpts from Kornilios Kourtis's message of 2009-07-28: > 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. Sorry for the delay. I think this is good. Applied. Thanks! -- William From marco-oweber@gmx.de Fri Sep 4 12:25:39 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Fri, 04 Sep 2009 18:25:39 +0200 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1252002797-sup-6522@zyrg.net> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> <1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net> <1251998504-sup-6794@nixos> <1252002797-sup-6522@zyrg.net> Message-ID: <1252081334-sup-213@nixos> Sorry. It was my fault. I had a ~/.sup/xapian I forgot about. That made the trouble causing the correct error message. So I think it's safe to switch to Xapian. You may use this script. It will copy the existing ~/.sup and create a new directory $NEW with the xapian index. You cane set SUP_BASE to run the new sup to try it out. Next feels so much better in various ways (speed, search in threads etc.) Thanks for your all this work! set -x set -e OLD=~/.sup NEW=/pr/sup-new-test DUMP=/tmp/dump-file-new DUMP2=/tmp/dump-file-new2 SYNC_LOG=/tmp/sup-sync-log GIT_REPO=~/managed_repos/sup_mainline rm -fr $NEW export SUP_BASE=$OLD sup-dump > $DUMP # from now on operate on the new base only export SUP_BASE=$NEW cp -r $OLD $NEW rm -fr $NEW/ferret rm -fr $NEW/xapian # remove old xapian cruft! mv $NEW/{hooks,hooks-disabled} # echo loading stuff.. export SUP_INDEX=xapian cd $GIT_REPO echo "syncing.. this will take long. use tail -f $SYNC_LOG to watch progress" ruby -Ilib bin/sup-sync --all --all-sources --restore $DUMP &> $SYNC_LOG echo "writing dump" ruby -Ilib bin/sup-dump # > $DUMP2 Marc Weber From rlane@club.cc.cmu.edu Fri Sep 4 13:00:57 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 04 Sep 2009 13:00:57 -0400 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1251998177-sup-3432@masanjin.net> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> <1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net> <1251998177-sup-3432@masanjin.net> Message-ID: <1252083532-sup-2011@zyrg.net> Excerpts from William Morgan's message of Thu Sep 03 13:16:41 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-09-03: > > I added support for thread killing in 4d82ef88, which hasn't been > > merged to master yet. If you'd like to use the Xapian index I suggest > > using next for now. > > If you feel it's reasonably stable, I can merge it into master. I think it's ok to merge. From wmorgan-sup@masanjin.net Fri Sep 4 13:29:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 04 Sep 2009 10:29:23 -0700 Subject: [sup-talk] Trouble loading dump into Xapian index In-Reply-To: <1252083532-sup-2011@zyrg.net> References: <1251987692-sup-9940@nixos> <1251991420-sup-3869@masanjin.net> <1251994802-sup-8575@nixos> <1251995984-sup-7983@zyrg.net> <1251998177-sup-3432@masanjin.net> <1252083532-sup-2011@zyrg.net> Message-ID: <1252085325-sup-2315@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-04: > I think it's ok to merge. Merged! If you're running a Xapian from master (weird!) you will have to rebuild your index after removing ~/.sup/{xapian,*.db}. -- William From sean.escriva@gmail.com Fri Sep 4 15:13:32 2009 From: sean.escriva@gmail.com (Sean Escriva) Date: Fri, 4 Sep 2009 12:13:32 -0700 Subject: [sup-talk] a few questions on mail handling with sup Message-ID: <20090904191332.GA5525@gmail.com> I've got sup working with the exchange server at work thanks to offlineimap, but I have a few questions I was hope to get some input on. Currently I have no way to way move messages out of my inbox on the imap server, since I'm accessing a local maildir created by offlineimap. This is only an issue since mailboxes have a limit of 800mb in size on the server and given the volume of mail I have that will be reached every other month. I've looked at imap filter and this could possibly work, but anyone have experience with this sort of sitatuation? Additionally, since sup doesn't actually change the maildir, messages in the maildir do not seem be getting marked as not new when reading them with sup and offlineimap then doesn't update the message state on the server. Is there any way to addess this? thanks! From bwalton@artsci.utoronto.ca Fri Sep 4 16:47:39 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 04 Sep 2009 16:47:39 -0400 Subject: [sup-talk] more xapian/label woes In-Reply-To: <1252077954-sup-8898@masanjin.net> References: <1252030139-sup-6351@ntdws12.chass.utoronto.ca> <1252077954-sup-8898@masanjin.net> Message-ID: <1252081294-sup-4119@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Fri Sep 04 11:30:11 -0400 2009: > Is this with a recent next, and after deleting any vestigal > ~/.sup/xapian directory and .db files? If so, there really shouldn't be > any label issues. If there are, can you attach the original exception? > Also, does your sources.yaml file have something weird for labels? It was with cdb1017, but I likely did have a ~/.sup/xapian directory from previous attempts. I'll try again tonight with that cleared out. > > This got me to the point where I could fire up sup with > > SUP_INDEX=xapian, but the initial poll caused the attached exception. > > I wonder if LabelManager should simply call .to_sym (.intern) on > > everything passed to it? > > Certainly an option, but I'm hoping to keep the "fail fast" behavior for > now since it is revealing underlying problems. Ok, I think this is likely the best approach too. Strings and symbols have a somewhat special relationship in ruby though, so I thought it might be ok to force a coercion in that case. Lets make it the last resort as you suggest. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Fri Sep 4 17:01:11 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 04 Sep 2009 17:01:11 -0400 Subject: [sup-talk] a few questions on mail handling with sup In-Reply-To: <20090904191332.GA5525@gmail.com> References: <20090904191332.GA5525@gmail.com> Message-ID: <1252098027-sup-4487@ntdws12.chass.utoronto.ca> Excerpts from Sean Escriva's message of Fri Sep 04 15:13:32 -0400 2009: > Currently I have no way to way move messages out of my inbox on the > imap server, since I'm accessing a local maildir created by > offlineimap. This is only an issue since mailboxes have a limit of > 800mb in size on the server and given the volume of mail I have that > will be reached every other month. I've looked at imap filter and this > could possibly work, but anyone have experience with this sort of > sitatuation? Could you pull it down with fetchmail into a local MTA setup that only handles local delivery? Fetchmail has the 'delete on server' option if offlineimap doesn't. -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 Sep 5 15:08:52 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 05 Sep 2009 15:08:52 -0400 Subject: [sup-talk] new exception Message-ID: <1252177626-sup-316@ntdws12.chass.utoronto.ca> This attached exception log was generated after sending a reply, before the inbox buffer was redisplayed. I have the following small modifications to 99e62d55 included (still required for importing to xapian in my case): --snip-- - raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol + t = t.intern if t.is_a? String + + unless t.is_a? Symbol + m = "expecting a symbol, got a #{t.class} (#{t.to_s})" + raise ArgumentError, m + end + --snip-- 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: exception-log.txt URL: -------------- 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 Sat Sep 5 15:30:04 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 05 Sep 2009 15:30:04 -0400 Subject: [sup-talk] new exception In-Reply-To: <1252177626-sup-316@ntdws12.chass.utoronto.ca> References: <1252177626-sup-316@ntdws12.chass.utoronto.ca> Message-ID: <1252178309-sup-7297@zyrg.net> Excerpts from Ben Walton's message of Sat Sep 05 15:08:52 -0400 2009: > --- RuntimeError from thread: main > DocNotFoundError: No termlist found for document 2478134195 > /usr/lib/ruby/site_ruby/1.8/xapian.rb:239:in `doclength' > /usr/lib/ruby/site_ruby/1.8/xapian.rb:239:in `postlist' > /usr/lib/ruby/site_ruby/1.8/xapian.rb:59:in `_safelyIterate' > /usr/lib/ruby/site_ruby/1.8/xapian.rb:237:in `postlist' > ./sup/xapian_index.rb:361:in `term_docids' I'm guessing you're using the Chert Xapian backend. When I moved all the index data into Xapian it started triggering this Chert bug. Unfortunately, it's nondeterministic and very hard to reproduce in a small testcase. I've been holding off filing a bug upstream until I had a better failing testcase than "run sup-sync". If anyone would like to familiarize themselves with the xapian-index internals and narrow this bug down a bit I'd be very glad for the help. The Flint Xapian backend seems to work fine, so for now I suggest using that. From bwalton@artsci.utoronto.ca Sat Sep 5 15:35:50 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 05 Sep 2009 15:35:50 -0400 Subject: [sup-talk] new exception In-Reply-To: <1252178309-sup-7297@zyrg.net> References: <1252177626-sup-316@ntdws12.chass.utoronto.ca> <1252178309-sup-7297@zyrg.net> Message-ID: <1252179264-sup-8449@ntdws12.chass.utoronto.ca> Excerpts from Rich Lane's message of Sat Sep 05 15:30:04 -0400 2009: > I'm guessing you're using the Chert Xapian backend. When I moved all the > index data into Xapian it started triggering this Chert bug. > Unfortunately, it's nondeterministic and very hard to reproduce in a > small testcase. I've been holding off filing a bug upstream until I had > a better failing testcase than "run sup-sync". If anyone would like to > familiarize themselves with the xapian-index internals and narrow this > bug down a bit I'd be very glad for the help. Your guess is as good as mine here...I didn't realize there were different back ends. How would I go about switching? 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 rlane@club.cc.cmu.edu Sat Sep 5 15:55:12 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sat, 05 Sep 2009 15:55:12 -0400 Subject: [sup-talk] new exception In-Reply-To: <1252179264-sup-8449@ntdws12.chass.utoronto.ca> References: <1252177626-sup-316@ntdws12.chass.utoronto.ca> <1252178309-sup-7297@zyrg.net> <1252179264-sup-8449@ntdws12.chass.utoronto.ca> Message-ID: <1252179965-sup-8043@zyrg.net> Excerpts from Ben Walton's message of Sat Sep 05 15:35:50 -0400 2009: > Your guess is as good as mine here...I didn't realize there were > different back ends. How would I go about switching? Interesting, AFAIK Flint is still the default. Check for a .sup/xapian/iamchert file to see if it's really a Chert DB. If it is Chert, you'll have to delete the xapian directory before you can switch to Flint. The environment variable XAPIAN_PREFER_CHERT controls which backend is used. Set it to the empty string to make sure you're getting Flint. From bwalton@artsci.utoronto.ca Sat Sep 5 17:57:41 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 05 Sep 2009 17:57:41 -0400 Subject: [sup-talk] new exception In-Reply-To: <1252179965-sup-8043@zyrg.net> References: <1252177626-sup-316@ntdws12.chass.utoronto.ca> <1252178309-sup-7297@zyrg.net> <1252179264-sup-8449@ntdws12.chass.utoronto.ca> <1252179965-sup-8043@zyrg.net> Message-ID: <1252187828-sup-3676@ntdws12.chass.utoronto.ca> Excerpts from Rich Lane's message of Sat Sep 05 15:55:12 -0400 2009: > Interesting, AFAIK Flint is still the default. Check for a > .sup/xapian/iamchert file to see if it's really a Chert DB. If it is Nope. I've got ~/.sup/xapian/iamflint though... Thanks for the info. -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 Sep 5 20:19:06 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 05 Sep 2009 20:19:06 -0400 Subject: [sup-talk] sources.yaml labels Message-ID: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> Hi All, After still requiring modifications to the LabelManager to manage my xapian conversion, I'm wondering if I've done something wrong in my sources.yaml (most of which was put together by hand instead of via sup-add). What format should a labels definition be using? On of my sources looks like: --snip-- - !masanjin.net,2006-10-01/Redwood/Maildir uri: maildir:///u/bwalton/Maildir/.systemtap/ cur_offset: 12264068440005086 usual: true archived: false id: 6 labels: - systemtap mtimes: cur: 2008-10-23 13:22:54 -04:00 new: 2008-11-11 07:34:04 -05:00 --snip-- Should the '- systemtap' be '- :systemtap'? 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 richard@infoarts.info Sun Sep 6 05:40:57 2009 From: richard@infoarts.info (Richard Sandilands) Date: Sun, 06 Sep 2009 19:40:57 +1000 Subject: [sup-talk] Sent messages and Sent label Message-ID: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local> Hi there I've set: :sent_source: sup://sent in my config.yaml and am sending using msmtp succesfully, however I'm not seeing my sent mail anywhere in Sup. I'm assuming that it is labelled as 'Sent' and accessible via the 'Sent' label. But no mail is visible under that label - should I be adding a hook to label outgoing mail as 'Sent' or am I missing something obvious? -- Richard Sandilands From richard@infoarts.info Sun Sep 6 05:42:50 2009 From: richard@infoarts.info (Richard Sandilands) Date: Sun, 06 Sep 2009 19:42:50 +1000 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view? Message-ID: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local> Hi there Am just playing with colors.yaml and was looking to change the colors of the highlight line that indicates a selected thread in inbox view. Is there a setting for this element? -- Richard Sandilands From richard@infoarts.info Sun Sep 6 05:40:57 2009 From: richard@infoarts.info (Richard Sandilands) Date: Sun, 06 Sep 2009 19:40:57 +1000 Subject: [sup-talk] Sent messages and Sent label Message-ID: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local> Hi there I've set: :sent_source: sup://sent in my config.yaml and am sending using msmtp succesfully, however I'm not seeing my sent mail anywhere in Sup. I'm assuming that it is labelled as 'Sent' and accessible via the 'Sent' label. But no mail is visible under that label - should I be adding a hook to label outgoing mail as 'Sent' or am I missing something obvious? -- Richard Sandilands From wmorgan-sup@masanjin.net Sun Sep 6 09:07:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 06 Sep 2009 06:07:48 -0700 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view? In-Reply-To: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local> References: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local> Message-ID: <1252241877-sup-6125@masanjin.net> Reformatted excerpts from Richard Sandilands's message of 2009-09-06: > Am just playing with colors.yaml and was looking to change the colors > of the highlight line that indicates a selected thread in inbox view. > > Is there a setting for this element? Currently the highlight color is generated programmatically, so there's no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa line 82) if you want. Ideas on how to move this configuration to colors.yaml (or some other configuration mechanism) welcome. -- William From wmorgan-sup@masanjin.net Sun Sep 6 09:22:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 06 Sep 2009 06:22:21 -0700 Subject: [sup-talk] sources.yaml labels In-Reply-To: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> Message-ID: <1252242820-sup-1452@masanjin.net> Reformatted excerpts from Ben Walton's message of 2009-09-05: > Should the '- systemtap' be '- :systemtap'? The former is "correct". But if you put in the latter, it should be converted automatically, and written out as the former when you exit Sup. I'm a little disturbed that you're still seeing problems with this. Can you confirm that SerializeLabelsNicely#after_unmarshal! (source.rb circa line 167) is being run in your sources after they're loaded from sources.yaml? That should ensure that you end up with a Set of symbols when Sup's running, regardless of what's in the file. The other source of bad labels is the serialized version of the messages stored by Xapian, if you use Xapian. But if you've regenerated your Xapian index recently, this shouldn't be a problem... It strikes me now that the other possible source of non-symbol labels is a hook like before-add. Are you using that to call Message#add_label with a string argument, by any chance? If none of the above, can you post the latest version of the exceptions you're seeing? -- William From bwalton@artsci.utoronto.ca Sun Sep 6 09:47:06 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 06 Sep 2009 09:47:06 -0400 Subject: [sup-talk] sources.yaml labels In-Reply-To: <1252242820-sup-1452@masanjin.net> References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> <1252242820-sup-1452@masanjin.net> Message-ID: <1252244621-sup-3579@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Sun Sep 06 09:22:21 -0400 2009: > The former is "correct". But if you put in the latter, it should be > converted automatically, and written out as the former when you exit > Sup. Ok, so my sources.yaml is 'good.' > I'm a little disturbed that you're still seeing problems with this. Can > you confirm that SerializeLabelsNicely#after_unmarshal! (source.rb circa > line 167) is being run in your sources after they're loaded from > sources.yaml? That should ensure that you end up with a Set of symbols > when Sup's running, regardless of what's in the file. Yes, I added a debug in that method and saw a message for each source. > The other source of bad labels is the serialized version of the messages > stored by Xapian, if you use Xapian. But if you've regenerated your > Xapian index recently, this shouldn't be a problem... I generated this about 2 days ago with a current (at the time) head of next. > It strikes me now that the other possible source of non-symbol labels is > a hook like before-add. Are you using that to call Message#add_label > with a string argument, by any chance? I was doing this. I had a hook from my very early sup days still in play. Since it was actually completely redundant (procmail filtering and autolabelling via sources) now, I've simply removed it. > If none of the above, can you post the latest version of the exceptions > you're seeing? I still can't load sup without coercing strings to symbols in the << method though. The exception log is attached (from a clean startup). 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 -------------- An embedded and charset-unspecified text was scrubbed... Name: exception-log.txt URL: -------------- 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 Sun Sep 6 09:50:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 06 Sep 2009 06:50:35 -0700 Subject: [sup-talk] Sent messages and Sent label In-Reply-To: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local> References: <1252230039-sup-3920@Richard-Sandilandss-MacBook-Pro.local> Message-ID: <1252244925-sup-2820@masanjin.net> Reformatted excerpts from Richard Sandilands's message of 2009-09-06: > But no mail is visible under that label - should I be adding a hook to > label outgoing mail as 'Sent' or am I missing something obvious? Whoops, this is a bug I introduced recently. I've fixed it now. Please git pull and try again. To apply the sent label to previously-sent messages, please run: sup-tweak-labels -a sent sup://sent Sorry about that! -- William From bwalton@artsci.utoronto.ca Sun Sep 6 10:07:55 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 06 Sep 2009 10:07:55 -0400 Subject: [sup-talk] sources.yaml labels In-Reply-To: <1252242820-sup-1452@masanjin.net> References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> <1252242820-sup-1452@masanjin.net> Message-ID: <1252246006-sup-3945@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Sun Sep 06 09:22:21 -0400 2009: > The other source of bad labels is the serialized version of the messages > stored by Xapian, if you use Xapian. But if you've regenerated your > Xapian index recently, this shouldn't be a problem... Since I had a bad hook and imported to Xapian with that hook live, should I reimport my dumpfile after having the hook removed? I'm thinking that I did the damage in a permanent fashion while doing the import... 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 ingmar@exherbo.org Sun Sep 6 10:16:56 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Sun, 06 Sep 2009 16:16:56 +0200 Subject: [sup-talk] sources.yaml labels In-Reply-To: <1252244621-sup-3579@ntdws12.chass.utoronto.ca> References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> <1252242820-sup-1452@masanjin.net> <1252244621-sup-3579@ntdws12.chass.utoronto.ca> Message-ID: <1252246564-sup-241@cannonball> Excerpts from Ben Walton's message of Sun Sep 06 15:47:06 +0200 2009: > I still can't load sup without coercing strings to symbols in the << > method though. The exception log is attached (from a clean startup). That looks like you're using labels as strings, or at least not as symbols, in one of your hooks. -- Exherbo KDE, X.org maintainer From wmorgan-sup@masanjin.net Sun Sep 6 11:06:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 06 Sep 2009 08:06:16 -0700 Subject: [sup-talk] sources.yaml labels In-Reply-To: <1252246006-sup-3945@ntdws12.chass.utoronto.ca> References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> <1252242820-sup-1452@masanjin.net> <1252246006-sup-3945@ntdws12.chass.utoronto.ca> Message-ID: <1252248461-sup-5213@masanjin.net> Reformatted excerpts from Ben Walton's message of 2009-09-06: > Since I had a bad hook and imported to Xapian with that hook live, > should I reimport my dumpfile after having the hook removed? I'm > thinking that I did the damage in a permanent fashion while doing the > import... I suspect that would fix it. I've just pushed a change to to make Message#add_label coerce arguments to symbols, anyways, so that writing your hook wrong won't destroy your index for all eternity. Sorry about all this. The silver lining is that it's a side effect of lots of development activity. :) -- William From bwalton@artsci.utoronto.ca Sun Sep 6 11:26:26 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 06 Sep 2009 11:26:26 -0400 Subject: [sup-talk] sources.yaml labels In-Reply-To: <1252248461-sup-5213@masanjin.net> References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> <1252242820-sup-1452@masanjin.net> <1252246006-sup-3945@ntdws12.chass.utoronto.ca> <1252248461-sup-5213@masanjin.net> Message-ID: <1252250590-sup-9666@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Sun Sep 06 11:06:16 -0400 2009: > I suspect that would fix it. I've just pushed a change to to make > Message#add_label coerce arguments to symbols, anyways, so that writing > your hook wrong won't destroy your index for all eternity. Ok, that's cool. I was going to write the same change but with a 'raise ArgumentError' similar to the one in << to stick with the fail fast approach you prefer. > Sorry about all this. The silver lining is that it's a side effect of > lots of development activity. :) Hey, it's not a problem. I don't mind guinea pigging this stuff at all. Sup has steadily improved since I've been using it, so I'm a happy camper. [Plus, I'm running next, so I 'get what I get.'] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Sun Sep 6 12:41:48 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 06 Sep 2009 12:41:48 -0400 Subject: [sup-talk] sources.yaml labels In-Reply-To: <1252248461-sup-5213@masanjin.net> References: <1252196204-sup-4575@ntdws12.chass.utoronto.ca> <1252242820-sup-1452@masanjin.net> <1252246006-sup-3945@ntdws12.chass.utoronto.ca> <1252248461-sup-5213@masanjin.net> Message-ID: <1252255225-sup-9921@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Sun Sep 06 11:06:16 -0400 2009: > I suspect that would fix it. I've just pushed a change to to make > Message#add_label coerce arguments to symbols, anyways, so that writing > your hook wrong won't destroy your index for all eternity. Verified. I've re-imported my dump file after removing my hook. The import ran successfully with an unmodified sup. I think this makes me a full-time xapian convert. Thanks for all your effort on this William and Rich! -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 Sun Sep 6 13:02:19 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 06 Sep 2009 13:02:19 -0400 Subject: [sup-talk] new exception In-Reply-To: <1252187828-sup-3676@ntdws12.chass.utoronto.ca> References: <1252177626-sup-316@ntdws12.chass.utoronto.ca> <1252178309-sup-7297@zyrg.net> <1252179264-sup-8449@ntdws12.chass.utoronto.ca> <1252179965-sup-8043@zyrg.net> <1252187828-sup-3676@ntdws12.chass.utoronto.ca> Message-ID: <1252255655-sup-2460@zyrg.net> Excerpts from Ben Walton's message of Sat Sep 05 17:57:41 -0400 2009: > Excerpts from Rich Lane's message of Sat Sep 05 15:55:12 -0400 2009: > > > Interesting, AFAIK Flint is still the default. Check for a > > .sup/xapian/iamchert file to see if it's really a Chert DB. If it is > > Nope. I've got ~/.sup/xapian/iamflint though... Well, that's not good. How often does this bug occur? What version of Xapian are you running? How many messages are in your index? From bwalton@artsci.utoronto.ca Sun Sep 6 13:22:39 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 06 Sep 2009 13:22:39 -0400 Subject: [sup-talk] new exception In-Reply-To: <1252255655-sup-2460@zyrg.net> References: <1252177626-sup-316@ntdws12.chass.utoronto.ca> <1252178309-sup-7297@zyrg.net> <1252179264-sup-8449@ntdws12.chass.utoronto.ca> <1252179965-sup-8043@zyrg.net> <1252187828-sup-3676@ntdws12.chass.utoronto.ca> <1252255655-sup-2460@zyrg.net> Message-ID: <1252257711-sup-2477@ntdws12.chass.utoronto.ca> Excerpts from Rich Lane's message of Sun Sep 06 13:02:19 -0400 2009: > Well, that's not good. How often does this bug occur? What version of > Xapian are you running? How many messages are in your index? It's only occurred twice, but both were with my polluted index of ~77k messages. Let me run for a bit now that I've cleaned out my string labels and see what happens. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Sun Sep 6 14:08:42 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 06 Sep 2009 14:08:42 -0400 Subject: [sup-talk] [PATCH] small sent labels fixup Message-ID: <1252260470-sup-6960@ntdws12.chass.utoronto.ca> Hi William, I still wasn't seeing the sent label applied to things in my maildir. The attached patch restores the behaviour for non sup://sent sent sources. 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: 0001-always-apply-label-sent-to-messages-in-sentmanager.patch Type: application/octet-stream Size: 689 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.pouillard@gmail.com Sun Sep 6 15:43:06 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sun, 06 Sep 2009 21:43:06 +0200 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252000831-sup-9922@masanjin.net> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> Message-ID: <1252266137-sup-4139@peray> Excerpts from William Morgan's message of Thu Sep 03 20:06:55 +0200 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-26: > > These behave identically to the existing ",a" and ",d" commands, (that > > is they archive or delete the current thread and then view the next). > > Sorry it's taken me so long to look at this. Thanks for the patch! > > I'm curious what other people think about this. On the one hand, it's > only additional keybindings, so it's not going to adversely affect > anyone. On the other hand, there is a nice balance with the ".", "," > and "]" commands which this disrupts, and it can't be extended to the > other commands from thread-index-mode. And on the third hand, I'm happy > to have keybinding hooks. > > I guess if most people primarily closes their thread-view-modes using > ",a" and ",d", then I'm fine with this. I personally do prefer ]a and ]d, to read mail in the chronological order. -- Nicolas Pouillard http://nicolaspouillard.fr From michael@content-space.de Sun Sep 6 17:04:22 2009 From: michael@content-space.de (Michael Hamann) Date: Sun, 6 Sep 2009 23:04:22 +0200 Subject: [sup-talk] [PATCH] sort labels in the dump Message-ID: <1252271062-8775-1-git-send-email-michael@content-space.de> Sorting labels in the dump is useful when you e.g. want to keep track of your dump using an incremental backup system that records diffs, with this patch lines in the dump will only change when there is a real change and no longer just because the random order of the labels changes. --- bin/sup-dump | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/bin/sup-dump b/bin/sup-dump index 8b5bf07..7b33be5 100755 --- a/bin/sup-dump +++ b/bin/sup-dump @@ -26,5 +26,5 @@ Redwood::SourceManager.init index.load index.each_message :load_spam => true, :load_deleted => true, :load_killed => true do |m| - puts "#{m.id} (#{m.labels.to_a * ' '})" + puts "#{m.id} (#{m.labels.to_a.sort_by { |l| l.to_s } * ' '})" end -- 1.6.4.2 From nicolas.pouillard@gmail.com Mon Sep 7 07:03:43 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 07 Sep 2009 13:03:43 +0200 Subject: [sup-talk] [PATCH] sort labels in the dump In-Reply-To: <1252271062-8775-1-git-send-email-michael@content-space.de> References: <1252271062-8775-1-git-send-email-michael@content-space.de> Message-ID: <1252321409-sup-2683@peray> Excerpts from Michael Hamann's message of Sun Sep 06 23:04:22 +0200 2009: > Sorting labels in the dump is useful when you e.g. want to keep track of > your dump using an incremental backup system that records diffs, with > this patch lines in the dump will only change when there is a real > change and no longer just because the random order of the labels > changes. +1 for this change. -- Nicolas Pouillard http://nicolaspouillard.fr From richard@infoarts.info Mon Sep 7 07:47:53 2009 From: richard@infoarts.info (Richard Sandilands) Date: Mon, 7 Sep 2009 21:47:53 +1000 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox Message-ID: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com> Am tracking 'next' branch and moved to Xapian earlier today. I had Sup running when I slept my OS X laptop by shutting the lid. Upon awakening, Sup raised the following error. Upon trying to run Sup again from the prompt, the same error re-occurs: I'm populating my local Maildirs using getmail from Gmail via POP. =========== --- ArgumentError from thread: poll after loading inbox expecting a symbol /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/label.rb:64:in `<<' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:114:in `sync_message' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in `each' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in `each_key' /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/set.rb:195:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:114:in `sync_message' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/xapian_index.rb:87:in `add_message' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:166:in `add_new_message' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:110:in `do_poll' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:152:in `each_message_from' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:160:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `upto' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/maildir.rb:157:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:560:in `__pass' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:547:in `method_missing' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:140:in `each_message_from' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:93:in `do_poll' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `each' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:81:in `do_poll' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `synchronize' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:80:in `do_poll' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/poll-mode.rb:15:in `poll' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/poll.rb:48:in `poll' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `send' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/util.rb:520:in `method_missing' /Users/richard/src/mainline/bin/sup:196 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `new' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' /Users/richard/src/mainline/bin/sup:196 /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `call' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `call' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:77:in `reporting_thread' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `initialize' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `new' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup.rb:75:in `reporting_thread' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /Library/Ruby/Gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /Users/richard/src/mainline/bin/sup:196 ============== -- Richard From andrew@pimlott.net Mon Sep 7 13:04:50 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Mon, 7 Sep 2009 10:04:50 -0700 Subject: [sup-talk] sup-sync and xapian memory usage Message-ID: <20090907170450.GO14010@pimlott.net> Last time I tried to use sup[1], I posted about sup-sync crashing with various symptoms of memory exhaustion[2]. I've tried again (using git mainline), with similar results, but now I have a bit more to say about it. I am running on a fairly low-memory virtual machine. I think some of the variability in what I was seeing before had to do with what other things were running. Sorry about not being aware of this before. In the following, I have pretty well controlled for other system memory use. All of these tests are done on the same mbox with all indices cleared. Some of the failures I see are out of memory when running gpg ("Errno::ENOMEM Exception: Cannot allocate memory - /usr/bin/gpg" ...). I stopped at that point in the debugger and found that at this point, the ruby backtick operator fails the same way on any command. Using strace, I saw a failure in clone: 20528 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7cb3908) = -1 ENOMEM (Cannot allocate memory) top reports 2.5M of physical and 30M of swap free, so I don't really know why clone fails, but I guess there's not much you can do about that. Other failures were the result of sup blowing up on messages with large attachments. sup's memory use is many times the attachment size. Testing on an mbox with a single message with 4 ~5M (encoded size) attachments (total file size ~21M), sup goes up to ~150M. Accounting for baseline, that's about 6 times the file size. I hope that can be improved. FWIW, mutt never seems to try to load a whole attachment into memory. Using the ferret index, the memory (virtual as reported by Linux) behaviour of sup-sync is pretty good. It starts out 25M and levels out around 31M. It spikes from time to time, presumably because of large messages, but it comes right back. After processing the last message, it uses another 10M to finish up. Using the xapian index, things are different. It starts at 32M and steadily climbs to 77M after ~3500 messages, or around 1M every 100 messages. It does seem to climb faster at first and then more slowly. Either xapian is keeping a cache (but some searches suggest it doesn't), it's leaking memory, or it's allocating memory in a way that the the allocator can't reclaim the VM space. Any ideas? BTW, is there really no way to ask for ruby's heap size with (unpatched) ruby 1.8? Andrew [1] This is about the fourth time. I seem to be easily discouraged. [2] http://rubyforge.org/pipermail/sup-talk/2009-May/002171.html From bwalton@artsci.utoronto.ca Mon Sep 7 14:14:41 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 07 Sep 2009 14:14:41 -0400 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <20090907170450.GO14010@pimlott.net> References: <20090907170450.GO14010@pimlott.net> Message-ID: <1252347051-sup-135@ntdws12.chass.utoronto.ca> Excerpts from Andrew Pimlott's message of Mon Sep 07 13:04:50 -0400 2009: > I am running on a fairly low-memory virtual machine. I think some of > the variability in what I was seeing before had to do with what > other I'm running sup on real hardware w/1GB physical ram. > things were running. Sorry about not being aware of this before. In > the following, I have pretty well controlled for other system memory > use. All of these tests are done on the same mbox with all indices > cleared. > > Some of the failures I see are out of memory when running gpg > ("Errno::ENOMEM Exception: Cannot allocate memory - /usr/bin/gpg" ...). > I stopped at that point in the debugger and found that at this point, > the ruby backtick operator fails the same way on any command. Using > strace, I saw a failure in clone: I found sup crashed this morning too with an ENOMEM on a gpg operation. I thought I may actually have been at the memory exhaustion point normally though as I run screen and tend to leave lots of sessions going all the time. > Using the xapian index, things are different. It starts at 32M and > steadily climbs to 77M after ~3500 messages, or around 1M every 100 > messages. It does seem to climb faster at first and then more > slowly. I've never paid attention to this before, but currently, my sup process (running for about 6 hours now) looks like it's using ~77M virtual with 59 of that resident. This has only happened to me once, but since you reported it, I thought I'd chime in with some extra data. 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 rlane@club.cc.cmu.edu Mon Sep 7 14:33:06 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 07 Sep 2009 14:33:06 -0400 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <20090907170450.GO14010@pimlott.net> References: <20090907170450.GO14010@pimlott.net> Message-ID: <1252348258-sup-415@zyrg.net> Excerpts from Andrew Pimlott's message of Mon Sep 07 13:04:50 -0400 2009: > Using the xapian index, things are different. It starts at 32M and > steadily climbs to 77M after ~3500 messages, or around 1M every 100 > messages. It does seem to climb faster at first and then more slowly. > Either xapian is keeping a cache (but some searches suggest it doesn't), > it's leaking memory, or it's allocating memory in a way that the the > allocator can't reclaim the VM space. Any ideas? Xapian keeps writes buffered in memory. Try setting the environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000 documents) and see if that helps. From bwalton@artsci.utoronto.ca Mon Sep 7 15:11:58 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 07 Sep 2009 15:11:58 -0400 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252348258-sup-415@zyrg.net> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> Message-ID: <1252350686-sup-8800@ntdws12.chass.utoronto.ca> Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009: > Xapian keeps writes buffered in memory. Try setting the environment > variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000 > documents) and see if that helps. Does this explain the lag at shutdown? Xapian is flushing writes to disk? -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 Mon Sep 7 15:15:08 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Mon, 07 Sep 2009 15:15:08 -0400 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252350686-sup-8800@ntdws12.chass.utoronto.ca> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> <1252350686-sup-8800@ntdws12.chass.utoronto.ca> Message-ID: <1252350896-sup-5026@zyrg.net> Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009: > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009: > > Xapian keeps writes buffered in memory. Try setting the environment > > variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000 > > documents) and see if that helps. > > Does this explain the lag at shutdown? Xapian is flushing writes to > disk? Yep. From andrew@pimlott.net Mon Sep 7 15:26:11 2009 From: andrew@pimlott.net (Andrew Pimlott) Date: Mon, 7 Sep 2009 12:26:11 -0700 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252348258-sup-415@zyrg.net> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> Message-ID: <20090907192611.GQ14010@pimlott.net> On Mon, Sep 07, 2009 at 02:33:06PM -0400, Rich Lane wrote: > Xapian keeps writes buffered in memory. Try setting the environment > variable XAPIAN_FLUSH_THRESHOLD to a smaller value (the default is 10000 > documents) and see if that helps. Thanks--it was hard for me to find that kind of information. I first tried setting XAPIAN_FLUSH_THRESHOLD to 1, and sup-sync ran slowly and just kept getting slower: ## read 139m (about 7%) @ 9.2m/s. 0:00:15 elapsed, about 0:03:21 remaining ... ## read 1238m (about 35%) @ 3.1m/s. 0:06:36 elapsed, about 0:12:08 remaining I stopped at this point because it was taking too long. The memory use seemed stable, but that could have been because it was making such slow progress. I guess xapian gets a lot slower writing as the db grows? That's a bit discouraging. Using ferret, sup-sync only dropped from 28.1m/s to 27.3m/s during its run. For reference, when I didn't set XAPIAN_FLUSH_THRESHOLD, I was getting 35-36m/s until it ran out of memory. I then set XAPIAN_FLUSH_THRESHOLD to 100 and got more reasonable results. It started at 25.6m/s and slowed to 17.8m/s. It stabilized at around 41M virtual memory used and finished successfuly. I also note that the memory use didn't jump during the finish-up phase ("Deleting missing messages") as it had with ferret. Finally, I set XAPIAN_FLUSH_THRESHOLD to 1000. It started at 34.6m/s and dropped to 29.8m/s., stabilized at around 51M virtual memory, and finished successfully. In this case, it stays faster than ferret, but it sill bugs me that xapian still slows down while ferret doesn't. So I conclude... I don't know what I conclude. Letting xapian use a lot of memory sure helps its performance. And a big sup-sync should only have to be done rarely. So maybe just document that those on low-memory systems should consider using XAPIAN_FLUSH_THRESHOLD during sup-sync. Thanks again for your help! Andrew From infoarts@gmail.com Thu Sep 3 19:02:12 2009 From: infoarts@gmail.com (infoarts at gmail.com) Date: Fri, 4 Sep 2009 09:02:12 +1000 Subject: [sup-talk] Can't add a local maildir source Message-ID: <2e8d08f0909031602r37472cdcjcf4826f7cd2b48c7@mail.gmail.com> Hi there I'm tracking next via git and am having trouble adding a mail source. I've removed any existing ~/.sup directory, then run sup-config and all is OK until sup-config runs sup-add maildir when I get this message: "Ok, trying to run "/Users/richard/src/sup/bin/sup-add maildir:/Users/richard/mail/gmail/INBOX"... /Users/richard/src/sup/lib/sup/index.rb:177: undefined method `[]' for false:FalseClass (NoMethodError) from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require' from /Users/richard/src/sup/lib/sup.rb:277 from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /Library/Ruby/Site/1.8/rubygems/custom_require.rb:31:in `require' from /Users/richard/src/sup/bin/sup-add:7 So I'm thinking this might have something to do with my environment setup on OS X. I'm running sup from ~/src/sup and am mirroring my gmail mail to ~/mail/gmail via offlineimap - this all seems fine. I've added: 'export RUBYLIB="~/src/sup/lib" ' to my .bash_profile but it still fails on the 'require "sup"' line in sup-add I've checked that I have all the required gem dependencies and that seems fine too. And I installed the sup-999 gems. What could I be missing here? Any clues appreciated... -- Richard From eg@gaute.vetsj.com Mon Sep 7 12:21:35 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Mon, 07 Sep 2009 18:21:35 +0200 Subject: [sup-talk] lbdb module for sup Message-ID: <1252340369-sup-9611@qwerzila> Greetings, attached is a lbdb (http://sup.rubyforge.org/wiki/wiki.pl?LbdbIntegration) module for the sup contact list. Useful if you want access to the sup contact list from Vim. put in .lbdb/modules and add .lbdb/modules to your MODULES_PATH in .lbdbrc aswell as adding the m_sup module to the modules list. - gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: m_sup Type: application/octet-stream Size: 289 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From isra@herraiz.org Mon Sep 7 18:46:50 2009 From: isra@herraiz.org (Israel Herraiz) Date: Tue, 08 Sep 2009 00:46:50 +0200 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post is not present In-Reply-To: <1252072500-sup-8128@masanjin.net> References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net> <1251794935-sup-3802@elly> <1252072500-sup-8128@masanjin.net> Message-ID: <1252363563-sup-1774@elly> Excerpts from William Morgan's message of Fri Sep 04 15:56:41 +0200 2009: > Actually you're right. I think I prefer your patch. But based on the > code, it seems like reply-mode would crash if it got a message that > claims it's a list message but doesn't have a list address. Does it > actually work? Umm. Yes, you are right. It fails because there is no list address. Let me figure out another solution for this, I will send another patch to the list. Cheers, Israel From wmorgan-sup@masanjin.net Tue Sep 8 08:25:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 05:25:50 -0700 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post is not present In-Reply-To: <1252363563-sup-1774@elly> References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net> <1251794935-sup-3802@elly> <1252072500-sup-8128@masanjin.net> <1252363563-sup-1774@elly> Message-ID: <1252412603-sup-9617@masanjin.net> Reformatted excerpts from Israel Herraiz's message of 2009-09-07: > Umm. Yes, you are right. It fails because there is no list > address. Let me figure out another solution for this, I will send > another patch to the list. We need to figure out what the right behavior should be when replying to a message that you know is a list message, but where you don't know the list address. If there's a reliable way of extracting the list address from another header (From?), we can use that, but I suspect there isn't. If there isn't a reliable wa, then maybe the original behavior is fine (don't treat it specially at all). -- William From isra@herraiz.org Tue Sep 8 08:41:51 2009 From: isra@herraiz.org (Israel Herraiz) Date: Tue, 08 Sep 2009 14:41:51 +0200 Subject: [sup-talk] [PATCH] Identify list messages by list-id if list-post is not present In-Reply-To: <1252412603-sup-9617@masanjin.net> References: <1251192579-sup-1849@elly> <1251773879-sup-5227@masanjin.net> <1251794935-sup-3802@elly> <1252072500-sup-8128@masanjin.net> <1252363563-sup-1774@elly> <1252412603-sup-9617@masanjin.net> Message-ID: <1252413599-sup-7371@elly> Excerpts from William Morgan's message of Tue Sep 08 14:25:50 +0200 2009: > We need to figure out what the right behavior should be when replying to > a message that you know is a list message, but where you don't know the > list address. If there's a reliable way of extracting the list address > from another header (From?), we can use that, but I suspect there isn't. > If there isn't a reliable wa, then maybe the original behavior is fine > (don't treat it specially at all). Well, yes, after all, the broken thing here is the list, that does not have a list-post header. So I guess that what should be fixed is that list, not Sup :-). I did not realize about the list address bug before sending the patch, that's why I asked it to be merged. However, I am afraid you are right, and I think it is worthless to implement this behavior. Cheers, Israel From wmorgan-sup@masanjin.net Tue Sep 8 09:15:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 06:15:49 -0700 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <20090907170450.GO14010@pimlott.net> References: <20090907170450.GO14010@pimlott.net> Message-ID: <1252415545-sup-3158@masanjin.net> Reformatted excerpts from Andrew Pimlott's message of 2009-09-07: > Last time I tried to use sup[1], I posted about sup-sync crashing with > various symptoms of memory exhaustion[2]. Excellent resolution to that thread. > sup's memory use is many times the attachment size. Testing on an > mbox with a single message with 4 ~5M (encoded size) attachments > (total file size ~21M), sup goes up to ~150M. Accounting for > baseline, that's about 6 times the file size. I hope that can be > improved. Sup uses the unmaintained RubyMail for MIME handling. I'm sure this behavior can be improved if you can find someone who wants to write some MIME handling code. Personally that's near the bottom of my list. -- William From wmorgan-sup@masanjin.net Tue Sep 8 09:39:12 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 06:39:12 -0700 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252350896-sup-5026@zyrg.net> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> <1252350686-sup-8800@ntdws12.chass.utoronto.ca> <1252350896-sup-5026@zyrg.net> Message-ID: <1252415772-sup-7288@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-07: > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009: > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009: > > > Xapian keeps writes buffered in memory. Try setting the > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value > > > (the default is 10000 documents) and see if that helps. > > > > Does this explain the lag at shutdown? Xapian is flushing writes to > > disk? > > Yep. Good to know. Is there a way to force a flush in Xapian? Just curious. The delay is a little scary sometimes. Maybe it just needs an appropriate message somewhere. -- William From bwalton@artsci.utoronto.ca Tue Sep 8 09:58:15 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 08 Sep 2009 09:58:15 -0400 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252415772-sup-7288@masanjin.net> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> <1252350686-sup-8800@ntdws12.chass.utoronto.ca> <1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net> Message-ID: <1252418267-sup-8800@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Tue Sep 08 09:39:12 -0400 2009: > Good to know. Is there a way to force a flush in Xapian? Just curious. > The delay is a little scary sometimes. Maybe it just needs an > appropriate message somewhere. ...even just a message indicating that xapian is flushing the buffered writes would be a good thing. -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 rgh@roughage.com.au Tue Sep 8 10:27:10 2009 From: rgh@roughage.com.au (Richard Heycock) Date: Wed, 09 Sep 2009 00:27:10 +1000 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252415772-sup-7288@masanjin.net> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> <1252350686-sup-8800@ntdws12.chass.utoronto.ca> <1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net> Message-ID: <1252419716-sup-3031@roughage.com.au> Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009: > Reformatted excerpts from Rich Lane's message of 2009-09-07: > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009: > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009: > > > > Xapian keeps writes buffered in memory. Try setting the > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value > > > > (the default is 10000 documents) and see if that helps. > > > > > > Does this explain the lag at shutdown? Xapian is flushing writes to > > > disk? > > > > Yep. > > Good to know. Is there a way to force a flush in Xapian? Just curious. > The delay is a little scary sometimes. Maybe it just needs an > appropriate message somewhere. Xapian, by default, flushes every 10 000 documents which in email terms is a pretty long time! You can force a flush but it does increase your IO significantly. Having said that emails are fairly small so flushing every 10 or 20 emails might not be too bad. Maybe it could be dynamic, if there is a high volume of incoming emails flushing could be done after 50 or 100 emails or a timer based flush might be easier. rgh From nicolas.pouillard@gmail.com Tue Sep 8 11:14:22 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 08 Sep 2009 17:14:22 +0200 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252419716-sup-3031@roughage.com.au> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> <1252350686-sup-8800@ntdws12.chass.utoronto.ca> <1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net> <1252419716-sup-3031@roughage.com.au> Message-ID: <1252422827-sup-805@peray> Excerpts from Richard Heycock's message of Tue Sep 08 16:27:10 +0200 2009: > Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009: > > Reformatted excerpts from Rich Lane's message of 2009-09-07: > > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009: > > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009: > > > > > Xapian keeps writes buffered in memory. Try setting the > > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value > > > > > (the default is 10000 documents) and see if that helps. > > > > > > > > Does this explain the lag at shutdown? Xapian is flushing writes to > > > > disk? > > > > > > Yep. > > > > Good to know. Is there a way to force a flush in Xapian? Just curious. > > The delay is a little scary sometimes. Maybe it just needs an > > appropriate message somewhere. > > Xapian, by default, flushes every 10 000 documents which in email terms > is a pretty long time! You can force a flush but it does increase your > IO significantly. Having said that emails are fairly small so flushing > every 10 or 20 emails might not be too bad. > > Maybe it could be dynamic, if there is a high volume of incoming emails > flushing could be done after 50 or 100 emails or a timer based flush > might be easier. Should the '$' command, force a write of the Xapian database? -- Nicolas Pouillard http://nicolaspouillard.fr From wirtwolff@gmail.com Tue Sep 8 11:17:18 2009 From: wirtwolff@gmail.com (Wirt Wolff) Date: Tue, 08 Sep 2009 09:17:18 -0600 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252000831-sup-9922@masanjin.net> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> Message-ID: <1252422961-sup-9843@chigamba> Excerpts from William Morgan's message of Thu Sep 03 12:06:55 -0600 2009: > Reformatted excerpts from Carl Worth's message of 2009-08-26: > > These behave identically to the existing ",a" and ",d" commands, (that > > is they archive or delete the current thread and then view the next). > > Sorry it's taken me so long to look at this. Thanks for the patch! > > I'm curious what other people think about this. On the one hand, it's > only additional keybindings, so it's not going to adversely affect > anyone. On the other hand, there is a nice balance with the ".", "," > and "]" commands which this disrupts, and it can't be extended to the > other commands from thread-index-mode. And on the third hand, I'm happy > to have keybinding hooks. > > I guess if most people primarily closes their thread-view-modes using > ",a" and ",d", then I'm fine with this. Don't mind having 'a' and 'd' around, but likely won't use them. Generally I pass down index with &, A, S, etc. occaisionally reading high priority thread, then ]n, ]a etc. back up in thread view. -- wmw From wmorgan-sup@masanjin.net Tue Sep 8 15:21:47 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 12:21:47 -0700 Subject: [sup-talk] [PATCH] small sent labels fixup In-Reply-To: <1252260470-sup-6960@ntdws12.chass.utoronto.ca> References: <1252260470-sup-6960@ntdws12.chass.utoronto.ca> Message-ID: <1252437698-sup-9601@masanjin.net> Reformatted excerpts from Ben Walton's message of 2009-09-06: > I still wasn't seeing the sent label applied to things in my maildir. > The attached patch restores the behaviour for non sup://sent sent > sources. Applied, thanks! -- William From wmorgan-sup@masanjin.net Tue Sep 8 15:45:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 12:45:32 -0700 Subject: [sup-talk] master branch merge report Message-ID: <1252438950-sup-3895@masanjin.net> On preparation for an 0.9 release, I've merged the following branches into master (in case anyone's keeping track!): console-mode, reply-all-keybindings, restore-state, logging-tweaks, enclosed-message-display-tweaks, hook-local-vars. If anyone's running master, keep an eye out for changes and problems. -- William From nicolas.pouillard@gmail.com Tue Sep 8 15:51:56 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 08 Sep 2009 21:51:56 +0200 Subject: [sup-talk] master branch merge report In-Reply-To: <1252438950-sup-3895@masanjin.net> References: <1252438950-sup-3895@masanjin.net> Message-ID: <1252439403-sup-6192@peray> Excerpts from William Morgan's message of Tue Sep 08 21:45:32 +0200 2009: > On preparation for an 0.9 release, I've merged the following branches > into master (in case anyone's keeping track!): console-mode, > reply-all-keybindings, restore-state, logging-tweaks, > enclosed-message-display-tweaks, hook-local-vars. > > If anyone's running master, keep an eye out for changes and problems. Thanks for these reports on the status of branches. They are really precious. May ask for more? :) I would like you to also report on the status of what is merged in next (or not yet merged in master). -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Tue Sep 8 16:05:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 13:05:14 -0700 Subject: [sup-talk] master branch merge report In-Reply-To: <1252439403-sup-6192@peray> References: <1252438950-sup-3895@masanjin.net> <1252439403-sup-6192@peray> Message-ID: <1252440062-sup-8543@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2009-09-08: > Thanks for these reports on the status of branches. They are really > precious. May ask for more? :) I would like you to also report on the > status of what is merged in next (or not yet merged in master). The only branches not merged into master at this point are preemptive-loading and alignment-tweaks. This is based on a gut estimate of whether they need to bake a little longer. You can always get a complete report by using git wtf (http://git-wt-commit.rubyforge.org/git-wtf). `git wtf -r -s master` and `git wtf -r -s next` will show you what's merged into master and next respectively. I've also just merged custom-search-hook into master, with some effort. -- William From wmorgan-sup@masanjin.net Tue Sep 8 16:08:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 13:08:03 -0700 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252422961-sup-9843@chigamba> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> <1252422961-sup-9843@chigamba> Message-ID: <1252440374-sup-9813@masanjin.net> Reformatted excerpts from Wirt Wolff's message of 2009-09-08: > Don't mind having 'a' and 'd' around, but likely won't use them. So far I'm counting 3 yes votes (including patch submitter), 3 "won't use them" votes (including me), and no one being offended. I think I'm going to apply this. -- William From cworth@cworth.org Tue Sep 8 16:26:45 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 08 Sep 2009 13:26:45 -0700 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252266137-sup-4139@peray> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> <1252266137-sup-4139@peray> Message-ID: <1252441461-sup-5330@yoom.home.cworth.org> Excerpts from Nicolas Pouillard's message of Sun Sep 06 12:43:06 -0700 2009: > I personally do prefer ]a and ]d, to read mail in the chronological order. What if there were a way to reverse the sort order for the index view? That would then change the meaning of "next" and "previous" and then you could use the single letter 'a' and 'd' commands to read your mail in chronological order. Would that make sense? Because that is something I would like to do on occasion. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.pouillard@gmail.com Tue Sep 8 16:28:56 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 08 Sep 2009 22:28:56 +0200 Subject: [sup-talk] master branch merge report In-Reply-To: <1252440062-sup-8543@masanjin.net> References: <1252438950-sup-3895@masanjin.net> <1252439403-sup-6192@peray> <1252440062-sup-8543@masanjin.net> Message-ID: <1252441390-sup-9847@peray> Excerpts from William Morgan's message of Tue Sep 08 22:05:14 +0200 2009: > Reformatted excerpts from Nicolas Pouillard's message of 2009-09-08: > > Thanks for these reports on the status of branches. They are really > > precious. May ask for more? :) I would like you to also report on the > > status of what is merged in next (or not yet merged in master). > > The only branches not merged into master at this point are > preemptive-loading and alignment-tweaks. This is based on a gut estimate > of whether they need to bake a little longer. OK nice. > You can always get a complete report by using git wtf > (http://git-wt-commit.rubyforge.org/git-wtf). `git wtf -r -s master` and > `git wtf -r -s next` will show you what's merged into master and next > respectively. I already use git-wtf (thanks for this tool BTW), with still some pain though. These two commands outputs ~60 lines about dozen of branches. However that's mainly due to the fact that I do have private branches. It would be nice to simply ask differences between to branches in terms of merged branches: git wtf mainline/master..mainline/next > I've also just merged custom-search-hook into master, with some effort. Thanks -- Nicolas Pouillard http://nicolaspouillard.fr From nicolas.pouillard@gmail.com Tue Sep 8 16:33:13 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 08 Sep 2009 22:33:13 +0200 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252441461-sup-5330@yoom.home.cworth.org> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> <1252266137-sup-4139@peray> <1252441461-sup-5330@yoom.home.cworth.org> Message-ID: <1252441854-sup-203@peray> Excerpts from Carl Worth's message of Tue Sep 08 22:26:45 +0200 2009: > Excerpts from Nicolas Pouillard's message of Sun Sep 06 12:43:06 -0700 2009: > > I personally do prefer ]a and ]d, to read mail in the chronological order. > > What if there were a way to reverse the sort order for the index view? > That would then change the meaning of "next" and "previous" and then > you could use the single letter 'a' and 'd' commands to read your mail > in chronological order. > > Would that make sense? Because that is something I would like to do on > occasion. Yes it does make sense. This change would both improve this feature and will reduce the default enforcement. Regards, -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Tue Sep 8 16:38:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 13:38:35 -0700 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox In-Reply-To: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com> References: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com> Message-ID: <1252442225-sup-154@masanjin.net> Reformatted excerpts from Richard Sandilands's message of 2009-09-07: > Am tracking 'next' branch and moved to Xapian earlier today. Do you have a before-add-message hook? If so, I'm sorry to say that you will have to regenerate your index to fix this. There was a problem with next for a while that allowed that hook to add non-symbol labels to messages, and those got serialized into Xapian's index. If not, regenerating it will probably help, but it would be good to find the source of the non-symbol labels. -- William From wmorgan-sup@masanjin.net Tue Sep 8 16:45:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 13:45:08 -0700 Subject: [sup-talk] lbdb module for sup In-Reply-To: <1252340369-sup-9611@qwerzila> References: <1252340369-sup-9611@qwerzila> Message-ID: <1252442690-sup-9709@masanjin.net> Reformatted excerpts from Gaute Hope's message of 2009-09-07: > attached is a lbdb (http://sup.rubyforge.org/wiki/wiki.pl?LbdbIntegration) > module for the sup contact list. Useful if you want access to the sup > contact list from Vim. Thanks! -- William From wmorgan-sup@masanjin.net Tue Sep 8 16:47:18 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 08 Sep 2009 13:47:18 -0700 Subject: [sup-talk] Can't add a local maildir source In-Reply-To: <2e8d08f0909031602r37472cdcjcf4826f7cd2b48c7@mail.gmail.com> References: <2e8d08f0909031602r37472cdcjcf4826f7cd2b48c7@mail.gmail.com> Message-ID: <1252442749-sup-842@masanjin.net> Reformatted excerpts from infoarts's message of 2009-09-03: > I'm tracking next via git and am having trouble adding a mail source. This should be fixed in the latest next. Sorry about that! -- William From cworth@cworth.org Tue Sep 8 16:50:52 2009 From: cworth@cworth.org (Carl Worth) Date: Tue, 08 Sep 2009 13:50:52 -0700 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view? In-Reply-To: <1252241877-sup-6125@masanjin.net> References: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local> <1252241877-sup-6125@masanjin.net> Message-ID: <1252442174-sup-1472@yoom.home.cworth.org> Excerpts from William Morgan's message of Sun Sep 06 06:07:48 -0700 2009: > Reformatted excerpts from Richard Sandilands's message of 2009-09-06: > > Is there a setting for this element? > > Currently the highlight color is generated programmatically, so there's > no setting in colors.yaml. You can edit colormap.rb#highlight_for (circa > line 82) if you want. Thanks for pointing this out. The highlight color has been one of the last color annoyances for me, but I hadn't done the effort to find this in the code yet. > Ideas on how to move this configuration to colors.yaml (or some other > configuration mechanism) welcome. What I think I would really like is a mode where none of the foreground colors/attributes change at all, (it seems distracting to have the text invert while trying to process mail quickly). Instead, I'd like the highlight to be a subtle change in the background color, (but still light or dark like the background so that the foreground colors are all still readable). I poked around at this, and my terminal does have two variants of each of 8 colors available (one brighter than the other), so it seemed like I should be able to use one as the normal background and one as the highlight background. But on looking closer, it appears that the terminal color support here is to name the 8 different colors and to select the variant for each with the bold attribute. So if I'm understanding that correctly, that's 16 colors available for the foreground, but only 8 for the background. That's frustrating. Such a limited color selection is almost unimaginable with hardware capability today. (I do see references to "xterm-256color"[*] terminal definitions. Could sup start depending on things like that? Are there users of sup using the Linux console or so, and does that support 256-color escape codes?). Anyway, I gave up for now and decided not to use color for highlight at all. Instead, I did: def highlight_for fg, bg, attrs [fg, bg, attrs + [Curses::A_UNDERLINE]] I should figure out how to make the underline vs. color choice for highlighting to be a configuration option in order to propose this as a proper patch. But I still would prefer a subtle change in the background color instead of an underline if anyone can figure out how to give me that[**]. -Car [*] And even 256 colors is antiquated. Anything requiring a fixed palette is very constraining on an application author today. [**] Of course, one way is to go away from a curses-based interface. That might very well make sense in the future where sup is implemented as a protocol and we can easily have multiple clients. For me, a graphical client won't be of any interest unless it allows full keyboard control exactly as sup does, but if it does that and renders text as well as my terminal, I could imagine using it. From richard@infoarts.info Tue Sep 8 17:13:07 2009 From: richard@infoarts.info (Richard Sandilands) Date: Wed, 9 Sep 2009 07:13:07 +1000 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox In-Reply-To: <1252442225-sup-154@masanjin.net> References: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com> <1252442225-sup-154@masanjin.net> Message-ID: <2e8d08f0909081413i402cbb71sfbff3b1fb5e59a2f@mail.gmail.com> On Wed, Sep 9, 2009 at 6:38 AM, William Morgan wrote: > Do you have a before-add-message hook? If so, I'm sorry to say that you > will have to regenerate your index to fix this. There was a problem with > next for a while that allowed that hook to add non-symbol labels to > messages, and those got serialized into Xapian's index. I do indeed, as follows: if message.subj =~ /\[sup-talk\]/ message.add_label "sup" message.add_label "list" end > If not, regenerating it will probably help, but it would be good to find > the source of the non-symbol labels. I do have some labels prepended with an ! to force them to sort to the top of the 'L' list - such as '!followup', '!hold' etc. Could that be an issue? -- Richard From sean.escriva@gmail.com Tue Sep 8 17:50:23 2009 From: sean.escriva@gmail.com (Sean Escriva) Date: Tue, 8 Sep 2009 14:50:23 -0700 Subject: [sup-talk] a few questions on mail handling with sup In-Reply-To: <1252098027-sup-4487@ntdws12.chass.utoronto.ca> References: <20090904191332.GA5525@gmail.com> <1252098027-sup-4487@ntdws12.chass.utoronto.ca> Message-ID: <20090908215023.GA7134@gmail.com> Excerpts from Ben Walton's message of Fri Sep 04 05:01:11 -0400 2009: > Excerpts from Sean Escriva's message of Fri Sep 04 15:13:32 -0400 2009: > > > Currently I have no way to way move messages out of my inbox on the > > imap server, since I'm accessing a local maildir created by > > offlineimap. This is only an issue since mailboxes have a limit of > > 800mb in size on the server and given the volume of mail I have that > > will be reached every other month. I've looked at imap filter and this > > could possibly work, but anyone have experience with this sort of > > sitatuation? > > Could you pull it down with fetchmail into a local MTA setup that only > handles local delivery? Fetchmail has the 'delete on server' option > if offlineimap doesn't. thanks for the reply. fetchmail/procmail is a better option in this case than offlineimap. No need to setup a whole different MTA since I am already using msmtp for sending... thanks again. -sme From rlane@club.cc.cmu.edu Wed Sep 9 02:18:09 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 09 Sep 2009 02:18:09 -0400 Subject: [sup-talk] sup-sync and xapian memory usage In-Reply-To: <1252422827-sup-805@peray> References: <20090907170450.GO14010@pimlott.net> <1252348258-sup-415@zyrg.net> <1252350686-sup-8800@ntdws12.chass.utoronto.ca> <1252350896-sup-5026@zyrg.net> <1252415772-sup-7288@masanjin.net> <1252419716-sup-3031@roughage.com.au> <1252422827-sup-805@peray> Message-ID: <1252427486-sup-8093@zyrg.net> Excerpts from Nicolas Pouillard's message of Tue Sep 08 11:14:22 -0400 2009: > Excerpts from Richard Heycock's message of Tue Sep 08 16:27:10 +0200 2009: > > Excerpts from William Morgan's message of Tue Sep 08 23:39:12 +1000 2009: > > > Reformatted excerpts from Rich Lane's message of 2009-09-07: > > > > Excerpts from Ben Walton's message of Mon Sep 07 15:11:58 -0400 2009: > > > > > Excerpts from Rich Lane's message of Mon Sep 07 14:33:06 -0400 2009: > > > > > > Xapian keeps writes buffered in memory. Try setting the > > > > > > environment variable XAPIAN_FLUSH_THRESHOLD to a smaller value > > > > > > (the default is 10000 documents) and see if that helps. > > > > > > > > > > Does this explain the lag at shutdown? Xapian is flushing writes to > > > > > disk? > > > > > > > > Yep. > > > > > > Good to know. Is there a way to force a flush in Xapian? Just curious. > > > The delay is a little scary sometimes. Maybe it just needs an > > > appropriate message somewhere. > > > > Xapian, by default, flushes every 10 000 documents which in email terms > > is a pretty long time! You can force a flush but it does increase your > > IO significantly. Having said that emails are fairly small so flushing > > every 10 or 20 emails might not be too bad. > > > > Maybe it could be dynamic, if there is a high volume of incoming emails > > flushing could be done after 50 or 100 emails or a timer based flush > > might be easier. > > Should the '$' command, force a write of the Xapian database? I think once we're saving label changes to the index immediately we could re-purpose '$' for this. I've also been considering a timer, as Richard suggests, which would trigger a flush once the user has been idle for some time. A fatal exception in Sup is still a clean exit as far as SWIG is concerned and the Xapian database destructor will do the flush for us in that case, so don't worry about random Sup exceptions causing data loss. From eg@gaute.vetsj.com Wed Sep 9 03:54:53 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Wed, 09 Sep 2009 09:54:53 +0200 Subject: [sup-talk] Exception when trying to open console view Message-ID: <1252482842-sup-4833@qwerzila> Greetings, I get this exception when pressing '~' in the main view: --- ArgumentError from thread: main wrong number of arguments (0 for 1) /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize' /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302:in `new' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302 /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/buffer.rb:341:in `spawn_unless_exists' /home/gaute/.gem/ruby/1.8/gems/sup-999/bin/sup:302 /home/gaute/.gem/ruby/1.8/bin/sup:19:in `load' /home/gaute/.gem/ruby/1.8/bin/sup:19 Cheers, Gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From eg@gaute.vetsj.com Wed Sep 9 04:49:21 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Wed, 09 Sep 2009 10:49:21 +0200 Subject: [sup-talk] updated before-poll hook for offlineimap Message-ID: <1252485986-sup-4958@qwerzila> Greetings, Here's an updated before-poll.rb hook for offlineimap working with latest git. I'm suppressing some nasty python deprecation errors as well. before-poll.rb: def offlineimap(*folders) cmd = "offlineimap -u Noninteractive.Basic 2>&1" cmd << " -f #{folders * ','}" unless folders.compact.empty? `#{cmd}` end def folder_names(sources) sources.map { |s| s.uri.split('/').last } end def inbox_sources(sources = SourceManager.sources) sources.find_all { |s| !s.archived? }.sort_by {|s| s.id } end if (@last_fetch || Time.at(0)) < Time.now - 120 say "Running offlineimap..." # only check non-auto-archived sources on the first run log offlineimap(@last_fetch ? nil : folder_names(inbox_sources)) say "Finished offlineimap." end @last_fetch = Time.now Cheers, Gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Wed Sep 9 09:54:55 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 09 Sep 2009 09:54:55 -0400 Subject: [sup-talk] U (unread) search is off Message-ID: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> Since my update to Xapian, my U searches to display on unread mail aren't working correctly any more. I get lots of mail that is definitely read (doesn't show as new in the search buffer). Is anyone else seeing this? I'm hoping to dig into it later today, but wanted to fire of the query first. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Wed Sep 9 10:14:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 09 Sep 2009 07:14:16 -0700 Subject: [sup-talk] Exception when trying to open console view In-Reply-To: <1252482842-sup-4833@qwerzila> References: <1252482842-sup-4833@qwerzila> Message-ID: <1252505638-sup-6887@masanjin.net> Reformatted excerpts from Gaute Hope's message of 2009-09-09: > --- ArgumentError from thread: main > wrong number of arguments (0 for 1) > /home/gaute/.gem/ruby/1.8/gems/sup-999/lib/sup/modes/console-mode.rb:67:in `initialize' Fixed in master and next. Sorry about that. -- William From wmorgan-sup@masanjin.net Wed Sep 9 10:20:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 09 Sep 2009 07:20:03 -0700 Subject: [sup-talk] ArgumentError from thread: poll after loading inbox In-Reply-To: <2e8d08f0909081413i402cbb71sfbff3b1fb5e59a2f@mail.gmail.com> References: <2e8d08f0909070447u73d6d2efq8eca89f229f890ed@mail.gmail.com> <1252442225-sup-154@masanjin.net> <2e8d08f0909081413i402cbb71sfbff3b1fb5e59a2f@mail.gmail.com> Message-ID: <1252505721-sup-2684@masanjin.net> Reformatted excerpts from Richard Sandilands's message of 2009-09-08: > I do indeed, as follows: Excellent. > I do have some labels prepended with an ! to force them to sort to the > top of the 'L' list - such as '!followup', '!hold' etc. Could that be > an issue? Nope, it was the hook above. (Which is fine, btw, it just triggered something bad.) You will need to regenerate the index and everything should be fine. Sorry about that. If you don't have a recent dumpfile, you may have to apply the following patch to get sup-dump to work. Then you should be able to git fetch, reset the head to origin/next, and run `sup-sync --restored --restore --all-sources`. Let me know if you run into problems. diff --git a/lib/sup/label.rb b/lib/sup/label.rb index 67474c2..b94474d 100644 --- a/lib/sup/label.rb +++ b/lib/sup/label.rb @@ -61,7 +61,7 @@ class LabelManager end def << t - raise ArgumentError, "expecting a symbol" unless t.is_a? Symbol + t = t.to_sym unless @labels.member?(t) || RESERVED_LABELS.member?(t) @labels[t] = true -- William From wmorgan-sup@masanjin.net Wed Sep 9 10:30:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 09 Sep 2009 07:30:43 -0700 Subject: [sup-talk] Change color of 'highlight' indicator in inbox view? In-Reply-To: <1252442174-sup-1472@yoom.home.cworth.org> References: <1252230162-sup-8625@Richard-Sandilandss-MacBook-Pro.local> <1252241877-sup-6125@masanjin.net> <1252442174-sup-1472@yoom.home.cworth.org> Message-ID: <1252506333-sup-9244@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-09-08: > So if I'm understanding that correctly, that's 16 colors available for > the foreground, but only 8 for the background. That's frustrating. Yup. Curses is happy to welcome you to 1982! > Such a limited color selection is almost unimaginable with hardware > capability today. FWIW, most terminal emulators allow you to tweak the actual colors that the curses colors refer to. So you have some flexibility about the actual colors, just a small palette. > (I do see references to "xterm-256color"[*] terminal definitions. > Could sup start depending on things like that? Are there users of sup > using the Linux console or so, and does that support 256-color escape > codes?). I'm not sure. I suspect no, but I would be interested in learning more. > I should figure out how to make the underline vs. color choice for > highlighting to be a configuration option in order to propose this as > a proper patch. I think the only patch I would accept at this point for tweaking the highlight would be a new hook. > Of course, one way is to go away from a curses-based interface. That > might very well make sense in the future where sup is implemented as a > protocol and we can easily have multiple clients. That is one of the goals. > For me, a graphical client won't be of any interest unless it allows > full keyboard control exactly as sup does, but if it does that and > renders text as well as my terminal, I could imagine using it. I agree completely. -- William From wmorgan-sup@masanjin.net Wed Sep 9 10:37:16 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 09 Sep 2009 07:37:16 -0700 Subject: [sup-talk] [PATCH] Add 'a' and 'd' keybindings to thread-view-mode to archive/delete current thread In-Reply-To: <1252440374-sup-9813@masanjin.net> References: <1251325542-sup-3105@yoom.home.cworth.org> <1252000831-sup-9922@masanjin.net> <1252422961-sup-9843@chigamba> <1252440374-sup-9813@masanjin.net> Message-ID: <1252507021-sup-715@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-09-08: > So far I'm counting 3 yes votes (including patch submitter), 3 "won't > use them" votes (including me), and no one being offended. I think I'm > going to apply this. Applied to master. Thanks! -- William From wmorgan-sup@masanjin.net Wed Sep 9 10:38:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 09 Sep 2009 07:38:59 -0700 Subject: [sup-talk] [PATCH] sort labels in the dump In-Reply-To: <1252271062-8775-1-git-send-email-michael@content-space.de> References: <1252271062-8775-1-git-send-email-michael@content-space.de> Message-ID: <1252507122-sup-5429@masanjin.net> Applied to master. Thanks! -- William From cworth@cworth.org Wed Sep 9 13:24:13 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 09 Sep 2009 10:24:13 -0700 Subject: [sup-talk] Thoughts on simplifying thread-view-mode keybindings Message-ID: <1252516237-sup-9414@yoom.home.cworth.org> I only just barely got my proposal for new 'a' and 'd' keybindings into master, and now I'm rethinking them to some extent. Take a look at the existing keybindings for navigating away from the current thread: .a : Archive this thread and kill buffer .d : Delete this thread and kill buffer .s : Mark this thread as spam and kill buffer .N : Mark this thread as unread and kill buffer ,a : Archive this thread, kill buffer, and view next ,d : Delete this thread, kill buffer, and view next ,s : Mark this thread as spam, kill buffer, and view next ,N : Mark this thread as unread, kill buffer, and view next ,n : Kill buffer, and view next ]a : Archive this thread, kill buffer, and view previous ]d : Delete this thread, kill buffer, and view previous ]s : Mark this thread as spam, kill buffer, and view previous ]N : Mark this thread as unread, kill buffer, and view previous ]n : Kill buffer, and view previous Each of these keybindings involve two keys, and each command involves two actions. But the order of the keybindings and actions are reversed. Imagine, for a moment, what would happen if the keybinding order was "fixed" to match the order of the commands, (that is, things like "a," for archive, then view next). With that change, we would no longer need dual-key bindings as the single-key actions could be easily combined with the same effect. That is, we could have just: a : Archive this thread d : Delete this thread s : Mark this thread as spam N : Mark this thread as unread ., x : Kill this buffer , : View next thread ] : View previous thread That's definitely a simpler amount of documentation to have to grasp, and shouldn't be any less work to actually use, (other than the pain of having to retrain muscle memory to do things like "a," instead of ",a"). The next tweak I'd make is to choose keybdindings for 'next' and 'previous' that more obviously go together. (Such as '[' and ']', but then I think I'd also expect '[' to mean previous and ']' to mean next which might wreak havoc on muscle memory). Finally, I'd personally still want a single-key keybinding to do my most frequent combination, (such as archive-and-view-next as with the current 'a' that just landed in master), but maybe that makes more sense to happen only in a hook. What do you all think? Me, I'm pretty new to sup, so the muscle-memory thing isn't *too* big an issue. Is sup still young enough as a tool to be able to accept interface changes like this? -Carl From cworth@cworth.org Wed Sep 9 13:32:30 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 09 Sep 2009 10:32:30 -0700 Subject: [sup-talk] How hard would a universal undo be? Message-ID: <1252517083-sup-58@yoom.home.cworth.org> Being a ruthless mail-processor, I sometimes archive or delete a message hastily and realize a moment later that I actually want to look at the message again. Of course, if that happens when I'm in a thread-index-mode, then I can just hit 'u' to undo and all is fine. But if I make the same mistake in thread-view-mode then I'm currently out of luck. Would it be a small change to move the undo keybinding to somewhere more universal? As a first cut, I'd be happy if it just undid the changes to the index, even without undoing any interface changes. That is, if my previous command was archive-thread-and-view-next-thread, it would be OK if it just undid the archiving part. Bonus points if it also undoes the view-next part, but I can imagine that being more work. Again, this is a feature I'd be happy to spend some time investigating myself when I get the chance. I'd just be happy to hear any thoughts on feasibility. And I'm trying to get in the habit of mentioning issues as I run into them rather than waiting until I have the chance to actually work on them, (at which point I may have forgotten the issues). -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eg@gaute.vetsj.com Wed Sep 9 13:37:29 2009 From: eg@gaute.vetsj.com (Gaute Hope) Date: Wed, 09 Sep 2009 19:37:29 +0200 Subject: [sup-talk] updated before-poll hook for offlineimap In-Reply-To: <1252485986-sup-4958@qwerzila> References: <1252485986-sup-4958@qwerzila> Message-ID: <1252517773-sup-6259@qwerzila> Greetings, It seems like the before-poll.rb hooks is not run when i manually poll for messages; pressing P. Could this be correct? Running 8903cdedc81 - gaute Excerpts from Gaute Hope's message of on. sep. 09 10:49:21 +0200 2009: > Greetings, > > Here's an updated before-poll.rb hook for offlineimap working with > latest git. I'm suppressing some nasty python deprecation errors as > well. > > before-poll.rb: > def offlineimap(*folders) > cmd = "offlineimap -u Noninteractive.Basic 2>&1" > cmd << " -f #{folders * ','}" unless folders.compact.empty? > `#{cmd}` > end > > def folder_names(sources) > sources.map { |s| s.uri.split('/').last } > end > > def inbox_sources(sources = SourceManager.sources) > sources.find_all { |s| !s.archived? }.sort_by {|s| s.id } > end > > if (@last_fetch || Time.at(0)) < Time.now - 120 > say "Running offlineimap..." > # only check non-auto-archived sources on the first run > log offlineimap(@last_fetch ? nil : folder_names(inbox_sources)) > say "Finished offlineimap." > end > @last_fetch = Time.now > > Cheers, Gaute -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ingmar@exherbo.org Thu Sep 10 07:22:30 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Thu, 10 Sep 2009 13:22:30 +0200 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> Message-ID: <1252581713-sup-9701@cannonball> Excerpts from Ben Walton's message of Wed Sep 09 15:54:55 +0200 2009: > > Since my update to Xapian, my U searches to display on unread mail > aren't working correctly any more. I get lots of mail that is > definitely read (doesn't show as new in the search buffer). Is anyone > else seeing this? I'm hoping to dig into it later today, but wanted > to fire of the query first. > > Thanks > -Ben Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and Rich's answer to my mail. -- Exherbo KDE, X.org maintainer From wmorgan-sup@masanjin.net Thu Sep 10 09:59:13 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 10 Sep 2009 06:59:13 -0700 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252581713-sup-9701@cannonball> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> Message-ID: <1252590993-sup-3885@masanjin.net> Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10: > Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and > Rich's answer to my mail. Actually, I haven't been following this too closely, but what is the status? I noticed we have this in xapian_index.rb: qp.default_op = Xapian::Query::OP_AND Is that not sufficient (combined with a newish Xapian, I guess?) to fix the problem? -- William From michael+sup@stapelberg.de Thu Sep 10 09:57:42 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Thu, 10 Sep 2009 15:57:42 +0200 Subject: [sup-talk] GPG: Sending mail to people without a trust-path Message-ID: <1252590996-sup-4087@midna> Hi, occasionally, I receive E-Mail by people who do not have any signatures or at least no trust-path to me. sup (or GPG?) rejects to encrypt mail for such people, just stating: There is no indication that the key belongs to this user It would be good if we can fix this somehow. Best regards, Michael From bwalton@artsci.utoronto.ca Thu Sep 10 10:04:02 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 10 Sep 2009 10:04:02 -0400 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252590993-sup-3885@masanjin.net> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> Message-ID: <1252591407-sup-1747@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009: > Is that not sufficient (combined with a newish Xapian, I guess?) to fix > the problem? I'm running 1.0.14. Maybe I need to update to 1.0.15 then? 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 ingmar@exherbo.org Thu Sep 10 10:08:15 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Thu, 10 Sep 2009 16:08:15 +0200 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252590993-sup-3885@masanjin.net> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> Message-ID: <1252591597-sup-1906@cannonball> Excerpts from William Morgan's message of Thu Sep 10 15:59:13 +0200 2009: > Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10: > > Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and > > Rich's answer to my mail. > > Actually, I haven't been following this too closely, but what is the status? > I noticed we have this in xapian_index.rb: > qp.default_op = Xapian::Query::OP_AND > > Is that not sufficient (combined with a newish Xapian, I guess?) to fix > the problem? Refining a query still doesn't work: Searching for label:foo, then piping through label:bar gives messages that even have neither label. This is on xapian 1.0.15 -- Exherbo KDE, X.org maintainer From wmorgan-sup@masanjin.net Thu Sep 10 10:13:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 10 Sep 2009 07:13:50 -0700 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: <1252517083-sup-58@yoom.home.cworth.org> References: <1252517083-sup-58@yoom.home.cworth.org> Message-ID: <1252591706-sup-7219@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-09-09: > Would it be a small change to move the undo keybinding to somewhere > more universal? The undo keybinding could definitely be moved from thread-index-mode to the main event loop. That's a small change. The bigger amount of work is writing undo lambdas for every operation you want to be able to undo, e.g. every command in thread-view-mode. It's not complicated, just a little tedious, IMO. -- William From wmorgan-sup@masanjin.net Thu Sep 10 10:34:01 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 10 Sep 2009 07:34:01 -0700 Subject: [sup-talk] updated before-poll hook for offlineimap In-Reply-To: <1252517773-sup-6259@qwerzila> References: <1252485986-sup-4958@qwerzila> <1252517773-sup-6259@qwerzila> Message-ID: <1252592969-sup-418@masanjin.net> Reformatted excerpts from Gaute Hope's message of 2009-09-09: > It seems like the before-poll.rb hooks is not run when i manually poll > for messages; pressing P. Could this be correct? It should be. Are you sure the before-poll hook isn't dying the first time it's run (automatically), causing Sup to skip it the second time (when you press P)? You can look in the log buffer. If that's not the case, can you confirm that PollManager#poll gets invoked in both cases? -- William From marco-oweber@gmx.de Thu Sep 10 10:35:46 2009 From: marco-oweber@gmx.de (Marc Weber) Date: Thu, 10 Sep 2009 16:35:46 +0200 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: <1252517083-sup-58@yoom.home.cworth.org> References: <1252517083-sup-58@yoom.home.cworth.org> Message-ID: <1252592875-sup-5649@nixos> Excerpts from Carl Worth's message of Wed Sep 09 19:32:30 +0200 2009: > Being a ruthless mail-processor, I sometimes archive or delete a > message hastily and realize a moment later that I actually want to > look at the message again. What about a "last viewed history" list? Then you could use that to review the threads? Maybe its best to add a property: last-viewed-on: timestamp. Then you can even use the existing search engine to view those threads ? Marc Weber From wmorgan-sup@masanjin.net Thu Sep 10 10:36:22 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 10 Sep 2009 07:36:22 -0700 Subject: [sup-talk] GPG: Sending mail to people without a trust-path In-Reply-To: <1252590996-sup-4087@midna> References: <1252590996-sup-4087@midna> Message-ID: <1252593258-sup-7506@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-10: > occasionally, I receive E-Mail by people who do not have any signatures or > at least no trust-path to me. sup (or GPG?) rejects to encrypt mail for such > people, just stating: > > There is no indication that the key belongs to this user > > It would be good if we can fix this somehow. It's a GPG behavior, which we can work around by adding --always-trust to the GPG commandline, but I'm pretty sure someone will object to that. Patches for a hook to run gpg in a user-defined matter will be accepted. -- William From rlane@club.cc.cmu.edu Thu Sep 10 12:16:35 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 10 Sep 2009 12:16:35 -0400 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252590993-sup-3885@masanjin.net> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> Message-ID: <1252595946-sup-171@zyrg.net> There are actually 2 bugs in this thread. Ben is still using Xapian 1.0.14 which doesn't have my fix for the phantom labels problem. Ingmar's message was about the surprise Xapian::QueryParser feature. Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009: > Reformatted excerpts from Ingmar Vanhassel's message of 2009-09-10: > > Known issue, see http://mid.gmane.org/1251792282-sup-2057 at cannonball and > > Rich's answer to my mail. > > Actually, I haven't been following this too closely, but what is the status? > I noticed we have this in xapian_index.rb: > qp.default_op = Xapian::Query::OP_AND > > Is that not sufficient (combined with a newish Xapian, I guess?) to fix > the problem? I thought it was, but it turns out that unless you explicitly add AND operators Xapian will OR terms over the same field such that "label:foo label:bar" gives you the union instead of the intersection. We could fix this by patching Xapian to make this behavior configurable, or we could come up with an index-agnostic simple query language that doesn't support boolean operators. The native query language would still be available, of course, but the simple one would suffice for most usage and potentially have Sup-specific features. From rlane@club.cc.cmu.edu Thu Sep 10 12:17:11 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 10 Sep 2009 12:17:11 -0400 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252591407-sup-1747@ntdws12.chass.utoronto.ca> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> <1252591407-sup-1747@ntdws12.chass.utoronto.ca> Message-ID: <1252599402-sup-3970@zyrg.net> Excerpts from Ben Walton's message of Thu Sep 10 10:04:02 -0400 2009: > Excerpts from William Morgan's message of Thu Sep 10 09:59:13 -0400 2009: > > > Is that not sufficient (combined with a newish Xapian, I guess?) to fix > > the problem? > > I'm running 1.0.14. Maybe I need to update to 1.0.15 then? Yes, upgrading to 1.0.15 will fix this problem. From bwalton@artsci.utoronto.ca Thu Sep 10 13:13:32 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 10 Sep 2009 13:13:32 -0400 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252599402-sup-3970@zyrg.net> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> <1252591407-sup-1747@ntdws12.chass.utoronto.ca> <1252599402-sup-3970@zyrg.net> Message-ID: <1252602768-sup-3245@ntdws12.chass.utoronto.ca> Excerpts from Rich Lane's message of Thu Sep 10 12:17:11 -0400 2009: > Yes, upgrading to 1.0.15 will fix this problem. Ok, I rolled rpms for 1.0.16 (available to anyone else if they want/need them) and updated. This has resolved the issue for me. Thanks Rich! :) -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 Thu Sep 10 18:45:20 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 10 Sep 2009 18:45:20 -0400 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: <1252517083-sup-58@yoom.home.cworth.org> References: <1252517083-sup-58@yoom.home.cworth.org> Message-ID: <1252599828-sup-7368@zyrg.net> Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009: > Would it be a small change to move the undo keybinding to somewhere > more universal? No :( > As a first cut, I'd be happy if it just undid the changes to the > index, even without undoing any interface changes. That is, if my > previous command was archive-thread-and-view-next-thread, it would be > OK if it just undid the archiving part. Bonus points if it also undoes > the view-next part, but I can imagine that being more work. I know I sound a bit like a broken record here, but immediate label changes will solve this problem. Then, the undo system would just need to keep a global stack of (msgid, previous_labels). I'm just hoping somebody will volunteer for this - it will be a big patch. From nicolas.pouillard@gmail.com Fri Sep 11 05:16:49 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Fri, 11 Sep 2009 11:16:49 +0200 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: <1252599828-sup-7368@zyrg.net> References: <1252517083-sup-58@yoom.home.cworth.org> <1252599828-sup-7368@zyrg.net> Message-ID: <1252660564-sup-4253@peray> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009: > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009: > > Would it be a small change to move the undo keybinding to somewhere > > more universal? > > No :( > > > As a first cut, I'd be happy if it just undid the changes to the > > index, even without undoing any interface changes. That is, if my > > previous command was archive-thread-and-view-next-thread, it would be > > OK if it just undid the archiving part. Bonus points if it also undoes > > the view-next part, but I can imagine that being more work. > > I know I sound a bit like a broken record here, but immediate > label changes will solve this problem. Then, the undo system would just > need to keep a global stack of (msgid, previous_labels). I'm just hoping > somebody will volunteer for this - it will be a big patch. What prevent us from having a global stack of (msgid, previous_labels) in the actual settings? -- Nicolas Pouillard http://nicolaspouillard.fr From bgamari.foss@gmail.com Fri Sep 11 12:58:31 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Fri, 11 Sep 2009 12:58:31 -0400 Subject: [sup-talk] Crash while scrolling Message-ID: <20090911165830.GA11260@ben-laptop> Recently I've been seeing this crash[1] pretty consistently on the next branch with the Xapian backend. All I need to do to reproduce the crash is move to the last thread in the thread-index-mode and attempt to move to the next thread. I can also produce a very similar crash[2] by attempting to load all threads. Thanks, - Ben [1] Crash while scrolling: --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil /opt/exp/sup/lib/sup.rb:17:in `id' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' /opt/exp/sup/lib/sup.rb:75:in `initialize' /opt/exp/sup/lib/sup.rb:75:in `new' /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /opt/exp/sup/lib/sup/mode.rb:51:in `send' /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input' /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input' /usr/bin/sup:238 [2] Crash after attempting to load all threads --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil /opt/exp/sup/lib/sup.rb:17:in `id' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `each' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `sort_by' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:225:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `synchronize' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:628:in `__unprotected_load_n_threads' /opt/exp/sup/lib/sup/thread.rb:334:in `load_n_threads' /opt/exp/sup/lib/sup/xapian_index.rb:151:in `each_id_by_date' /opt/exp/sup/lib/sup/xapian_index.rb:144:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:144:in `each' /opt/exp/sup/lib/sup/xapian_index.rb:144:in `each_id' /opt/exp/sup/lib/sup/xapian_index.rb:151:in `each_id_by_date' /opt/exp/sup/lib/sup/thread.rb:328:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' /opt/exp/sup/lib/sup.rb:75:in `initialize' /opt/exp/sup/lib/sup.rb:75:in `new' /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:658:in `load_all_threads' /opt/exp/sup/lib/sup/mode.rb:51:in `send' /opt/exp/sup/lib/sup/mode.rb:51:in `handle_input' /opt/exp/sup/lib/sup/buffer.rb:267:in `handle_input' /usr/bin/sup:238 From rlane@club.cc.cmu.edu Fri Sep 11 15:52:24 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 11 Sep 2009 15:52:24 -0400 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: <1252660564-sup-4253@peray> References: <1252517083-sup-58@yoom.home.cworth.org> <1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray> Message-ID: <1252685502-sup-8928@zyrg.net> Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009: > Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009: > > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009: > > > Would it be a small change to move the undo keybinding to somewhere > > > more universal? > > > > No :( > > > > > As a first cut, I'd be happy if it just undid the changes to the > > > index, even without undoing any interface changes. That is, if my > > > previous command was archive-thread-and-view-next-thread, it would be > > > OK if it just undid the archiving part. Bonus points if it also undoes > > > the view-next part, but I can imagine that being more work. > > > > I know I sound a bit like a broken record here, but immediate > > label changes will solve this problem. Then, the undo system would just > > need to keep a global stack of (msgid, previous_labels). I'm just hoping > > somebody will volunteer for this - it will be a big patch. > > What prevent us from having a global stack of (msgid, previous_labels) in > the actual settings? Hmm, you may be right. I was thinking that changes weren't propagated between buffers except on save, but that's wrong because UpdateManager is called in the keybinding. In that case, the user sees a mostly* linear series of label changes, so it's safe to have a global undo stack. * User opens thread-index-mode A containing message M with labels L1 User changes labels on A.M to L2 User opens thread-index-mode B containing message M with labels L1 User changes labels on B.M to L3 UpdateManager changes labels on A.M to L3 User hits 'u' - now A.M and B.M have labels L1 From nicolas.pouillard@gmail.com Fri Sep 11 17:25:06 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Fri, 11 Sep 2009 23:25:06 +0200 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: <1252685502-sup-8928@zyrg.net> References: <1252517083-sup-58@yoom.home.cworth.org> <1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray> <1252685502-sup-8928@zyrg.net> Message-ID: On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane wrote: > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009: >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009: >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009: >> > > Would it be a small change to move the undo keybinding to somewhere >> > > more universal? >> > >> > No :( >> > >> > > As a first cut, I'd be happy if it just undid the changes to the >> > > index, even without undoing any interface changes. That is, if my >> > > previous command was archive-thread-and-view-next-thread, it would be >> > > OK if it just undid the archiving part. Bonus points if it also undoes >> > > the view-next part, but I can imagine that being more work. >> > >> > I know I sound a bit like a broken record here, but immediate >> > label changes will solve this problem. Then, the undo system would just >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping >> > somebody will volunteer for this - it will be a big patch. >> >> What prevent us from having a global stack of (msgid, previous_labels) in >> the actual settings? > > Hmm, you may be right. I was thinking that changes weren't propagated > between buffers except on save, but that's wrong because UpdateManager > is called in the keybinding. In that case, the user sees a mostly* > linear series of label changes, so it's safe to have a global undo > stack. he next question is, what else is needed on this undo stack? Are labels the only interaction we have? Here is what come to my mind: * contacts (I more and more think that contacts should not be handled by sup directly, but that's another topic) * drafts -- Nicolas Pouillard From wmorgan-sup@masanjin.net Sat Sep 12 12:35:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 12 Sep 2009 09:35:21 -0700 Subject: [sup-talk] Crash while scrolling In-Reply-To: <20090911165830.GA11260@ben-laptop> References: <20090911165830.GA11260@ben-laptop> Message-ID: <1252773189-sup-246@masanjin.net> Reformatted excerpts from Ben Gamari's message of 2009-09-11: > Recently I've been seeing this crash[1] pretty consistently on the next > branch with the Xapian backend. Is your Xapian index somewhat old? There have been index format changes that have caused this type of thing recently. You might try rebuilding it. -- William From wmorgan-sup@masanjin.net Sat Sep 12 12:47:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 12 Sep 2009 09:47:14 -0700 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252595946-sup-171@zyrg.net> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> <1252595946-sup-171@zyrg.net> Message-ID: <1252773806-sup-11@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-10: > I thought it was, but it turns out that unless you explicitly add AND > operators Xapian will OR terms over the same field such that > "label:foo label:bar" gives you the union instead of the intersection. Ok. I only ask because I'm considering how to present the Xapian index option in 0.9---the options are to not say anything about it, to force everyone to switch to it, or anywhere in between. > We could fix this by patching Xapian to make this behavior > configurable, or we could come up with an index-agnostic simple query > language that doesn't support boolean operators. The former sounds easier to me. Especially since it seems like this is something Xapian should have... -- William From wmorgan-sup@masanjin.net Sat Sep 12 13:08:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 12 Sep 2009 10:08:50 -0700 Subject: [sup-talk] [PATCH] Fix parsing of encrypted messages that contain further multipart elements In-Reply-To: <6fd87965a2e243b190678edb6c4b9cefbde9ae66.1248369563.git.dato@net.com.org.es> References: <6fd87965a2e243b190678edb6c4b9cefbde9ae66.1248369563.git.dato@net.com.org.es> Message-ID: <1252775304-sup-291@masanjin.net> Reformatted excerpts from Adeodato Sim?'s message of 2009-07-23: > Amended patch follows, with a better wording that I had seemingly not > committed. Sorry for the noise. Not sure why I missed this. Branch crypto-mime-fix, merged into next. Thanks! -- William From kevinr@free-dissociation.com Sat Sep 12 15:10:03 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Sat, 12 Sep 2009 15:10:03 -0400 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail stupidity? Message-ID: <1252781841-sup-6303@black-opal.mit.edu> Several people from whom I receive e-mail regularly use a MUA which generates Content-Type: headers of the form > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed The symptoms I see are that I don't get any preview text, and Sup shows the message as consisting only of a spurious attachment of the form: > - Attachment: sup-attachment-1252774311-2202. (8 lines) (Note no file-type suffix.) RFC 2045 (the MIME specification) section 5.1 says in part > The type, subtype, and parameter names are not case sensitive. For > example, TEXT, Text, and TeXt are all equivalent top-level media > types. So the above should be handled just like the many mails with headers of the form > Content-Type: text/plain; charset="us-ascii"; format=flowed I get, which Sup handles perfectly. I theorize that RubyMail is being case-sensitive where it shouldn't. Given the number of work-arounds Sup has had to implement to compensate for RubyMail's stupidity, and that RubyMail is currently unmaintained, has any thought been given to switching Sup to eg. TMail (http://tmail.rubyforge.org), which is maintained? Failing that, thoughts on how best to work around this problem in Sup? - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com From gigabo@gmail.com Sat Sep 12 17:01:17 2009 From: gigabo@gmail.com (Bo Borgerson) Date: Sat, 12 Sep 2009 17:01:17 -0400 Subject: [sup-talk] Hello and thanks Message-ID: <1252787425-sup-4073@longword> Hi, I just started using sup yesterday. I'm really impressed by it. As I've been using it I've been thinking of little tweaks to get it working exactly how I like. Some of these will work with hooks (that's a nice system), but some seem better suited to small patches. I'm going to submit some of these patches to see if they're useful enough to include upstream. A git-send-email out of the blue isn't necessarily the friendliest of introductions, though, so I just wanted to write first and say thanks to William and everyone who has contributed to sup. It's pretty awesome. Thanks. Bo From gigabo@gmail.com Sat Sep 12 17:04:05 2009 From: gigabo@gmail.com (Bo Borgerson) Date: Sat, 12 Sep 2009 17:04:05 -0400 Subject: [sup-talk] [PATCH] Handle added messages in label-list-mode Message-ID: <1252789445-30193-1-git-send-email-gigabo@gmail.com> Register label-list-mode with the UpdateManager and handle added updates with a reload to keep unread message counts up to date --- lib/sup/modes/label-list-mode.rb | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/label-list-mode.rb b/lib/sup/modes/label-list-mode.rb index d94f56f..f0084a9 100644 --- a/lib/sup/modes/label-list-mode.rb +++ b/lib/sup/modes/label-list-mode.rb @@ -31,9 +31,15 @@ EOS @text = [] @unread_only = false super + UpdateManager.register self regen_text end + def cleanup + UpdateManager.unregister self + super + end + def lines; @text.length end def [] i; @text[i] end @@ -52,6 +58,10 @@ EOS reload # make sure unread message counts are up-to-date end + def handle_added_update sender, m + reload + end + protected def toggle_show_unread_only -- 1.6.0.4 From gigabo@gmail.com Sun Sep 13 10:38:35 2009 From: gigabo@gmail.com (Bo Borgerson) Date: Sun, 13 Sep 2009 10:38:35 -0400 Subject: [sup-talk] [PATCH] Add command for polling unusual sources Message-ID: <1252852715-9601-1-git-send-email-gigabo@gmail.com> bin/sup: Add new global key binding, '{', to poll unusual sources (requires confirmation). This allows update of unusual sources without having to leave sup to run a sync. lib/sup/poll.rb: Add new method, poll_unusual. Both the pre-existing poll method and the new poll_unusual method are now wrappers around new poll_with_sources method that contains the bulk of functionality previously in poll. lib/sup/source.rb: Add new accessor for unusual_sources --- bin/sup | 5 +++++ lib/sup/poll.rb | 23 +++++++++++++++++++---- lib/sup/source.rb | 1 + 3 files changed, 25 insertions(+), 4 deletions(-) diff --git a/bin/sup b/bin/sup index 76a0438..996c99e 100755 --- a/bin/sup +++ b/bin/sup @@ -75,6 +75,7 @@ global_keymap = Keymap.new do |k| k.add :search_unread, "Show all unread messages", 'U' k.add :list_labels, "List labels", 'L' k.add :poll, "Poll for new messages", 'P' + k.add :poll_unusual, "Poll for new messages from unusual sources", '{' k.add :compose, "Compose new message", 'm', 'c' k.add :nothing, "Do nothing", :ctrl_g k.add :recall_draft, "Edit most recent draft message", 'R' @@ -282,6 +283,10 @@ begin ComposeMode.spawn_nicely when :poll reporting_thread("user-invoked poll") { PollManager.poll } + when :poll_unusual + if BufferManager.ask_yes_or_no "Really poll unusual sources?" + reporting_thread("user-invoked unusual poll") { PollManager.poll_unusual } + end when :recall_draft case Index.num_results_for :label => :draft when 0 diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb index b59237f..ec51dec 100644 --- a/lib/sup/poll.rb +++ b/lib/sup/poll.rb @@ -35,12 +35,11 @@ EOS @thread = nil @last_poll = nil @polling = false + @poll_sources = nil @mode = nil end - def poll - return if @polling - @polling = true + def poll_with_sources @mode ||= PollMode.new HookManager.run "before-poll" @@ -54,6 +53,22 @@ EOS HookManager.run "after-poll", :num => num, :num_inbox => numi, :from_and_subj => from_and_subj, :from_and_subj_inbox => from_and_subj_inbox, :num_inbox_total_unread => lambda { Index.num_results_for :labels => [:inbox, :unread] } + end + + def poll + return if @polling + @polling = true + @poll_sources = SourceManager.usual_sources + num, numi = poll_with_sources + @polling = false + [num, numi] + end + + def poll_unusual + return if @polling + @polling = true + @poll_sources = SourceManager.unusual_sources + num, numi = poll_with_sources @polling = false [num, numi] end @@ -78,7 +93,7 @@ EOS from_and_subj_inbox = [] @mutex.synchronize do - SourceManager.usual_sources.each do |source| + @poll_sources.each do |source| # yield "source #{source} is done? #{source.done?} (cur_offset #{source.cur_offset} >= #{source.end_offset})" begin yield "Loading from #{source}... " unless source.done? || (source.respond_to?(:has_errors?) && source.has_errors?) diff --git a/lib/sup/source.rb b/lib/sup/source.rb index 78386ff..6fe7bfb 100644 --- a/lib/sup/source.rb +++ b/lib/sup/source.rb @@ -207,6 +207,7 @@ class SourceManager def source_for uri; sources.find { |s| s.is_source_for? uri }; end def usual_sources; sources.find_all { |s| s.usual? }; end + def unusual_sources; sources.find_all { |s| !s.usual? }; end def load_sources fn=Redwood::SOURCE_FN source_array = (Redwood::load_yaml_obj(fn) || []).map { |o| Recoverable.new o } -- 1.6.0.4 From bgamari.foss@gmail.com Sun Sep 13 11:02:32 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Sun, 13 Sep 2009 11:02:32 -0400 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1252773189-sup-246@masanjin.net> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> Message-ID: <20090913150232.GB10024@ben-laptop> On Sat, Sep 12, 2009 at 09:35:21AM -0700, William Morgan wrote: > Reformatted excerpts from Ben Gamari's message of 2009-09-11: > > Recently I've been seeing this crash[1] pretty consistently on the next > > branch with the Xapian backend. > > Is your Xapian index somewhat old? There have been index format changes > that have caused this type of thing recently. You might try rebuilding > it. I wish I could say it was unfortunately I just rebuilt it two days ago, suspecting that might be part of the issue. I'll try again, just to make sure but I'm fairly certain the index is up-to-date. - Ben From rlane@club.cc.cmu.edu Sun Sep 13 14:44:09 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 13 Sep 2009 11:44:09 -0700 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state Message-ID: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu> Refactor index_message so that we do the minimal amount of work based on what state the user has modified. --- lib/sup/xapian_index.rb | 241 +++++++++++++++++++++++++++-------------------- 1 files changed, 137 insertions(+), 104 deletions(-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index e1cfe65..ad45b0e 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -42,8 +42,6 @@ EOS @xapian = Xapian::WritableDatabase.new(path, Xapian::DB_CREATE) @xapian.set_metadata 'version', INDEX_VERSION end - @term_generator = Xapian::TermGenerator.new() - @term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE) @enquire = Xapian::Enquire.new @xapian @enquire.weighting_scheme = Xapian::BoolWeight.new @enquire.docid_order = Xapian::Enquire::ASCENDING @@ -91,41 +89,9 @@ EOS m end - def add_message m; sync_message m end - def update_message m; sync_message m end - def update_message_state m; sync_message m end - - def sync_message m, opts={} - entry = synchronize { get_entry m.id } - snippet = m.snippet - entry ||= {} - labels = m.labels - entry = {} if opts[:force_overwrite] - - d = { - :message_id => m.id, - :source_id => m.source.id, - :source_info => m.source_info, - :date => (entry[:date] || m.date), - :snippet => snippet, - :labels => labels, - :from => (entry[:from] || [m.from.email, m.from.name]), - :to => (entry[:to] || m.to.map { |p| [p.email, p.name] }), - :cc => (entry[:cc] || m.cc.map { |p| [p.email, p.name] }), - :bcc => (entry[:bcc] || m.bcc.map { |p| [p.email, p.name] }), - :subject => m.subj, - :refs => (entry[:refs] || m.refs), - :replytos => (entry[:replytos] || m.replytos), - } - - labels.each { |l| LabelManager << l } - - synchronize do - index_message m, d, opts - end - true - end - private :sync_message + def add_message m; sync_message m, true end + def update_message m; sync_message m, true end + def update_message_state m; sync_message m, false end def num_results_for query={} xapian_query = build_xapian_query query @@ -153,7 +119,6 @@ EOS def each_message_in_thread_for m, opts={} # TODO thread by subject - # TODO handle killed threads return unless doc = find_doc(m.id) queue = doc.value(THREAD_VALUENO).split(',') msgids = [m.id] @@ -438,100 +403,140 @@ EOS end end - def index_message m, entry, opts - terms = [] - text = [] + def sync_message m, overwrite + doc = synchronize { find_doc(m.id) } + existed = doc != nil + doc ||= Xapian::Document.new + do_index_static = overwrite || !existed + old_entry = !do_index_static && doc.entry + snippet = do_index_static ? m.snippet : old_entry[:snippet] - subject_text = m.indexable_subject - body_text = m.indexable_body + entry = { + :message_id => m.id, + :source_id => m.source.id, + :source_info => m.source_info, + :date => m.date, + :snippet => snippet, + :labels => m.labels.to_a, + :from => [m.from.email, m.from.name], + :to => m.to.map { |p| [p.email, p.name] }, + :cc => m.cc.map { |p| [p.email, p.name] }, + :bcc => m.bcc.map { |p| [p.email, p.name] }, + :subject => m.subj, + :refs => m.refs.to_a, + :replytos => m.replytos.to_a, + } + if do_index_static + doc.clear_terms + doc.clear_values + index_message_static m, doc, entry + end + + index_message_threading doc, entry, old_entry + index_message_labels doc, entry[:labels], (do_index_static ? [] : old_entry[:labels]) + doc.entry = entry + + synchronize do + unless docid = existed ? doc.docid : assign_docid(m, truncate_date(m.date)) + # Could be triggered by spam + warn "docid underflow, dropping #{m.id.inspect}" + return + end + @xapian.replace_document docid, doc + end + + m.labels.each { |l| LabelManager << l } + true + end + + ## Index content that can't be changed by the user + def index_message_static m, doc, entry # Person names are indexed with several prefixes person_termer = lambda do |d| lambda do |p| ["#{d}_name", "name", "body"].each do |x| - text << [p.name, PREFIX[x]] + doc.index_text p.name, PREFIX[x] end if p.name - [d, :any].each { |x| terms << mkterm(:email, x, p.email) } + [d, :any].each { |x| doc.add_term mkterm(:email, x, p.email) } end end person_termer[:from][m.from] if m.from (m.to+m.cc+m.bcc).each(&(person_termer[:to])) - terms << mkterm(:date,m.date) if m.date - m.labels.each { |t| terms << mkterm(:label,t) } - terms << mkterm(:type, 'mail') - terms << mkterm(:msgid, m.id) - terms << mkterm(:source_id, m.source.id) + # Full text search content + subject_text = m.indexable_subject + body_text = m.indexable_body + doc.index_text subject_text, PREFIX['subject'] + doc.index_text subject_text, PREFIX['body'] + doc.index_text body_text, PREFIX['body'] + m.attachments.each { |a| doc.index_text a, PREFIX['attachment'] } + + # Miscellaneous terms + doc.add_term mkterm(:date, m.date) if m.date + doc.add_term mkterm(:type, 'mail') + doc.add_term mkterm(:msgid, m.id) + doc.add_term mkterm(:source_id, m.source.id) m.attachments.each do |a| a =~ /\.(\w+)$/ or next - t = mkterm(:attachment_extension, $1) - terms << t + doc.add_term mkterm(:attachment_extension, $1) + end + + # Date value for range queries + date_value = begin + Xapian.sortable_serialise m.date.to_i + rescue TypeError + Xapian.sortable_serialise 0 end - ## Thread membership - children = term_docids(mkterm(:ref, m.id)).map { |docid| @xapian.document docid } - parent_ids = m.refs + m.replytos + doc.add_value MSGID_VALUENO, m.id + doc.add_value DATE_VALUENO, date_value + end + + def index_message_labels doc, new_labels, old_labels + return if new_labels == old_labels + added = new_labels.to_a - old_labels.to_a + removed = old_labels.to_a - new_labels.to_a + added.each { |t| doc.add_term mkterm(:label,t) } + removed.each { |t| doc.remove_term mkterm(:label,t) } + end + + ## Assign a set of thread ids to the document. This is a hybrid of the runtime + ## search done by the Ferret index and the index-time union done by previous + ## versions of the Xapian index. We first find the thread ids of all messages + ## with a reference to or from us. If that set is empty, we use our own + ## message id. Otherwise, we use all the thread ids we previously found. In + ## the common case there's only one member in that set, but if we're the + ## missing link between multiple previously unrelated threads we can have + ## more. XapianIndex#each_message_in_thread_for follows the thread ids when + ## searching so the user sees a single unified thread. + def index_message_threading doc, entry, old_entry + return if old_entry && (entry[:refs] == old_entry[:refs]) && (entry[:replytos] == old_entry[:replytos]) + children = term_docids(mkterm(:ref, entry[:message_id])).map { |docid| @xapian.document docid } + parent_ids = entry[:refs] + entry[:replytos] parents = parent_ids.map { |id| find_doc id }.compact thread_members = SavingHash.new { [] } (children + parents).each do |doc2| thread_ids = doc2.value(THREAD_VALUENO).split ',' thread_ids.each { |thread_id| thread_members[thread_id] << doc2 } end + thread_ids = thread_members.empty? ? [entry[:message_id]] : thread_members.keys + thread_ids.each { |thread_id| doc.add_term mkterm(:thread, thread_id) } + parent_ids.each { |ref| doc.add_term mkterm(:ref, ref) } + doc.add_value THREAD_VALUENO, (thread_ids * ',') + end - thread_ids = thread_members.empty? ? [m.id] : thread_members.keys - - thread_ids.each { |thread_id| terms << mkterm(:thread, thread_id) } - parent_ids.each do |ref| - terms << mkterm(:ref, ref) - end - - # Full text search content - text << [subject_text, PREFIX['subject']] - text << [subject_text, PREFIX['body']] - text << [body_text, PREFIX['body']] - m.attachments.each { |a| text << [a, PREFIX['attachment']] } - - truncated_date = if m.date < MIN_DATE - debug "warning: adjusting too-low date #{m.date} for indexing" + def truncate_date date + if date < MIN_DATE + debug "warning: adjusting too-low date #{date} for indexing" MIN_DATE - elsif m.date > MAX_DATE - debug "warning: adjusting too-high date #{m.date} for indexing" + elsif date > MAX_DATE + debug "warning: adjusting too-high date #{date} for indexing" MAX_DATE else - m.date - end - - # Date value for range queries - date_value = begin - Xapian.sortable_serialise truncated_date.to_i - rescue TypeError - Xapian.sortable_serialise 0 - end - - docid = nil - unless doc = find_doc(m.id) - doc = Xapian::Document.new - if not docid = assign_docid(m, truncated_date) - # Could be triggered by spam - Redwood::log "warning: docid underflow, dropping #{m.id.inspect}" - return - end - else - doc.clear_terms - doc.clear_values - docid = doc.docid + date end - - @term_generator.document = doc - text.each { |text,prefix| @term_generator.index_text text, 1, prefix } - terms.each { |term| doc.add_term term if term.length <= MAX_TERM_LENGTH } - doc.add_value MSGID_VALUENO, m.id - doc.add_value THREAD_VALUENO, (thread_ids * ',') - doc.add_value DATE_VALUENO, date_value - doc.data = Marshal.dump entry - - @xapian.replace_document docid, doc end # Construct a Xapian term @@ -561,6 +566,34 @@ EOS end end + module DocumentMethods + def entry + Marshal.load data + end + + def entry=(x) + self.data = Marshal.dump x + end + + def index_text text, prefix, weight=1 + term_generator = Xapian::TermGenerator.new + term_generator.stemmer = Xapian::Stem.new(STEM_LANGUAGE) + term_generator.document = self + term_generator.index_text text, weight, prefix + end + + def add_term term + if term.length <= MAX_TERM_LENGTH + super term + else + warn "dropping excessively long term #{term}" + end + end + end +end + end +class Xapian::Document + include Redwood::XapianIndex::DocumentMethods end -- 1.6.4.2 From rlane@club.cc.cmu.edu Sun Sep 13 17:40:05 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 13 Sep 2009 17:40:05 -0400 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: References: <1252517083-sup-58@yoom.home.cworth.org> <1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray> <1252685502-sup-8928@zyrg.net> Message-ID: <1252877576-sup-8500@zyrg.net> Excerpts from Nicolas Pouillard's message of Fri Sep 11 17:25:06 -0400 2009: > On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane wrote: > > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009: > >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009: > >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009: > >> > > Would it be a small change to move the undo keybinding to somewhere > >> > > more universal? > >> > > >> > No :( > >> > > >> > > As a first cut, I'd be happy if it just undid the changes to the > >> > > index, even without undoing any interface changes. That is, if my > >> > > previous command was archive-thread-and-view-next-thread, it would be > >> > > OK if it just undid the archiving part. Bonus points if it also undoes > >> > > the view-next part, but I can imagine that being more work. > >> > > >> > I know I sound a bit like a broken record here, but immediate > >> > label changes will solve this problem. Then, the undo system would just > >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping > >> > somebody will volunteer for this - it will be a big patch. > >> > >> What prevent us from having a global stack of (msgid, previous_labels) in > >> the actual settings? > > > > Hmm, you may be right. I was thinking that changes weren't propagated > > between buffers except on save, but that's wrong because UpdateManager > > is called in the keybinding. In that case, the user sees a mostly* > > linear series of label changes, so it's safe to have a global undo > > stack. > > he next question is, what else is needed on this undo stack? > > Are labels the only interaction we have? Here is what come to my mind: > > * contacts (I more and more think that contacts should not be handled by > sup directly, but that's another topic) > * drafts > What actions on drafts are you thinking of making undoable? Could we implement them with reserved labels? From dato@net.com.org.es Sun Sep 13 19:17:53 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Mon, 14 Sep 2009 00:17:53 +0100 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <1251048347-sup-5075@masanjin.net> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry> <20090730155656.GA20442@chistera.yi.org> <20090819212209.GA10883@chistera.yi.org> <1250964880-sup-7106@masanjin.net> <20090822191617.GA26897@chistera.yi.org> <1251048347-sup-5075@masanjin.net> Message-ID: <20090913231753.GA20849@chistera.yi.org> + William Morgan (Sun, 23 Aug 2009 10:34:10 -0700): > Anyways, I just merged my hook changes into next, on the branch > hook-local-vars. Take a look and tell me what you think. This should > also fix Edward Z. Yang's problems with hook locals not being useable in > statements like "x = x.foo()". Works for me, thanks. Now that that fix is in, can you merge the mime-decode improvement from <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato at net.com.org.es>? Thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai From rlane@club.cc.cmu.edu Sun Sep 13 20:31:23 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 13 Sep 2009 20:31:23 -0400 Subject: [sup-talk] U (unread) search is off In-Reply-To: <1252773806-sup-11@masanjin.net> References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> <1252595946-sup-171@zyrg.net> <1252773806-sup-11@masanjin.net> Message-ID: <1252878152-sup-9190@zyrg.net> Excerpts from William Morgan's message of Sat Sep 12 12:47:14 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-09-10: > > I thought it was, but it turns out that unless you explicitly add AND > > operators Xapian will OR terms over the same field such that > > "label:foo label:bar" gives you the union instead of the intersection. > > Ok. I only ask because I'm considering how to present the Xapian index > option in 0.9---the options are to not say anything about it, to force > everyone to switch to it, or anywhere in between. Yeah, we do need the query behavior to be reasonable before advertising the Xapian index. What's your timeline on 0.9? > > We could fix this by patching Xapian to make this behavior > > configurable, or we could come up with an index-agnostic simple query > > language that doesn't support boolean operators. > > The former sounds easier to me. Especially since it seems like this is > something Xapian should have... Agreed that Xapian should have this, and I'll probably implement it. We still need to support people using older Xapian versions though. Whether this means a log message telling them to use explicit ANDs in their query, or automatically transforming simple-enough queries into what we think they actually want, I don't know. I'll also need to add a workaround for the earlier Xapian bug before this index gets wider usage. As far as which index to make the default, Ferret has the advantage of being installable as a gem dependency. I think this ease of installation is important enough to block Xapian for now, unless someone can create a Xapian gem. There's been interest in this before: http://article.gmane.org/gmane.comp.search.xapian.devel/1408/ From nicolas.pouillard@gmail.com Mon Sep 14 12:29:09 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 14 Sep 2009 18:29:09 +0200 Subject: [sup-talk] How hard would a universal undo be? In-Reply-To: <1252877576-sup-8500@zyrg.net> References: <1252517083-sup-58@yoom.home.cworth.org> <1252599828-sup-7368@zyrg.net> <1252660564-sup-4253@peray> <1252685502-sup-8928@zyrg.net> <1252877576-sup-8500@zyrg.net> Message-ID: <1252945595-sup-1907@peray> Excerpts from Rich Lane's message of Sun Sep 13 23:40:05 +0200 2009: > Excerpts from Nicolas Pouillard's message of Fri Sep 11 17:25:06 -0400 2009: > > On Fri, Sep 11, 2009 at 9:52 PM, Rich Lane wrote: > > > Excerpts from Nicolas Pouillard's message of Fri Sep 11 05:16:49 -0400 2009: > > >> Excerpts from Rich Lane's message of Fri Sep 11 00:45:20 +0200 2009: > > >> > Excerpts from Carl Worth's message of Wed Sep 09 13:32:30 -0400 2009: > > >> > > Would it be a small change to move the undo keybinding to somewhere > > >> > > more universal? > > >> > > > >> > No :( > > >> > > > >> > > As a first cut, I'd be happy if it just undid the changes to the > > >> > > index, even without undoing any interface changes. That is, if my > > >> > > previous command was archive-thread-and-view-next-thread, it would be > > >> > > OK if it just undid the archiving part. Bonus points if it also undoes > > >> > > the view-next part, but I can imagine that being more work. > > >> > > > >> > I know I sound a bit like a broken record here, but immediate > > >> > label changes will solve this problem. Then, the undo system would just > > >> > need to keep a global stack of (msgid, previous_labels). I'm just hoping > > >> > somebody will volunteer for this - it will be a big patch. > > >> > > >> What prevent us from having a global stack of (msgid, previous_labels) in > > >> the actual settings? > > > > > > Hmm, you may be right. I was thinking that changes weren't propagated > > > between buffers except on save, but that's wrong because UpdateManager > > > is called in the keybinding. In that case, the user sees a mostly* > > > linear series of label changes, so it's safe to have a global undo > > > stack. > > > > he next question is, what else is needed on this undo stack? > > > > Are labels the only interaction we have? Here is what come to my mind: > > > > * contacts (I more and more think that contacts should not be handled by > > sup directly, but that's another topic) > > * drafts > > > > What actions on drafts are you thinking of making undoable? Could we > implement them with reserved labels? No I think that's fine for now to consider, discarding, editing... non-undoable actions. Basically I agree with a global undo stack of labels, I'm just searching for issues ahead. -- Nicolas Pouillard http://nicolaspouillard.fr From olly@survex.com Tue Sep 15 03:18:51 2009 From: olly@survex.com (Olly Betts) Date: Tue, 15 Sep 2009 07:18:51 +0000 (UTC) Subject: [sup-talk] U (unread) search is off References: <1252504368-sup-9406@ntdws12.chass.utoronto.ca> <1252581713-sup-9701@cannonball> <1252590993-sup-3885@masanjin.net> <1252595946-sup-171@zyrg.net> <1252773806-sup-11@masanjin.net> <1252878152-sup-9190@zyrg.net> Message-ID: Rich Lane writes: > Agreed that Xapian should have this, and I'll probably implement it. We > still need to support people using older Xapian versions though. Whether > this means a log message telling them to use explicit ANDs in their > query, or automatically transforming simple-enough queries into what we > think they actually want, I don't know. I'll also need to add a > workaround for the earlier Xapian bug before this index gets wider > usage. I've now opened a Xapian ticket for this: http://trac.xapian.org/ticket/402 Patches are certainly most welcome, especially as I'm currently trying to focus on getting Xapian 1.2.0 out of the door. I don't see a satisfactory workaround for it, sadly. > As far as which index to make the default, Ferret has the advantage of > being installable as a gem dependency. I think this ease of installation > is important enough to block Xapian for now, unless someone can create a > Xapian gem. There's been interest in this before: > http://article.gmane.org/gmane.comp.search.xapian.devel/1408/ I recently noticed this gem version of (modified) xapian-bindings: http://groups.google.com/group/acts_as_xapian/msg/1bbb1e0d3753a0b7 I've not had a chance to look at it yet though, so I don't know if the changes mentioned are compatible or not. Assuming they're useful, they probably should be folded in upstream - more idiomatic wrappers are a desirable improvement (though if they're incompatible we'd need some sort of migration plan). It doesn't seem productive to have forked versions like this either. Cheers, Olly From michael@content-space.de Tue Sep 15 12:20:59 2009 From: michael@content-space.de (Michael Hamann) Date: Tue, 15 Sep 2009 18:20:59 +0200 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock? Message-ID: <1253030868-sup-8556@mithink> Hi, as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/. After that I tried running sup and after seeing the main screen for a few moments sup crashed with the following error (I'm using the latest version from next, but with master it's the same): ThreadError from thread: load threads for thread-index-mode deadlock; recursive locking :6:in `lock' :6:in `synchronize' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:757:in `regen_text' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:687:in `resize' /home/michitux/pub/software/sup/lib/sup/buffer.rb:87:in `resize' /home/michitux/pub/software/sup/lib/sup/buffer.rb:328:in `draw_screen' /home/michitux/pub/software/sup/lib/sup/buffer.rb:728:in `flash' /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing' /home/michitux/pub/software/sup/lib/sup/hook.rb:87:in `rescue in run' /home/michitux/pub/software/sup/lib/sup/hook.rb:81:in `run' /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:714:in `size_widget_for_thread' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `block (2 levels) in update' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `map' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `block in update' :8:in `synchronize' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:223:in `update' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:637:in `load_n_threads' (eval):12:in `load_n_threads' /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:609:in `block in load_n_threads_background' /home/michitux/pub/software/sup/lib/sup.rb:77:in `block in reporting_thread I then tried running sup-dump, it worked without problems, the results looks correct (just a few changed lines that represent the changes of the last days). I then installed xapian and tried reimporting my mails and all I've got after importing 46 mails of about 44000 is: Scanning maildir:/home/michitux/mail... /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `gsub': invalid byte sequence in US-ASCII (ArgumentError) from /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `parse_header' from /home/michitux/pub/software/sup/lib/sup/message.rb:238:in `load_from_source!' from /home/michitux/pub/software/sup/lib/sup/message.rb:335:in `build_from_source' from /home/michitux/pub/software/sup/lib/sup/poll.rb:145:in `block in each_message_from' from /home/michitux/pub/software/sup/lib/sup/maildir.rb:160:in `block in each' from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `upto' from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `each' from /home/michitux/pub/software/sup/lib/sup/util.rb:560:in `__pass' from /home/michitux/pub/software/sup/lib/sup/util.rb:547:in `method_missing' from /home/michitux/pub/software/sup/lib/sup/poll.rb:139:in `each_message_from' from /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing' from bin/sup-sync:146:in `block in
' from bin/sup-sync:141:in `each' from bin/sup-sync:141:in `
' Running sup with xapian and ruby 1.9.1 works as long as there aren't any mails displayed, when I e.g. select a label that contains mails, sub crashes again with the same exception as with ferret. Is there anything I'm missing, is sup just not ready for Ruby 1.9.1 or is there another issue? Greetings Michael Hamann From sean.escriva@gmail.com Tue Sep 15 13:53:39 2009 From: sean.escriva@gmail.com (Sean Escriva) Date: Tue, 15 Sep 2009 10:53:39 -0700 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock? In-Reply-To: <1253030868-sup-8556@mithink> References: <1253030868-sup-8556@mithink> Message-ID: <20090915175339.GA15735@gmail.com> Excerpts from Michael Hamann's message of Tue Sep 15 06:20:59 +0200 2009: > Hi, > > as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got > Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of > sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at > http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/. I followed a similar path after the recent upgrade to no avail. In the end I downgraded ruby back to 1.8.7_p160 from older arch packages available here: http://www.schlunix.org/archlinux/extra/os/x86_64/ I'd like a better solution, but I've become dependent on sup for daily work. > [..snip..] From mailinglist@flasht.de Tue Sep 15 16:21:59 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Tue, 15 Sep 2009 22:21:59 +0200 Subject: [sup-talk] Fixing header for encrypted messages (might be an old issue) Message-ID: <1253045775-sup-210@thinkpad-ubuntu> Hi! I've been having problems with encrypting messages. No idea where this came from, but somehow the protocol part in encrypted messages had an extra pair of quotes, e.g.: protocol=""application/pgp-encrypted"" which caused it to not be recognized by some clients (e.g. mutt as far as I know). Here's a simple fix. I have no idea, why this suddenly came up. Might be that it had been like this all the time, just no one had a problem with it? (I highly doubt that though!) If this is an old issue and I'm just using an old version, feel free to ignore this. I've tried using the current master or next branch, but that causes a crash when trying to open encrypted emails. Maybe someone else is having a similar problem? Greetings, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: protocol-fix.patch Type: application/octet-stream Size: 509 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Tue Sep 15 16:32:42 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Tue, 15 Sep 2009 16:32:42 -0400 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock? In-Reply-To: <1253030868-sup-8556@mithink> References: <1253030868-sup-8556@mithink> Message-ID: <1253043209-sup-8800@zyrg.net> Excerpts from Michael Hamann's message of Tue Sep 15 12:20:59 -0400 2009: > Hi, > > as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got > Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of > sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at > http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/. > > After that I tried running sup and after seeing the main screen for a few > moments sup crashed with the following error (I'm using the latest version from > next, but with master it's the same): > > ThreadError from thread: load threads for thread-index-mode > deadlock; recursive locking > :6:in `lock' > :6:in `synchronize' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:757:in > `regen_text' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:687:in > `resize' > /home/michitux/pub/software/sup/lib/sup/buffer.rb:87:in `resize' > /home/michitux/pub/software/sup/lib/sup/buffer.rb:328:in `draw_screen' > /home/michitux/pub/software/sup/lib/sup/buffer.rb:728:in `flash' > /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing' > /home/michitux/pub/software/sup/lib/sup/hook.rb:87:in `rescue in run' > /home/michitux/pub/software/sup/lib/sup/hook.rb:81:in `run' > /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:714:in > `size_widget_for_thread' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in > `block (2 levels) in update' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in `map' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:226:in > `block in update' > :8:in `synchronize' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:223:in > `update' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:637:in > `load_n_threads' > (eval):12:in `load_n_threads' > /home/michitux/pub/software/sup/lib/sup/modes/thread-index-mode.rb:609:in > `block in load_n_threads_background' > /home/michitux/pub/software/sup/lib/sup.rb:77:in `block in reporting_thread > We're calling the size widget hook while holding the thread-index-mode lock, then the hook throws an exception that results in trying to acquire the lock again. We shouldn't be calling arbitrary code with locks held. Until we figure that change out we could just change the mutex to be a monitor. > I then tried running sup-dump, it worked without problems, the results looks > correct (just a few changed lines that represent the changes of the last days). > > I then installed xapian and tried reimporting my mails and all I've got after > importing 46 mails of about 44000 is: > > Scanning maildir:/home/michitux/mail... > /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `gsub': invalid byte > sequence in US-ASCII (ArgumentError) > from /home/michitux/pub/software/sup/lib/sup/message.rb:103:in `parse_header' > from /home/michitux/pub/software/sup/lib/sup/message.rb:238:in > `load_from_source!' > from /home/michitux/pub/software/sup/lib/sup/message.rb:335:in > `build_from_source' > from /home/michitux/pub/software/sup/lib/sup/poll.rb:145:in `block in > each_message_from' > from /home/michitux/pub/software/sup/lib/sup/maildir.rb:160:in `block in each' > from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `upto' > from /home/michitux/pub/software/sup/lib/sup/maildir.rb:157:in `each' > from /home/michitux/pub/software/sup/lib/sup/util.rb:560:in `__pass' > from /home/michitux/pub/software/sup/lib/sup/util.rb:547:in `method_missing' > from /home/michitux/pub/software/sup/lib/sup/poll.rb:139:in `each_message_from' > from /home/michitux/pub/software/sup/lib/sup/util.rb:520:in `method_missing' > from bin/sup-sync:146:in `block in
' > from bin/sup-sync:141:in `each' > from bin/sup-sync:141:in `
' This is a 1.9 encoding issue. I imagine we have a number of these, even outside of rmail. > Running sup with xapian and ruby 1.9.1 works as long as there aren't any mails > displayed, when I e.g. select a label that contains mails, sub crashes again > with the same exception as with ferret. > > Is there anything I'm missing, is sup just not ready for Ruby 1.9.1 or is there > another issue? I think William said he's been doing some 1.9 work recently. I wouldn't say it's ready just yet. From ef_dva@yahoo.com Tue Sep 15 17:24:58 2009 From: ef_dva@yahoo.com (Dusan) Date: Tue, 15 Sep 2009 23:24:58 +0200 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock? In-Reply-To: <20090915175339.GA15735@gmail.com> References: <1253030868-sup-8556@mithink> <20090915175339.GA15735@gmail.com> Message-ID: <1253049733-sup-276@archpc> Excerpts from Sean Escriva's message of Tue Sep 15 19:53:39 +0200 2009: > Excerpts from Michael Hamann's message of Tue Sep 15 06:20:59 +0200 2009: > > Hi, > > > > as Arch Linux has decided to put Ruby 1.9.1 into the extra repository I've got > > Ruby 1.8 replaced by 1.9.1 today. I then tried reinstalling all dependencies of > > sup again with Ruby 1.9.1. I've also found a Ferret gem for Ruby 1.9.1 at > > http://pennysmalls.com/2009/03/24/ferret-on-ruby-191/. > > I followed a similar path after the recent upgrade to no avail. In the > end I downgraded ruby back to 1.8.7_p160 from older arch packages > available here: > > http://www.schlunix.org/archlinux/extra/os/x86_64/ > > I'd like a better solution, but I've become dependent on sup for daily > work. > > > [..snip..] This is pretty big question for arch users, including me. I can block ruby upgrade but it's few month before other distros start using 1.9 From dato@net.com.org.es Tue Sep 15 18:21:19 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Tue, 15 Sep 2009 23:21:19 +0100 Subject: [sup-talk] Fixing header for encrypted messages (might be an old issue) In-Reply-To: <1253045775-sup-210@thinkpad-ubuntu> References: <1253045775-sup-210@thinkpad-ubuntu> Message-ID: <20090915222119.GA5290@chistera.yi.org> + Christopher Bertels (Tue, 15 Sep 2009 22:21:59 +0200): > Hi! Hello! > I've been having problems with encrypting messages. No idea where this > came from, but somehow the protocol part in encrypted messages had an > extra pair of quotes, e.g.: protocol=""application/pgp-encrypted"" > which caused it to not be recognized by some clients (e.g. mutt as far as I know). > Here's a simple fix. I have no idea, why this suddenly came up. Might > be that it had been like this all the time, just no one had a problem > with it? (I highly doubt that though!) It's been like that all the time, but AFAIK only Mutt has problem opening those messages. FWIW, it's a bug in RMail (another one to add to the pile...): http://rubyforge.org/tracker/index.php?func=detail&aid=2170&group_id=446&atid=1754 http://rubyforge.org/tracker/index.php?func=detail&aid=2661&group_id=446&atid=1756 I advice against using your patch, since it depends on broken behavior of RMail to produce correct results, and people may be using fixed versions of the library. For example, I uploaded fixed packages of RMail to Debian, and they'll become available in Ubuntu at some point. Instead, you can find a patch to fix the issue in your system's RMail in one bugs linked above. > If this is an old issue and I'm just using an old version, feel free > to ignore this. I've tried using the current master or next branch, > but that causes a crash when trying to open encrypted emails. Maybe > someone else is having a similar problem? No, I've recently started experiencing this as well, asuming you're talking about: --- NoMethodError from thread: load messages for thread-view-mode undefined method `expandable?' for # /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text' /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each' /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text' /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each' /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff' [...] Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai From bgamari.foss@gmail.com Wed Sep 16 13:23:40 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Wed, 16 Sep 2009 13:23:40 -0400 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1252773189-sup-246@masanjin.net> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> Message-ID: <20090916172340.GA20566@ben-laptop> On Sat, Sep 12, 2009 at 09:35:21AM -0700, William Morgan wrote: > Reformatted excerpts from Ben Gamari's message of 2009-09-11: > > Recently I've been seeing this crash[1] pretty consistently on the next > > branch with the Xapian backend. > > Is your Xapian index somewhat old? There have been index format changes > that have caused this type of thing recently. You might try rebuilding > it. Well, after several attempts at rebuilding my index, I finally got lucky and sup-sync ran to completion. Unfortunately, sup now fails to even start, failing out with the following exception while loading threads for inbox-mode, $ sup --- SystemExit from thread: main Thread#join: deadlock 0x7f592eec4d78 - mutual join(0x7f592f01d6e8) /opt/exp/sup/lib/sup/message.rb:240:in `select' /opt/exp/sup/lib/sup/buffer.rb:35:in `nonblocking_getch' /usr/bin/sup:213 However, at this point during debugging I happened to pipe stderr to a file and accidentally found that most of the backtrace was actually being hidden by curses. Examining the full output on stderr reveals, /usr/bin/sup:213(eval):3:in `synchronize': Thread#join: deadlock 0x7f4d5da565c0 - mutual join(0x7f4d5daf8be0) (ThreadError) from (eval):3:in `raw_header' from /opt/exp/sup/lib/sup/imap.rb:98:in `load_header' from /opt/exp/sup/lib/sup/util.rb:560:in `send' from /opt/exp/sup/lib/sup/util.rb:560:in `__pass' from /opt/exp/sup/lib/sup/util.rb:547:in `method_missing' from /opt/exp/sup/lib/sup/message.rb:238:in `load_from_source!' from /opt/exp/sup/lib/sup/message.rb:219:in `chunks' from /opt/exp/sup/lib/sup/message.rb:164:in `snippet' from /opt/exp/sup/lib/sup/thread.rb:91:in `snippet' from /opt/exp/sup/lib/sup/imap.rb:259:in `select' from /opt/exp/sup/lib/sup/thread.rb:68:in `each' from /opt/exp/sup/lib/sup/thread.rb:168:in `each_with_stuff' from /opt/exp/sup/lib/sup/thread.rb:67:in `each' from /opt/exp/sup/lib/sup/thread.rb:91:in `select' from /opt/exp/sup/lib/sup/thread.rb:91:in `snippet' from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:840:in `text_for_thread_at' from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:758:in `regen_text' from /opt/exp/sup/lib/sup/util.rb:364:in `map_with_index' from /opt/exp/sup/lib/sup/imap.rb:259:in `each_with_index' from /opt/exp/sup/lib/sup/util.rb:364:in `each' from /opt/exp/sup/lib/sup/util.rb:364:in `each_with_index' from /opt/exp/sup/lib/sup/util.rb:364:in `map_with_index' from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:758:in `regen_text' from /opt/exp/sup/lib/sup/modes/thread-index-mode.rb:687:in `resize' from /opt/exp/sup/lib/sup/buffer.rb:88:in `resize' from /opt/exp/sup/lib/sup/buffer.rb:329:in `draw_screen' from /opt/exp/sup/lib/sup/buffer.rb:745:in `clear' from /opt/exp/sup/lib/sup/util.rb:520:in `send' from /opt/exp/sup/lib/sup/util.rb:520:in `method_missing' from /opt/exp/sup/lib/sup/imap.rb:283:in `shutup' from /opt/exp/sup/lib/sup/imap.rb:270:in `unsafe_connect' from /opt/exp/sup/lib/sup/imap.rb:244:in `initialize' from /opt/exp/sup/lib/sup/imap.rb:244:in `new' from /opt/exp/sup/lib/sup/imap.rb:244:in `unsafe_connect' from /opt/exp/sup/lib/sup/imap.rb:331:in `safely' from /opt/exp/sup/lib/sup/imap.rb:148:in `unsynchronized_connect' from (eval):3:in `connect' from (eval):3:in `synchronize' from (eval):3:in `connect' from /opt/exp/sup/lib/sup/util.rb:560:in `send' from /opt/exp/sup/lib/sup/util.rb:560:in `__pass' from /opt/exp/sup/lib/sup/util.rb:547:in `method_missing' from /usr/bin/sup:189 from /opt/exp/sup/lib/sup.rb:77:in `reporting_thread' from /opt/exp/sup/lib/sup.rb:75:in `initialize' from /opt/exp/sup/lib/sup.rb:75:in `new' from /opt/exp/sup/lib/sup.rb:75:in `reporting_thread' from /usr/bin/sup:187 from /usr/bin/sup:185:in `each' from /usr/bin/sup:185 [Wed Sep 16 13:01:11 -0400 2009] ERROR: oh crap, an exception ---------------------------------------------------------------- I'm very sorry. It seems that an error occurred in Sup. Please accept my sincere apologies. If you don't mind, please send the contents of ~/.sup/exception-log.txt and a brief report of the circumstances to sup-talk at rubyforge dot orgs so that I might address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- with the first stacktrace following this on stdout. With this information it looks like this bug should become much more debuggable. Being in the imap module, it seems likely that it is my gmail source that is causing the failure. Unfortunately I have no way to verify that the problem is limited to the gmail source as sup raises as exception when it encounters an unknown source, precluding the option of simply commenting out the source in sources.yaml. Anyways, this is the current status of things on my machine. William, do you have any ideas what might cause such a backtrace. At this point classes have started and I really have no more time to devote to getting sup working. If there isn't a fairly simple solution here I guess I'll just need to stick with mutt (ugh). Anyways, thanks for your work. Cheers, - Ben From mailinglist@flasht.de Tue Sep 15 18:42:04 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Wed, 16 Sep 2009 00:42:04 +0200 Subject: [sup-talk] Fixing header for encrypted messages (might be an old issue) In-Reply-To: <20090915222119.GA5290@chistera.yi.org> References: <1253045775-sup-210@thinkpad-ubuntu> <20090915222119.GA5290@chistera.yi.org> Message-ID: <1253054438-sup-8449@thinkpad-ubuntu> Excerpts from Adeodato Sim?'s message of Mi Sep 16 00:21:19 +0200 2009: > It's been like that all the time, but AFAIK only Mutt has problem > opening those messages. FWIW, it's a bug in RMail (another one to add to > the pile...): Alright, good to know. > I advice against using your patch, since it depends on broken behavior > of RMail to produce correct results, and people may be using fixed > versions of the library. For example, I uploaded fixed packages of RMail > to Debian, and they'll become available in Ubuntu at some point. > > Instead, you can find a patch to fix the issue in your system's RMail in > one bugs linked above. Alright, thanks. I'll just leave it for me like this until I've got a new version of RMail then. > > If this is an old issue and I'm just using an old version, feel free > > to ignore this. I've tried using the current master or next branch, > > but that causes a crash when trying to open encrypted emails. Maybe > > someone else is having a similar problem? > > No, I've recently started experiencing this as well, asuming you're > talking about: > > --- NoMethodError from thread: load messages for thread-view-mode > undefined method `expandable?' for # > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text' > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each' > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text' > /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each' > /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff' > [...] Yes, it's the same error I get. Any insights as to what is causing this? Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From cworth@cworth.org Thu Sep 17 16:05:45 2009 From: cworth@cworth.org (Carl Worth) Date: Thu, 17 Sep 2009 13:05:45 -0700 Subject: [sup-talk] [PATCH] Fix message_to_chunks for the m.body == nil case. Message-ID: <1253217341-sup-8631@yoom.home.cworth.org> The code was previously broken in calling EnclosedMessage.new with only 2 instead of 5 arguments. --- A friend of mine couldn't import his mail into sup due to the crash fixed by this patch. It looks like the message he had that was causing this infrequently-used (and obviously broken) code to be executed had some mime pieces corrupted. The message consisted of several mime-attached messages looking like: --==_Exmh_5062123120 Content-Type: message/rfc822 ; name="5714" Content-Description: 5714 Content-Disposition: attachment; filename="5714" Return-path: ... but one part was missing the mime searpate and Content-Type and instead just looked like: Content-Description: 5692 Content-Disposition: attachment; filename="5692" Return-path: ... I tried fixing this first by adding several more empty-string arguments, that is: [Chunk::EnclosedMessage.new(nil, "", "", "", "")] but that ended up causing this exception instead: ./lib/sup/message-chunks.rb:212:in `initialize': undefined method `full_adress' for nil:NilClass (NoMethodError) So I'm not 100% sure that this patch is correct, but it does allow sup-sync to proceed and the message appears in sup as well as could be expected, (the "extra" headers from the corrupted mime part appear in the body as one might expect here). -Carl lib/sup/message.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/message.rb b/lib/sup/message.rb index afa8f00..579c1e5 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -453,7 +453,7 @@ private cc_people = cc ? Person.from_address_list(cc) : nil [Chunk::EnclosedMessage.new(from_person, to_people, cc_people, msgdate, subj)] + message_to_chunks(payload, encrypted) else - [Chunk::EnclosedMessage.new(nil, "")] + [] end else filename = -- 1.6.4.3 From web-sup@superscript.com Fri Sep 18 15:50:13 2009 From: web-sup@superscript.com (William Erik Baxter) Date: Fri, 18 Sep 2009 15:50:13 -0400 Subject: [sup-talk] Hello, and before-add-message hook for applying labels per CDB Message-ID: <1253303164-sup-1138@kronos> Hello fellow sup users. I began using sup last week, spent some time setting it up in parallel with mutt, and have not used mutt since, except through accident of habit. Thanks to all developers for your excellent work. A before-add-message hook follows. It applies labels per entries in a CDB constructed externally. I hope you find it useful. Cheers, W. #### Automatically add labels. require 'cdb'; @cdb ||= CDB.new("/home/web/Mail/suplabel.cdb"); # Mark by a recipient (to/cc) # Construct [ [ prefix, string ] ... ]. # Look up "prefix:string" in CDB to obtain a list of labels to apply. a = [] a += [ [ "from", message.from.email ] ] a += message.recipients.map{ |x| [ "recipient", x.email ] } a.each { |pair| key = pair[0] + ":" + pair[1]; @cdb.each(key) { |value| value.split.each { |label| message.add_label(label) } } } From web-sup@superscript.com Fri Sep 18 15:54:18 2009 From: web-sup@superscript.com (William Erik Baxter) Date: Fri, 18 Sep 2009 15:54:18 -0400 Subject: [sup-talk] [PATCH] Add hooks to sort and format label-list-mode display. Message-ID: <1253303493-sup-288@kronos> --- lib/sup/modes/label-list-mode.rb | 37 ++++++++++++++++++++++++++++++++++--- 1 files changed, 34 insertions(+), 3 deletions(-) diff --git a/lib/sup/modes/label-list-mode.rb b/lib/sup/modes/label-list-mode.rb index f65ec2e..d94f56f 100644 --- a/lib/sup/modes/label-list-mode.rb +++ b/lib/sup/modes/label-list-mode.rb @@ -8,6 +8,24 @@ class LabelListMode < LineCursorMode k.add :toggle_show_unread_only, "Toggle between showing all labels and those with unread mail", 'u' end + HookManager.register "label-list-filter", < label unread = (label == :unread)? total : Index.num_results_for(:labels => [label, :unread]) [label, string, total, unread] - end.sort_by { |l, s, t, u| s.downcase } + end + + if HookManager.enabled? "label-list-filter" + counts = HookManager.run "label-list-filter", :counted => counted + else + counts = counted.sort_by { |l, s, t, u| s.downcase } + end width = counts.max_of { |l, s, t, u| s.length } + tmax = counts.max_of { |l, s, t, u| t } + umax = counts.max_of { |l, s, t, u| u } if @unread_only counts.delete_if { | l, s, t, u | u == 0 } @@ -78,8 +104,13 @@ protected next end + fmt = HookManager.run "label-list-format", :width => width, :tmax => tmax, :umax => umax + if !fmt + fmt = "%#{width + 1}s %5d %s, %5d unread" + end + @text << [[(unread == 0 ? :labellist_old_color : :labellist_new_color), - sprintf("%#{width + 1}s %5d %s, %5d unread", string, total, total == 1 ? " message" : "messages", unread)]] + sprintf(fmt, string, total, total == 1 ? " message" : "messages", unread)]] @labels << [label, unread] yield i if block_given? end.compact -- 1.5.3.2 From richard@infoarts.info Fri Sep 18 18:15:03 2009 From: richard@infoarts.info (Richard Sandilands) Date: Sat, 19 Sep 2009 08:15:03 +1000 Subject: [sup-talk] Trouble implementing UTF-8 ncurses fix Message-ID: <1253311953-sup-3472@Richard-Sandilandss-MacBook-Pro.local> Hi there I'm trying to implement the fix found here: but am running into trouble when I run 'run-this-for-sup.sh'. I've installed the ncurses-5.7 library on my Mac 10.6 machine, but the shell script above gives this output to mkmf.log: Any clues on what I might be missing would be appreciated. -- Richard Sandilands From michael+sup@stapelberg.de Sun Sep 20 15:46:24 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sun, 20 Sep 2009 21:46:24 +0200 Subject: [sup-talk] Bug: Converting the index to xapian fails with a message with very old date Message-ID: <1253475875-sup-5119@midna.zekjur.net> Hi, I have a spam mail in one of my sources. This mail has the following Date-line: Date: Mon, 1 Jan 1601 00:48:33 +0500 This makes sup/xapian/ruby (one of them) go crazy and abort with an exception: ## read 5856m (about 72%) @ 10.0m/s. 0:09:47 elapsed, about 0:03:44 remaining /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `_dump': year too big to marshal (ArgumentError) from /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `dump' from /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `index_message' from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message' from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/1.8/sup/xapian_index.rb:398:in `synchronize' from /usr/lib/ruby/1.8/sup/xapian_index.rb:123:in `sync_message' from /usr/lib/ruby/1.8/sup/xapian_index.rb:94:in `add_message' from /home/michael/software/sup-mainline/bin/sup-sync:211 from /usr/lib/ruby/1.8/sup/poll.rb:151:in `each_message_from' from /usr/lib/ruby/1.8/sup/imap.rb:197:in `each' from /usr/lib/ruby/1.8/sup/imap.rb:185:in `upto' from /usr/lib/ruby/1.8/sup/imap.rb:185:in `each' from /usr/lib/ruby/1.8/sup/util.rb:560:in `send' from /usr/lib/ruby/1.8/sup/util.rb:560:in `__pass' from /usr/lib/ruby/1.8/sup/util.rb:547:in `method_missing' from /usr/lib/ruby/1.8/sup/poll.rb:139:in `each_message_from' from /usr/lib/ruby/1.8/sup/util.rb:520:in `send' from /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' from /home/michael/software/sup-mainline/bin/sup-sync:146 from /home/michael/software/sup-mainline/bin/sup-sync:141:in `each' from /home/michael/software/sup-mainline/bin/sup-sync:141 I used revision 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf of sup. Best regards, Michael From michael+sup@stapelberg.de Sun Sep 20 15:51:38 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sun, 20 Sep 2009 21:51:38 +0200 Subject: [sup-talk] Bug: Opening PGP encrypted mails fails with latest revision Message-ID: <1253476236-sup-9371@midna.zekjur.net> Hi, when opening PGP encrypted mails (MIME), sup crashes with the following exception: --- NoMethodError from thread: load messages for thread-view-mode undefined method `expandable?' for nil:NilClass /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:621:in `regen_text' /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:616:in `each' /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:616:in `regen_text' /usr/lib/ruby/1.8/sup/thread.rb:68:in `each' /usr/lib/ruby/1.8/sup/thread.rb:168:in `each_with_stuff' /usr/lib/ruby/1.8/sup/thread.rb:67:in `each' /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:585:in `regen_text' /usr/lib/ruby/1.8/sup/modes/thread-view-mode.rb:135:in `initialize' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:112:in `new' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:112:in `select' /usr/lib/ruby/1.8/sup.rb:77:in `reporting_thread' /usr/lib/ruby/1.8/sup.rb:75:in `initialize' /usr/lib/ruby/1.8/sup.rb:75:in `new' /usr/lib/ruby/1.8/sup.rb:75:in `reporting_thread' /usr/lib/ruby/1.8/sup/modes/thread-index-mode.rb:102:in `select' /usr/lib/ruby/1.8/sup/mode.rb:50:in `send' /usr/lib/ruby/1.8/sup/mode.rb:50:in `handle_input' /usr/lib/ruby/1.8/sup/buffer.rb:265:in `handle_input' bin/sup:236 Best regards, Michael From alip@exherbo.org Sun Sep 20 17:16:34 2009 From: alip@exherbo.org (Ali Polatel) Date: Mon, 21 Sep 2009 00:16:34 +0300 Subject: [sup-talk] Problem with lbdb and extra contacts hook Message-ID: <1253481392-sup-4891@harikalardiyari> Hello, I've just started using sup and I'm really loving it. Thanks for the great software. I have a problem with extra-contact-addresses hook and lbdb. Using the hook in the wiki: contacts = [] `lbdbq |awk -F"\t" '{print $2 , "<"$1">"}'`.each { |c| contacts.push(c) } return contacts I get error running hook and here's the message that appears in the log: [Sun Sep 20 23:50:17 +0300 2009] hook: error running hook: unexpected return [Sun Sep 20 23:50:17 +0300 2009] hook: /home/alip/.sup/hooks/extra-contact-addresses.rb:7:in `__run' /home/alip/src/sup/lib/sup/hook.rb:42:in `__run' /home/alip/src/sup/lib/sup/hook.rb:82:in `run' /home/alip/src/sup/lib/sup/util.rb:520:in `send' /home/alip/src/sup/lib/sup/util.rb:520:in `method_missing' /home/alip/src/sup/lib/sup/buffer.rb:540:in `ask_for_contacts' /home/alip/src/sup/lib/sup/util.rb:520:in `send' /home/alip/src/sup/lib/sup/util.rb:520:in `method_missing' /home/alip/src/sup/lib/sup/modes/compose-mode.rb:24:in `spawn_nicely' /home/alip/src/sup/bin/sup:282 This is with current master 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf -- Regards, Ali Polatel From alip@exherbo.org Sun Sep 20 19:11:04 2009 From: alip@exherbo.org (Ali Polatel) Date: Mon, 21 Sep 2009 02:11:04 +0300 Subject: [sup-talk] Problem with lbdb and extra contacts hook In-Reply-To: <1253481392-sup-4891@harikalardiyari> References: <1253481392-sup-4891@harikalardiyari> Message-ID: <1253488117-sup-4560@harikalardiyari> Ali Polatel yazm??: > Hello, > I've just started using sup and I'm really loving it. > Thanks for the great software. > > I have a problem with extra-contact-addresses hook and lbdb. > Using the hook in the wiki: > contacts = [] > `lbdbq |awk -F"\t" '{print $2 , "<"$1">"}'`.each { |c| contacts.push(c) } > return contacts Answering myself, removing return from the last line works as expected! I'll see if I can edit the wiki. -- Regards, Ali Polatel From michael+sup@stapelberg.de Tue Sep 22 13:05:48 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Tue, 22 Sep 2009 19:05:48 +0200 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted Message-ID: <1253638189-sup-7758@midna.zekjur.net> Hi, I noticed that emails sent by Thunderbird which contain inline GPG messages are not decrypted at all. I?ve attached such a message so you can verify it. Unfortunately my ruby skills did not suffice to fix this on my own. Thanks and best regards, Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: crypted.txt URL: From michael+sup@stapelberg.de Tue Sep 22 13:24:24 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Tue, 22 Sep 2009 19:24:24 +0200 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted In-Reply-To: <1253638189-sup-7758@midna.zekjur.net> References: <1253638189-sup-7758@midna.zekjur.net> Message-ID: <1253640093-sup-48@midna.zekjur.net> Hi, Excerpts from Michael Stapelberg's message of Di Sep 22 19:05:48 +0200 2009: > I noticed that emails sent by Thunderbird which contain inline GPG messages > are not decrypted at all. I?ve attached such a message so you can verify > it. Unfortunately my ruby skills did not suffice to fix this on my own. Addition: Probably I was able to fix it, but the other bug I reported about not being able to open GPG encrypted email at all was the one I was seeing. So, fix should be easy (untested, because of the other bug): --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -436,6 +436,16 @@ private end chunks + elsif m.header.content_type == "application/pgp" + notice, sig, decryptedm = CryptoManager.decrypt m.body + if decryptedm # managed to decrypt + children = message_to_chunks(decryptedm, true) + chunks = [notice, sig, children] + else + chunks = [notice] + end + + chunks elsif m.header.content_type == "message/rfc822" if m.body payload = RMail::Parser.read(m.body) Best regards, Michael From david.pflug@hostdime.com Tue Sep 22 14:01:50 2009 From: david.pflug@hostdime.com (David Pflug) Date: Tue, 22 Sep 2009 14:01:50 -0400 Subject: [sup-talk] Exception while marking mail as read Message-ID: <1253642183-sup-1331@dpflug-desktop> Hi there, I'm using :next, having used the fix from :ncursesw. I've got some unread threads that are 300+ messages long (threaded by subject) from automated processes. I did a search for is:unread and started marking them read, and saved my changes (or, at least, pressed $ while sup was chugging through the last thread). It's possible a poll started at the same time, but I can't be sure. Here's exception.log: --- Ferret::StateError from thread: load threads for thread-index-mode State Error occured at :93 in xraise Error occured in index.c:4150 - sr_get_lazy_doc Document 9233 has already been deleted /usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]' /usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:413:in `[]' ./lib/sup/ferret_index.rb:163:in `each_id_by_date' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' ./lib/sup/ferret_index.rb:163:in `each_id_by_date' ./lib/sup/ferret_index.rb:162:in `each' ./lib/sup/ferret_index.rb:162:in `each_id_by_date' ./lib/sup/thread.rb:328:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:625:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' ./lib/sup.rb:77:in `reporting_thread' ./lib/sup.rb:75:in `initialize' ./lib/sup.rb:75:in `new' ./lib/sup.rb:75:in `reporting_thread' ./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' ./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' ./lib/sup/modes/thread-index-mode.rb:81:in `initialize' ./lib/sup/modes/line-cursor-mode.rb:22:in `call' ./lib/sup/modes/line-cursor-mode.rb:22:in `initialize' ./lib/sup/modes/line-cursor-mode.rb:22:in `each' ./lib/sup/modes/line-cursor-mode.rb:22:in `initialize' ./lib/sup/modes/line-cursor-mode.rb:19:in `new' ./lib/sup/modes/line-cursor-mode.rb:19:in `initialize' ./lib/sup/modes/thread-index-mode.rb:54:in `initialize' ./lib/sup/modes/search-results-mode.rb:6:in `initialize' ./lib/sup/modes/search-results-mode.rb:30:in `new' ./lib/sup/modes/search-results-mode.rb:30:in `spawn_from_query' bin/sup:270 Regards, David -- David Pflug System Technician Hostdime.com, Inc. From michael+sup@stapelberg.de Fri Sep 25 15:08:52 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Fri, 25 Sep 2009 21:08:52 +0200 Subject: [sup-talk] Bug: Opening PGP encrypted mails fails with latest revision In-Reply-To: <1253476236-sup-9371@midna.zekjur.net> References: <1253476236-sup-9371@midna.zekjur.net> Message-ID: <1253905662-sup-1750@midna.zekjur.net> Hi, Excerpts from Michael Stapelberg's message of So Sep 20 21:51:38 +0200 2009: > when opening PGP encrypted mails (MIME), sup crashes with the following > exception: Further debugging revealed that this has been introduced in revision 927b7df4b2052a6b3c2ae1f2b44a6bc901315f8d and can be fixed with the following patch: --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -413,7 +413,7 @@ private notice, sig, decryptedm = CryptoManager.decrypt payload if decryptedm # managed to decrypt children = message_to_chunks(decryptedm, true) - [notice, sig, children] + [notice, sig, children].flatten.compact else [notice] end Best regards, Michael From michael+sup@stapelberg.de Fri Sep 25 15:10:11 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Fri, 25 Sep 2009 21:10:11 +0200 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted In-Reply-To: <1253640093-sup-48@midna.zekjur.net> References: <1253638189-sup-7758@midna.zekjur.net> <1253640093-sup-48@midna.zekjur.net> Message-ID: <1253905743-sup-419@midna.zekjur.net> Hi, after fixing the other bug related to GPG messages, this patch has to be modified, too: --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -436,6 +436,16 @@ private end chunks + elsif m.header.content_type == "application/pgp" + notice, sig, decryptedm = CryptoManager.decrypt m.body + if decryptedm # managed to decrypt + children = message_to_chunks(decryptedm, true) + chunks = [notice, sig, children].flatten.compact + else + chunks = [notice] + end + + chunks elsif m.header.content_type == "message/rfc822" if m.body payload = RMail::Parser.read(m.body) Best regards, Michael From michael+sup@stapelberg.de Fri Sep 25 15:13:29 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Fri, 25 Sep 2009 21:13:29 +0200 Subject: [sup-talk] Bug: Killed threads coming up again Message-ID: <1253905917-sup-5964@midna.zekjur.net> Hi, I noticed that killed messages sometimes appear in my inbox again. This might be caused by a new label coming up by a new message for this thread, which arrived through a different source (in my case, a message was marked as spam, thus arrived in a new IMAP folder and thus a new source in sup and therefore came up with the label spam). Did anyone of you notice the same? Can you reproduce this? Best regards, Michael From cworth@cworth.org Fri Sep 25 16:46:31 2009 From: cworth@cworth.org (Carl Worth) Date: Fri, 25 Sep 2009 13:46:31 -0700 Subject: [sup-talk] [PATCH] Fix uninitialized @name member in person.rb. Message-ID: <1253911543-sup-7680@yoom.home.cworth.org> Apparently a Person can be initialized with a nil name, (presumably from a message where there's no name given), which before this commit resulted in the following warning: ./lib/sup/person.rb:46: warning: instance variable @name not initialized This warning was especially unpleasant since it appeared in the current window, causing the terminal contents to incorrectly scroll up, (as opposed to just appearing in the log or so). --- lib/sup/person.rb | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/lib/sup/person.rb b/lib/sup/person.rb index c4f40a5..cd5b1ea 100644 --- a/lib/sup/person.rb +++ b/lib/sup/person.rb @@ -11,6 +11,8 @@ class Person if @name =~ /^(['"]\s*)(.*?)(\s*["'])$/ @name = $2 end + else + @name = nil end @email = email.gsub(/^\s+|\s+$/, "").gsub(/\s+/, " ").downcase -- 1.6.4.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From cworth@cworth.org Fri Sep 25 17:08:23 2009 From: cworth@cworth.org (Carl Worth) Date: Fri, 25 Sep 2009 14:08:23 -0700 Subject: [sup-talk] [PATCH] Allow thread index view to sort oldest first Message-ID: <1253911610-sup-2052@yoom.home.cworth.org> Keith and I both want to read our email in chronological order, (reading oldest messages first), so we believe it makes sense to present the inbox mode in this order, (with the oldest messages at the top). This is distinct from the order for global searches where having the newest messages first does seem obviously correct. The below patches are a first cut at implementing this. They provide a new configuration option, (:inbox_newest_first), which can be used to control the default sorting for the inbox. Keith's original patch doesn't change sup's behavior unless the user manually configures this option to false. My second patch changes the default. Obviously, it would be easy to accept Keith's version without changing the default for sup. One nice thing about the inmplentation is that any refined searches inherit the mode of the parent search, which makes it easy to maintain oldest-message-first for "reading" and newest-message-first for "searching". Also note that there's a new command 'o' to toggle the search order for a current view. This is a feature that we talked about earlier as a way to avoid the need for the distinction between the ',' and ']' commands in thread-view-mode. If the user can control the sort of the search view, then it would be more natural to have commands that simply advance to the "next" message, (since the user can choose in advance what "next" means). A couple of caveats with respect to the patch as it exists so far: 1. When doing oldest-first searching, it wasn't obvious if it's even possible to query for only the N oldest messages (to lazily load new threads while navigating as sup currently does). So the patch currently loads all threads when in oldest-first mode. In my use so far this has worked well since I generally have a small number of messages in my inbox (and even fewer in my refined views of my inbox) and those are the only places where I use oldest-first sorting. For global searches, I do have an effectively infinite number of messages, but there I do use newest-first searching which still has the lazy loading. 2. Currently sup uses the date of the newest message in a thread as the key for sorting that message. This is correct for newest-first sorting. But when doing the new oldest-first sorting, the patch really should be augmented to instead use the date of the oldest message in a thread that matches the current search criteria. We haven't looked yet into how hard this would be to fix. (And we'd of course be glad for any help or pointers.) -Carl PS. We're still total ruby newbies, so please point out any silly mistakes we're missing with respect to ruby idioms. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Allow-thread-index-view-to-sort-oldest-first.patch Type: application/octet-stream Size: 7849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Change-the-default-sort-for-inbox-mode-to-be-oldest-.patch Type: application/octet-stream Size: 777 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Sat Sep 26 09:48:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 06:48:04 -0700 Subject: [sup-talk] Problem with lbdb and extra contacts hook In-Reply-To: <1253488117-sup-4560@harikalardiyari> References: <1253481392-sup-4891@harikalardiyari> <1253488117-sup-4560@harikalardiyari> Message-ID: <1253972856-sup-3123@masanjin.net> Reformatted excerpts from Ali Polatel's message of 2009-09-20: > Answering myself, removing return from the last line works as > expected! I'll see if I can edit the wiki. Yep, that was the problem. Hooks shouldn't call return. Nice work. :) -- William From wmorgan-sup@masanjin.net Sat Sep 26 09:50:29 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 06:50:29 -0700 Subject: [sup-talk] Trouble implementing UTF-8 ncurses fix In-Reply-To: <1253311953-sup-3472@Richard-Sandilandss-MacBook-Pro.local> References: <1253311953-sup-3472@Richard-Sandilandss-MacBook-Pro.local> Message-ID: <1253972920-sup-9313@masanjin.net> Reformatted excerpts from Richard Sandilands's message of 2009-09-18: > but am running into trouble when I run 'run-this-for-sup.sh'. I've > installed the ncurses-5.7 library on my Mac 10.6 machine, but the shell > script above gives this output to mkmf.log: I'm not sure of how to do it on your particular system, but you need to install libncursesw (note the "w"). Maybe someone else who runs Sup on a mac can help. -- William From wmorgan-sup@masanjin.net Sat Sep 26 09:56:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 06:56:04 -0700 Subject: [sup-talk] Bug: Converting the index to xapian fails with a message with very old date In-Reply-To: <1253475875-sup-5119@midna.zekjur.net> References: <1253475875-sup-5119@midna.zekjur.net> Message-ID: <1253973258-sup-3347@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-20: > This makes sup/xapian/ruby (one of them) go crazy and abort with an exception: > ## read 5856m (about 72%) @ 10.0m/s. 0:09:47 elapsed, about 0:03:44 remaining > /usr/lib/ruby/1.8/sup/xapian_index.rb:532:in `_dump': year too big to marshal > (ArgumentError) Interesting. The Xapian index has had some trouble with crazy dates in the past, but that should be fixed. Can you apply the following debug patch and send the output for that message? Thanks! diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index ab25ea0..b94c8b0 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -509,6 +509,9 @@ EOS Xapian.sortable_serialise 0 end + puts "> truncated date is #{truncated_date.inspect}" + puts "> date_value is #{date_value.inspect}" + docid = nil unless doc = find_doc(m.id) doc = Xapian::Document.new -- William From wmorgan-sup@masanjin.net Sat Sep 26 09:58:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 06:58:59 -0700 Subject: [sup-talk] Hello, and before-add-message hook for applying labels per CDB In-Reply-To: <1253303164-sup-1138@kronos> References: <1253303164-sup-1138@kronos> Message-ID: <1253973470-sup-620@masanjin.net> Reformatted excerpts from William Erik Baxter's message of 2009-09-18: > Hello fellow sup users. I began using sup last week, spent some time setting > it up in parallel with mutt, and have not used mutt since, except through > accident of habit. Thanks to all developers for your excellent work. Great! Welcome! > A before-add-message hook follows. It applies labels per entries in a CDB > constructed externally. I hope you find it useful. Thanks! If you get a chance, please add it to the wiki: http://sup.rubyforge.org/wiki/wiki.pl?Hooks -- William From wmorgan-sup@masanjin.net Sat Sep 26 10:31:56 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 07:31:56 -0700 Subject: [sup-talk] Crash while scrolling In-Reply-To: <20090916172340.GA20566@ben-laptop> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> Message-ID: <1253975267-sup-8308@masanjin.net> Sorry it's taken me so long to get back to this. Reformatted excerpts from Ben Gamari's message of 2009-09-16: > Thread#join: deadlock 0x7f592eec4d78 - mutual join(0x7f592f01d6e8) > /opt/exp/sup/lib/sup/message.rb:240:in `select' > /opt/exp/sup/lib/sup/buffer.rb:35:in `nonblocking_getch' > /usr/bin/sup:213 > > However, at this point during debugging I happened to pipe stderr to a > file and accidentally found that most of the backtrace was actually > being hidden by curses. Examining the full output on stderr reveals, > > /usr/bin/sup:213(eval):3:in `synchronize': Thread#join: deadlock > 0x7f4d5da565c0 - mutual join(0x7f4d5daf8be0) (ThreadError) > from (eval):3:in `raw_header' > from /opt/exp/sup/lib/sup/imap.rb:98:in `load_header' I definitely am not sure why there's a deadlock happening, but I am guessing, based on the line numbers in that first exception, that it's being triggered by an underlying problem with the source. If you run sup with -n, does that change anything? (Or produce a better exception?) > Anyways, this is the current status of things on my machine. William, do > you have any ideas what might cause such a backtrace. At this point > classes have started and I really have no more time to devote to > getting sup working. If there isn't a fairly simple solution here I guess > I'll just need to stick with mutt (ugh). Anyways, thanks for your work. Well, there's a workaround, which is to switch over to an offlineimap setup where your Gmail is mirrored locally and Sup reads the mirror (which is what you want anyways if you're serious about using Sup with an IMAP client). I don't know what's causing the deadlock, but I will try and reproduce it on my end. -- William From wmorgan-sup@masanjin.net Sat Sep 26 10:40:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 07:40:59 -0700 Subject: [sup-talk] Fixing header for encrypted messages (might be an old issue) In-Reply-To: <1253054438-sup-8449@thinkpad-ubuntu> References: <1253045775-sup-210@thinkpad-ubuntu> <20090915222119.GA5290@chistera.yi.org> <1253054438-sup-8449@thinkpad-ubuntu> Message-ID: <1253976007-sup-711@masanjin.net> Reformatted excerpts from Christopher Bertels's message of 2009-09-15: > Excerpts from Adeodato Sim?'s message of Mi Sep 16 00:21:19 +0200 2009: > > --- NoMethodError from thread: load messages for thread-view-mode > > undefined method `expandable?' for # > > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:615:in `regen_text' > > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `each' > > /home/dato/devel/sup/work/lib/sup/modes/thread-view-mode.rb:610:in `regen_text' > > /home/dato/devel/sup/work/lib/sup/thread.rb:68:in `each' > > /home/dato/devel/sup/work/lib/sup/thread.rb:170:in `each_with_stuff' > > [...] > > Yes, it's the same error I get. Any insights as to what is causing this? Just to confirm---both of you are seeing this error, with a recent git master, when opening encrypted messages? -- William From wmorgan-sup@masanjin.net Sat Sep 26 10:48:48 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 07:48:48 -0700 Subject: [sup-talk] Sup and Ruby 1.9.1 - deadlock? In-Reply-To: <1253043209-sup-8800@zyrg.net> References: <1253030868-sup-8556@mithink> <1253043209-sup-8800@zyrg.net> Message-ID: <1253976432-sup-3851@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-15: > I think William said he's been doing some 1.9 work recently. I wouldn't > say it's ready just yet. My current plan is to release an 0.9 tomorrow or so (probably without advertising the Xapian support), and to focus on Ruby 1.9 support for the next release. -- William From wmorgan-sup@masanjin.net Sat Sep 26 10:49:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 07:49:41 -0700 Subject: [sup-talk] Fixing header for encrypted messages (might be an old issue) In-Reply-To: <1253976007-sup-711@masanjin.net> References: <1253045775-sup-210@thinkpad-ubuntu> <20090915222119.GA5290@chistera.yi.org> <1253054438-sup-8449@thinkpad-ubuntu> <1253976007-sup-711@masanjin.net> Message-ID: <1253976576-sup-8002@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-09-26: > Just to confirm---both of you are seeing this error, with a recent git > master, when opening encrypted messages? Ah, looks like Michael Stapelberg's patch will fix this. -- William From wmorgan-sup@masanjin.net Sat Sep 26 10:56:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 07:56:14 -0700 Subject: [sup-talk] Hello and thanks In-Reply-To: <1252787425-sup-4073@longword> References: <1252787425-sup-4073@longword> Message-ID: <1253976950-sup-8220@masanjin.net> Hi Bo, Reformatted excerpts from Bo Borgerson's message of 2009-09-12: > A git-send-email out of the blue isn't necessarily the friendliest of > introductions, though, so I just wanted to write first and say thanks > to William and everyone who has contributed to sup. It's pretty > awesome. Thanks for the kind words, and welcome! -- William From wmorgan-sup@masanjin.net Sat Sep 26 13:45:49 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 10:45:49 -0700 Subject: [sup-talk] [PATCH] Fix uninitialized @name member in person.rb. In-Reply-To: <1253911543-sup-7680@yoom.home.cworth.org> References: <1253911543-sup-7680@yoom.home.cworth.org> Message-ID: <1253987121-sup-2390@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-09-25: > Apparently a Person can be initialized with a nil name, (presumably > from a message where there's no name given), which before this commit > resulted in the following warning: > > ./lib/sup/person.rb:46: warning: instance variable @name not initialized Thanks, I have fixed this in master. Let me know if it doesn't work! -- William From wmorgan-sup@masanjin.net Sat Sep 26 13:50:42 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 10:50:42 -0700 Subject: [sup-talk] Bug: Killed threads coming up again In-Reply-To: <1253905917-sup-5964@midna.zekjur.net> References: <1253905917-sup-5964@midna.zekjur.net> Message-ID: <1253987261-sup-6729@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-25: > I noticed that killed messages sometimes appear in my inbox again. Rats. I thought we had this problem licked. > Did anyone of you notice the same? Can you reproduce this? I haven't seen this recently. Are you using 0.8.1 or git? Does anyone else see this with git? -- William From michael+sup@stapelberg.de Sat Sep 26 14:03:53 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sat, 26 Sep 2009 20:03:53 +0200 Subject: [sup-talk] Bug: Killed threads coming up again In-Reply-To: <1253987261-sup-6729@masanjin.net> References: <1253905917-sup-5964@midna.zekjur.net> <1253987261-sup-6729@masanjin.net> Message-ID: <1253988170-sup-189@midna.zekjur.net> Hi, Excerpts from William Morgan's message of Sa Sep 26 19:50:42 +0200 2009: > Rats. I thought we had this problem licked. Unfortunately not. Also, this also happened with a thread which got no new labels today, so my guess in the last mail was not correct. > I haven't seen this recently. Are you using 0.8.1 or git? Does anyone > else see this with git? I am using git version 68bf6a277c5fdefb3b9d6a4b5d4dfbce3f9f9ccf. Best regards, Michael From wmorgan-sup@masanjin.net Sat Sep 26 14:09:36 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 11:09:36 -0700 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted In-Reply-To: <1253905743-sup-419@midna.zekjur.net> References: <1253638189-sup-7758@midna.zekjur.net> <1253640093-sup-48@midna.zekjur.net> <1253905743-sup-419@midna.zekjur.net> Message-ID: <1253988435-sup-8649@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-25: > after fixing the other bug related to GPG messages, this patch has to be > modified, too: I believe I've fixed this in git. Thunderbird is not producing RFC3156-compliant encrypted emails, but by the Postel's Law we will accomodate their errors. Let me know if it doesn't work. -- William From wmorgan-sup@masanjin.net Sat Sep 26 14:10:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 11:10:04 -0700 Subject: [sup-talk] Bug: Opening PGP encrypted mails fails with latest revision In-Reply-To: <1253905662-sup-1750@midna.zekjur.net> References: <1253476236-sup-9371@midna.zekjur.net> <1253905662-sup-1750@midna.zekjur.net> Message-ID: <1253988590-sup-9530@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-25: > Further debugging revealed that this has been introduced in revision > 927b7df4b2052a6b3c2ae1f2b44a6bc901315f8d and can be fixed with the > following patch: Thanks, this should be fixed in git. Give it a try. -- William From guillaume.quintard@gmail.com Sat Sep 26 14:09:56 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Sat, 26 Sep 2009 20:09:56 +0200 Subject: [sup-talk] Hook, again Message-ID: <1253988011-sup-8497@altis> Sorry to come back again with that issue, but I'm having trouble with the reply-from hook. Here's what I have: message.recipients.each { |person| if (person.email =~ /addr at site.com/) != nil Person.from_address "Foo " end } But it doesn't seem to work. If I reply to a mail addressed to addr at site.com, the log says nothing, but the from field isn't changed. If I reply to any other mail, le log complains I didn't return a Person And if I just put Person.from_address "Foo " in the hook, the from field is correctly changed. I'm a bit lost on that one (still not knowing alot of ruby doesn't help I must say). Am I missing the obvious here? Cheers. -- Guillaume From wmorgan-sup@masanjin.net Sat Sep 26 14:12:24 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 11:12:24 -0700 Subject: [sup-talk] [PATCH] Fix message_to_chunks for the m.body == nil case. In-Reply-To: <1253217341-sup-8631@yoom.home.cworth.org> References: <1253217341-sup-8631@yoom.home.cworth.org> Message-ID: <1253988663-sup-3838@masanjin.net> Reformatted excerpts from Carl Worth's message of 2009-09-17: > The code was previously broken in calling EnclosedMessage.new with > only 2 instead of 5 arguments. Thanks, this has been applied. > So I'm not 100% sure that this patch is correct, but it does allow > sup-sync to proceed and the message appears in sup as well as could be > expected, (the "extra" headers from the corrupted mime part appear in > the body as one might expect here). Yeah, I think that's the best we can hope for here. -- William From wmorgan-sup@masanjin.net Sat Sep 26 14:12:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 11:12:50 -0700 Subject: [sup-talk] [PATCH] mime-decode hook: provide a "charset" variable with the attachment charset In-Reply-To: <20090913231753.GA20849@chistera.yi.org> References: <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato@net.com.org.es> <20090723093543.GA2265@chistera.yi.org> <1248713434-sup-4961@entry> <20090730155656.GA20442@chistera.yi.org> <20090819212209.GA10883@chistera.yi.org> <1250964880-sup-7106@masanjin.net> <20090822191617.GA26897@chistera.yi.org> <1251048347-sup-5075@masanjin.net> <20090913231753.GA20849@chistera.yi.org> Message-ID: <1253988754-sup-7987@masanjin.net> Reformatted excerpts from Adeodato Sim?'s message of 2009-09-13: > Now that that fix is in, can you merge the mime-decode improvement from > <6fc2e5dd8aa2b0b8547375d77b1776d779f85817.1247238014.git.dato at net.com.org.es>? Applied directly to master. Sorry for the grand delay. -- William From wmorgan-sup@masanjin.net Sat Sep 26 14:17:14 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 11:17:14 -0700 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail stupidity? In-Reply-To: <1252781841-sup-6303@black-opal.mit.edu> References: <1252781841-sup-6303@black-opal.mit.edu> Message-ID: <1253988779-sup-2896@masanjin.net> Reformatted excerpts from Kevin Riggle's message of 2009-09-12: > I theorize that RubyMail is being case-sensitive where it shouldn't. Although I love criticizing RubyMail, I think this is Sup's fault. I don't think it's in RubyMail's proper purview to canonicalize header values (though header names are fine). Anyways, I think I've fixed this in git. Give it a try. > Given the number of work-arounds Sup has had to implement to > compensate for RubyMail's stupidity, and that RubyMail is currently > unmaintained, has any thought been given to switching Sup to eg. TMail > (http://tmail.rubyforge.org), which is maintained? It's certainly an option, but with so many workarounds invested in RubyMail, I'm not sure it's a win. A patch that magically makes everything work would certainly be considered. -- William From wmorgan-sup@masanjin.net Sat Sep 26 14:23:34 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 11:23:34 -0700 Subject: [sup-talk] sup 0.9 pre-release checkin Message-ID: <1253989249-sup-3372@masanjin.net> Hi all, I'm getting to release Sup 0.9. I have applied all outstanding bugfixes I've found, and have merged preemptive-loading into master, which was the only remaining unmerged feature branch. If there's anything obviously missing, or obviously wrong with the state of git master, now's a good time to point it out! Other pending patches will be merged into next afterwards, and targeted for an 0.10 release. -- William From michael+sup@stapelberg.de Sat Sep 26 16:28:54 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sat, 26 Sep 2009 22:28:54 +0200 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted In-Reply-To: <1253988435-sup-8649@masanjin.net> References: <1253638189-sup-7758@midna.zekjur.net> <1253640093-sup-48@midna.zekjur.net> <1253905743-sup-419@midna.zekjur.net> <1253988435-sup-8649@masanjin.net> Message-ID: <1253996823-sup-6670@midna.zekjur.net> Hi, Excerpts from William Morgan's message of Sa Sep 26 20:09:36 +0200 2009: > I believe I've fixed this in git. Thunderbird is not producing > RFC3156-compliant encrypted emails, but by the Postel's Law we will > accomodate their errors. Let me know if it doesn't work. The changes basically work. The message itself is opened and decrypted correctly. However, when handling some messages, an exception occurs (downcase called on NilClass), which can be fixed like this: --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -436,7 +436,7 @@ private end chunks - elsif m.header.content_type.downcase == "message/rfc822" + elsif m.header.content_type && m.header.content_type.downcase == "message/rfc822" if m.body payload = RMail::Parser.read(m.body) from = payload.header.from.first ? payload.header.from.first.format : "" @@ -456,7 +456,7 @@ private debug "no body for message/rfc822 enclosure; skipping" [] end - elsif m.header.content_type.downcase == "application/pgp" && m.body + elsif m.header.content_type && m.header.content_type.downcase == "application/pgp" && m.body ## apparently some versions of Thunderbird generate encryped email that ## does not follow RFC3156, e.g. messages with X-Enigmail-Version: 0.95.0 ## they have no MIME multipart and just set the body content type to Best regards, Michael From kevinr@free-dissociation.com Sat Sep 26 17:35:31 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Sat, 26 Sep 2009 17:35:31 -0400 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail stupidity? In-Reply-To: <1253988779-sup-2896@masanjin.net> References: <1252781841-sup-6303@black-opal.mit.edu> <1253988779-sup-2896@masanjin.net> Message-ID: <1254000848-sup-7848@black-opal.mit.edu> Excerpts from William Morgan's message of Sat Sep 26 14:17:14 -0400 2009: > Reformatted excerpts from Kevin Riggle's message of 2009-09-12: > > I theorize that RubyMail is being case-sensitive where it shouldn't. > > Although I love criticizing RubyMail, I think this is Sup's fault. I > don't think it's in RubyMail's proper purview to canonicalize header > values (though header names are fine). > > Anyways, I think I've fixed this in git. Give it a try. > Updated to next, restarted Sup, went to open a message, and got this crash: (Appears to be individual messages, not all messages.) --- NoMethodError from thread: load messages for thread-view-mode undefined method `downcase' for nil:NilClass ./lib/sup/message.rb:439:in `message_to_chunks' ./lib/sup/message.rb:239:in `load_from_source!' ./lib/sup/modes/thread-index-mode.rb:108:in `select' ./lib/sup/hook.rb:121:in `each_with_index' ./lib/sup/thread.rb:68:in `each' ./lib/sup/thread.rb:168:in `each_with_stuff' ./lib/sup/thread.rb:67:in `each' ./lib/sup/modes/thread-index-mode.rb:105:in `each_with_index' ./lib/sup/modes/thread-index-mode.rb:105:in `select' ./lib/sup/buffer.rb:716:in `say' ./lib/sup/util.rb:520:in `send' ./lib/sup/util.rb:520:in `method_missing' ./lib/sup/modes/thread-index-mode.rb:104:in `select' ./lib/sup.rb:77:in `reporting_thread' ./lib/sup.rb:75:in `initialize' ./lib/sup.rb:75:in `new' ./lib/sup.rb:75:in `reporting_thread' ./lib/sup/modes/thread-index-mode.rb:101:in `select' ./lib/sup/mode.rb:51:in `send' ./lib/sup/mode.rb:51:in `handle_input' ./lib/sup/buffer.rb:267:in `handle_input' bin/sup:238 - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com From bwalton@artsci.utoronto.ca Sat Sep 26 17:37:53 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 26 Sep 2009 17:37:53 -0400 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted In-Reply-To: <1253996823-sup-6670@midna.zekjur.net> References: <1253638189-sup-7758@midna.zekjur.net> <1253640093-sup-48@midna.zekjur.net> <1253905743-sup-419@midna.zekjur.net> <1253988435-sup-8649@masanjin.net> <1253996823-sup-6670@midna.zekjur.net> Message-ID: <1254001034-sup-5895@ntdws12.chass.utoronto.ca> Excerpts from Michael Stapelberg's message of Sat Sep 26 16:28:54 -0400 2009: > The changes basically work. The message itself is opened and decrypted > correctly. However, when handling some messages, an exception occurs > (downcase called on NilClass), which can be fixed like this: +1 for this patch. I need it after updating too. -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. From michael+sup@stapelberg.de Sat Sep 26 17:38:49 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sat, 26 Sep 2009 23:38:49 +0200 Subject: [sup-talk] Bug: Converting the index to xapian fails with a message with very old date In-Reply-To: <1253973258-sup-3347@masanjin.net> References: <1253475875-sup-5119@midna.zekjur.net> <1253973258-sup-3347@masanjin.net> Message-ID: <1254001080-sup-5742@midna.zekjur.net> Hi, Excerpts from William Morgan's message of Sa Sep 26 15:56:04 +0200 2009: > Interesting. The Xapian index has had some trouble with crazy dates in > the past, but that should be fixed. Can you apply the following debug > patch and send the output for that message? Yes, here we go: truncated date is Thu Jan 01 01:00:00 +0100 1970 date_value is "\200" /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `_dump': year too big to marshal (ArgumentError) from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `dump' from /usr/lib/ruby/1.8/sup/xapian_index.rb:536:in `index_message' from /usr/lib/ruby/1.8/sup/xapian_index.rb:124:in `sync_message' from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/1.8/sup/xapian_index.rb:398:in `synchronize' from /usr/lib/ruby/1.8/sup/xapian_index.rb:123:in `sync_message' from /usr/lib/ruby/1.8/sup/xapian_index.rb:94:in `add_message' from /home/michael/software/sup-mainline/bin/sup-sync:211 from /usr/lib/ruby/1.8/sup/poll.rb:151:in `each_message_from' from /usr/lib/ruby/1.8/sup/imap.rb:197:in `each' from /usr/lib/ruby/1.8/sup/imap.rb:185:in `upto' from /usr/lib/ruby/1.8/sup/imap.rb:185:in `each' from /usr/lib/ruby/1.8/sup/util.rb:560:in `send' from /usr/lib/ruby/1.8/sup/util.rb:560:in `__pass' from /usr/lib/ruby/1.8/sup/util.rb:547:in `method_missing' from /usr/lib/ruby/1.8/sup/poll.rb:139:in `each_message_from' from /usr/lib/ruby/1.8/sup/util.rb:520:in `send' from /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' from /home/michael/software/sup-mainline/bin/sup-sync:146 from /home/michael/software/sup-mainline/bin/sup-sync:141:in `each' from /home/michael/software/sup-mainline/bin/sup-sync:141 Best regards, Michael From michael+sup@stapelberg.de Sat Sep 26 17:41:58 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Sat, 26 Sep 2009 23:41:58 +0200 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted In-Reply-To: <1253996823-sup-6670@midna.zekjur.net> References: <1253638189-sup-7758@midna.zekjur.net> <1253640093-sup-48@midna.zekjur.net> <1253905743-sup-419@midna.zekjur.net> <1253988435-sup-8649@masanjin.net> <1253996823-sup-6670@midna.zekjur.net> Message-ID: <1254001238-sup-5754@midna.zekjur.net> Hi, Excerpts from Michael Stapelberg's message of Sa Sep 26 22:28:54 +0200 2009: > The changes basically work. The message itself is opened and decrypted > correctly. However, when handling some messages, an exception occurs > (downcase called on NilClass), which can be fixed like this: I noticed that this is not the only place where this was wrong. Complete patch attached (also fixes mixups like control.header.downcase.content_type vs. control.header.content_type.downcase). Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: sup-downcase.patch Type: application/octet-stream Size: 2375 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Sat Sep 26 21:27:57 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 18:27:57 -0700 Subject: [sup-talk] Hook, again In-Reply-To: <1253988011-sup-8497@altis> References: <1253988011-sup-8497@altis> Message-ID: <1254014763-sup-4749@masanjin.net> Reformatted excerpts from Guillaume Quintard's message of 2009-09-26: > message.recipients.each { > |person| > if (person.email =~ /addr at site.com/) != nil > Person.from_address "Foo " > end > } The problem is that #each returns the original array, i.e. message.recipients. Your Person object is getting constructed and then forgotten. Try: if messages.recipients.any? { |p| p.email =~ /addr at site\.com/ } Person.from_address "Foo " end -- William From wmorgan-sup@masanjin.net Sat Sep 26 21:40:06 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 18:40:06 -0700 Subject: [sup-talk] Bug: Messages using inline GPG are not decrypted In-Reply-To: <1254001238-sup-5754@midna.zekjur.net> References: <1253638189-sup-7758@midna.zekjur.net> <1253640093-sup-48@midna.zekjur.net> <1253905743-sup-419@midna.zekjur.net> <1253988435-sup-8649@masanjin.net> <1253996823-sup-6670@midna.zekjur.net> <1254001238-sup-5754@midna.zekjur.net> Message-ID: <1254015511-sup-5690@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-26: > I noticed that this is not the only place where this was wrong. Complete > patch attached (also fixes mixups like control.header.downcase.content_type > vs. control.header.content_type.downcase). Applied, thanks. BTW it will be slightly easier on me if you commit changes and use git format-patch to send them (or git send-email). That will also put your name in the automatically-generated contributors list. -- William From wmorgan-sup@masanjin.net Sat Sep 26 21:46:03 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Sep 2009 18:46:03 -0700 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail stupidity? In-Reply-To: <1254000848-sup-7848@black-opal.mit.edu> References: <1252781841-sup-6303@black-opal.mit.edu> <1253988779-sup-2896@masanjin.net> <1254000848-sup-7848@black-opal.mit.edu> Message-ID: <1254015946-sup-7518@masanjin.net> Reformatted excerpts from Kevin Riggle's message of 2009-09-26: > undefined method `downcase' for nil:NilClass Should be fix0red. -- William From kevinr@free-dissociation.com Sun Sep 27 03:10:51 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Sun, 27 Sep 2009 03:10:51 -0400 Subject: [sup-talk] Case-sensitivity of Content-Type: more RubyMail stupidity? In-Reply-To: <1254015946-sup-7518@masanjin.net> References: <1252781841-sup-6303@black-opal.mit.edu> <1253988779-sup-2896@masanjin.net> <1254000848-sup-7848@black-opal.mit.edu> <1254015946-sup-7518@masanjin.net> Message-ID: <1254035436-sup-1220@black-opal.mit.edu> Excerpts from William Morgan's message of Sat Sep 26 21:46:03 -0400 2009: > Reformatted excerpts from Kevin Riggle's message of 2009-09-26: > > undefined method `downcase' for nil:NilClass > > Should be fix0red. Looks like it is -- thanks! - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com From dato@net.com.org.es Sun Sep 27 08:48:56 2009 From: dato@net.com.org.es (Adeodato =?utf-8?B?U2ltw7M=?=) Date: Sun, 27 Sep 2009 13:48:56 +0100 Subject: [sup-talk] Fixing header for encrypted messages (might be an old issue) In-Reply-To: <1253976576-sup-8002@masanjin.net> References: <1253045775-sup-210@thinkpad-ubuntu> <20090915222119.GA5290@chistera.yi.org> <1253054438-sup-8449@thinkpad-ubuntu> <1253976007-sup-711@masanjin.net> <1253976576-sup-8002@masanjin.net> Message-ID: <20090927124856.GA322@chistera.yi.org> + William Morgan (Sat, 26 Sep 2009 07:49:41 -0700): > Reformatted excerpts from William Morgan's message of 2009-09-26: > > Just to confirm---both of you are seeing this error, with a recent git > > master, when opening encrypted messages? > Ah, looks like Michael Stapelberg's patch will fix this. I can confirm it works again on master (and next), thanks! -- - Are you sure we're good? - Always. -- Rory and Lorelai From web-sup@superscript.com Sun Sep 27 13:04:39 2009 From: web-sup@superscript.com (William Erik Baxter) Date: Sun, 27 Sep 2009 13:04:39 -0400 Subject: [sup-talk] Why inbox-mode instead of default search? Message-ID: <1254070015-sup-5151@kronos> Why does sup have a separate mode for viewing the inbox rather than simply applying a default search (possibly configurable) and displaying the results with search-results-mode? Like a number of other posters to the list, I wanted to refine my inbox search. But the requisite key binding exists only in search-results-mode and not in inbox-mode. Using inbox as an ordinary label with search-results-mode instead of inbox-mode offers several advantages over the separate inbox-mode: less code, less separate modality, ability to refine the inbox search. It introduces the possibility of closing the inbox window, readily addressed with a key binding to perform the default search. What are the disadvantages? One loses the difference in the archiving behavior between the two modes. The inbox label would appear in the label editors. The program may need new code to handle a new no-windows case. Perhaps efficiency considerations enter here. Thanks, W. From wmorgan-sup@masanjin.net Sun Sep 27 13:46:00 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 27 Sep 2009 10:46:00 -0700 Subject: [sup-talk] Why inbox-mode instead of default search? In-Reply-To: <1254070015-sup-5151@kronos> References: <1254070015-sup-5151@kronos> Message-ID: <1254073440-sup-2700@masanjin.net> Reformatted excerpts from William Erik Baxter's message of 2009-09-27: > Why does sup have a separate mode for viewing the inbox rather than > simply applying a default search (possibly configurable) and > displaying the results with search-results-mode? Because there are two special actions that are specific to inboxes: archiving and killing. > Like a number of other posters to the list, I wanted to refine my > inbox search. But the requisite key binding exists only in > search-results-mode and not in inbox-mode. It would be easy enough to add a "|" command to inbox mode that would spawn a search buffer with label:inbox and the rest of your search terms. -- William From web-sup@superscript.com Sun Sep 27 14:50:08 2009 From: web-sup@superscript.com (William Erik Baxter) Date: Sun, 27 Sep 2009 14:50:08 -0400 Subject: [sup-talk] Why inbox-mode instead of default search? In-Reply-To: <1254073440-sup-2700@masanjin.net> References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net> Message-ID: <1254074517-sup-4465@kronos> Excerpts from William Morgan's message of Sun Sep 27 13:46:00 -0400 2009: > Reformatted excerpts from William Erik Baxter's message of 2009-09-27: > > Why does sup have a separate mode for viewing the inbox rather than > > simply applying a default search (possibly configurable) and > > displaying the results with search-results-mode? > > Because there are two special actions that are specific to inboxes: > archiving and killing. Both modes support archive and kill in some form. So I don't understand how this argues for splitting as opposed to consolidating the two modes. The need for preallocated, special-purpose labels like inbox and killed seems clear enough. However, minimizing the amount of magical behavior they exhibit also seems beneficial, if only for the sake of consistency. Treating the inbox as something other than an ordinary label search is magical. > It would be easy enough to add a "|" command to inbox mode that would > spawn a search buffer with label:inbox and the rest of your search > terms. A patch to add this command to inbox-mode appears in the August sup-talk archive. I would like to see this feature become part of the base system. Cheers, W. From bgamari.foss@gmail.com Mon Sep 28 14:10:06 2009 From: bgamari.foss@gmail.com (Ben Gamari) Date: Mon, 28 Sep 2009 14:10:06 -0400 Subject: [sup-talk] Crash while scrolling In-Reply-To: <1253975267-sup-8308@masanjin.net> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> <1253975267-sup-8308@masanjin.net> Message-ID: <1254160696-sup-3522@ben-laptop> Excerpts from William Morgan's message of Sat Sep 26 10:31:56 -0400 2009: > Sorry it's taken me so long to get back to this. Quite alright. I know we're all busy. > > I definitely am not sure why there's a deadlock happening, but I am > guessing, based on the line numbers in that first exception, that it's > being triggered by an underlying problem with the source. If you run > sup with -n, does that change anything? (Or produce a better exception?) Well, things definitely failed a bit differently. I tried this a few times and after seeing no real improvement, I moved on to your suggestion below. > > > Anyways, this is the current status of things on my machine. William, do > > you have any ideas what might cause such a backtrace. At this point > > classes have started and I really have no more time to devote to > > getting sup working. If there isn't a fairly simple solution here I guess > > I'll just need to stick with mutt (ugh). Anyways, thanks for your work. > > Well, there's a workaround, which is to switch over to an offlineimap > setup where your Gmail is mirrored locally and Sup reads the mirror > (which is what you want anyways if you're serious about using Sup with > an IMAP client). I don't know what's causing the deadlock, but I will > try and reproduce it on my end. This is definitely what I should have done from the beginning. Given that sup seems to work fine after removing my imap sources, it seems that that might be the source of the above deadlock. I think I'll just stick with offlineimap for now. This does raise one important question, however. It seems that offlineimap will delete messages if they are found to have been deleted in the remote respository. Is there any way that you know of to disable this behavior, such that it will only drop new messages into the local repository, thus making it somewhat compatible with sup's add-only source requirement? It is awfully nice to be able to use GMail's web interface when I'm away from my computer, but needing to re-sync sup afterwards becomes quite tiresome. This actually brings up a larger question. How difficult would it be to relax sup's assumption that sources are add-only? This seems like a horribly restriction to have in an email program. I understand that in the case of sources such as imap where there is no globally unique message identifier trying to track message changes could be quite difficult, but for local sources (especially maildirs) it seems like this should be quite possible. Anyways, thanks a ton for your work. Now since I finally have sup up and running reliably, it's been a joy to use. Leaps and bounds above my former mutt-based system. - Ben From cworth@cworth.org Mon Sep 28 18:57:38 2009 From: cworth@cworth.org (Carl Worth) Date: Mon, 28 Sep 2009 15:57:38 -0700 Subject: [sup-talk] [PATCH] Add new :crypto_default configuration option. Message-ID: <1254178611-sup-369@yoom.home.cworth.org> For example, users that want to sign all outgoing messages by default can set: :crypto_default: :sign in ~/.sup/config.yaml. Configuring an invalid value will cause a list of the valid values to be logged at the "error" level. --- lib/sup/horizontal-selector.rb | 8 +++++++- lib/sup/modes/edit-message-mode.rb | 7 ++++++- 2 files changed, 13 insertions(+), 2 deletions(-) diff --git a/lib/sup/horizontal-selector.rb b/lib/sup/horizontal-selector.rb index aef16d4..13c63ed 100644 --- a/lib/sup/horizontal-selector.rb +++ b/lib/sup/horizontal-selector.rb @@ -12,7 +12,13 @@ class HorizontalSelector @selection = 0 end - def set_to val; @selection = @vals.index(val) end + def set_to val + if @vals.index(val) + @selection = @vals.index(val) + else + error "Invalid option ", val.inspect, " (valid options: ", @vals.inspect, ")" + end + end def val; @vals[@selection] end diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb index 8da316f..3449503 100644 --- a/lib/sup/modes/edit-message-mode.rb +++ b/lib/sup/modes/edit-message-mode.rb @@ -89,7 +89,12 @@ EOS if CryptoManager.have_crypto? HorizontalSelector.new "Crypto:", [:none] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.keys, ["None"] + CryptoManager::OUTGOING_MESSAGE_OPERATIONS.values end - add_selector @crypto_selector if @crypto_selector + if @crypto_selector + if !$config[:crypto_default].nil? + @crypto_selector.set_to $config[:crypto_default] + end + add_selector @crypto_selector + end HookManager.run "before-edit", :header => @header, :body => @body -- 1.6.4.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From michael+sup@stapelberg.de Tue Sep 29 14:43:09 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Tue, 29 Sep 2009 20:43:09 +0200 Subject: [sup-talk] [BUG] [PATCH] Encrypted messages without signature generate an exception Message-ID: <1254249719-sup-3652@midna.zekjur.net> Hi, when viewing (or replying to) an encrypted message without a signature, sup throws an exception because of a nil chunk. I?ve attached a patch which fixes the issue by instead providing a message stating that this mail is not signed. Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Bugfix-Display-a-notice-when-a-mail-is-not-signed.patch Type: application/octet-stream Size: 1212 bytes Desc: not available URL: From stettberger@dokucode.de Tue Sep 29 14:14:58 2009 From: stettberger@dokucode.de (Christian Dietrich) Date: Tue, 29 Sep 2009 20:14:58 +0200 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode Message-ID: <1254247706-sup-2745@peer.zerties.org> Hey there, i am using sup now for just a few weeks and it is just amazing how good it works (the lack of folders iritated me a little bit at first). But now to my Request, i would like to have something like datelines in index mode, like: ,----------------- | -- Today | 12:23 ... | 23:42 ... | -- Yesterday | Yest. 9 .... | Yest. 4.... | -- Last week | ..... .--------------- I think this would cause an bigger overview over the mails, especially in the inbox. I tried to implement the feature by my self, but the mapping beetween `curpos' and `@threads' in modes/thread-index-mode.rb made this a little bit hard, and i didn't know how to solve this problem without breaking sup. Perhaps you can give me a hint, how this problem with the direct mapping can be solved. greetz didi -- No documentation is better than bad documentation -- Das Ausdrucken dieser Mail wird urheberrechtlich verfolgt. From wmorgan-sup@masanjin.net Wed Sep 30 11:16:35 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 08:16:35 -0700 Subject: [sup-talk] Why inbox-mode instead of default search? In-Reply-To: <1254074517-sup-4465@kronos> References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net> <1254074517-sup-4465@kronos> Message-ID: <1254323181-sup-1735@masanjin.net> Reformatted excerpts from William Erik Baxter's message of 2009-09-27: > Both modes support archive and kill in some form. So I don't > understand how this argues for splitting as opposed to consolidating > the two modes. How does the notion of killing a thread that makes sense except in the context of having an special inbox mode? > The need for preallocated, special-purpose labels like > inbox and killed seems clear enough. However, minimizing the amount > of magical behavior they exhibit also seems beneficial, if only for > the sake of consistency. Treating the inbox as something other than > an ordinary label search is magical. The inbox is magical, because you do different things with your inbox than you do with non-inbox buffers: you classify threads into a) I'm done with this thread for now, but let me know if someone replies (archive); b) I'm done with this thread for now and don't let me know if someone replies (kill); c) I'll deal with this later (ignore). > A patch to add this command to inbox-mode appears in the August sup-talk > archive. I would like to see this feature become part of the base system. I agree. -- William From cworth@cworth.org Wed Sep 30 12:12:35 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 30 Sep 2009 09:12:35 -0700 Subject: [sup-talk] Why inbox-mode instead of default search? In-Reply-To: <1254323181-sup-1735@masanjin.net> References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net> <1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net> Message-ID: <1254326318-sup-904@yoom.home.cworth.org> Excerpts from William Morgan's message of Wed Sep 30 08:16:35 -0700 2009: > How does the notion of killing a thread that makes sense except in the > context of having an special inbox mode? The kill-thread notion can be handled in multiple ways without a special inbox mode. One way would be to simply not apply the inbox label to new messages belonging to killed threads. A better way would be to expand the search capability to something like: Search for all threads containing messages matching AND exclude all threads containing messages matching I'd be happy to have that kind of functionality for arbitrary labels that would function like killed for specific searches. > The inbox is magical, because you do different things with your inbox > than you do with non-inbox buffers: you classify threads into a) I'm > done with this thread for now, but let me know if someone replies > (archive); b) I'm done with this thread for now and don't let me know if > someone replies (kill); c) I'll deal with this later (ignore). It's definitely true that reading new mail is a different activity than searching old mail, (note my recent patch that provides different sort orders for these two operations). But there are at least two problems with the current inbox mode implemented separately from the search mode: 1. Some functionality appears in only one or the other of the modes. Refine search is the easy-to-notice one that we've talked about. But really, any keybindings performing distinct actions in these two modes is just confusing. The two modes are far too similar to have independent lists of possible actions and bindings. This should be unified. 2. There are some things that are currently implemented as "magic" in inbox mode that should really be made available to all searches. Things like the archive operation making a message disappear from the inbox. Instead, any operation making a message no longer satisfy the current search should cause it to disappear from the current view. > > A patch to add this command to inbox-mode appears in the August sup-talk > > archive. I would like to see this feature become part of the base system. > > I agree. One shortcoming of that patch is that refined versions of the inbox come up in search-results-mode, not inbox-mode. So you don't actually get what you want yet, (such as archiving no longer works the same in a refined inbox as it does in the raw inbox). Or said another way, you would get exactly what you want if there was nothing magic about inbox. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Wed Sep 30 13:47:53 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 30 Sep 2009 13:47:53 -0400 Subject: [sup-talk] Why inbox-mode instead of default search? In-Reply-To: <1254326318-sup-904@yoom.home.cworth.org> References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net> <1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net> <1254326318-sup-904@yoom.home.cworth.org> Message-ID: <1254331067-sup-9065@zyrg.net> Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009: > Or said another way, you would get exactly what you want if there was > nothing magic about inbox. I've been working on a patch to do this. You can see the current state at http://github.com/rlane/sup/tree/personal/. It's still buggy and needs to be cleaned up a lot before I submit it. The basic idea is that ThreadSet becomes tightly coupled to the Index and stays in sync with it. This lets us use the index to determine whether a message is relevant to a query, which was the main cause of magic previously. It also makes ThreadIndexMode much simpler in general resulting in a net code reduction. From wmorgan-sup@masanjin.net Wed Sep 30 14:04:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 11:04:52 -0700 Subject: [sup-talk] Why inbox-mode instead of default search? In-Reply-To: <1254331067-sup-9065@zyrg.net> References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net> <1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net> <1254326318-sup-904@yoom.home.cworth.org> <1254331067-sup-9065@zyrg.net> Message-ID: <1254333819-sup-408@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-30: > This lets us use the index to determine whether a message is relevant > to a query, which was the main cause of magic previously. It also > makes ThreadIndexMode much simpler in general resulting in a net code > reduction. Now you're talking my language. :) -- William From wmorgan-sup@masanjin.net Wed Sep 30 14:17:55 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 11:17:55 -0700 Subject: [sup-talk] Feature Request: Collecting Lines in Index Mode In-Reply-To: <1254247706-sup-2745@peer.zerties.org> References: <1254247706-sup-2745@peer.zerties.org> Message-ID: <1254334371-sup-5145@masanjin.net> Reformatted excerpts from Christian Dietrich's message of 2009-09-29: > i am using sup now for just a few weeks and it is just amazing how > good it works (the lack of folders iritated me a little bit at > first). Welcome! > But now to my Request, i would like to have something like datelines > in index mode, like: Cool idea. I'd like to see how this looks. > I tried to implement the feature by my self, but the mapping beetween > `curpos' and `@threads' in modes/thread-index-mode.rb made this a > little bit hard, and i didn't know how to solve this problem without > breaking sup. Perhaps you can give me a hint, how this problem with > the direct mapping can be solved. If you look at #regen_text, @text and @lines are the two variables that control the display. @text is an array of the GUI elements for each line of the display. Right now it's just set to one line for each thread. You want to add one additional element at the appropriate position. for each date line. GUI elements are represented as arrays of [color, text] pairs; you can look at #text_for_thread_at for an example. Then, you want to make sure that @lines is set correctly. @lines is a map (hash) from line number to thread (so that when the user presses a key, we know which thread the cursor is resting on). Hope that helps. -- William From wmorgan-sup@masanjin.net Wed Sep 30 14:21:46 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 11:21:46 -0700 Subject: [sup-talk] sup 0.9 pre-release checkin In-Reply-To: <1253989249-sup-3372@masanjin.net> References: <1253989249-sup-3372@masanjin.net> Message-ID: <1254334862-sup-8690@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-09-26: > If there's anything obviously missing, or obviously wrong with the > state of git master, now's a good time to point it out! I've just made a few more bugfix changes, so I'm giving this another day of baking. -- William From michael+sup@stapelberg.de Wed Sep 30 14:55:30 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Wed, 30 Sep 2009 20:55:30 +0200 Subject: [sup-talk] sup 0.9 pre-release checkin In-Reply-To: <1254334862-sup-8690@masanjin.net> References: <1253989249-sup-3372@masanjin.net> <1254334862-sup-8690@masanjin.net> Message-ID: <1254336855-sup-2395@midna.zekjur.net> Hi William, Excerpts from William Morgan's message of Mi Sep 30 20:21:46 +0200 2009: > I've just made a few more bugfix changes, so I'm giving this another day > of baking. I am not sure if you have not noticed my patch, but in any case I would like to see it in 0.9: http://rubyforge.org/pipermail/sup-talk/2009-September/003189.html It fixes a crash when opening PGP encrypted (but not signed) emails. Best regards, Michael From cworth@cworth.org Wed Sep 30 15:12:45 2009 From: cworth@cworth.org (Carl Worth) Date: Wed, 30 Sep 2009 12:12:45 -0700 Subject: [sup-talk] Why inbox-mode instead of default search? In-Reply-To: <1254331067-sup-9065@zyrg.net> References: <1254070015-sup-5151@kronos> <1254073440-sup-2700@masanjin.net> <1254074517-sup-4465@kronos> <1254323181-sup-1735@masanjin.net> <1254326318-sup-904@yoom.home.cworth.org> <1254331067-sup-9065@zyrg.net> Message-ID: <1254337861-sup-4368@yoom.home.cworth.org> Excerpts from Rich Lane's message of Wed Sep 30 10:47:53 -0700 2009: > Excerpts from Carl Worth's message of Wed Sep 30 12:12:35 -0400 2009: > > Or said another way, you would get exactly what you want if there was > > nothing magic about inbox. > > I've been working on a patch to do this. You can see the current state > at http://github.com/rlane/sup/tree/personal/. It's still buggy and > needs to be cleaned up a lot before I submit it. Very nice stuff, Rich! It's great to see this coming along so far already. Please let me know if there are specific bugs or issues you'd like help fixing, and I'll be glad to try out where I can. Or even if there are just specific things you'd like tested---I'm not too afraid of running half-baked sup branches. :-) -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 236 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Wed Sep 30 15:33:34 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 12:33:34 -0700 Subject: [sup-talk] sup 0.9 pre-release checkin In-Reply-To: <1254336855-sup-2395@midna.zekjur.net> References: <1253989249-sup-3372@masanjin.net> <1254334862-sup-8690@masanjin.net> <1254336855-sup-2395@midna.zekjur.net> Message-ID: <1254339174-sup-648@masanjin.net> Reformatted excerpts from Michael Stapelberg's message of 2009-09-30: > http://rubyforge.org/pipermail/sup-talk/2009-September/003189.html > > It fixes a crash when opening PGP encrypted (but not signed) emails. Can you please try the branch i-suck? About five patches later, I've come in a full circle with this bit of code. -- William From wmorgan-sup@masanjin.net Wed Sep 30 15:40:32 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 12:40:32 -0700 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state In-Reply-To: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu> References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1254339542-sup-886@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-09-13: > Refactor index_message so that we do the minimal amount of work based > on what state the user has modified. Branch xapian-message-state, merged into next. Thanks! BTW I'm excited about the direction this is going. State changes on large numbers of messages seem significantly faster with this. -- William From michael+sup@stapelberg.de Wed Sep 30 15:53:03 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Wed, 30 Sep 2009 21:53:03 +0200 Subject: [sup-talk] sup 0.9 pre-release checkin In-Reply-To: <1254339174-sup-648@masanjin.net> References: <1253989249-sup-3372@masanjin.net> <1254334862-sup-8690@masanjin.net> <1254336855-sup-2395@midna.zekjur.net> <1254339174-sup-648@masanjin.net> Message-ID: <1254340355-sup-5292@midna.zekjur.net> Hi William, Excerpts from William Morgan's message of Mi Sep 30 21:33:34 +0200 2009: > Can you please try the branch i-suck? > > About five patches later, I've come in a full circle with this bit of > code. Hehe. Yes, the version in this branch works. Thanks for fixing it, Best regards, Michael From wmorgan-sup@masanjin.net Wed Sep 30 15:56:55 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 12:56:55 -0700 Subject: [sup-talk] Ignore killed messages in U screen In-Reply-To: <1252004504-sup-3189@javelin> References: <1251387376-sup-7180@javelin> <1252003380-sup-272@masanjin.net> <1252004144-sup-6662@javelin> <1252004285-sup-476@masanjin.net> <1252004504-sup-3189@javelin> Message-ID: <1254339746-sup-79@masanjin.net> Reformatted excerpts from Edward Z. Yang's message of 2009-09-03: > > What if you just delete messages in the the third condition? > > Then replies show up. :-) I am still thinking about this, BTW. I think solution will either be: treat deleted like killed for the purposes of inbox-mode (so a thread with at least one deleted message will just never appear in inbox-mode), or have a combined delete-and-kill command. FWIW, I believe Gmail will pull a thread with a deleted message back into the inbox if someone replies. -- William From michael+sup@stapelberg.de Wed Sep 30 16:01:33 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Wed, 30 Sep 2009 22:01:33 +0200 Subject: [sup-talk] [PATCH] Save all attachments to a folder Message-ID: <1254340829-sup-2273@midna.zekjur.net> Hi, I finally implemented saving all attachments of a message to a folder. Please review and test this patch, I would be happy if we could merge it into mainline. Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-saving-all-attachments-to-a-folder-keybind.patch Type: application/octet-stream Size: 2438 bytes Desc: not available URL: From ezyang@MIT.EDU Wed Sep 30 16:05:28 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 30 Sep 2009 16:05:28 -0400 Subject: [sup-talk] [PATCH] Save all attachments to a folder In-Reply-To: <1254340829-sup-2273@midna.zekjur.net> References: <1254340829-sup-2273@midna.zekjur.net> Message-ID: <1254341104-sup-4958@javelin> Excerpts from Michael Stapelberg's message of Wed Sep 30 16:01:33 -0400 2009: > I finally implemented saving all attachments of a message to a folder. Please > review and test this patch, I would be happy if we could merge it into > mainline. +1 for this functionality. Haven't looked at the patch; I'll let William do that. :-) Cheers, Edward From rlane@club.cc.cmu.edu Wed Sep 30 16:16:53 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 30 Sep 2009 16:16:53 -0400 Subject: [sup-talk] [PATCH] xapian: do less work for update_message_state In-Reply-To: <1254339542-sup-886@masanjin.net> References: <1252867449-30734-1-git-send-email-rlane@club.cc.cmu.edu> <1254339542-sup-886@masanjin.net> Message-ID: <1254341186-sup-4357@zyrg.net> Excerpts from William Morgan's message of Wed Sep 30 15:40:32 -0400 2009: > Reformatted excerpts from Rich Lane's message of 2009-09-13: > > Refactor index_message so that we do the minimal amount of work based > > on what state the user has modified. > > Branch xapian-message-state, merged into next. Thanks! > > BTW I'm excited about the direction this is going. State changes on > large numbers of messages seem significantly faster with this. They're about 3 times faster on my machine with this patch. An optimization the Xapian devs have been planning to make (and that this patch is necessary to take advantage of) should increase performance much more. From michael+sup@stapelberg.de Wed Sep 30 16:43:13 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Wed, 30 Sep 2009 22:43:13 +0200 Subject: [sup-talk] [PATCH] When providing a wildcard as file for an attachment, correctly expand it Message-ID: <1254343324-sup-7275@midna.zekjur.net> Hi, the attached patch will expand wildcards given as filename when adding attachments to a message. Thus, you can now add ~/work/foo/* at once. As with the last patch, please review, test and merge. Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-When-providing-a-wildcard-as-file-for-an-attachment-.patch Type: application/octet-stream Size: 1050 bytes Desc: not available URL: From kevinr@free-dissociation.com Wed Sep 30 16:54:21 2009 From: kevinr@free-dissociation.com (Kevin Riggle) Date: Wed, 30 Sep 2009 16:54:21 -0400 Subject: [sup-talk] [PATCH] Save all attachments to a folder In-Reply-To: <1254340829-sup-2273@midna.zekjur.net> References: <1254340829-sup-2273@midna.zekjur.net> Message-ID: <1254343903-sup-2789@black-opal.mit.edu> Excerpts from Michael Stapelberg's message of Wed Sep 30 16:01:33 -0400 2009: > Hi, > > I finally implemented saving all attachments of a message to a folder. Please > review and test this patch, I would be happy if we could merge it into > mainline. > +1. And what do you know, I hadn't noticed the :default_attachment_save_dir: config option and had set myself a to-do list item to implement that, so now I don't have to, and thanks for drawing it to my attention! - Kevin -- Kevin Riggle (kevinr at free-dissociation.com) http://free-dissociation.com From wmorgan-sup@masanjin.net Wed Sep 30 17:21:01 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 30 Sep 2009 14:21:01 -0700 Subject: [sup-talk] Crash while scrolling In-Reply-To: <20090916172340.GA20566@ben-laptop> References: <20090911165830.GA11260@ben-laptop> <1252773189-sup-246@masanjin.net> <20090916172340.GA20566@ben-laptop> Message-ID: <1254345607-sup-2358@masanjin.net> Reformatted excerpts from Ben Gamari's message of 2009-09-16: > Well, after several attempts at rebuilding my index, I finally got > lucky and sup-sync ran to completion. Unfortunately, sup now fails to > even start, failing out with the following exception while loading > threads for inbox-mode, Hey, I just started seeing this too, Xapian only. I think I've fixed in master. -- William From michael+sup@stapelberg.de Wed Sep 30 18:08:39 2009 From: michael+sup@stapelberg.de (Michael Stapelberg) Date: Thu, 01 Oct 2009 00:08:39 +0200 Subject: [sup-talk] [PATCH] more inline GPG madness Message-ID: <1254348163-sup-6170@midna.zekjur.net> Hi, browsing some older emails, I noticed that the inline GPG patch I sent earlier was not completely correct. It only handled messages which were encrypted *and* signed, but not messages which were signed only. Attached comes a patch which fixes the behaviour. However (!) the patch is not well aligned, the error case (else) is untested and should probably be handled differently and the old_charset line can probably be written more elegantly in ruby. By the way, the charset stuff is necessary to get the correct character set for messages which are sent inline. I really start to dislike Thunderbird and other crappy software for that :-\. So, please, clean up the patch and merge it. I have also attached a message which was sent using thunderbird and contains inline crypto. If the patch works correctly, you should be able to open it and see some umlauts. Best regards, Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sign.txt URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: inline-gpg.patch Type: application/octet-stream Size: 1394 bytes Desc: not available URL: From mailinglist@flasht.de Wed Sep 30 19:30:54 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 01 Oct 2009 01:30:54 +0200 Subject: [sup-talk] i18n? Message-ID: <1254353101-sup-1021@thinkpad-ubuntu> Hi, are there any plans on doing some internationalization? If not, would people like to have something like this, now that I have mentioned it? ;) I guess something yaml-based could work, there are some good libraries out there afaik. Why this came to my mind: I usually write mails in german and english and have done a custom patch to check for the german word for "attachment" to warn me before sending an email, if I haven't yet added an attachment to a composed mail. This obviously works for english right now, but I wanted to have a similar feature in german. Since adding language specific options all over the code really isn't the right way, maybe having some kind of language packs would be nice. I could take care of some german translation (and I suppose I'm not the only one on this list ;)) Cheers, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de GPG Key ID: 0x2345b203 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 902 bytes Desc: not available URL: