From eg@gaute.vetsj.com Tue Feb 1 08:34:10 2011 From: eg@gaute.vetsj.com (Gaute Hope) Date: Tue, 01 Feb 2011 14:34:10 +0100 Subject: [sup-devel] Bug: UTF-8 error when sending messages In-Reply-To: <1296497911-sup-5024@poincare> References: <1296497911-sup-5024@poincare> Message-ID: <1296566276-sup-4340@qwerzila> Excerpts from Adeel Ahmad Khan's message of 2011-01-31 19:24:42 +0100: > > Tero Tilus : > > Adeel Ahmad Khan, 2011-01-29 05:11: > > > invalid byte sequence in UTF-8 > > ... > > > I am using a nearly fresh installation of Sup 0.12.1 with Ruby > > > 1.9.2p136. I have LOCALE="en_US.UTF-8". What editor are you using ? Could you attach some buggy text (make sure it is transferred in binary - ie upload an archive somewhere like http://paste.xinu.at/)? > > Both the errors were from regex matches against message body. Somehow > > your editor doesn't know your locale or is not obeying it. As a > > result non-utf8 stuff gets saved to disk and sup gets confused. > > You were right. It turned out to be an issue with editor. I'm not so sure. I think it is a problem with Ruby (1.9) degrading the the text it reads to US-ASCII (8bit). And when you later try to do UTF-8 stuff with it (append, or regexp with UTF-8) it fails. Perhaps even when trying to access chars in the string (the body) that are not really US-ASCII [2]. What my patch does is tell Ruby that the string is an UTF-8 string, no matter what it deduced from reading the file in the first place - or what might have happened throughout Sup's processing of the text. Try this patch, it forces encoding on the entire body: http://ix.io/1rO (these patches are workarounds; not to be applied to source-tree) The same happened with labels.txt (or with contacts). Whenever a label string could be degraded to US-ASCII, Ruby did so (how should it know it was UTF-8 anyway?), then when trying to append, match or work with the US-ASCII string towards UTF-8 input it failed. What I think must be done (as an alternative to supporting different encodings all the way) - is to _always_ read all files in UTF-8 [1] (or transcode to UTF-8), and perhaps most difficultly _keep_ the strings UTF-8 throught the entire Sup processes. [1] http://blog.grayproductions.net/articles/ruby_19s_three_default_encodings [2] http://www.ruby-forum.com/topic/194493 Best regards, Gaute From dmishd@gmail.com Thu Feb 3 18:27:18 2011 From: dmishd@gmail.com (Hamish D) Date: Thu, 3 Feb 2011 23:27:18 +0000 Subject: [sup-devel] couple more gpg related patches Message-ID: I've uploaded a couple more patches to the gpgme branch and merged them into next: * one fixes the fingerprint of untrusted keys * the other adds "untrusted" to the signature summary line when the key is untrusted - ie when there is no web of trust from you to that key. Patches below for your reading pleasure. Someone tell me if you'd rather have less detail from me. Hamish Downer commit 6f1b9d7e94496543eacc63807b99fa29059ed300 Author: Hamish Downer Date: Wed Feb 2 21:06:22 2011 +0000 show the FULL key fingerprint, not just the first half diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb index 967c09e..978e145 100644 --- a/lib/sup/crypto.rb +++ b/lib/sup/crypto.rb @@ -313,7 +313,7 @@ private if signature.validity != GPGME::GPGME_VALIDITY_FULL && signature.validity != GPGME::GPGME_VALIDITY_MARGINAL output_lines << "WARNING: This key is not certified with a trusted signature!" output_lines << "There is no indication that the signature belongs to the owner" - output_lines << "Full fingerprint is: " + (0..9).map {|i| signature.fpr[(i*2),2]}.join(":") + output_lines << "Full fingerprint is: " + (0..9).map {|i| signature.fpr[(i*4),4]}.join(":") else trusted = true end commit 0e1f5e56dc7063104c52f1b2d03a3fd85573bc47 Author: Hamish Downer Date: Wed Feb 2 21:02:05 2011 +0000 signature summary now states "untrusted" if the signing key is not trusted diff --git a/lib/sup/crypto.rb b/lib/sup/crypto.rb index 5a38f27..967c09e 100644 --- a/lib/sup/crypto.rb +++ b/lib/sup/crypto.rb @@ -153,16 +153,18 @@ EOS end end + summary_line = simplify_sig_line(verify_result.signatures[0].to_s, all_trusted) + if all_output_lines.length == 0 Chunk::CryptoNotice.new :valid, "Encrypted message wasn't signed", all_output_lines elsif valid if all_trusted - Chunk::CryptoNotice.new(:valid, simplify_sig_line(verify_result.signatures[0].to_s), all_output_lines) + Chunk::CryptoNotice.new(:valid, summary_line, all_output_lines) else - Chunk::CryptoNotice.new(:valid_untrusted, simplify_sig_line(verify_result.signatures[0].to_s), all_output_lines) + Chunk::CryptoNotice.new(:valid_untrusted, summary_line, all_output_lines) end elsif !unknown - Chunk::CryptoNotice.new(:invalid, simplify_sig_line(verify_result.signatures[0].to_s), all_output_lines) + Chunk::CryptoNotice.new(:invalid, summary_line, all_output_lines) else unknown_status all_output_lines end @@ -274,8 +276,12 @@ private end # remove the hex key_id and info in () - def simplify_sig_line sig_line - sig_line.sub(/from [0-9A-F]{16} /, "from ") + def simplify_sig_line sig_line, trusted + sig_line.sub!(/from [0-9A-F]{16} /, "from ") + if !trusted + sig_line.sub!(/Good signature/, "Good (untrusted) signature") + end + sig_line end def sig_output_lines signature From wael.nasreddine@gmail.com Sun Feb 6 19:10:13 2011 From: wael.nasreddine@gmail.com (Wael M. Nasreddine) Date: Mon, 7 Feb 2011 01:10:13 +0100 Subject: [sup-devel] Branch maildir-sync Message-ID: Hello, I'm trying to test the Next branch but with maildir sync support, however the branch maildir-sync does not merge without conflict into either of master nor Next, Damien could you please rebase the branch on master please? Thanks -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Wa?l Nasreddine TechnoGate www.technogate.fr mobile : 06.32.94.70.13 agence : 09.70.444.236 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eg@gaute.vetsj.com Tue Feb 8 03:01:44 2011 From: eg@gaute.vetsj.com (Gaute Hope) Date: Tue, 08 Feb 2011 09:01:44 +0100 Subject: [sup-devel] new branch: keybindings In-Reply-To: <1296187729-sup-7405@zyrg.net> References: <1296187729-sup-7405@zyrg.net> Message-ID: <1297152028-sup-5512@qwerzila> Excerpts from Rich Lane's message of 2011-01-28 05:26:38 +0100: > This branch makes the keybindings hook more useful. It moves the global > keymap into a new GlobalMode that all others inherit from. This lets > you write the same code to make a global keybinding as for a > mode-specific one: > > class Redwood::GlobalMode > keymap.add! :list_starred, "List all starred threads", "s" > > def list_starred > SearchResultsMode.spawn_from_query "is:starred" > end > end > > I got rid of the "modes" local since I think it's better to just reopen > the class with normal Ruby syntax. The keybindings hook is now exactly > like the startup hook but with the O-k keybinding to reload it. > > This branch also makes it easier to write keybindings by catching and > displaying exceptions from any keybinding, including builtin Sup ones. > Masking Sup bugs isn't the goal (there's still a backtrace and bug > report instructions) but the user experience is much better than losing > a half-composed email. > > I've added some of my own keybindings (not using GlobalMode yet) to the > wiki: http://sup.rubyforge.org/wiki/wiki.pl?CustomizingKeys Could it be that this broke continue buffer search key 'n' ? lib/sup/buffer.rb:171 This doesn't work for me anymore, could anyone confirm that? Best regards, Gaute Hope From eg@gaute.vetsj.com Tue Feb 8 03:07:31 2011 From: eg@gaute.vetsj.com (Gaute Hope) Date: Tue, 08 Feb 2011 09:07:31 +0100 Subject: [sup-devel] new branch: keybindings In-Reply-To: <1297152028-sup-5512@qwerzila> References: <1296187729-sup-7405@zyrg.net> <1297152028-sup-5512@qwerzila> Message-ID: <1297152370-sup-4647@qwerzila> Excerpts from Gaute Hope's message of 2011-02-08 09:01:44 +0100: > Excerpts from Rich Lane's message of 2011-01-28 05:26:38 +0100: > Could it be that this broke continue buffer search key 'n' ? > > lib/sup/buffer.rb:171 > > This doesn't work for me anymore, could anyone confirm that? Ah - I just noticed that I have to move down one line before I can hit 'n' to search for the next occurrence. I don't think this was the original, or desired, behaviour? - Gaute From wmorgan-sup@masanjin.net Wed Feb 9 01:14:52 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 09 Feb 2011 06:14:52 +0000 Subject: [sup-devel] whistlepig Message-ID: <1297231668-sup-8433@masanjin.net> Today I've released something that I've been working on for many many months now, which I hope will form the basis of the mythical Sup 2.0. It's a tiny full-text search engine called Whistlepig. http://masanjin.net/whistlepig For a quick demo, if you clone it and check out the ruby/ directory, you can run: ruby -Ilib bin/email-indexer ruby -Ilib bin/email-searcher (You will also need to install the oklahoma_mixer, console and trollop gems.) This is a super simple non-threaded non-curses email browser. The email parsing code is much of the Sup email parsing code, but I think I've ironed out all the Ruby 1.9 encoding-related bugs through a very laborious process of trial and error. For my next trick, I am going to start writing a server version of this. Believe it or not, I'm thinking HTTP. -- William From john.wyzer@gmx.de Wed Feb 9 07:59:50 2011 From: john.wyzer@gmx.de (John Wyzer) Date: Wed, 09 Feb 2011 13:59:50 +0100 Subject: [sup-devel] bug report / trace, exiting message search buffer Message-ID: <1297256387-sup-1667@localhost> Hi. sup v0.12.1: I experienced this a few times. Sup crashes sometimes when I hit "x" in a buffer with message search results. Submitting it here since the bugtracker is down. --- NoMethodError from thread: poll after loading inbox undefined method `content_width' for nil:NilClass /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:921:in `from_width' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:840:in `block in text_for_thread_at' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:839:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:839:in `each_with_index' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:839:in `text_for_thread_at' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:781:in `block in regen_text' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:444:in `block in map_with_index' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:444:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:444:in `each_with_index' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:444:in `map_with_index' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:781:in `regen_text' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:242:in `update' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:717:in `add_or_unhide' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:196:in `handle_added_update' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/update.rb:26:in `block in relay' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/update.rb:26:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/update.rb:26:in `relay' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:175:in `block in poll_from' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/maildir.rb:106:in `block (2 levels) in poll' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `each_with_index' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `block in poll' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/maildir.rb:90:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/maildir.rb:90:in `poll' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:155:in `poll_from' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:113:in `block (2 levels) in do_poll' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:103:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:103:in `block in do_poll' :10:in `synchronize' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:102:in `do_poll' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/poll-mode.rb:15:in `poll' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:49:in `poll_with_sources' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/poll.rb:68:in `poll' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.9.1/gems/sup-0.12.1/bin/sup:212:in `block (2 levels) in ' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup.rb:78:in `block in reporting_thread' From gaudenz@soziologie.ch Wed Feb 9 16:27:13 2011 From: gaudenz@soziologie.ch (Gaudenz Steinlin) Date: Wed, 09 Feb 2011 22:27:13 +0100 Subject: [sup-devel] Encoding of message snippet in xapian Message-ID: <1297286134-sup-7498@meteor.durcheinandertal.local> Hi While debuging the trackeback posted below I discovered that my xapian index contains some of the message snippets in ASCII-8BIT and others in UTF-8. This leads to probelems when building the thread-view for collapsed messages for messages wich have non 7-bit ASCII characters in their snippet. message_patina_lines combines the snippet which comes from the xapian index and is (sometimes) in ASCII-8BIT with other parts of the message which are in UTF-8. I don't know exactly how I ended up with a xapian index which has some strings in ASCII-8BIT and others in UTF-8. I guess it's because I first used sup with Ruby 1.8 and only recently switched to Ruby 1.9.1. What's the expected encoding of things coming from the xapian index? Is there a way to fix the index? Or is a fix in sup needed for this? Or should I just recreate my index from scratch? Running sup with Ruby 1.8 avoids the problem. But I guess it only masks it because 1.8 is not encoding aware. Gaudenz --- Encoding::CompatibilityError from thread: load messages for thread-view-mode incompatible character encodings: UTF-8 and ASCII-8BIT /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:792:in `message_patina_lines' /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:853:in `chunk_to_lines' /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:724:in `block in regen_text' /home/gaudenz/projects/sup/lib/sup/thread.rb:68:in `block in each' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:174:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' /home/gaudenz/projects/sup/lib/sup/thread.rb:67:in `each' /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:713:in `regen_text' /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:175:in `buffer=' /home/gaudenz/projects/sup/lib/sup/buffer.rb:387:in `spawn' (eval):1:in `spawn' /home/gaudenz/projects/sup/lib/sup/modes/thread-index-mode.rb:120:in `block in select' /home/gaudenz/projects/sup/lib/sup.rb:78:in `block in reporting_thread' -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ From dmishd@gmail.com Wed Feb 9 17:03:55 2011 From: dmishd@gmail.com (Hamish D) Date: Wed, 9 Feb 2011 22:03:55 +0000 Subject: [sup-devel] BRANCH: rerun_crypto_selector Message-ID: I noticed that if I changed the reply-to selector that my crypto-selector hook wasn't getting called, so I've made a branch called rerun_crypto_selector (and merged it to next). From the main commit message in the branch: Re-run the crypto selector hook after message changes. The crypto-selector hook will be re-run after the message is edited, or after the recipients change due to changing the "Reply to" selector in reply-mode. So when the recipients change, the default selector will also change. However, if the user has manually changed the crypto selector then the hook will not be re-run, so as to avoid over-riding the user's choice. I've also updated the wiki as the headers["to"] bit is sometimes an array. Working much nicer now. I've pasted in the two patches at the end for those who like to review them in the email. Hamish Downer commit f111201a469fd1c1dccb143e089cc623ce35025d Author: Hamish Downer Date: Tue Feb 8 23:53:13 2011 +0000 added @changed_by_user to HorizontalSelector diff --git a/lib/sup/horizontal-selector.rb b/lib/sup/horizontal-selector.rb index 35a028e..e6ec6dc 100644 --- a/lib/sup/horizontal-selector.rb +++ b/lib/sup/horizontal-selector.rb @@ -1,7 +1,7 @@ module Redwood class HorizontalSelector - attr_accessor :label + attr_accessor :label, :changed_by_user def initialize label, vals, labels, base_color=:horizontal_selector_unselected_color, selected_color=:horizontal_selector_selected_color @label = label @@ -10,6 +10,7 @@ class HorizontalSelector @base_color = base_color @selected_color = selected_color @selection = 0 + @changed_by_user = false end def set_to val; @selection = @vals.index(val) end @@ -37,10 +38,12 @@ class HorizontalSelector def roll_left @selection = (@selection - 1) % @labels.length + @changed_by_user = true end def roll_right @selection = (@selection + 1) % @labels.length + @changed_by_user = true end end commit 3cbccb471fc73b1593374ef8efea1a22ba237d89 Author: Hamish Downer Date: Wed Feb 9 18:58:30 2011 +0000 Re-run the crypto selector hook after message changes. The crypto-selector hook will be re-run after the message is edited, or after the recipients change due to changing the "Reply to" selector in reply-mode. So when the recipients change, the default selector will also change. However, if the user has manually changed the crypto selector then the hook will not be re-run, so as to avoid over-riding the user's choice. diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb index 734a879..6c2d61c 100644 --- a/lib/sup/modes/edit-message-mode.rb +++ b/lib/sup/modes/edit-message-mode.rb @@ -179,6 +179,7 @@ EOS header, @body = parse_file @file.path @header = header - NON_EDITABLE_HEADERS handle_new_text @header, @body + rerun_crypto_selector_hook update @edited @@ -215,6 +216,12 @@ EOS protected + def rerun_crypto_selector_hook + if @crypto_selector && !@crypto_selector.changed_by_user + HookManager.run "crypto-mode", :header => @header, :body => @body, :crypto_selector => @crypto_selector + end + end + def mime_encode string string = [string].pack('M') # basic quoted-printable string.gsub!(/=\n/,'') # .. remove trailing newline diff --git a/lib/sup/modes/reply-mode.rb b/lib/sup/modes/reply-mode.rb index 079e4de..ccdf371 100644 --- a/lib/sup/modes/reply-mode.rb +++ b/lib/sup/modes/reply-mode.rb @@ -165,6 +165,7 @@ protected if @headers[@type_selector.val] != self.header self.header = @headers[@type_selector.val] self.body = @bodies[@type_selector.val] unless @edited + rerun_crypto_selector_hook update end end @@ -174,6 +175,7 @@ protected if @headers[@type_selector.val] != self.header self.header = @headers[@type_selector.val] self.body = @bodies[@type_selector.val] unless @edited + rerun_crypto_selector_hook update end end From dmishd@gmail.com Wed Feb 9 19:57:55 2011 From: dmishd@gmail.com (Hamish D) Date: Thu, 10 Feb 2011 00:57:55 +0000 Subject: [sup-devel] Improved GPG start up checks Message-ID: Better gpg error checking. The crypto initialize code now checks for a number of common reasons for GPG not working, all related to the gpg-agent side of things. It will then give a reasonably friendly error message, helping diagnose why GPG is not working for you. In particular it will check whether the environment variable is set, whether the environment variable points to a file, and whether that file is a socket. On branch gpgme and next. Though this change also merged the improved rescue of NameError from the master branch to the gpgme branch, and the improved rescue was already on the next branch, so a quick manual merge was required to merge into next, and will presumably also be required to merge the gpgme stuff into master. I should probably start a new branch for further gpg improvements to save trouble down the road. Let me know if you want me to pick out commits for cherry-pick to get past this. Hamish Downer From dmishd@gmail.com Thu Feb 10 18:26:29 2011 From: dmishd@gmail.com (Hamish) Date: Thu, 10 Feb 2011 23:26:29 +0000 Subject: [sup-devel] branching and merging Message-ID: <1297380057-sup-9005@whisper> Hello I'm wondering if there are preferred strategies for the feature branches. I'm aware that new branches should be branched off master, and merged into next when the author thinks they're ready. But I'm wondering when a merge has been done from a branch, should development continue on that branch? I've been working on the gpgme branch, even though a number of the earlier commits on that branch have been merged into master. So I've been using git cherry-pick to merge later commits into next. Is that a reasonable way to go or should I be starting lots of little branches, or merging into next less often? Or does it just not make much difference to the maintainers and I should do what works for me? Any opinions? Hamish From wmorgan-sup@masanjin.net Thu Feb 10 19:01:17 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 11 Feb 2011 00:01:17 +0000 Subject: [sup-devel] branching and merging In-Reply-To: <1297380057-sup-9005@whisper> References: <1297380057-sup-9005@whisper> Message-ID: <1297381879-sup-6069@masanjin.net> Reformatted excerpts from Hamish's message of 2011-02-10: > But I'm wondering when a merge has been done from a branch, should > development continue on that branch? If it's essentially more work on the same feature, then yes, continue on that branch. Otherwise, no. Branches are cheap. The point of a feature branch is that you can merge or not merge or revert it without touching other features. So that should be the deciding factor on whether to start a new feature branch: if I have to throw away, or if I have to revert this whole branch, will I be losing extra stuff? The other option is that if it's a long-running set of related and dependent features, you can also call it an integration branch, merge individual feature branches into it as necessary, and finally merge the whole thing into master in one go. I haven't been following the gpgme changes, but it sounds like maybe this is the case. -- William From sascha-pgp@silbe.org Fri Feb 11 09:30:15 2011 From: sascha-pgp@silbe.org (Sascha Silbe) Date: Fri, 11 Feb 2011 15:30:15 +0100 Subject: [sup-devel] [PATCH] Delete messages from index if there is no location left In-Reply-To: <1297428180-sup-8381@mail.univers-libre.net> References: <1297428180-sup-8381@mail.univers-libre.net> Message-ID: <1297434615-5101-1-git-send-email-sascha-pgp@silbe.org> If messages don't have any location, we cannot access their body and are also unable to restore them from a message state dump (written by sup-dump). So it's more consistent to the user if we remove them completely. This is most likely what the user expects anyway: why else would they delete the message from all locations? The drawback is that messages that were moved between sources need to be either scanned in a single sup-sync run or the new location must be scanned first. But that isn't a regression from behaviour before the maildir branch was merged. Signed-off-by: Sascha Silbe --- I've had this in my branch for quite some time now, but didn't have a a chance yet to thoroughly test it after rebasing on top of next (which made changes in the same area of the code, causing conflicts). Feel free to push to next and/or master once you verified it doesn't cause you to loose mails. bin/sup-sync | 9 +++++++++ lib/sup/index.rb | 9 +++++++++ lib/sup/poll.rb | 9 +++++++++ 3 files changed, 27 insertions(+), 0 deletions(-) diff --git a/bin/sup-sync b/bin/sup-sync index b4d5cba..c54359d 100755 --- a/bin/sup-sync +++ b/bin/sup-sync @@ -115,6 +115,7 @@ def time end end + deleted_message_ids = Set.new sources.each do |source| puts "Scanning #{source}..." num_added = num_updated = num_deleted = num_scanned = num_restored = 0 @@ -124,9 +125,11 @@ def time num_scanned += 1 if action == :delete num_deleted += 1 + deleted_message_ids.add m.id if m.locations.empty? puts "Deleting #{m.id}" if opts[:verbose] elsif action == :add seen[m.id] = true + deleted_message_ids.delete(m.id) ## tweak source labels according to commandline arguments if necessary m.labels.delete :inbox if opts[:archive] @@ -190,6 +193,12 @@ def time puts "Restored state on #{num_restored} (#{100.0 * num_restored / num_scanned}%) messages." if num_restored > 0 end + puts "Deleting #{deleted_message_ids.size} messages from index." + deleted_message_ids.each do |id| + debug "Removing #{id} from index" + index.remove_message_by_id id + end + index.save if opts[:optimize] diff --git a/lib/sup/index.rb b/lib/sup/index.rb index 4ad91e7..7dcc7f9 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -129,6 +129,7 @@ def load_index 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 remove_message_by_id id; delete_message id end def save_index info "Flushing Xapian updates to disk. This may take a while..." @@ -627,6 +628,14 @@ def build_xapian_query opts end end + def delete_message id + doc = synchronize { find_doc(id) } + fail unless doc + doc.clear_terms + doc.clear_values + synchronize { @xapian.delete_document doc.docid } + end + def sync_message m, overwrite doc = synchronize { find_doc(m.id) } existed = doc != nil diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb index 7e05292..46ad441 100644 --- a/lib/sup/poll.rb +++ b/lib/sup/poll.rb @@ -98,6 +98,7 @@ def do_poll from_and_subj = [] from_and_subj_inbox = [] loaded_labels = Set.new + deleted_message_ids = Set.new @mutex.synchronize do @poll_sources.each do |source| @@ -112,9 +113,11 @@ def do_poll numi = 0 poll_from source do |action,m,old_m,progress| if action == :delete + deleted_message_ids.add m.id if m.locations.empty? yield "Deleting #{m.id}" elsif action == :add if old_m + deleted_message_ids.delete(m.id) new_locations = (m.locations - old_m.locations) if not new_locations.empty? yield "Message at #{new_locations[0].info} is an update of an old message. Updating labels from #{old_m.labels.to_a * ','} => #{m.labels.to_a * ','}" @@ -139,6 +142,12 @@ def do_poll total_numi += numi end + yield "Deleting #{deleted_message_ids.size} messages from index." + deleted_message_ids.each do |id| + debug "Removing #{id} from index" + Index.remove_message_by_id id + end + loaded_labels = loaded_labels - LabelManager::HIDDEN_RESERVED_LABELS - [:inbox, :killed] yield "Done polling; loaded #{total_num} new messages total" @last_poll = Time.now -- 1.7.2.3 From romain@univers-libre.net Fri Feb 11 13:18:31 2011 From: romain@univers-libre.net (Romain Dessort) Date: Fri, 11 Feb 2011 19:18:31 +0100 Subject: [sup-devel] [PATCH] Delete messages from index if there is no location left In-Reply-To: <1297434615-5101-1-git-send-email-sascha-pgp@silbe.org> References: <1297428180-sup-8381@mail.univers-libre.net> <1297434615-5101-1-git-send-email-sascha-pgp@silbe.org> Message-ID: <1297447700-sup-8352@mail.univers-libre.net> Excerpts from Sascha Silbe's message of ven f?v 11 15:30:15 +0100 2011: > If messages don't have any location, we cannot access their body and are also > unable to restore them from a message state dump (written by sup-dump). So > it's more consistent to the user if we remove them completely. This is > most likely what the user expects anyway: why else would they delete the > message from all locations? Yes, I agree with you, this should be the normal behaviour. > I've had this in my branch for quite some time now, but didn't have a > a chance yet to thoroughly test it after rebasing on top of next (which > made changes in the same area of the code, causing conflicts). Feel > free to push to next and/or master once you verified it doesn't cause > you to loose mails. > > bin/sup-sync | 9 +++++++++ > lib/sup/index.rb | 9 +++++++++ > lib/sup/poll.rb | 9 +++++++++ > 3 files changed, 27 insertions(+), 0 deletions(-) > [...] Thanks for this patch ! I going to try to merge it with my current Sup version. -- Romain Dessort Jabber ID : romain at univers-libre.net GnuPG : 3072D/724BC532 From john.wyzer@gmx.de Sat Feb 12 09:07:05 2011 From: john.wyzer@gmx.de (John Wyzer) Date: Sat, 12 Feb 2011 15:07:05 +0100 Subject: [sup-devel] [bug] trace: undefined method `mark_dirty' for nil:NilClass Message-ID: <1297519607-sup-128@localhost> Hi. sup v0.12.1: Submitting it here since the bugtracker is down. I got this when I hit the "u" key after killing a thread. --- NoMethodError from thread: main undefined method `mark_dirty' for nil:NilClass /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/line-cursor-mode.rb:68:in `set_cursor_pos' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:240:in `update' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:717:in `add_or_unhide' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:479:in `block (2 levels) in multi_kill' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:477:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:477:in `block in multi_kill' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/undo.rb:27:in `call' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/undo.rb:27:in `block in undo' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/undo.rb:27:in `each' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/undo.rb:27:in `undo' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:227:in `undo' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/mode.rb:59:in `handle_input' /var/lib/gems/1.9.1/gems/sup-0.12.1/lib/sup/buffer.rb:277:in `handle_input' /var/lib/gems/1.9.1/gems/sup-0.12.1/bin/sup:260:in `' /var/lib/gems/1.9.1/gems/sup-0.12.1/bin/sup:69:in `' /var/lib/gems/1.9.1/bin/sup:19:in `load' /var/lib/gems/1.9.1/bin/sup:19:in `
' -- From john.wyzer@gmx.de Sun Feb 13 07:08:50 2011 From: john.wyzer@gmx.de (John Wyzer) Date: Sun, 13 Feb 2011 13:08:50 +0100 Subject: [sup-devel] [bug] two more different traces: RuntimeError from thread: poll after loading inbox Message-ID: <1297598759-sup-2911@localhost> sup 0.12.1. I experienced two more different exceptions while indexing was running in the background: ---------------------------------------------------------------- --- NoMethodError from thread: poll after loading inbox undefined method `content_width' for nil:NilClass /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:921:in `from_width' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:840:in `text_for_thread_at' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/index.rb:537:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:839:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:839:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:839:in `text_for_thread_at' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:781:in `regen_text' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:444:in `map_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/index.rb:537:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:444:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:444:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:444:in `map_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:781:in `regen_text' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:242:in `update' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:717:in `add_or_unhide' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:196:in `handle_added_update' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `relay' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `relay' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:175:in `poll_from' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:106:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/hook.rb:128:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:90:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:90:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:155:in `poll_from' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:113:in `do_poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:103:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:103:in `do_poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:102:in `synchronize' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb :102:in `do_poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/poll-mode.rb:15:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:49:in `poll_with_sources' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:68:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.8/gems/sup-0.12.1/bin/sup:212 /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:78:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `initialize' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `new' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/bin/sup:212 /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:684:in `call' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:684 /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:625:in `call' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:625:in `load_n_threads_background' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:78:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `initialize' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `new' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:623:in `load_n_threads_background' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:694:in `__unprotected_load_threads' (eval):12:in `load_threads' /var/lib/gems/1.8/gems/sup-0.12.1/bin/sup:212 /var/lib/gems/1.8/bin/sup:19:in `load' /var/lib/gems/1.8/bin/sup:19 --- RuntimeError from thread: poll after loading inbox unknown drawable object: nil in # for line 37 /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/scroll-mode.rb:200:in `draw_line' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/line-cursor-mode.rb:52:in `draw_line' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/scroll-mode.rb:48:in `draw' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/scroll-mode.rb:48:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/scroll-mode.rb:48:in `draw' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/line-cursor-mode.rb:37:in `draw' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/buffer.rb:119:in `draw' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/buffer.rb:103:in `redraw' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/buffer.rb:339:in `draw_screen' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:197:in `handle_added_update' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `relay' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/update.rb:26:in `relay' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:175:in `poll_from' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:106:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/hook.rb:128:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `each_with_index' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:105:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:90:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/maildir.rb:90:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:155:in `poll_from' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:113:in `do_poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:103:in `each' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:103:in `do_poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:102:in `synchronize' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:102:in `do_poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/poll-mode.rb:15:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:49:in `poll_with_sources' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/poll.rb:68:in `poll' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `send' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/util.rb:609:in `method_missing' /var/lib/gems/1.8/gems/sup-0.12.1/bin/sup:212 /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:78:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `initialize' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `new' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/bin/sup:212 /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:684:in `call' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:684 /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:625:in `call' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:625:in `load_n_threads_background' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:78:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `initialize' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `new' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup.rb:76:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:623:in `load_n_threads_background' /var/lib/gems/1.8/gems/sup-0.12.1/lib/sup/modes/thread-index-mode.rb:694:in `__unprotected_load_threads' (eval):12:in `load_threads' /var/lib/gems/1.8/gems/sup-0.12.1/bin/sup:212 /var/lib/gems/1.8/bin/sup:19:in `load' /var/lib/gems/1.8/bin/sup:19 -- From rlane@club.cc.cmu.edu Sun Feb 13 13:05:40 2011 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Sun, 13 Feb 2011 13:05:40 -0500 Subject: [sup-devel] new branch: keybindings In-Reply-To: <1297152370-sup-4647@qwerzila> References: <1296187729-sup-7405@zyrg.net> <1297152028-sup-5512@qwerzila> <1297152370-sup-4647@qwerzila> Message-ID: <1297620229-sup-1485@zyrg.net> Excerpts from Gaute Hope's message of 2011-02-08 03:07:31 -0500: > Excerpts from Gaute Hope's message of 2011-02-08 09:01:44 +0100: > > Excerpts from Rich Lane's message of 2011-01-28 05:26:38 +0100: > > Could it be that this broke continue buffer search key 'n' ? > > > > lib/sup/buffer.rb:171 > > > > This doesn't work for me anymore, could anyone confirm that? > > Ah - I just noticed that I have to move down one line before I can hit > 'n' to search for the next occurrence. I don't think this was the > original, or desired, behaviour? I did a git bisect and had to stop at the last index format change in May 2010. It looks like 'n' has been broken for a long time. From sup@zevv.nl Sun Feb 13 14:13:10 2011 From: sup@zevv.nl (Ico Doornekamp) Date: Sun, 13 Feb 2011 20:13:10 +0100 Subject: [sup-devel] Sup crash when trying to view full headers on deleted message. Message-ID: <1297624152-sup-1543@pruts.nl> The patch below avoids a crash when opening a full header view on deleted messages. --- lib/sup/message.rb | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 832716e..b8d066d 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -274,7 +274,11 @@ EOS end def raw_header - location.raw_header + begin + location.raw_header + rescue OutOfSyncSourceError => e + error_message + end end def raw_message -- 1.7.0.4 -- :wq ^X^Cy^K^X^C^C^C^C From gaudenz@soziologie.ch Thu Feb 17 09:42:58 2011 From: gaudenz@soziologie.ch (Gaudenz Steinlin) Date: Thu, 17 Feb 2011 15:42:58 +0100 Subject: [sup-devel] Encoding of message snippet in xapian In-Reply-To: <1297286134-sup-7498@meteor.durcheinandertal.local> References: <1297286134-sup-7498@meteor.durcheinandertal.local> Message-ID: <1297953544-sup-6116@meteor.durcheinandertal.local> HI Excerpts from Gaudenz Steinlin's message of 2011-02-09 22:27:13 +0100: > Hi > > While debuging the trackeback posted below I discovered that my xapian > index contains some of the message snippets in ASCII-8BIT and others > in UTF-8. This leads to probelems when building the thread-view for > collapsed messages for messages wich have non 7-bit ASCII characters > in their snippet. message_patina_lines combines the snippet which > comes from the xapian index and is (sometimes) in ASCII-8BIT with > other parts of the message which are in UTF-8. > > I don't know exactly how I ended up with a xapian index which has some > strings in ASCII-8BIT and others in UTF-8. I guess it's because I > first used sup with Ruby 1.8 and only recently switched to Ruby 1.9.1. > What's the expected encoding of things coming from the xapian index? > Is there a way to fix the index? Or is a fix in sup needed for this? > Or should I just recreate my index from scratch? > > Running sup with Ruby 1.8 avoids the problem. But I guess it only > masks it because 1.8 is not encoding aware. Just for the record. I solved the issue by dumping all labels and recreating the index with ruby 1.9. That's what I did: sup-dump > label-dump.txt rm -r ~/.sup/xapian sup-sync --restore label-dump.txt --all-sources While reimporting all my messages I discovered a few message parsing bugs and some bugs related to GPGME. I created patches for all these problems and will submit these in separate mails. Gaudenz > > Gaudenz > > --- Encoding::CompatibilityError from thread: load messages for thread-view-mode > incompatible character encodings: UTF-8 and ASCII-8BIT > /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:792:in `message_patina_lines' > /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:853:in `chunk_to_lines' > /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:724:in `block in regen_text' > /home/gaudenz/projects/sup/lib/sup/thread.rb:68:in `block in each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block (2 levels) in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:174:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:176:in `block in each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each' > /home/gaudenz/projects/sup/lib/sup/thread.rb:175:in `each_with_stuff' > /home/gaudenz/projects/sup/lib/sup/thread.rb:67:in `each' > /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:713:in `regen_text' > /home/gaudenz/projects/sup/lib/sup/modes/thread-view-mode.rb:175:in `buffer=' > /home/gaudenz/projects/sup/lib/sup/buffer.rb:387:in `spawn' > (eval):1:in `spawn' > /home/gaudenz/projects/sup/lib/sup/modes/thread-index-mode.rb:120:in `block in select' > /home/gaudenz/projects/sup/lib/sup.rb:78:in `block in reporting_thread' -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From gaudenz@soziologie.ch Thu Feb 17 09:44:49 2011 From: gaudenz@soziologie.ch (Gaudenz Steinlin) Date: Thu, 17 Feb 2011 15:44:49 +0100 Subject: [sup-devel] Message parsing fixes Message-ID: <1297953809-sup-575@meteor.durcheinandertal.local> Hi While reimporting all my messages to recreate the index I fixed a few message parsing issues. Please consider the attached patches against master. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Don-t-normalize_whitespace-message-rfc822-parts.patch Type: application/octet-stream Size: 1132 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Be-more-cautious-about-invalid-content-type-headers.patch Type: application/octet-stream Size: 1526 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From gaudenz@soziologie.ch Thu Feb 17 09:49:01 2011 From: gaudenz@soziologie.ch (Gaudenz Steinlin) Date: Thu, 17 Feb 2011 15:49:01 +0100 Subject: [sup-devel] GPGME fixes Message-ID: <1297953902-sup-8049@meteor.durcheinandertal.local> Hi While reimporting all my messages I encountered a few problemes with the GPGME code. Please consider the attached fixes. The second patch depends on the first (error message unification). But if you don't like the first I can easily produce a standalone version. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Encode-multipart-messages-for-crypt-operations.patch Type: application/octet-stream Size: 2180 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Unify-formatting-of-GPGME-error-messages.patch Type: application/octet-stream Size: 2413 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Check-for-ArgumentError-on-signature-verification.patch Type: application/octet-stream Size: 1614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Check-for-valid-signature-before-signature.to_s.patch Type: application/octet-stream Size: 1290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From dmishd@gmail.com Thu Feb 17 13:45:20 2011 From: dmishd@gmail.com (Hamish D) Date: Thu, 17 Feb 2011 18:45:20 +0000 Subject: [sup-devel] GPGME fixes In-Reply-To: <1297953902-sup-8049@meteor.durcheinandertal.local> References: <1297953902-sup-8049@meteor.durcheinandertal.local> Message-ID: > While reimporting all my messages I encountered a few problemes with > the GPGME code. Please consider the attached fixes. 0001-Encode-multipart-messages-for-crypt-operations.patch already appears to be in master ... I like the others though, though in applying them I ran into some trouble, partly through my adding lines near the top of the file that change line numbers and seemed to confuse git. So they are now applied to a local copy, but in my name (but with your commit messages). I imagine you would like them to be in your name, so I have not pushed them yet. If anyone could tell me how I should be applying them properly then I will do. And maybe it might be necessary to format the patches with options that give more context. I'm hoping someone with more git knowledge than me can help ... Hamish From gaudenz@soziologie.ch Thu Feb 17 15:44:08 2011 From: gaudenz@soziologie.ch (Gaudenz Steinlin) Date: Thu, 17 Feb 2011 21:44:08 +0100 Subject: [sup-devel] GPGME fixes In-Reply-To: References: <1297953902-sup-8049@meteor.durcheinandertal.local> Message-ID: <1297974845-sup-4146@meteor.durcheinandertal.local> Excerpts from Hamish D's message of 2011-02-17 19:45:20 +0100: > > While reimporting all my messages I encountered a few problemes with > > the GPGME code. Please consider the attached fixes. > > 0001-Encode-multipart-messages-for-crypt-operations.patch already > appears to be in master ... Yes this one belongs to another patch serie already submitted earlier. Sorry. > > I like the others though, though in applying them I ran into some > trouble, partly through my adding lines near the top of the file that > change line numbers and seemed to confuse git. So they are now applied > to a local copy, but in my name (but with your commit messages). > > I imagine you would like them to be in your name, so I have not pushed > them yet. If anyone could tell me how I should be applying them > properly then I will do. And maybe it might be necessary to format the > patches with options that give more context. > > I'm hoping someone with more git knowledge than me can help ... What command do you use to apply the patches? If I can fetch your changes somewhere I can also rebase my patches on top of them. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 482 bytes Desc: not available URL: From dmishd@gmail.com Thu Feb 17 17:57:42 2011 From: dmishd@gmail.com (Hamish D) Date: Thu, 17 Feb 2011 22:57:42 +0000 Subject: [sup-devel] GPGME fixes In-Reply-To: <1297974845-sup-4146@meteor.durcheinandertal.local> References: <1297953902-sup-8049@meteor.durcheinandertal.local> <1297974845-sup-4146@meteor.durcheinandertal.local> Message-ID: >> I like the others though, though in applying them I ran into some >> trouble, partly through my adding lines near the top of the file that >> change line numbers and seemed to confuse git. So they are now applied >> to a local copy, but in my name (but with your commit messages). > > What command do you use to apply the patches? If I can fetch your > changes somewhere I can also rebase my patches on top of them. My changes are on the gpgme branch on gitorious. I used the git apply command. I also tried git am but that did't work at all. Hamish From dmishd@gmail.com Sun Feb 20 14:19:17 2011 From: dmishd@gmail.com (Hamish) Date: Sun, 20 Feb 2011 19:19:17 +0000 Subject: [sup-devel] Need help applying patches Message-ID: <1298228733-sup-6115@whisper> Gaudenz has submitted a few useful patches which I want to commit to the gpgme branch, but git apply seems to fail. I've forwarded the message text below, and attached the patches. When I apply it gpgme, I get: $ git apply --check --verbose ../patches2merge/0001-Unify-formatting-of-GPGME-error-messages.patch Checking patch lib/sup/crypto.rb... error: while searching for: begin sig = GPGME.detach_sign(format_payload(payload), gpg_opts) rescue GPGME::Error => exc info "Error while running gpg: #{exc.message}" raise Error, "GPG command failed. See log for details." end envelope = RMail::Message.new error: patch failed: lib/sup/crypto.rb:75 error: lib/sup/crypto.rb: patch does not apply But I can't see why it could not find it. The code quoted above has moved down by 31 lines, but is otherwise unchanged, but I thought git could cope with that :/ I tried hand-editing the patch to change the line numbers, but I still get the same error. Am I missing a trick? I've checked the file formats and both have unix-style line endings. I have tried and I can apply these patches by hand, but then they will appear as committed by me, rather than giving Gaudenz his due. Do others have the same problem? You could try by checking out the gpgme branch and trying git apply. I've also tried git am on a directory with these 3 attachments in: $ git am -s ../patches2merge/ Nothing to do. Not very helpful. Any help appreciated. Hamish Downer PS I am using git 1.7.1 on Ubuntu 10.10 x86_64 --- Begin forwarded message from Gaudenz Steinlin --- From: Gaudenz Steinlin To: sup-devel Date: Thu, 17 Feb 2011 14:49:01 +0000 Subject: [sup-devel] GPGME fixes Hi While reimporting all my messages I encountered a few problemes with the GPGME code. Please consider the attached fixes. The second patch depends on the first (error message unification). But if you don't like the first I can easily produce a standalone version. Gaudenz --- End forwarded message --- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Check-for-valid-signature-before-signature.to_s.patch Type: application/octet-stream Size: 1290 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Check-for-ArgumentError-on-signature-verification.patch Type: application/octet-stream Size: 1614 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Unify-formatting-of-GPGME-error-messages.patch Type: application/octet-stream Size: 2413 bytes Desc: not available URL: From dmishd@gmail.com Sun Feb 20 14:55:33 2011 From: dmishd@gmail.com (Hamish) Date: Sun, 20 Feb 2011 19:55:33 +0000 Subject: [sup-devel] Need help applying patches In-Reply-To: <1298228733-sup-6115@whisper> References: <1298228733-sup-6115@whisper> Message-ID: <1298230750-sup-6418@whisper> Excerpts from Hamish's message of Sun Feb 20 19:19:17 +0000 2011: > Gaudenz has submitted a few useful patches which I want to commit to the > gpgme branch, but git apply seems to fail. I've forwarded the message > text below, and attached the patches. When I apply it gpgme, I get: Of course, having just written an email describing my problem, I do a little more playing about and manage to find a way through. To record what I did: $ cat ../patches2merge/0001-Unify-formatting-of-GPGME-error-messages.patch | git am -s -3 $ vim lib/sup/crypto.rb $ git add lib/sup/crypto.rb $ git am -3 --resolved Rinse and repeat for the other 2 patches. And now the log looks like I expect it to. I ran into some more issues merging this into next - my usual cherry-pick method led to the same problems as originally, and led to me being listed as the committer, but I managed to do a git merge which preserved the commit messages from Gaudenz (although a couple of mine appear to be repeated). If there is some better way to do this in future, please tell me. Hamish From michael@content-space.de Sun Feb 20 15:12:50 2011 From: michael@content-space.de (Michael Hamann) Date: Sun, 20 Feb 2011 21:12:50 +0100 Subject: [sup-devel] Need help applying patches In-Reply-To: <1298228733-sup-6115@whisper> References: <1298228733-sup-6115@whisper> Message-ID: <1298232315-sup-3221@mithink> Hi, Excerpts from Hamish's message of 2011-02-20 20:19:17 +0100: [...] > I have tried and I can apply these patches by hand, but then they will > appear as committed by me, rather than giving Gaudenz his due. You can use git commit --author="Name ", then you are recorded as committer and the author you supply is recorded as author of the change. Michael Hamann From wmorgan-sup@masanjin.net Sun Feb 20 16:58:13 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sun, 20 Feb 2011 21:58:13 +0000 Subject: [sup-devel] Need help applying patches In-Reply-To: <1298228733-sup-6115@whisper> References: <1298228733-sup-6115@whisper> Message-ID: <1298238906-sup-3941@masanjin.net> Reformatted excerpts from Hamish's message of 2011-02-20: > But I can't see why it could not find it. The code quoted above has > moved down by 31 lines, but is otherwise unchanged, but I thought git > could cope with that :/ Git apply is a pretty low-level command and I believe it acts basically like the patch command, i.e. fails fast if things aren't perfectly in tune. To pull in the git merge logic on patch files, use `git am -3`. > $ git am -s ../patches2merge/ > Nothing to do. I think it's trying to interpret that directory as a maildir. Give it the individual files. -- William From dmishd@gmail.com Sun Feb 20 17:02:54 2011 From: dmishd@gmail.com (Hamish) Date: Sun, 20 Feb 2011 22:02:54 +0000 Subject: [sup-devel] editing messages outside of sup Message-ID: <1298239068-sup-6985@whisper> Hello It is often useful to be able to look at messages while writing a message. While I can exit my editor and look at other messages, and then come back to my editor, it would be nice to have both open at the same time. So I've written some code that allows you to do that. When you are in compose-mode/reply-mode/etc you can press 'E' and it will transform into a buffer showing a file path of the file to edit, and a key to press ('E' again) to say you've finished. So you can open the file in another editor, whether on your desktop, in another terminal, in a screen session split so you can see both, or whatever. While editing you can still navigate around sup's buffers and copy text, email addresses etc into your editor and so on. Then when you're done, you can exit the editor, navigate back to the edit buffer and press 'E' to go back to normal edit-message-mode and carry on as normal. As part of this, I've created a way to hide the original buffer. I think I handle buffer killing properly in the various states (file still being edited, file saved etc), but someone will doubtless find an edge case ... For the moment this work is in the async_message_edit branch. If no one shouts about this being a terrible idea then I'll merge it into next within a week. Hamish Downer From dmishd@gmail.com Sun Feb 20 20:22:41 2011 From: dmishd@gmail.com (Hamish) Date: Mon, 21 Feb 2011 01:22:41 +0000 Subject: [sup-devel] [sup-talk] Label Display; Sorting Alphabetically In-Reply-To: <1297863023-sup-4209@plc.intranet.plecavalier.com> References: <1297784079-sup-7440@plc.intranet.plecavalier.com> <1297847031-sup-6835@tilus.net> <1297863023-sup-4209@plc.intranet.plecavalier.com> Message-ID: <1298250926-sup-5020@whisper> Excerpts from Philippe LeCavalier's message of Wed Feb 16 13:33:32 +0000 2011: > > Philippe LeCavalier, 2011-02-15 17:37: > > > Hi All. Just wondering if there has ever been any consideration to > > > sorting labels alphabetically. I'm assuming the way sup displays the > > > labels is purely esthetic's? > > > > I assume you are talking about thread index mode. > No. Any mode really. Even in search mode they're random. No longer! I've published a branch called order_labels that will fix this, both in the various thread index modes, and when editing the labels for a message. Diffs at the end of the email for your viewing pleasure ... I'll merge this into next when I'm a bit more awake - been up a bit long ... Hamish Downer commit 1ae7c0a1e5b20681ea6ecb9a6bf15fffa5f4c0e3 Author: Hamish Downer Date: Sun Feb 20 22:57:47 2011 +0000 Order labels alphabetically in thread index mode diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 11548c7..36d6db3 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -893,7 +893,7 @@ protected [:to_me_color, t.labels.member?(:attachment) ? "@" : " "], [:to_me_color, dp ? ">" : (p ? '+' : " ")], ] + - (t.labels - @hidden_labels).map { |label| [:label_color, "#{label} "] } + + (t.labels - @hidden_labels).sort_by {|x| x.to_s}.map { |label| [:label_color, "#{label} "] } + [ [subj_color, t.subj + (t.subj.empty? ? "" : " ")], [:snippet_color, t.snippet], commit 490e57254c5ee493e8acf4b8358b54e7eb3ab698 Author: Hamish Downer Date: Sun Feb 20 23:22:05 2011 +0000 When editing labels, they are presented in alphabetical order diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 36d6db3..613aa61 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -542,7 +542,7 @@ EOS keepl, modifyl = thread.labels.partition { |t| speciall.member? t } - user_labels = BufferManager.ask_for_labels :label, "Labels for thread: ", modifyl, @hidden_labels + user_labels = BufferManager.ask_for_labels :label, "Labels for thread: ", modifyl.sort_by {|x| x.to_s}, @hidden_labels return unless user_labels thread.labels = Set.new(keepl) + user_labels diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 59705bc..e69de57 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -282,7 +282,7 @@ EOS def edit_labels old_labels = @thread.labels reserved_labels = old_labels.select { |l| LabelManager::RESERVED_LABELS.include? l } - new_labels = BufferManager.ask_for_labels :label, "Labels for thread: ", @thread.labels + new_labels = BufferManager.ask_for_labels :label, "Labels for thread: ", @thread.labels.sort_by {|x| x.to_s} return unless new_labels @thread.labels = Set.new(reserved_labels) + new_labels From dmishd@gmail.com Sun Feb 20 20:29:20 2011 From: dmishd@gmail.com (Hamish) Date: Mon, 21 Feb 2011 01:29:20 +0000 Subject: [sup-devel] [BRANCH] Ctrl-W behaviour Message-ID: <1298251460-sup-4333@whisper> I use Ctrl-W when deleting labels from a thread, and it's been a minor annoyance that this is slightly broken - when there is a space before the cursor, Ctrl-W will just delete the space, and you need to press Ctrl-W a second time to delete the word aswell. This is not how I'm used to it working in vim or on the command line. So I've now had a go at fixing it, in the branch called ctrl_w - just one commit so far, and it took quite a bit of farting around to get this far. I'll review it when it's not the early hours of the morning and merge it into next at that point. Please have a go and see if you can get any strange behaviour - I had some strange behaviour with single-letter labels, but I seem to have fixed that ... Hamish Downer From wmorgan-sup@masanjin.net Mon Feb 21 16:02:28 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 21 Feb 2011 21:02:28 +0000 Subject: [sup-devel] sup-server revisited Message-ID: <1298320404-sup-5972@masanjin.net> Hello Sup fans, As I alluded to in an earlier email to sup-devel, I have been working recently on the ancient goal of splitting Sup functionality out into separate client and server programs. This will have many advantages; in particular it will remove email lock-in by making it possible to have non-Sup clients interact with Sup. I've tried various approaches to this goal at various times, without much success. But with the release of Whistlepig, I have been making a lot of progress in a short amount of time. I wanted to lay out my general plan in this email, so that everyone can follow along and try things out if they feel inclined. I'm focusing on the server component first. My specific goals are: - Encapsulate all storage and indexing logic. - Formalize the notion of labels and state, and the relationship between them, messages, and threads. Currently these relationships are fuzzy in Sup, and things suffer for it. - Precompute threads, so that search requires only moderate effort, instead of the large effort it does now. This will make search much, much faster, at the expense of a little more effort at index time. - Allow concurrent access from multiple clients. - Provide something that is transparent and easy to modify without having to go through an ncurses client. You can find the work in progress here: https://github.com/wmorgan/heliotrope Currently it is not actually a server, but accomplishes many of the goals above. Run bin/email-indexer and then bin/email-searcher to play around with a simple preview of things to come. Stay tuned for more on this. Once the server is in a reasonable state, my goals for the curses client reboot are: - Move to an event-based model rather than the polling + many threads + observable model we have now. Dump all events into one big queue, and block on it. - Have one, and only one, non-main thread, which it to communicate with the server. No more mutex insanity. - Work from the ground up with Ruby 1.9, which means finding the many sources of encoding errors and punishing them. - Require the console and ncurses gems so that i18n works out of the box. - Borrow as much code as possible from the current Sup, because I sure as shit don't want to have to rewrite it all. I haven't started on this at all. So stay tuned, and check out heliotrope if you are so inclined. -- William From roni@cs.utah.edu Mon Feb 21 16:17:04 2011 From: roni@cs.utah.edu (Roni Choudhury) Date: Mon, 21 Feb 2011 14:17:04 -0700 Subject: [sup-devel] [PATCH] eliminated nil-to-integer error when standard library ruby code calls make_tmpname with n=nil Message-ID: <1298322910-sup-1012@medusa> I was getting an error from monkeypatched code that didn't seem to call into the standard library properly... this patch seemed to fix things for me, but I didn't fully understand what was going on here. roni --- lib/sup/message-chunks.rb | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index c275f41..90137da 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -34,7 +34,11 @@ require 'tempfile' ## monkey-patch time: make temp files have the right extension class Tempfile def make_tmpname basename, n - sprintf '%d-%d-%s', $$, n, basename + if n == nil + sprintf '%d-nil-%s', $$, basename + else + sprintf '%d-%d-%s', $$, n, basename + end end end -- 1.7.3.2 From alvherre@alvh.no-ip.org Mon Feb 21 18:26:07 2011 From: alvherre@alvh.no-ip.org (Alvaro Herrera) Date: Mon, 21 Feb 2011 20:26:07 -0300 Subject: [sup-devel] [PATCH] eliminated nil-to-integer error when standard library ruby code calls make_tmpname with n=nil In-Reply-To: <1298322910-sup-1012@medusa> References: <1298322910-sup-1012@medusa> Message-ID: <1298330683-sup-2583@alvh.no-ip.org> Excerpts from Roni Choudhury's message of lun feb 21 18:17:04 -0300 2011: > I was getting an error from monkeypatched code that didn't seem to > call into the standard library properly... this patch seemed to fix > things for me, but I didn't fully understand what was going on here. Seems like the way to really solve the problem would be to figure out what's calling make_tmpname with a nil n, and fix that instead. Is it possible for you to figure that out from the trace? -- ?lvaro Herrera From roni@cs.utah.edu Mon Feb 21 18:54:28 2011 From: roni@cs.utah.edu (Roni Choudhury) Date: Mon, 21 Feb 2011 16:54:28 -0700 Subject: [sup-devel] [PATCH] eliminated nil-to-integer error when standard library ruby code calls make_tmpname with n=nil In-Reply-To: <1298330683-sup-2583@alvh.no-ip.org> References: <1298322910-sup-1012@medusa> <1298330683-sup-2583@alvh.no-ip.org> Message-ID: <1298332384-sup-5832@medusa> Excerpts from Alvaro Herrera's message of 2011-02-21 16:26:07 -0700: > Excerpts from Roni Choudhury's message of lun feb 21 18:17:04 -0300 2011: > > I was getting an error from monkeypatched code that didn't seem to > > call into the standard library properly... this patch seemed to fix > > things for me, but I didn't fully understand what was going on here. > > Seems like the way to really solve the problem would be to figure out > what's calling make_tmpname with a nil n, and fix that instead. Is it > possible for you to figure that out from the trace? > I believe I did track it down, and it looked like a custom use for make_tmpname somewhere... I could figure it out again, but I was also informed in the IRC channel that this fix has already been applied to master under different circumstances. roni From gaudenz@soziologie.ch Tue Feb 22 08:14:38 2011 From: gaudenz@soziologie.ch (Gaudenz Steinlin) Date: Tue, 22 Feb 2011 14:14:38 +0100 Subject: [sup-devel] Need help applying patches In-Reply-To: <1298230750-sup-6418@whisper> References: <1298228733-sup-6115@whisper> <1298230750-sup-6418@whisper> Message-ID: <1298379918-sup-5032@meteor.durcheinandertal.local> Hi Excerpts from Hamish's message of 2011-02-20 20:55:33 +0100: > Excerpts from Hamish's message of Sun Feb 20 19:19:17 +0000 2011: > I ran into some more issues merging this into next - my usual > cherry-pick method led to the same problems as originally, and led to me > being listed as the committer, but I managed to do a git merge which > preserved the commit messages from Gaudenz (although a couple of mine > appear to be repeated). Cherrypicking has basically the same disadvantages as rebasing as it changes the commit ID. So don't cherry pick commits from one branch (e.g. next) into another branch (e.g. gpgme) if you want to merge that branch back into the branch from which you cherry-picked (e.g. you want to merge gpgme back into next). Also don't rebase a branch as soon as you published it somwhere for other to pull from. > > If there is some better way to do this in future, please tell me. I think the correct thing to do is to rebase your development branches against the branch they will eventually be merged into as long as you did not publish them. Rebasing has the nice effect of not complicating the history to much. If you can't rebase then merge, either merge your feature branch into the target branch and then you are free recreate your feature branch and rebase while you are doing development. Or if your changes are not ready yet for merging, you can also merge the target branch into your feature branch to get the latest changes into your feature branch. For testing and day to day usage I usually create a sepeparate branch based of next and merge all my development branches into this branch. This branch is then never published and frequently recreated if something fails... Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: not available URL: From marka@pobox.com Tue Feb 22 08:46:56 2011 From: marka@pobox.com (Mark Alexander) Date: Tue, 22 Feb 2011 08:46:56 -0500 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298320404-sup-5972@masanjin.net> References: <1298320404-sup-5972@masanjin.net> Message-ID: <1298382339-sup-4016@bloovis.org> Excerpts from William Morgan's message of Mon Feb 21 16:02:28 -0500 2011: > You can find the work in progress here: https://github.com/wmorgan/heliotrope I took a very quick look, and it appears to support mbox only at the moment. Presumably maildir will be supported eventually? From nicolas.pouillard@gmail.com Tue Feb 22 09:09:43 2011 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Tue, 22 Feb 2011 06:09:43 -0800 (PST) Subject: [sup-devel] sup-server revisited In-Reply-To: <1298320404-sup-5972@masanjin.net> References: <1298320404-sup-5972@masanjin.net> Message-ID: <4d63c3a7.8389cc0a.52c5.7a5c@mx.google.com> On Mon, 21 Feb 2011 21:02:28 +0000, William Morgan wrote: > Hello Sup fans, [...] > I'm focusing on the server component first. My specific goals are: > > - Encapsulate all storage and indexing logic. > - Formalize the notion of labels and state, and the relationship between them, > messages, and threads. Currently these relationships are fuzzy in Sup, and > things suffer for it. > - Precompute threads, so that search requires only moderate effort, instead of > the large effort it does now. This will make search much, much faster, at the > expense of a little more effort at index time. > - Allow concurrent access from multiple clients. > - Provide something that is transparent and easy to modify without having to go > through an ncurses client. On the server side, and more precisely on the interaction between the two, I would love to see a simple Unix/command/CLI defined for the server. To make myself clear, a bit like the notmuch CLI. This would allow for a greater modularity and reusablity between components. For instance I would like to index my mails with differents backends (disk is cheap), to get a way to compare different tools on real data, when searching emails, and thus allow to debug the different tools. -- Nicolas Pouillard http://nicolaspouillard.fr From dmishd@gmail.com Tue Feb 22 12:01:29 2011 From: dmishd@gmail.com (Hamish) Date: Tue, 22 Feb 2011 17:01:29 +0000 Subject: [sup-devel] [BRANCH] Ctrl-W behaviour In-Reply-To: <1298251460-sup-4333@whisper> References: <1298251460-sup-4333@whisper> Message-ID: <1298393768-sup-7839@whisper> Excerpts from Hamish's message of Mon Feb 21 01:29:20 +0000 2011: > I use Ctrl-W when deleting labels from a thread, and it's been a minor > annoyance that this is slightly broken - when there is a space before > the cursor, Ctrl-W will just delete the space, and you need to press > Ctrl-W a second time to delete the word aswell. This is not how I'm used > to it working in vim or on the command line. I've now merged this into next. I forgot to put the patches in email last night, so I've put the branch diff at the end of this email. Hamish Downer diff --git a/lib/sup/textfield.rb b/lib/sup/textfield.rb index a3d002a..343e450 100644 --- a/lib/sup/textfield.rb +++ b/lib/sup/textfield.rb @@ -120,6 +120,9 @@ class TextField nop Ncurses::Form::REQ_BEG_FIELD when ?\C-w.ord + while action = remove_extra_space + Ncurses::Form.form_driver @form, action + end Ncurses::Form.form_driver @form, Ncurses::Form::REQ_PREV_CHAR Ncurses::Form.form_driver @form, Ncurses::Form::REQ_DEL_WORD when Ncurses::KEY_UP, Ncurses::KEY_DOWN @@ -167,6 +170,40 @@ private end end + def remove_extra_space + return nil unless @field + + Ncurses::Form.form_driver @form, Ncurses::Form::REQ_VALIDATION + x = Ncurses.curx + v = @field.field_buffer(0).gsub(/^\s+|\s+$/, "") + v_index = x - @question.length + + # at start of line + if v_index < 1 + nil + ## cursor <= end of text + elsif v_index < v.length + # is the character before the cursor a space? + if v[v_index-1] == ?\s + # if there is a non-space char under cursor then go back + if v[v_index] != ?\s + Ncurses::Form::REQ_PREV_CHAR + # otherwise delete the space + else + Ncurses::Form::REQ_DEL_PREV + end + else + nil + end + elsif v_index == v.length + # at end of string, with non-space before us + nil + else + # trailing spaces + Ncurses::Form::REQ_PREV_CHAR + end + end + def set_cursed_value v @field.set_field_buffer 0, v end From wmorgan-sup@masanjin.net Tue Feb 22 12:55:23 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 22 Feb 2011 17:55:23 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298382339-sup-4016@bloovis.org> References: <1298320404-sup-5972@masanjin.net> <1298382339-sup-4016@bloovis.org> Message-ID: <1298397161-sup-9723@masanjin.net> Reformatted excerpts from Mark Alexander's message of 2011-02-22: > I took a very quick look, and it appears to support mbox only at the moment. > Presumably maildir will be supported eventually? It's more like: you will give new emails to the server using some tool, and it will store them some way that you don't care about, and you can then use a sup client to view them, or (eventually) an IMAP client, or you can export them from the server and leave Sup entirely. -- William From tero@tilus.net Tue Feb 22 13:44:28 2011 From: tero@tilus.net (Tero Tilus) Date: Tue, 22 Feb 2011 20:44:28 +0200 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298397161-sup-9723@masanjin.net> References: <1298320404-sup-5972@masanjin.net> <1298382339-sup-4016@bloovis.org> <1298397161-sup-9723@masanjin.net> Message-ID: <1298399731-sup-2646@tilus.net> William Morgan, 2011-02-22 19:55: > It's more like: you will give new emails to the server using some > tool You mean something like configuring your MDA to do a pipe-deliver to "sup-indexer"? > you can then use a sup client to view them, or (eventually) an IMAP > client Does this mean you intend to implement IMAP capability to sup-server? -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Tue Feb 22 14:00:01 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 22 Feb 2011 19:00:01 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298399731-sup-2646@tilus.net> References: <1298320404-sup-5972@masanjin.net> <1298382339-sup-4016@bloovis.org> <1298397161-sup-9723@masanjin.net> <1298399731-sup-2646@tilus.net> Message-ID: <1298401081-sup-6560@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2011-02-22: > You mean something like configuring your MDA to do a pipe-deliver to > "sup-indexer"? Yes. > Does this mean you intend to implement IMAP capability to sup-server? Yeah. I'm not really looking forward to actually doing it, but I would like to have an IMAP compatibility layer on the server. That goes a long way to eliminating what I think is the biggest blocker for Sup adoption, which is lockin. -- William From tero@tilus.net Tue Feb 22 15:17:04 2011 From: tero@tilus.net (Tero Tilus) Date: Tue, 22 Feb 2011 22:17:04 +0200 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298320404-sup-5972@masanjin.net> References: <1298320404-sup-5972@masanjin.net> Message-ID: <1298400274-sup-4941@tilus.net> William Morgan, 2011-02-21 23:02: > I have been making a lot of > progress in a short amount of time. Cool! I'm thrilled. \o/ > - Precompute threads, so that search requires only moderate effort, > instead of the large effort it does now. This will make search > much, much faster, at the expense of a little more effort at index > time. I guess this offers the possibility to add threading to "external state" of messages, together with labels. I'd do a whole a lot of more prune'n'crafting with my threads if there only was more comfortable interface to doing it (admit it, been too lazy to implement it in sup). Do you have considerations wrt to programmatical thread browsing and editing API? Something I've thought of, on the top of my head. first_msg |-- second_msg |-- third_msg | `-- fifth_msg `-- fourth_msg sixth_msg `-- seventh_msg thread = Thread.find :second subthread = thread.find { |msg| msg == :third_msg }.prune! Message.find(:sixth_msg).craft! subthread first |-- second `-- fourth sixth |-- third | `-- fifth `-- seventh > - Allow concurrent access from multiple clients. Since the first post on sup-server I've been nurturing the idea of "fat" sup-client for maemo/meego. > - Borrow as much code as possible from the current Sup, because I > sure as shit don't want to have to rewrite it all. Would it be time to go for https://github.com/mikel/mail now? It would be supported and actively developed and I really like the API. As a downside, depending on activesupport pulls in a whole a lot of fluff and using treetop may suggest that parsing might hog a little more cpu and memory than is absolutely necessary. Who would give us bindings to GMime and wrap it inside Mail API... -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From wmorgan-sup@masanjin.net Tue Feb 22 16:29:07 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 22 Feb 2011 21:29:07 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298400274-sup-4941@tilus.net> References: <1298320404-sup-5972@masanjin.net> <1298400274-sup-4941@tilus.net> Message-ID: <1298409714-sup-1926@masanjin.net> Reformatted excerpts from Tero Tilus's message of 2011-02-22: > I guess this offers the possibility to add threading to "external state" > of messages, together with labels. I'd do a whole a lot of more > prune'n'crafting with my threads if there only was more comfortable > interface to doing it (admit it, been too lazy to implement it in sup). Not quite sure I follow, but the intention is certainly to allow clients to create and break threads and to present labels as per-thread, rather than per-message, data. > Do you have considerations wrt to programmatical thread browsing and > editing API? I suspect won't get into that level of detail. The API will be more along the lines of "give me thread 6" and you'll get a tree of message ids back, and on the client side you can represent that however you like. Unless there's a compelling case for handling portions of threads at the API level. > > - Allow concurrent access from multiple clients. > > Since the first post on sup-server I've been nurturing the idea of "fat" > sup-client for maemo/meego. That would be great. I would like an Android client while you're at it. :) > Would it be time to go for https://github.com/mikel/mail now? It would be > supported and actively developed and I really like the API. As a > downside, depending on activesupport pulls in a whole a lot of fluff and > using treetop may suggest that parsing might hog a little more cpu and > memory than is absolutely necessary. I looked at it, but the dependency on activesupport is a dealbreaker for me. There's no way I would pull that pile of Rails shit into Sup. RMail is not great and I don't like using it, but it really is the best thing I've found so far. I think I have whipped it into shape pretty well in heliotrope. > Who would give us bindings to GMime and wrap it inside Mail API... I would use GMime bindings in a heartbeat. -- William From nicolas.pouillard@gmail.com Wed Feb 23 04:48:12 2011 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Wed, 23 Feb 2011 01:48:12 -0800 (PST) Subject: [sup-devel] sup-server revisited In-Reply-To: <1298409714-sup-1926@masanjin.net> References: <1298320404-sup-5972@masanjin.net> <1298400274-sup-4941@tilus.net> <1298409714-sup-1926@masanjin.net> Message-ID: <4d64d7dc.5989cc0a.4550.ffffb543@mx.google.com> On Tue, 22 Feb 2011 21:29:07 +0000, William Morgan wrote: > Reformatted excerpts from Tero Tilus's message of 2011-02-22: > > I guess this offers the possibility to add threading to "external state" > > of messages, together with labels. I'd do a whole a lot of more > > prune'n'crafting with my threads if there only was more comfortable > > interface to doing it (admit it, been too lazy to implement it in sup). > > Not quite sure I follow, but the intention is certainly to allow clients to > create and break threads and to present labels as per-thread, rather than > per-message, data. I would not go for "labels on threads" only, here is a list of labels that are more message based than thread based: unread, starred, draft, sent, attachment. And while it would make sense to have special cases for those this also prevents from user defined per message labels. -- Nicolas Pouillard http://nicolaspouillard.fr From alvherre@alvh.no-ip.org Wed Feb 23 08:19:15 2011 From: alvherre@alvh.no-ip.org (Alvaro Herrera) Date: Wed, 23 Feb 2011 10:19:15 -0300 Subject: [sup-devel] [BRANCH] Ctrl-W behaviour In-Reply-To: <1298393768-sup-7839@whisper> References: <1298251460-sup-4333@whisper> <1298393768-sup-7839@whisper> Message-ID: <1298467110-sup-4536@alvh.no-ip.org> Excerpts from Hamish's message of mar feb 22 14:01:29 -0300 2011: > Excerpts from Hamish's message of Mon Feb 21 01:29:20 +0000 2011: > > I use Ctrl-W when deleting labels from a thread, and it's been a minor > > annoyance that this is slightly broken - when there is a space before > > the cursor, Ctrl-W will just delete the space, and you need to press > > Ctrl-W a second time to delete the word aswell. This is not how I'm used > > to it working in vim or on the command line. > > I've now merged this into next. I forgot to put the patches in email > last night, so I've put the branch diff at the end of this email. I've been using this and it works great. I was annoyed by the original behavior too. -- ?lvaro Herrera From wmorgan-sup@masanjin.net Wed Feb 23 13:43:34 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 23 Feb 2011 18:43:34 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <4d64d7dc.5989cc0a.4550.ffffb543@mx.google.com> References: <1298320404-sup-5972@masanjin.net> <1298400274-sup-4941@tilus.net> <1298409714-sup-1926@masanjin.net> <4d64d7dc.5989cc0a.4550.ffffb543@mx.google.com> Message-ID: <1298485426-sup-5530@masanjin.net> Reformatted excerpts from Nicolas Pouillard's message of 2011-02-23: > I would not go for "labels on threads" only, here is a list of labels that > are more message based than thread based: unread, starred, draft, sent, > attachment. And while it would make sense to have special cases for those > this also prevents from user defined per message labels. One of the major goals of Heliotrope is to formalize this type of thing and to implement it correctly. Here's the model: - Individual messages have "state", including unread, starred, and all the other things you've mentioned. - Threads have "labels", which are user-defined. - Message state is mapped onto thread labels by taking the union of the states of all the messages in a thread. E.g. if one message is unread, the entire thread has the unread label. - Sup maintains that mapping for you. - The user can set (some of) the state of a particular message. - The user can set the labels for a thread, but can't create labels that have the same name as a message state. - The labels of a thread match all messages in a thread at search time. Sup conflates these things, maintains labels on messages only, and does some UI stuff to make it seem like they apply to threads. It's easy to find corner cases where you get weird behavior. -- William From alvherre@alvh.no-ip.org Wed Feb 23 13:53:23 2011 From: alvherre@alvh.no-ip.org (Alvaro Herrera) Date: Wed, 23 Feb 2011 15:53:23 -0300 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298485426-sup-5530@masanjin.net> References: <1298320404-sup-5972@masanjin.net> <1298400274-sup-4941@tilus.net> <1298409714-sup-1926@masanjin.net> <4d64d7dc.5989cc0a.4550.ffffb543@mx.google.com> <1298485426-sup-5530@masanjin.net> Message-ID: <1298486753-sup-2845@alvh.no-ip.org> Excerpts from William Morgan's message of mi? feb 23 15:43:34 -0300 2011: > One of the major goals of Heliotrope is to formalize this type of thing and to > implement it correctly. Here's the model: > > - Individual messages have "state", including unread, starred, and all the > other things you've mentioned. > - Threads have "labels", which are user-defined. > - Message state is mapped onto thread labels by taking the union of the states > of all the messages in a thread. E.g. if one message is unread, the entire > thread has the unread label. > - Sup maintains that mapping for you. > - The user can set (some of) the state of a particular message. > - The user can set the labels for a thread, but can't create labels that have > the same name as a message state. > - The labels of a thread match all messages in a thread at search time. I like this, except the part that thread_labels = union(states). It doesn't work correctly for "attachment" for example: it makes it look like the whole thread "has attachments" which doesn't make sense. The user really needs to have a way of telling messages that really have attachments from ones that don't. Also, you said upthread that Heliotrope was going to provide ways to break threads and form new ones from pieces. I badly want this feature :-) (I haven't checked Heliotrope out yet). > Sup conflates these things, maintains labels on messages only, and does some UI > stuff to make it seem like they apply to threads. It's easy to find corner > cases where you get weird behavior. Agreed. Someone mentioned some weeks ago that "undo" badly messed up labels that you're now separating as "state" (again, attachment). Seems like the current proposal fixes that problem. -- ?lvaro Herrera From wmorgan-sup@masanjin.net Wed Feb 23 16:08:07 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 23 Feb 2011 21:08:07 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298486753-sup-2845@alvh.no-ip.org> References: <1298320404-sup-5972@masanjin.net> <1298400274-sup-4941@tilus.net> <1298409714-sup-1926@masanjin.net> <4d64d7dc.5989cc0a.4550.ffffb543@mx.google.com> <1298485426-sup-5530@masanjin.net> <1298486753-sup-2845@alvh.no-ip.org> Message-ID: <1298495002-sup-1617@masanjin.net> Reformatted excerpts from Alvaro Herrera's message of 2011-02-23: > I like this, except the part that thread_labels = union(states). It > doesn't work correctly for "attachment" for example: it makes it look > like the whole thread "has attachments" which doesn't make sense. The thread has the label "attachment", but when you look at the individual messages inside of it, you see which ones actually have the attachment state. I think this makes sense. > Also, you said upthread that Heliotrope was going to provide ways to > break threads and form new ones from pieces. I badly want this > feature :-) (I haven't checked Heliotrope out yet). Yes, this will definitely be there. -- William From alvherre@alvh.no-ip.org Wed Feb 23 16:30:26 2011 From: alvherre@alvh.no-ip.org (Alvaro Herrera) Date: Wed, 23 Feb 2011 18:30:26 -0300 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298495002-sup-1617@masanjin.net> References: <1298320404-sup-5972@masanjin.net> <1298400274-sup-4941@tilus.net> <1298409714-sup-1926@masanjin.net> <4d64d7dc.5989cc0a.4550.ffffb543@mx.google.com> <1298485426-sup-5530@masanjin.net> <1298486753-sup-2845@alvh.no-ip.org> <1298495002-sup-1617@masanjin.net> Message-ID: <1298496576-sup-8044@alvh.no-ip.org> Excerpts from William Morgan's message of mi? feb 23 18:08:07 -0300 2011: > Reformatted excerpts from Alvaro Herrera's message of 2011-02-23: > > I like this, except the part that thread_labels = union(states). It > > doesn't work correctly for "attachment" for example: it makes it look > > like the whole thread "has attachments" which doesn't make sense. > > The thread has the label "attachment", but when you look at the > individual messages inside of it, you see which ones actually have the > attachment state. I think this makes sense. Yes, this sounds good to me. > > Also, you said upthread that Heliotrope was going to provide ways to > > break threads and form new ones from pieces. I badly want this > > feature :-) (I haven't checked Heliotrope out yet). > > Yes, this will definitely be there. Great. -- ?lvaro Herrera From dmishd@gmail.com Sat Feb 26 14:15:40 2011 From: dmishd@gmail.com (Hamish) Date: Sat, 26 Feb 2011 19:15:40 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298320404-sup-5972@masanjin.net> References: <1298320404-sup-5972@masanjin.net> Message-ID: <1298744738-sup-631@whisper> Excerpts from William Morgan's message of Mon Feb 21 21:02:28 +0000 2011: > As I alluded to in an earlier email to sup-devel, I have been working recently > on the ancient goal of splitting Sup functionality out into separate client and > server programs. This will have many advantages; in particular it will remove > email lock-in by making it possible to have non-Sup clients interact with Sup. Excellent :) I look forward to an android client. I will definitely contribute to it, and I *might* even get it started. Or might not ... > You can find the work in progress here: https://github.com/wmorgan/heliotrope > Currently it is not actually a server, but accomplishes many of the goals > above. Run bin/email-indexer and then bin/email-searcher to play around with > a simple preview of things to come. Stay tuned for more on this. I've had a quick look at heliotrope (and whistlepig) and not got very far: $ ruby -I lib bin/email-indexer ~/path/to/mbox /var/lib/gems/1.8/gems/ffi-1.0.6/lib/ffi/library.rb:93:in `ffi_libraries': no library specified (LoadError) from /var/lib/gems/1.8/gems/ffi-1.0.6/lib/ffi/library.rb:129:in `attach_function' from /var/lib/gems/1.8/gems/oklahoma_mixer-0.4.0/lib/oklahoma_mixer/utilities.rb:39:in `func' from /var/lib/gems/1.8/gems/oklahoma_mixer-0.4.0/lib/oklahoma_mixer/utilities.rb:214 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /var/lib/gems/1.8/gems/oklahoma_mixer-0.4.0/lib/oklahoma_mixer/extensible_string/c.rb:1 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /var/lib/gems/1.8/gems/oklahoma_mixer-0.4.0/lib/oklahoma_mixer/extensible_string.rb:1 from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' from /usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /var/lib/gems/1.8/gems/oklahoma_mixer-0.4.0/lib/oklahoma_mixer/hash_database.rb:2 from /var/lib/gems/1.8/gems/oklahoma_mixer-0.4.0/lib/oklahoma_mixer.rb:11:in `open' from ./lib/heliotrope/store.rb:40:in `initialize' from bin/email-indexer:20:in `new' from bin/email-indexer:20 $ ruby --version ruby 1.8.7 (2010-06-23 patchlevel 299) [x86_64-linux] Am I missing something? It appears that the oklahoma_mixer gem is broken. I installed it though rubygems. Any ideas? I also wasn't sure how to build and run whistlepig from source. I'm not familiar with the extconf stuff. I can type make happily enough, but it appears more steps are required. If someone shows me the way I'll happily contribute an improved README for anyone else who wants to use it. (I installed whistlepig from the gem in order to try out heliotrope, in case you're wondering). Hamish From dmishd@gmail.com Sat Feb 26 14:23:13 2011 From: dmishd@gmail.com (Hamish) Date: Sat, 26 Feb 2011 19:23:13 +0000 Subject: [sup-devel] editing messages outside of sup In-Reply-To: <1298239068-sup-6985@whisper> References: <1298239068-sup-6985@whisper> Message-ID: <1298747943-sup-9749@whisper> Excerpts from Hamish's message of Sun Feb 20 22:02:54 +0000 2011: > For the moment this work is in the async_message_edit branch. If no one > shouts about this being a terrible idea then I'll merge it into next > within a week. No one shouted, so I've merged it into next. At the end of the email is the diff of the async_message_edit branch against where I started it. Hamish Downer diff --git a/lib/sup.rb b/lib/sup.rb index 74eb950..213823c 100644 --- a/lib/sup.rb +++ b/lib/sup.rb @@ -370,6 +370,7 @@ require "sup/horizontal-selector" require "sup/modes/line-cursor-mode" require "sup/modes/help-mode" require "sup/modes/edit-message-mode" +require "sup/modes/edit-message-async-mode" require "sup/modes/compose-mode" require "sup/modes/resume-mode" require "sup/modes/forward-mode" diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb index 25ea132..444589a 100644 --- a/lib/sup/buffer.rb +++ b/lib/sup/buffer.rb @@ -73,7 +73,7 @@ class InputSequenceAborted < StandardError; end class Buffer attr_reader :mode, :x, :y, :width, :height, :title, :atime bool_reader :dirty, :system - bool_accessor :force_to_top + bool_accessor :force_to_top, :hidden def initialize window, mode, width, height, opts={} @w = window @@ -82,6 +82,7 @@ class Buffer @focus = false @title = opts[:title] || "" @force_to_top = opts[:force_to_top] || false + @hidden = opts[:hidden] || false @x, @y, @width, @height = 0, 0, width, height @atime = Time.at 0 @system = opts[:system] || false @@ -265,7 +266,7 @@ EOS end def rollable_buffers - @buffers.select { |b| !b.system? || @buffers.last == b } + @buffers.select { |b| !(b.system? || b.hidden?) || @buffers.last == b } end def handle_input c diff --git a/lib/sup/modes/buffer-list-mode.rb b/lib/sup/modes/buffer-list-mode.rb index 40f2e76..08bb604 100644 --- a/lib/sup/modes/buffer-list-mode.rb +++ b/lib/sup/modes/buffer-list-mode.rb @@ -28,7 +28,7 @@ protected end def regen_text - @bufs = BufferManager.buffers.reject { |name, buf| buf.mode == self }.sort_by { |name, buf| buf.atime }.reverse + @bufs = BufferManager.buffers.reject { |name, buf| buf.mode == self || buf.hidden? }.sort_by { |name, buf| buf.atime }.reverse width = @bufs.max_of { |name, buf| buf.mode.name.length } @text = @bufs.map do |name, buf| base_color = buf.system? ? :system_buf_color : :regular_buf_color diff --git a/lib/sup/modes/edit-message-async-mode.rb b/lib/sup/modes/edit-message-async-mode.rb new file mode 100644 index 0000000..385ba6a --- /dev/null +++ b/lib/sup/modes/edit-message-async-mode.rb @@ -0,0 +1,89 @@ +module Redwood + +class EditMessageAsyncMode < LineCursorMode + + register_keymap do |k| + k.add :edit_finished, "Finished editing message", 'E' + k.add :path_to_clipboard, "Copy file path to the clipboard", :enter + end + + def initialize parent_edit_mode, file_path, msg_subject + @parent_edit_mode = parent_edit_mode + @file_path = file_path + @orig_mtime = File.mtime @file_path + + @text = ["ASYNC MESSAGE EDIT", + "", "Your message with subject:", msg_subject, "is saved in a file:", "", @file_path, "", + "You can edit your message in the editor of your choice and continue to", + "use sup while you edit your message.", "", + "Press to have the file path copied to the clipboard.", "", + "When you have finished editing, select this buffer and press 'E'.",] + super() + end + + def lines; @text.length end + + def [] i + @text[i] + end + + def killable? + if file_being_edited? + if !BufferManager.ask_yes_or_no("It appears the file is still being edited. Are you sure?") + return false + end + end + + @parent_edit_mode.edit_message_async_resume true + true + end + + def unsaved? + !file_being_edited? && !file_has_been_edited? + end + +protected + + def edit_finished + if file_being_edited? + if !BufferManager.ask_yes_or_no("It appears the file is still being edited. Are you sure?") + return false + end + end + + @parent_edit_mode.edit_message_async_resume + BufferManager.kill_buffer buffer + true + end + + def path_to_clipboard + if system("which xsel > /dev/null 2>&1") + # linux/unix path + IO.popen('xsel --clipboard --input', 'r+') { |clipboard| clipboard.puts(@file_path) } + BufferManager.flash "Copied file path to clipboard." + elsif system("which pbcopy > /dev/null 2>&1") + # mac path + IO.popen('pbcopy', 'r+') { |clipboard| clipboard.puts(@file_path) } + BufferManager.flash "Copied file path to clipboard." + else + BufferManager.flash "No way to copy text to clipboard - try installing xsel." + end + end + + def file_being_edited? + # check for common editor lock files + vim_lock_file = File.join(File.dirname(@file_path), '.'+File.basename(@file_path)+'.swp') + emacs_lock_file = File.join(File.dirname(@file_path), '.#'+File.basename(@file_path)) + + return true if File.exist?(vim_lock_file) || File.exist?(emacs_lock_file) + + false + end + + def file_has_been_edited? + File.mtime(@file_path) > @orig_mtime + end + +end + +end diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb index 734a879..01f3653 100644 --- a/lib/sup/modes/edit-message-mode.rb +++ b/lib/sup/modes/edit-message-mode.rb @@ -80,6 +80,7 @@ EOS k.add :edit_cc, "Edit Cc:", 'c' k.add :edit_subject, "Edit Subject", 's' k.add :edit_message, "Edit message", :enter + k.add :edit_message_async, "Edit message asynchronously", 'E' k.add :save_as_draft, "Save as draft", 'P' k.add :attach_file, "Attach a file", 'a' k.add :delete_attachment, "Delete an attachment", 'd' @@ -184,7 +185,51 @@ EOS @edited end + def edit_message_async + @file = Tempfile.new ["sup.#{self.class.name.gsub(/.*::/, '').camel_to_hyphy}", ".eml"] + @file.puts format_headers(@header - NON_EDITABLE_HEADERS).first + @file.puts + @file.puts @body.join("\n") + @file.close + + @mtime = File.mtime @file.path + + # put up buffer saying you can now edit the message in another + # terminal or app, and continue to use sup in the meantime. + subject = @header["Subject"] || "" + @async_mode = EditMessageAsyncMode.new self, @file.path, subject + BufferManager.spawn "Waiting for message \"#{subject}\" to be finished", @async_mode + + # hide ourselves, and wait for signal to resume from async mode ... + buffer.hidden = true + end + + def edit_message_async_resume being_killed=false + buffer.hidden = false + @async_mode = nil + BufferManager.raise_to_front buffer if !being_killed + + @edited = true if File.mtime(@file.path) > @mtime + + header, @body = parse_file @file.path + @header = header - NON_EDITABLE_HEADERS + handle_new_text @header, @body + update + + true + end + def killable? + if !@async_mode.nil? + return false if !@async_mode.killable? + if File.mtime(@file.path) > @mtime + @edited = true + header, @body = parse_file @file.path + @header = header - NON_EDITABLE_HEADERS + handle_new_text @header, @body + update + end + end !edited? || BufferManager.ask_yes_or_no("Discard message?") end From wmorgan-sup@masanjin.net Sat Feb 26 17:04:13 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Feb 2011 22:04:13 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298744738-sup-631@whisper> References: <1298320404-sup-5972@masanjin.net> <1298744738-sup-631@whisper> Message-ID: <1298757625-sup-9756@masanjin.net> Reformatted excerpts from Hamish's message of 2011-02-26: > /var/lib/gems/1.8/gems/ffi-1.0.6/lib/ffi/library.rb:93:in `ffi_libraries': no library specified (LoadError) > from /var/lib/gems/1.8/gems/ffi-1.0.6/lib/ffi/library.rb:129:in `attach_function' You need to install your system's TokyoTyrant / TokyoCabinet libraries. The OklahomaMixer gem is a ffi wrapper on those. Then it should work. > I also wasn't sure how to build and run whistlepig from source. `make rubygem` and then `gem install ruby/pkg/*.gem` will do it, but installing the public gem should be sufficient. I'm about to push some changes to Heliotrope that should make it easy to get started with. I will announce here. -- William From wmorgan-sup@masanjin.net Sat Feb 26 18:15:50 2011 From: wmorgan-sup@masanjin.net (William Morgan) Date: Sat, 26 Feb 2011 23:15:50 +0000 Subject: [sup-devel] sup-server revisited In-Reply-To: <1298757625-sup-9756@masanjin.net> References: <1298320404-sup-5972@masanjin.net> <1298744738-sup-631@whisper> <1298757625-sup-9756@masanjin.net> Message-ID: <1298762120-sup-1118@masanjin.net> Reformatted excerpts from William Morgan's message of 2011-02-26: > I'm about to push some changes to Heliotrope that should make it easy to get > started with. I will announce here. Check out the README and see if the instructions work for you. -- William From alvherre@alvh.no-ip.org Sat Feb 26 20:15:31 2011 From: alvherre@alvh.no-ip.org (Alvaro Herrera) Date: Sat, 26 Feb 2011 22:15:31 -0300 Subject: [sup-devel] editing messages outside of sup In-Reply-To: <1298747943-sup-9749@whisper> References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper> Message-ID: <1298768518-sup-4041@alvh.no-ip.org> Excerpts from Hamish's message of s?b feb 26 16:23:13 -0300 2011: > Excerpts from Hamish's message of Sun Feb 20 22:02:54 +0000 2011: > > For the moment this work is in the async_message_edit branch. If no one > > shouts about this being a terrible idea then I'll merge it into next > > within a week. > > No one shouted, so I've merged it into next. At the end of the email is > the diff of the async_message_edit branch against where I started it. I like this general idea very much. The bit about having to copy/paste the file name is a bit of a pain, though. I gave it a spin, and excepting that one infelicity, I found it pretty neat. I noticed no problems at all. The way I envision this working is with a "vim --servername foo" window being open at the time sup starts, and then "vim --remote" would open the file in that server each time I edit an email. Most likely, the command to edit a file should be specified via a hook. Thanks for your work on this. -- ?lvaro Herrera From roni@cs.utah.edu Sat Feb 26 21:51:05 2011 From: roni@cs.utah.edu (Roni Choudhury) Date: Sat, 26 Feb 2011 19:51:05 -0700 Subject: [sup-devel] editing messages outside of sup In-Reply-To: <1298768518-sup-4041@alvh.no-ip.org> References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper> <1298768518-sup-4041@alvh.no-ip.org> Message-ID: <1298774629-sup-4062@medusa> Excerpts from Alvaro Herrera's message of 2011-02-26 18:15:31 -0700: > Excerpts from Hamish's message of s?b feb 26 16:23:13 -0300 2011: > > Excerpts from Hamish's message of Sun Feb 20 22:02:54 +0000 2011: > > > For the moment this work is in the async_message_edit branch. If no one > > > shouts about this being a terrible idea then I'll merge it into next > > > within a week. > > > > No one shouted, so I've merged it into next. At the end of the email is > > the diff of the async_message_edit branch against where I started it. > > I like this general idea very much. The bit about having to copy/paste > the file name is a bit of a pain, though. I gave it a spin, and > excepting that one infelicity, I found it pretty neat. I noticed no > problems at all. > > The way I envision this working is with a "vim --servername foo" window > being open at the time sup starts, and then "vim --remote" would open > the file in that server each time I edit an email. Most likely, the > command to edit a file should be specified via a hook. > > Thanks for your work on this. > Hamish, definitely thank you for doing something about this. I actually had a general question about this problem a while back - if it is possible to edit the message independently via the approach you took in this patch, why can't the editor be fired up in a "nonblocking" kind of mode in the first place? Something like a fork()/exec() to start the editor, and then handling SIGCHLD rather than calling a variant of wait() immediately. The SIGCHLD handling could check the return code from the editor, and then update the message sending buffer appropriately. I promise, this is not to denigrate on your work at all... I have just always been confused what would be wrong with the general approach I just described. roni From sup@zevv.nl Sun Feb 27 10:31:14 2011 From: sup@zevv.nl (Ico Doornekamp) Date: Sun, 27 Feb 2011 16:31:14 +0100 Subject: [sup-devel] editing messages outside of sup In-Reply-To: <1298774629-sup-4062@medusa> References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper> <1298768518-sup-4041@alvh.no-ip.org> <1298774629-sup-4062@medusa> Message-ID: <1298819507-sup-8138@pruts.nl> * On Sun Feb 27 03:51:05 +0100 2011, Roni Choudhury wrote: > Excerpts from Alvaro Herrera's message of 2011-02-26 18:15:31 -0700: > > Excerpts from Hamish's message of s?b feb 26 16:23:13 -0300 2011: > > > Excerpts from Hamish's message of Sun Feb 20 22:02:54 +0000 2011: > > > > For the moment this work is in the async_message_edit branch. If no one > > > > shouts about this being a terrible idea then I'll merge it into next > > > > within a week. > > > > > > No one shouted, so I've merged it into next. At the end of the email is > > > the diff of the async_message_edit branch against where I started it. > > Hamish, definitely thank you for doing something about this. I > actually had a general question about this problem a while back - if > it is possible to edit the message independently via the approach you > took in this patch, why can't the editor be fired up in a > "nonblocking" kind of mode in the first place? Something like a > fork()/exec() to start the editor, and then handling SIGCHLD rather > than calling a variant of wait() immediately. The SIGCHLD handling > could check the return code from the editor, and then update the > message sending buffer appropriately. But in what tty should the forked editor run then? I guess the above idea would work for spawning an editor under X, but can not be used when running on a (remote) console. I guess the 'vim --remote' solution would be feasable, bug I guess this is not simple enough to add as an out-of-the-box solution. I guess one solution could be to add master/slave pty support to sup, allowing one or more regular console based editors instances (vim, nano, joe, etc) inside sup, passing all keyboard input to the slave process except for a few (configurable) keystrokes for switching sup buffers. (I'd make an exception for running emacs inside sup, because emacs users would probably prefer running their own lisp version of sup inside emacs instead of emacs in sup) A quick proto would probably be not very hard to do, it is mostly a matter of passing keyboard commands from the master sup to the editor running in the slave pty, passing pty output back to the terminal and handling the proper signals and ioctls() for keeping track of the window size. This will work as long as all terminal control characters are simple passed transparantly from the slave editor to the terminal, but things quickly get nasty when you would want to do the terminal emulation inside sup, and this is probably necessary for properly handling screen redrawing and resizing. It's hard to guess how much work this would really be. Part of me says it should not be too hard to find a simple terminal emulation implentation in another piece of (L)GPL software and simply steal as much as possible. Another part of my fears one would likely end up reimplementing at least half of GNU screen, which is probably not a very pleasant adventure. Ico -- :wq ^X^Cy^K^X^C^C^C^C From damien.leone@fensalir.fr Sun Feb 27 11:58:46 2011 From: damien.leone@fensalir.fr (Damien Leone) Date: Sun, 27 Feb 2011 17:58:46 +0100 Subject: [sup-devel] [PATCH] line-cursor-mode: Add an option to disable automatic threads loading when scrolling down for slow CPUs Message-ID: <1298825716-sup-3818@mailer> Sup guys, I run Sup on a Pogoplug-like device which has a slow CPU and I'm always annoyed when I scroll down to reach an entry and then everything stalls because some more threads are loading. This patch adds an option to disable this behavior. Cheers, -- Damien Leone Web: http://dleone.fensalir.fr/ GPG: 0x82EB4DDF -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-line-cursor-mode-Add-an-option-to-disable-automatic-.patch Type: application/octet-stream Size: 1249 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 damien.leone@fensalir.fr Sun Feb 27 12:09:43 2011 From: damien.leone@fensalir.fr (Damien Leone) Date: Sun, 27 Feb 2011 18:09:43 +0100 Subject: [sup-devel] [PATCH] Mark the thread as read after the ThreadViewMode has been instancied and displayed Message-ID: <1298826320-sup-8596@mailer> Sup guys, The current behavior is that when opening an unread thread, the unread label is removed at the instanciation of the ThreadViewMode, thus it makes the 'N' indicator useless. Even if new messages are automatically expanded it can be confusing when you open some old message in the same thread, at the end you might not remember which ones are new. This patch delays the moment when the unread label is removed so when opening a thread you know exactly what are the new messages thanks to that 'N' indicator. Cheers, -- Damien Leone Web: http://dleone.fensalir.fr/ GPG: 0x82EB4DDF -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Mark-the-thread-as-read-after-the-ThreadViewMode-has.patch Type: application/octet-stream Size: 1432 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 dmishd@gmail.com Sun Feb 27 12:20:55 2011 From: dmishd@gmail.com (Hamish) Date: Sun, 27 Feb 2011 17:20:55 +0000 Subject: [sup-devel] editing messages outside of sup In-Reply-To: <1298819507-sup-8138@pruts.nl> References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper> <1298768518-sup-4041@alvh.no-ip.org> <1298774629-sup-4062@medusa> <1298819507-sup-8138@pruts.nl> Message-ID: <1298826314-sup-276@whisper> Excerpts from Ico Doornekamp's message of Sun Feb 27 15:31:14 +0000 2011: > > Hamish, definitely thank you for doing something about this. I > > actually had a general question about this problem a while back - if > > it is possible to edit the message independently via the approach you > > took in this patch, why can't the editor be fired up in a > > "nonblocking" kind of mode in the first place? Something like a > > fork()/exec() to start the editor, and then handling SIGCHLD rather > > than calling a variant of wait() immediately. The SIGCHLD handling > > could check the return code from the editor, and then update the > > message sending buffer appropriately. > > But in what tty should the forked editor run then? I guess the above > idea would work for spawning an editor under X, but can not be used when > running on a (remote) console. I guess the 'vim --remote' solution would > be feasable, bug I guess this is not simple enough to add as an > out-of-the-box solution. Now I've got the basic stuff working, I'd be up for adding to it. Probably the best way would be to use a hook that could fire up something using a fork()/exec(). The way I'd see this working is that it would only be useful on a machine running X (or Wayland, or whatever the Mac GUI is called). If you have ssh'ed to a remote machine then I don't think there is a good way to manage this automatically without turning sup into screen (which I think would be a bad idea), though I wouldn't want to get in the way of imaginative hooks of course. Basically I would say that if you want to edit your message outside of sup on a remote machine (via ssh) you should use screen/tmux in split mode, or have 2 terminals that ssh to the same server, or something like that. Opening the file tends to involve typing: $ vim /tmp/sup and then pressing tab, so I don't think it's too onerous. And if you turned on X forwarding and had xsel installed you could just press (to copy the path to the clipboard) and then paste that into the other terminal. Anyway, I'll have a think about how best to do a hook for this. I might end up doing a blocking and a non-blocking variant - the blocking variant could drop you straight back to reply-mode when it detects the editor has exited, while the non-blocking mode would make it simpler to write a hook, but you would have to manually exit async mode once editing was done. Hamish From sup@zevv.nl Sun Feb 27 14:44:15 2011 From: sup@zevv.nl (Ico Doornekamp) Date: Sun, 27 Feb 2011 20:44:15 +0100 Subject: [sup-devel] editing messages outside of sup In-Reply-To: <1298826314-sup-276@whisper> References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper> <1298768518-sup-4041@alvh.no-ip.org> <1298774629-sup-4062@medusa> <1298819507-sup-8138@pruts.nl> <1298826314-sup-276@whisper> Message-ID: <1298833983-sup-4830@pruts.nl> * On Sun Feb 27 18:20:55 +0100 2011, Hamish wrote: > Excerpts from Ico Doornekamp's message of Sun Feb 27 15:31:14 +0000 2011: > > > Hamish, definitely thank you for doing something about this. I > > > actually had a general question about this problem a while back - if > > > it is possible to edit the message independently via the approach you > > > took in this patch, why can't the editor be fired up in a > > > "nonblocking" kind of mode in the first place? Something like a > > > fork()/exec() to start the editor, and then handling SIGCHLD rather > > > than calling a variant of wait() immediately. The SIGCHLD handling > > > could check the return code from the editor, and then update the > > > message sending buffer appropriately. > > > > But in what tty should the forked editor run then? I guess the above > > idea would work for spawning an editor under X, but can not be used when > > running on a (remote) console. I guess the 'vim --remote' solution would > > be feasable, bug I guess this is not simple enough to add as an > > out-of-the-box solution. > > If you have ssh'ed to a remote machine then I don't think there is a > good way to manage this automatically without turning sup into screen > (which I think would be a bad idea), though I wouldn't want to get in > the way of imaginative hooks of course. I've just hooked up a few lines of code (standalone, not part of sup) that forks two editors (one joe, one vim) in ptys and handling both terminal outputs with select(), allowing me to 'switch' between processes on-the-fly using a magic keystroke. Redrawing is forced before 'switching' to a process by doing a TIOCSWINSZ ioctl and sending a SIGWINCH twice, first with a fake, then with the true window size. This is not quite a complete rewrite of screen, but seems to work quite well. (Although I'm sure there are plenty of cases not covered by this crude method of switching) When the infrastructure for background-editor hooks is there, I'm ready to try to make the hook! -- :wq ^X^Cy^K^X^C^C^C^C