From wmorgan-sup@masanjin.net Tue Nov 3 12:45:17 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 09:45:17 -0800 Subject: [sup-devel] test Message-ID: <1257270304-sup-3058@masanjin.net> Just making sure the new list works. -- William From wmorgan-sup@masanjin.net Tue Nov 3 13:12:02 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 03 Nov 2009 10:12:02 -0800 Subject: [sup-devel] test In-Reply-To: <1257270304-sup-3058@masanjin.net> References: <1257270304-sup-3058@masanjin.net> Message-ID: <1257271895-sup-7431@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-11-03: > Just making sure the new list works. Trying again. -- William From pi+sup@pihost.us Tue Nov 3 22:05:19 2009 From: pi+sup@pihost.us (Anthony Martinez) Date: Tue, 3 Nov 2009 20:05:19 -0700 Subject: [sup-devel] [PATCH] If we have a COLUMNS environment variable, wrap to that instead of 80. Message-ID: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> From: Anthony Martinez I find that this provides a much smoother terminal experience, especially with dumped HTML output. At least on Linux+zsh, this environment variable is automatically updated, and if it doesn't exist, sup will continue to happily default to 80. --- lib/sup/message-chunks.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index 581b707..881ac4b 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -41,7 +41,7 @@ end module Redwood module Chunk - WRAP_LEN = 80 # wrap messages and text attachments at this width + WRAP_LEN = ENV["COLUMNS"] || 80 # wrap messages and text attachments at this width class Attachment HookManager.register "mime-decode", < References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> Message-ID: <1257304795-sup-5302@home.mrtheplague.net> Excerpts from Anthony Martinez's message of Tue Nov 03 20:05:19 -0700 2009: > I find that this provides a much smoother terminal experience, Or it would if I tested it. Sorry about the bad patch, seems today isn't my day. :) Either way, I'd like to see something like this. Discussion? From pi+sup@pihost.us Tue Nov 3 22:51:46 2009 From: pi+sup@pihost.us (Anthony Martinez) Date: Tue, 03 Nov 2009 20:51:46 -0700 Subject: [sup-devel] [CORRECTED PATCH] If we can get the terminal width, use that for WRAP_LEN. In-Reply-To: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> Message-ID: <1257306460-sup-1506@home.mrtheplague.net> I find that this provides a much smoother terminal experience, especially with elinks configured to dump to the same size in hook scripts. At least on Linux, "stty size"'s second numerical output is the number of columns, and if that fails somehow, sup will continue to happily default to 80. --- lib/sup/message-chunks.rb | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index 581b707..56ddf1e 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -41,7 +41,8 @@ end module Redwood module Chunk - WRAP_LEN = 80 # wrap messages and text attachments at this width + TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails. + WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width class Attachment HookManager.register "mime-decode", < References: <1257303919-30524-1-git-send-email-pi+sup@pihost.us> <1257304795-sup-5302@home.mrtheplague.net> Message-ID: <1257349056-sup-7760@Backspace.local> Excerpt from Anthony Martinez's message of Tue Nov 03 21:22:24 -0600 2009: > Either way, I'd like to see something like this. Discussion? Personally, I regularly use a full-screen width terminal. I'm on a Mac using a drop-down terminal app called Visor [1]. It lets me have an always accessible terminal app. However it's the with of the entire screen (probably 200-ish columns wide), which would be almost unusable if the things were wrapped to the full width. Also, general typography rules say to have a line length of about 2 to 3 lowercase alphabets wide for easily readable text. With monospaced fonts, as in a terminal, all you characters are the same with. So you get a suggested line length of 26 * 3 which is 78. I have no idea if anyone reasonably tries to apply typography rules to terminal apps though... [1] http://visor.binaryage.com/ -- Blake Burkhart From rlane@club.cc.cmu.edu Thu Nov 5 00:49:38 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 4 Nov 2009 21:49:38 -0800 Subject: [sup-devel] [PATCH] handle UpdateManager events in the main loop Message-ID: <1257400178-26889-1-git-send-email-rlane@club.cc.cmu.edu> --- bin/sup | 2 + lib/sup/buffer.rb | 17 +++++++++++--- lib/sup/draft.rb | 2 +- lib/sup/modes/thread-index-mode.rb | 42 ++++++++++++++++++------------------ lib/sup/modes/thread-view-mode.rb | 12 +++++----- lib/sup/poll.rb | 2 +- lib/sup/update.rb | 21 ++++++++++++++++++ 7 files changed, 65 insertions(+), 33 deletions(-) diff --git a/bin/sup b/bin/sup index 78c396a..348070a 100755 --- a/bin/sup +++ b/bin/sup @@ -224,6 +224,8 @@ begin nil end + UpdateManager.dequeue_all + if c.nil? if BufferManager.sigwinch_happened? debug "redrawing screen on sigwinch" diff --git a/lib/sup/buffer.rb b/lib/sup/buffer.rb index 35b7080..42005e8 100644 --- a/lib/sup/buffer.rb +++ b/lib/sup/buffer.rb @@ -4,6 +4,13 @@ require 'ncurses' if defined? Ncurses module Ncurses + $event_read_fd, $event_write_fd = IO.pipe + + def post_event + $event_write_fd << 'x' + $event_write_fd.flush + end + def rows lame, lamer = [], [] stdscr.getmaxyx lame, lamer @@ -32,9 +39,11 @@ module Ncurses ## it is NECESSARY to wrap Ncurses.getch in a select() otherwise all ## background threads will be BLOCKED. (except in very modern versions ## of libncurses-ruby. the current one on ubuntu seems to work well.) - if IO.select([$stdin], nil, nil, 0.5) - c = Ncurses.getch - end + read_fds, = IO.select([$stdin, $event_read_fd], nil, nil, 0.5) + return unless read_fds + + $event_read_fd.readpartial 1024 if read_fds.member? $event_read_fd + Ncurses.getch if read_fds.member? $stdin end ## pretends ctrl-c's are ctrl-g's @@ -44,7 +53,7 @@ module Ncurses KEY_CANCEL end - module_function :rows, :cols, :curx, :nonblocking_getch, :safe_nonblocking_getch, :mutex, :sync + module_function :rows, :cols, :curx, :nonblocking_getch, :safe_nonblocking_getch, :mutex, :sync, :post_event remove_const :KEY_ENTER remove_const :KEY_CANCEL diff --git a/lib/sup/draft.rb b/lib/sup/draft.rb index 5ea2935..5632e67 100644 --- a/lib/sup/draft.rb +++ b/lib/sup/draft.rb @@ -31,7 +31,7 @@ class DraftManager raise ArgumentError, "not a draft: source id #{m.source.id.inspect}, should be #{DraftManager.source_id.inspect} for #{m.id.inspect}" unless m.source.id.to_i == DraftManager.source_id Index.delete m.id File.delete @source.fn_for_offset(m.source_info) - UpdateManager.relay self, :single_message_deleted, m + UpdateManager.enqueue self, :single_message_deleted, m end end diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 12a76f9..323c565 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -117,7 +117,7 @@ EOS ## are set, and the second to show the cursor having moved update_text_for_line curpos - UpdateManager.relay self, :read, t.first + UpdateManager.enqueue self, :read, t.first when_done.call if when_done end end @@ -246,18 +246,18 @@ EOS pos = curpos if t.has_label? :starred # if ANY message has a star t.remove_label :starred # remove from all - UpdateManager.relay self, :unstarred, t.first + UpdateManager.enqueue self, :unstarred, t.first lambda do t.first.add_label :starred - UpdateManager.relay self, :starred, t.first + UpdateManager.enqueue self, :starred, t.first regen_text end else t.first.add_label :starred # add only to first - UpdateManager.relay self, :starred, t.first + UpdateManager.enqueue self, :starred, t.first lambda do t.remove_label :starred - UpdateManager.relay self, :unstarred, t.first + UpdateManager.enqueue self, :unstarred, t.first regen_text end end @@ -283,19 +283,19 @@ EOS pos = curpos if t.has_label? :inbox t.remove_label :inbox - UpdateManager.relay self, :archived, t.first + UpdateManager.enqueue self, :archived, t.first lambda do thread.apply_label :inbox update_text_for_line pos - UpdateManager.relay self,:unarchived, thread.first + UpdateManager.enqueue self,:unarchived, thread.first end else t.apply_label :inbox - UpdateManager.relay self, :unarchived, t.first + UpdateManager.enqueue self, :unarchived, t.first lambda do thread.remove_label :inbox update_text_for_line pos - UpdateManager.relay self, :unarchived, thread.first + UpdateManager.enqueue self, :unarchived, thread.first end end end @@ -306,20 +306,20 @@ EOS if t.has_label? :spam t.remove_label :spam add_or_unhide t.first - UpdateManager.relay self, :unspammed, t.first + UpdateManager.enqueue self, :unspammed, t.first lambda do thread.apply_label :spam self.hide_thread thread - UpdateManager.relay self,:spammed, thread.first + UpdateManager.enqueue self,:spammed, thread.first end else t.apply_label :spam hide_thread t - UpdateManager.relay self, :spammed, t.first + UpdateManager.enqueue self, :spammed, t.first lambda do thread.remove_label :spam add_or_unhide thread.first - UpdateManager.relay self,:unspammed, thread.first + UpdateManager.enqueue self,:unspammed, thread.first end end end @@ -329,20 +329,20 @@ EOS if t.has_label? :deleted t.remove_label :deleted add_or_unhide t.first - UpdateManager.relay self, :undeleted, t.first + UpdateManager.enqueue self, :undeleted, t.first lambda do t.apply_label :deleted hide_thread t - UpdateManager.relay self, :deleted, t.first + UpdateManager.enqueue self, :deleted, t.first end else t.apply_label :deleted hide_thread t - UpdateManager.relay self, :deleted, t.first + UpdateManager.enqueue self, :deleted, t.first lambda do t.remove_label :deleted add_or_unhide t.first - UpdateManager.relay self, :undeleted, t.first + UpdateManager.enqueue self, :undeleted, t.first end end end @@ -542,10 +542,10 @@ EOS UndoManager.register "labeling thread" do thread.labels = old_labels update_text_for_line pos - UpdateManager.relay self, :labeled, thread.first + UpdateManager.enqueue self, :labeled, thread.first end - UpdateManager.relay self, :labeled, thread.first + UpdateManager.enqueue self, :labeled, thread.first end def multi_edit_labels threads @@ -570,7 +570,7 @@ EOS LabelManager << l end end - UpdateManager.relay self, :labeled, t.first + UpdateManager.enqueue self, :labeled, t.first end regen_text @@ -578,7 +578,7 @@ EOS UndoManager.register "labeling #{threads.size.pluralize 'thread'}" do threads.zip(old_labels).map do |t, old_labels| t.labels = old_labels - UpdateManager.relay self, :labeled, t.first + UpdateManager.enqueue self, :labeled, t.first end regen_text end diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 2da0555..4e4290f 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -262,7 +262,7 @@ EOS @thread.labels = Set.new(reserved_labels) + new_labels new_labels.each { |l| LabelManager << l } update - UpdateManager.relay self, :labeled, @thread.first + UpdateManager.enqueue self, :labeled, @thread.first end def toggle_starred @@ -284,7 +284,7 @@ EOS ## TODO: don't recalculate EVERYTHING just to add a stupid little ## star to the display update - UpdateManager.relay self, :single_message_labeled, m + UpdateManager.enqueue self, :single_message_labeled, m end ## called when someone presses enter when the cursor is highlighting @@ -502,28 +502,28 @@ EOS def archive_and_then op dispatch op do @thread.remove_label :inbox - UpdateManager.relay self, :archived, @thread.first + UpdateManager.enqueue self, :archived, @thread.first end end def spam_and_then op dispatch op do @thread.apply_label :spam - UpdateManager.relay self, :spammed, @thread.first + UpdateManager.enqueue self, :spammed, @thread.first end end def delete_and_then op dispatch op do @thread.apply_label :deleted - UpdateManager.relay self, :deleted, @thread.first + UpdateManager.enqueue self, :deleted, @thread.first end end def unread_and_then op dispatch op do @thread.apply_label :unread - UpdateManager.relay self, :unread, @thread.first + UpdateManager.enqueue self, :unread, @thread.first end end diff --git a/lib/sup/poll.rb b/lib/sup/poll.rb index ec51dec..a6ed912 100644 --- a/lib/sup/poll.rb +++ b/lib/sup/poll.rb @@ -178,7 +178,7 @@ EOS ## does the gui callback stuff, etc. def add_new_message m Index.add_message m - UpdateManager.relay self, :added, m + UpdateManager.enqueue self, :added, m end end diff --git a/lib/sup/update.rb b/lib/sup/update.rb index d386801..31c4b3c 100644 --- a/lib/sup/update.rb +++ b/lib/sup/update.rb @@ -16,12 +16,33 @@ class UpdateManager def initialize @targets = {} + @queue = [] + @lock = Mutex.new end def register o; @targets[o] = true; end def unregister o; @targets.delete o; end + def enqueue sender, type, *args + @lock.synchronize { @queue << [sender, type, args] } + Ncurses.post_event if defined? Ncurses + debug "enqueued #{([type] + args) * ' '}" + end + + def dequeue_all + until @queue.empty? + old_queue = @lock.synchronize do + returning(@queue) { @queue = [] } + end + + old_queue.each do |sender, type, args| + relay sender, type, *args + end + end + end + def relay sender, type, *args + debug "relaying #{([type] + args) * ' '}" unless type == :tick meth = "handle_#{type}_update".intern @targets.keys.each { |o| o.send meth, sender, *args unless o == sender if o.respond_to? meth } end -- 1.6.4.2 From wmorgan-sup@masanjin.net Thu Nov 5 15:23:11 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 05 Nov 2009 12:23:11 -0800 Subject: [sup-devel] test In-Reply-To: <1257270304-sup-3058@masanjin.net> References: <1257270304-sup-3058@masanjin.net> Message-ID: <1257452583-sup-3041@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-11-03: > Just making sure the new list works. One more time. -- William From sup-bugs@masanjin.net Thu Nov 5 15:27:38 2009 From: sup-bugs@masanjin.net (William Morgan) Date: Thu, 05 Nov 2009 20:27:38 +0000 Subject: [sup-devel] [issue1] signature block not separated by a newline in sent messages Message-ID: <1257452858.49.0.55077786119.issue1@masanjin.net> New submission from William Morgan : In messages with no extra newlines at the end, the preview window displays the signature block with a newline prepended, which is correct. However, the actual sent message doesn't have this newline, and the signature follows the text immediately without a blank line. ---------- messages: 1 nosy: w priority: bug ruby_version: 1.8.7 status: unread sup_version: git master title: signature block not separated by a newline in sent messages _________________________________________ Sup issue tracker _________________________________________ From wmorgan-sup@masanjin.net Thu Nov 5 15:34:12 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 05 Nov 2009 12:34:12 -0800 Subject: [sup-devel] [issue1] signature block not separated by a newline in sent messages In-Reply-To: <1257452858.49.0.55077786119.issue1@masanjin.net> References: <1257452858.49.0.55077786119.issue1@masanjin.net> Message-ID: <1257452945-sup-9932@masanjin.net> Reformatted excerpts from William Morgan's message of 2009-11-05: > messages: 1 > nosy: w > priority: bug > ruby_version: 1.8.7 > status: unread > sup_version: git master > title: signature block not separated by a newline in sent messages Ok, so I have roundup set up at this address: http://masanjin.net/sup-bugs/ There are a couple things I don't like about it, but we can give it a shot for now. You don't have to register to create an issue (or to edit any of the existing ones, sigh), but if you'd like to assign yourself issues, you should set up an account. Any email that's cc'ed to sup-bugs with the appropriate subject will become part of the bug record. Automatic emails to sup-devel are only triggered on the creation of an issue. So if you're replying to an issue, you should think about what's on the to line a little. Feel free to add your issues! I'm going to point to this thing in the 0.9.1. error message, instead of sup-talk. -- William From plz@z-labs.com.ar Thu Nov 5 18:02:36 2009 From: plz@z-labs.com.ar (Pablo Luis Zorzoli) Date: Thu, 05 Nov 2009 20:02:36 -0300 Subject: [sup-devel] test In-Reply-To: <1257452583-sup-3041@masanjin.net> References: <1257270304-sup-3058@masanjin.net> <1257452583-sup-3041@masanjin.net> Message-ID: <1257462081-sup-247@mini-z> Excerpts from William Morgan's message of Thu Nov 05 17:23:11 -0300 2009: > Reformatted excerpts from William Morgan's message of 2009-11-03: > > Just making sure the new list works. > > One more time. It works like a charm. From bburky@bburky.com Thu Nov 5 20:18:02 2009 From: bburky@bburky.com (Blake Burkhart) Date: Thu, 05 Nov 2009 19:18:02 -0600 Subject: [sup-devel] Bug: Closing main inbox buffer and crashing Message-ID: <1257469857-sup-4704@Backspace.local> I managed to close the main inbox buffer in sup. This seems reproducible by creating a new message, exiting from the editor and then not immediately sending it. While this draft message is open in "compose-mode", switch back to "inbox-mode" and attempt to close sup, answering "yes" to "Really quit?" but "no" to "Discard message?" At this point the only buffers open are "compose-mode" and "log-mode" according to the buffer list. If you close all buffers with the "x" key, sup will crash with the following error: --- NoMethodError from thread: main undefined method `title' for nil:NilClass /Users/blake/Code/Others/sup/lib/sup/buffer.rb:775:in `get_status_and_title' /Users/blake/Code/Others/sup/lib/sup/buffer.rb:307:in `draw_screen' /Users/blake/Code/Others/sup/bin/sup:324 I'm currently running the "next" branch, but I can also reproduce this with "master." Note, if the "compose-mode" buffer is open when attempting to close sup, there is no problem, sup does not close the main inbox buffer. -- Blake Burkhart From markr.anderson@amd.com Fri Nov 6 15:00:38 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Fri, 6 Nov 2009 13:00:38 -0700 Subject: [sup-devel] Crash when I tried to resync after moving files from my offlineimap repo to a separate archive maildir Message-ID: <1257537462-sup-4310@testarossa> I'm still really raw with this Ruby stuff. I wonder if there's some way to prevent the running of before-add-message in sup-sync. I get the message on many of the mails that have already been categorized. But this seems like it could be separate. Perhaps my offlineimap was moving files around? I guess that's possible, I do have a web interface to the same IMAP box. Could it gracefully handle things when possible? -Mark [Fri Nov 06 12:45:10 -0700 2009] WARNING: problem getting messages from maildir:/home/manderso/MailExchange/INBOX: Problem reading file for id 12569185230017708: "/home/manderso/MailExc hange/INBOX/new/1256918523_0.28833.testarossa,U=146122,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,": No such file or directory - /home/manderso/MailExchange/INBOX/new/1256918523_0.28833.te starossa,U=146122,FMD5=7e33429f656f1e6e9d79b29c3f82c57e:2,. (eval):1: warning: instance variable @source_marked_read not initialized [Fri Nov 06 12:45:10 -0700 2009] hook: error running /home/manderso/.sup/hooks/before-add-message.rb: undefined method `index' for nil:NilClass [Fri Nov 06 12:45:10 -0700 2009] hook: /home/manderso/.sup/hooks/before-add-message.rb:49:in `__run' /home/manderso/.sup/hooks/before-add-message.rb:47:in `each' /home/manderso/.sup/hooks/before-add-message.rb:47:in `__run' /home/manderso/src/sup-git/mainline/lib/sup/hook.rb:42:in `__run' /home/manderso/src/sup-git/mainline/lib/sup/hook.rb:83:in `run' /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `send' /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `method_missing' /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:150:in `each_message_from' /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:160:in `each' /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `upto' /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `each' /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `send' /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `__pass' /home/manderso/src/sup-git/mainline/lib/sup/util.rb:547:in `method_missing' /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:139:in `each_message_from' /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `send' /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `method_missing' /home/manderso/src/sup-git/mainline/bin/sup-sync:146 /home/manderso/src/sup-git/mainline/bin/sup-sync:141:in `each' /home/manderso/src/sup-git/mainline/bin/sup-sync:141 [Fri Nov 06 12:45:10 -0700 2009] unlocking /home/manderso/.sup/lock... /home/manderso/src/ruby/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]': :(null) isn't a valid argument for IndexReader.get_document(index) (ArgumentError) from /home/manderso/src/ruby/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]' from /tool/pandora64/.package/ruby-1.8.7-p72/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /home/manderso/src/ruby/lib/ruby/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:413:in `[]' from /home/manderso/src/sup-git/mainline/lib/sup/ferret_index.rb:257:in `build_message' from /tool/pandora64/.package/ruby-1.8.7-p72/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /home/manderso/src/sup-git/mainline/lib/sup/ferret_index.rb:256:in `build_message' from /home/manderso/src/sup-git/mainline/bin/sup-sync:149 from /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:151:in `each_message_from' from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:160:in `each' from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `upto' from /home/manderso/src/sup-git/mainline/lib/sup/maildir.rb:157:in `each' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `send' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:560:in `__pass' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:547:in `method_missing' from /home/manderso/src/sup-git/mainline/lib/sup/poll.rb:139:in `each_message_from' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `send' from /home/manderso/src/sup-git/mainline/lib/sup/util.rb:520:in `method_missing' from /home/manderso/src/sup-git/mainline/bin/sup-sync:146 from /home/manderso/src/sup-git/mainline/bin/sup-sync:141:in `each' from /home/manderso/src/sup-git/mainline/bin/sup-sync:141 From pi+sup@pihost.us Fri Nov 6 21:16:42 2009 From: pi+sup@pihost.us (Anthony Martinez) Date: Fri, 06 Nov 2009 19:16:42 -0700 Subject: [sup-devel] [sup-talk] Sup-sync exception In-Reply-To: <1257537789-sup-1961@testarossa> References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca> <1257537789-sup-1961@testarossa> Message-ID: <1257556260-sup-1272@home.mrtheplague.net> Excerpts from Mark Anderson's message of Fri Nov 06 13:06:17 -0700 2009: > There was another patch that is complementary in getting the console to > recognize the width of the terminal, I forget the tname, but here's what I > have in my message-chunks.rb: > > TERM_WIDTH = `stty size 2>/dev/null`.split[1].to_i # to_i returns 0 if it fails > WRAP_LEN = TERM_WIDTH > 0 && TERM_WIDTH || 80 # wrap messages and text attachments at this width > > I don't know why that patch preferred `stty` to ENV["COLUMNS"], since that one > had worked for me. That'd be my patch. I used stty because ENV["COLUMNS"] doesn't consistently work for me: $ echo $COLUMNS 132 $ perl -wE 'say $ENV{COLUMNS}' Use of uninitialized value in say at -e line 1. $ ruby -e 'puts ENV["COLUMNS"]' nil $ irb irb(main):001:0> ENV["COLUMNS"] => "132" In Sup's console mode, ENV["COLUMNS"] is set, but when I tried WRAP_LEN = ENV["COLUMNS"] in message-chunks.rb, it gets nil. It appears to have something to do with readline: $ irb --noreadline irb(main):001:0> ENV["COLUMNS"] => nil I also tried Ncurses.cols, as suggested on sup-devel, and got a similar exception to yours. `stty`, albeit cheesy, works well enough for right now (even though I'm not quite happy with it, since, in addition to its reliance on the output of an external command, it also won't react to window size changes) Perhaps this should be a configuration option -- give it a number to wrap to that width, :auto to wrap to the terminal size (in some fashion that will allow it to resize when the terminal does), and in the absence of any configuration, 80. -- Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work. From marka@pobox.com Fri Nov 6 23:10:33 2009 From: marka@pobox.com (Mark Alexander) Date: Fri, 06 Nov 2009 23:10:33 -0500 Subject: [sup-devel] [sup-talk] Sup-sync exception In-Reply-To: <1257556260-sup-1272@home.mrtheplague.net> References: <1257452860-sup-7983@testarossa> <1257520288-sup-8595@onnadayr.ca> <1257537789-sup-1961@testarossa> <1257556260-sup-1272@home.mrtheplague.net> Message-ID: <1257566953-sup-306@r50p> Excerpts from Anthony Martinez's message of Fri Nov 06 21:16:42 -0500 2009: > That'd be my patch. I used stty because ENV["COLUMNS"] doesn't consistently work > for me: > > $ echo $COLUMNS > 132 > $ perl -wE 'say $ENV{COLUMNS}' > Use of uninitialized value in say at -e line 1. It sounds like you didn't do this: export COLUMNS From sup-bugs@masanjin.net Sat Nov 7 13:06:30 2009 From: sup-bugs@masanjin.net (anonymous) Date: Sat, 07 Nov 2009 18:06:30 +0000 Subject: [sup-devel] [issue2] msgid non-uniqueness Message-ID: <1257617190.5.0.336645039558.issue2@masanjin.net> New submission from anonymous: An important assumption in Sup is that message IDs are unique (or, at least that duplicate message IDs refer to the same abstract message). Normally this is true, but an attacker could trivially copy the id of a legitimate message, overwriting it in the index. Is this a problem we care about? Is there anything we can do about it? ---------- messages: 2 nosy: anonymous priority: bug ruby_version: any status: unread sup_version: 0.9 title: msgid non-uniqueness _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Sat Nov 7 14:39:56 2009 From: sup-bugs@masanjin.net (Blake Burkhart) Date: Sat, 07 Nov 2009 19:39:56 +0000 Subject: [sup-devel] [issue3] Closing main inbox buffer and crashing Message-ID: <1257622796.53.0.0965044838271.issue3@masanjin.net> New submission from Blake Burkhart : I posted this a couple days ago on sup-devel, and didn't get a response. Thought I'd repost it here on the tracker anyway. I managed to close the main inbox buffer in sup. This seems reproducible by creating a new message, exiting from the editor and then not immediately sending it. While this draft message is open in "compose-mode", switch back to "inbox-mode" and attempt to close sup, answering "yes" to "Really quit?" but "no" to "Discard message?" At this point the only buffers open are "compose-mode" and "log-mode" according to the buffer list. If you close all buffers with the "x" key, sup will crash with the following error: --- NoMethodError from thread: main undefined method `title' for nil:NilClass /Users/blake/Code/Others/sup/lib/sup/buffer.rb:775:in `get_status_and_title' /Users/blake/Code/Others/sup/lib/sup/buffer.rb:307:in `draw_screen' /Users/blake/Code/Others/sup/bin/sup:324 I'm currently running the "next" branch, but I can also reproduce this with "master." Note, if the "compose-mode" buffer is open when attempting to close sup, there is no problem, sup does not close the main inbox buffer. ---------- messages: 3 nosy: bburky priority: bug ruby_version: 1.8.7 status: unread sup_version: git master title: Closing main inbox buffer and crashing _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Sat Nov 7 15:24:10 2009 From: sup-bugs@masanjin.net (William Morgan) Date: Sat, 07 Nov 2009 20:24:10 +0000 Subject: [sup-devel] [issue4] be able to kill buffers in buffer-list-mode Message-ID: <1257625450.85.0.697495716313.issue4@masanjin.net> New submission from William Morgan : i'd like to be able to kill buffers in buffer-list-mode by pressing 'x'. currently i have to hit enter to raise the buffer and then 'x'. ---------- messages: 4 nosy: w priority: feature request ruby_version: 1.8.7 status: unread sup_version: 0.9 title: be able to kill buffers in buffer-list-mode _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Sat Nov 7 16:09:17 2009 From: sup-bugs@masanjin.net (seschwar) Date: Sat, 07 Nov 2009 21:09:17 +0000 Subject: [sup-devel] [issue5] white on black in colors.yaml looks like default on default Message-ID: <1257628157.53.0.667373052282.issue5@masanjin.net> New submission from seschwar : I use a terminal with a light background color. Whenever I set an element to white foreground and black background color -- like :status in this example -- the element looks like I had set the colors to default/default. --- :status: :fg: white :bg: black ... looks like --- :status: :fg: default :bg: default ... However these are all displayed correctly: --- :status: :fg: blue :bg: black ... --- :status: :fg: white :bg: blue ... --- :status: :fg: white :bg: default ... This problem is still present in the current "next" branch. ---------- messages: 5 nosy: seschwar priority: bug ruby_version: 1.8.7_p174 status: unread sup_version: 0.9 title: white on black in colors.yaml looks like default on default _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Sat Nov 7 16:21:51 2009 From: sup-bugs@masanjin.net (seschwar) Date: Sat, 07 Nov 2009 21:21:51 +0000 Subject: [sup-devel] [issue6] add an ask_for_to config option Message-ID: <1257628911.55.0.104494796803.issue6@masanjin.net> New submission from seschwar : Adding and an ask_for_to config option would allow to edit the header along with all others later in $EDITOR only. Together with the already existing ask_for_* options it would work like Mutt's $edit_headers. This would allow to skip *all* prompts when composing a message and editing the headers in $EDITOR only. ---------- messages: 6 nosy: seschwar priority: feature request ruby_version: 1.8.7_p174 status: unread sup_version: 0.9 title: add an ask_for_to config option _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Tue Nov 10 00:16:03 2009 From: sup-bugs@masanjin.net (Rich Lane) Date: Tue, 10 Nov 2009 05:16:03 +0000 Subject: [sup-devel] [issue7] per-source poll interval Message-ID: <1257830163.81.0.281752964078.issue7@masanjin.net> New submission from Rich Lane : It would be nice to be able to configure the poll interval per-source in sources.yaml. This would probably also mean refactoring the poll loop so that sources could be polled independently and changing the definition of the poll hooks. ---------- messages: 7 nosy: rlane priority: feature request ruby_version: 1.8.7 status: unread sup_version: 0.9.1 title: per-source poll interval _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Tue Nov 10 01:59:42 2009 From: sup-bugs@masanjin.net (Rich Lane) Date: Tue, 10 Nov 2009 06:59:42 +0000 Subject: [sup-devel] [issue8] ruby 1.9 compatibility Message-ID: <1257836382.46.0.473802932084.issue8@masanjin.net> New submission from Rich Lane : Tracking bug for 1.9 compatibility. ncurses needs a few fixes: http://github.com/rlane/ncurses rmail has encoding issues: http://github.com/rlane/rubymail Opening mbox files with the "BINARY" encoding seems to work. Patch attached. The rmail patch above is very hacky. But, these combined are enough to let me index a bunch of spam and run sup with no obvious problems. ---------- assignedto: rlane files: mbox-binary-encoding.patch messages: 8 nosy: rlane priority: bug ruby_version: 1.9.1 status: unread sup_version: 0.9 title: ruby 1.9 compatibility _________________________________________ Sup issue tracker _________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: mbox-binary-encoding.patch Type: text/x-patch Size: 569 bytes Desc: not available URL: From sup-bugs@masanjin.net Tue Nov 10 18:30:32 2009 From: sup-bugs@masanjin.net (micah) Date: Tue, 10 Nov 2009 23:30:32 +0000 Subject: [sup-devel] [issue9] VCS artifacts being shipped in the gem Message-ID: <1257895832.25.0.688101043926.issue9@masanjin.net> New submission from micah : There appears to be some VCS artifacts that are the result of a merge that wasn't cleaned up being distributed: pond% find ./ -name \*hook\* ~/.gem/ruby/1.8 ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_BASE_8625_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_BASE_8681_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_REMOTE_8681_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_BACKUP_8625_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_LOCAL_8625_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_LOCAL_8681_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_BACKUP_8681_rb.html ./doc/sup-0.9/rdoc/files/lib/sup/hook_rb_REMOTE_8625_rb.html ./doc/sup-0.9/ri/Redwood/Console/clear_hooks-i.yaml ./doc/sup-0.9/ri/Redwood/HookManager/print_hooks-i.yaml ./gems/sup-0.9/lib/sup/hook.rb.BASE.8625.rb ./gems/sup-0.9/lib/sup/hook.rb.REMOTE.8681.rb ./gems/sup-0.9/lib/sup/hook.rb ./gems/sup-0.9/lib/sup/hook.rb.BASE.8681.rb ./gems/sup-0.9/lib/sup/hook.rb.BACKUP.8625.rb ./gems/sup-0.9/lib/sup/hook.rb.LOCAL.8681.rb ./gems/sup-0.9/lib/sup/hook.rb.LOCAL.8625.rb ./gems/sup-0.9/lib/sup/hook.rb.REMOTE.8625.rb ./gems/sup-0.9/lib/sup/hook.rb.BACKUP.8681.rb ---------- messages: 9 nosy: micah priority: bug ruby_version: 1.8 status: unread sup_version: 0.9 title: VCS artifacts being shipped in the gem _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Wed Nov 11 11:11:29 2009 From: sup-bugs@masanjin.net (Christopher Bertels) Date: Wed, 11 Nov 2009 16:11:29 +0000 Subject: [sup-devel] [issue10] Show labels of polled messages Message-ID: <1257955889.47.0.883956565031.issue10@masanjin.net> New submission from Christopher Bertels : I've posted this to the sup-talk mailinglist a month ago, but no one replied and so I'll repost it here, since this is what the tracker is for, ain't it ;) here's the original message, I've also attached the patch (it's based on my m17n-branch but it can be easily rebased on master - that is, if there's any interest of including this into sup's mainline). --------- I always thought it would be nice to see to which labels new polled messages have been added. Usually, when I see new messages arrived, most of them aren't in my inbox, since I archive the messages of most of my sources (e.g. mailinglists like this one). Then, I usually go and look at the labels-list-mode to see where new messages got added. I've attached a patch that displays the labels of newly polled messages at the bottom, next to the amount of total messages added from polling. The patch is based on my i18n branch, but it should be easy to rebase it on next or master. What do you think of it? ---------- files: label_notification.patch messages: 10 nosy: bakkdoor priority: feature request ruby_version: 1.8 status: unread sup_version: 0.9 title: Show labels of polled messages _________________________________________ Sup issue tracker _________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: label_notification.patch Type: text/x-patch Size: 3505 bytes Desc: not available URL: From ph@malaprop.org Wed Nov 11 14:05:19 2009 From: ph@malaprop.org (Peter Harkins) Date: Wed, 11 Nov 2009 13:05:19 -0600 Subject: [sup-devel] patches for issues 6 and 10; q about 7 Message-ID: <1257965837-sup-1835@argyle> Howdy, new sup user here. I was poking around the issue tracker and issues 6 and 10 looked pretty straightforward. http://masanjin.net/sup-bugs/issue6 http://masanjin.net/sup-bugs/issue10 I've attached my patches to this email as well as uploaded to the tracker (it sounds like the workflow is in flux a little right now). My git repo is public at http://github.com/Harkins/sup for anyone curious. William, would you be interested in a patch for issue 7, adding a configurable timeout to each source? I could do this as well. http://masanjin.net/sup-bugs/issue7 -- Peter Harkins - http://push.cx - http://NearbyGamers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Edited-bakkdoor-s-patch-for-issue10-for-next.patch Type: application/octet-stream Size: 2108 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-issue6-Added-ask_for_to-to-match-_cc-_bcc-and-_subje.patch Type: application/octet-stream Size: 2458 bytes Desc: not available URL: From sup-bugs@masanjin.net Wed Nov 11 17:14:34 2009 From: sup-bugs@masanjin.net (anonymous) Date: Wed, 11 Nov 2009 22:14:34 +0000 Subject: [sup-devel] [issue11] Add "Reply-To" to the "Reply To" menu In-Reply-To: <1257977674.17.0.0680341683131.issue11@masanjin.net> Message-ID: <1257977674.17.0.0680341683131.issue11@masanjin.net> New submission from anonymous: Currently in the "Reply To" menu there are three options: "Sender" "Mailing List" and "Customized". However sometimes (such when subscribing to mailing list) there is mime "Reply-To" field that is different from the sender address. IMO when there is a "Reply-To" mime field, another option should be added to the "Reply To" menu (can't think of a good name for it tough). ---------- messages: 16 nosy: anonymous priority: feature request ruby_version: 1.8.7 status: unread sup_version: 0.9 title: Add "Reply-To" to the "Reply To" menu _________________________________________ Sup issue tracker _________________________________________ From rlane@club.cc.cmu.edu Wed Nov 11 23:31:08 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 11 Nov 2009 23:31:08 -0500 Subject: [sup-devel] patches for issues 6 and 10; q about 7 In-Reply-To: <1257965837-sup-1835@argyle> References: <1257965837-sup-1835@argyle> Message-ID: <1257999287-sup-7196@zyrg.net> Excerpts from Peter Harkins's message of Wed Nov 11 14:05:19 -0500 2009: > Howdy, new sup user here. I was poking around the issue tracker and > issues 6 and 10 looked pretty straightforward. > http://masanjin.net/sup-bugs/issue6 > http://masanjin.net/sup-bugs/issue10 > > I've attached my patches to this email as well as uploaded to the > tracker (it sounds like the workflow is in flux a little right now). > My git repo is public at http://github.com/Harkins/sup for anyone > curious. These look good to me. I've pushed them to branches display-poll-labels and config-ask-for-to in my repo* and merged them to master. * git://github.com/rlane/sup > William, would you be interested in a patch for issue 7, adding a > configurable timeout to each source? I could do this as well. > http://masanjin.net/sup-bugs/issue7 Go for it. I've had several people want to change the poll interval and I've had to tell them to edit the source. From tero@tilus.net Thu Nov 12 11:00:18 2009 From: tero@tilus.net (Tero Tilus) Date: Thu, 12 Nov 2009 18:00:18 +0200 Subject: [sup-devel] [issue11] Add "Reply-To" to the "Reply To" menu In-Reply-To: <1257977674.17.0.0680341683131.issue11@masanjin.net> References: <1257977674.17.0.0680341683131.issue11@masanjin.net> Message-ID: <1258039714-sup-5426@tilus.net> anonymous, 2009-11-12 00:14: > IMO when there is a "Reply-To" mime field, another option should be > added to the "Reply To" menu IMO Reply-To should be the default when available and it seems to be too. This is how recipient is sorted out for reply to option "Sender" (from reply-mode.rb, @m is the message) to = @m.is_list_message? ? @m.from : (@m.replyto || @m.from) What would be the use-case for separate sender and "reply-to" options? > (can't think of a good name for it tough). If there really is need for separate options like that I would pick - Sender: Reply-To (or From), which would be always available - Bounce back: Return-Path (or From), available when it differs from the previous -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From web-sup@superscript.com Sun Nov 15 18:27:37 2009 From: web-sup@superscript.com (William Erik Baxter) Date: Sun, 15 Nov 2009 18:27:37 -0500 Subject: [sup-devel] Correct AM/PM selector in DATE_FORMAT Message-ID: <1258327627-sup-6728@kronos> The selector case was incorrect in DATE_FORMAT: %P instead of %p. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Correct-AM-PM-selector-in-DATE_FORMAT.patch Type: application/octet-stream Size: 799 bytes Desc: not available URL: From sup-bugs@masanjin.net Mon Nov 16 16:16:34 2009 From: sup-bugs@masanjin.net (micah) Date: Mon, 16 Nov 2009 21:16:34 +0000 Subject: [sup-devel] [issue12] fixing gpg keyid handling in signing In-Reply-To: <1258406194.83.0.679207394644.issue12@masanjin.net> Message-ID: <1258406194.83.0.679207394644.issue12@masanjin.net> New submission from micah : I propose that the following gpg invocation in the sign function contained in lib/crypto.rb is changed. from: output = run_gpg "--output - --armor --detach-sign --textmode --local-user '#{from}' #{payload_fn.path}" to: output = run_gpg "--output - --armor --detach-sign --textmode #{payload_fn.path}" The reason is because (as I discussed on sup-talk), sup is using the From address to guess which gpg key it should use for signing, this is not the right thing to do, instead sup should use the default-key that gpg provides, which is user configurable in .gnupg/gpg.conf. As it is now, if the user has configured this, they are surprised to find that their preferred key is not used, and instead a different one could be used, causing issues. The --local-user flag overrides the default-key setting, which when set in .gnupg/gpg.conf is intended to be used unless it is explicitly overridden by the --local-user flag, overriding it implicitly is the wrong way to do that. If I remove the "--local-user '#{from}'" then sup behaves the way I expect, ie. it uses the key I have specified in my gpg.conf. I'd also suggest that a :gpgkey: account configuration variable is added to sup so that a user can specify, for their different account identities, in .sup/config.yaml the specific key they wish to use, if they want to. If they do not, the behavior should be to use the one that gpg uses, which can be done by *not* passing the --local-user flag *unless* the :gpgkey: is specified for that account. ---------- messages: 20 nosy: micah priority: bug ruby_version: 1.8 status: unread sup_version: next title: fixing gpg keyid handling in signing _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Tue Nov 17 06:31:05 2009 From: sup-bugs@masanjin.net (Carlos Garcia Campos) Date: Tue, 17 Nov 2009 11:31:05 +0000 Subject: [sup-devel] [issue13] Crypto selector default options In-Reply-To: <1258457465.08.0.918987088694.issue13@masanjin.net> Message-ID: <1258457465.08.0.918987088694.issue13@masanjin.net> New submission from Carlos Garcia Campos : I always send emails from a certain account signed, so every time I compose an email from such account I have to change the Crypto selector option from none to Sign. The thing is that I forget to change that option quite often, so it would be nice if there were an option in the config file to change default crypto options for every account. Or maybe a crypto-hook where I can do it myself. Thanks. ---------- messages: 21 nosy: carlosgc priority: feature request ruby_version: 1.8 status: unread sup_version: next title: Crypto selector default options _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Tue Nov 17 13:32:20 2009 From: sup-bugs@masanjin.net (anonymous) Date: Tue, 17 Nov 2009 18:32:20 +0000 Subject: [sup-devel] [issue14] Poll update message should accumulate changes if UI is idle In-Reply-To: <1258482740.0.0.442361884723.issue14@masanjin.net> Message-ID: <1258482740.0.0.442361884723.issue14@masanjin.net> New submission from anonymous: I usually leave my sup window up for a long time, and I have lots of filter rules in my before-add-message hook, so many of the messages that come in don't show up in my inbox. Could someone who knows what they're doing help me patch the polling update to keep a running total of the messages (Found 2 messages, 0 to inbox), so that I can see how active mail has been since I last touched it. We could keep the last update separate from the running total, if that's valuable. ---------- messages: 22 nosy: anonymous priority: feature request ruby_version: 1.8.7-p72 status: unread sup_version: 0.9.1 title: Poll update message should accumulate changes if UI is idle _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Tue Nov 17 13:36:04 2009 From: sup-bugs@masanjin.net (Mark Anderson) Date: Tue, 17 Nov 2009 18:36:04 +0000 Subject: [sup-devel] [issue15] BugTracker: Feature requests shouldn't require the Ruby version In-Reply-To: <1258482964.38.0.699410028803.issue15@masanjin.net> Message-ID: <1258482964.38.0.699410028803.issue15@masanjin.net> New submission from Mark Anderson : I was just entering a feature request, and the ticket wouldn't accept creation without a Ruby version. I agree that Ruby version is a must-have field for bug submission, but perhaps the web logic could detect that a feature request doesn't have to have the Ruby version supplied. Just a thought. ---------- messages: 23 nosy: mranders priority: feature request ruby_version: 1.8.7-p72 status: unread sup_version: 0.9.1 title: BugTracker: Feature requests shouldn't require the Ruby version _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Tue Nov 17 15:29:35 2009 From: sup-bugs@masanjin.net (Mark Anderson) Date: Tue, 17 Nov 2009 20:29:35 +0000 Subject: [sup-devel] [issue16] Messages on sup startup In-Reply-To: <1258489775.12.0.817458172429.issue16@masanjin.net> Message-ID: <1258489775.12.0.817458172429.issue16@masanjin.net> New submission from Mark Anderson : I see these warnings on startup, and I wondered if they are fixed in some branch I'm unaware of? Do they only show up in my version of Ruby? I had some simple fixes for them, but I still haven't figured out how to generate patches. $HOME/src/sup-git/mainline/lib/sup/util.rb:9: warning: method redefined; discarding old gen_lock_id $HOME/src/sup-git/mainline/lib/sup/util.rb:20: warning: method redefined; discarding old dump_lock_id [Tue Nov 17 11:37:39 -0700 2009] WARNING: can't find character set by using locale, defaulting to utf-8 $HOME/src/sup-git/mainline/lib/sup/message-chunks.rb:36: warning: method redefined; discarding old make_tmpname $HOME/src/sup-git/mainline/lib/sup/imap.rb:119: warning: ambiguous first argument; put parentheses or even spaces $HOME/src/sup-git/mainline/lib/sup/xapian_index.rb:398: warning: `&' interpreted as argument prefix ---------- messages: 24 nosy: mranders priority: bug ruby_version: 1.8.7-p72 status: unread sup_version: 0.9.1 title: Messages on sup startup _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Tue Nov 17 15:43:57 2009 From: sup-bugs@masanjin.net (Benoit PIERRE) Date: Tue, 17 Nov 2009 20:43:57 +0000 Subject: [sup-devel] [issue17] signature dectecion regexp to liberal In-Reply-To: <1258490637.79.0.340874377555.issue17@masanjin.net> Message-ID: <1258490637.79.0.340874377555.issue17@masanjin.net> New submission from Benoit PIERRE : For example I receive some messages from http://appdb.winehq.org who look like this: Test Results added to version 1.x of Fallout 3 by xxxx ------------------------------------------------------- http://appdb.winehq.org/objectManager.php?sClass=version&iId=14322&iTestingId=46626 This Test data has been submitted by xxxx. Appdb admin reply text: Since something is not working, it's not gold. Best regards. The AppDB team http://appdb.winehq.org/ resulting in sup marking the whole body (except the fist line) as a signature. I know not every mailer stick to ^-- $, but maybe sup could use some kind of heuristic based on the size of the signature? Also, ironically, the messages I receive from the sup mailing list end in: _______________________________________________ sup-talk mailing list sup-talk at rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk with an added: _________________________________________ Sup issue tracker _________________________________________ when they come from the tracker... ---------- messages: 25 nosy: bpierre priority: bug ruby_version: 1.8.7 status: unread sup_version: all title: signature dectecion regexp to liberal _________________________________________ Sup issue tracker _________________________________________ From ingmar@exherbo.org Tue Nov 17 18:25:26 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Wed, 18 Nov 2009 00:25:26 +0100 Subject: [sup-devel] [PATCH] Comment tweak, XapianIndex doesn't use GDBM anymore since 4d82ef88 Message-ID: <1258500326-17510-1-git-send-email-ingmar@exherbo.org> --- lib/sup/xapian_index.rb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) A really minor comment tweak, but I'd still like to see it fixed... :-) diff --git a/lib/sup/xapian_index.rb b/lib/sup/xapian_index.rb index 34d67d5..cebb148 100644 --- a/lib/sup/xapian_index.rb +++ b/lib/sup/xapian_index.rb @@ -3,7 +3,7 @@ require 'set' module Redwood -# This index implementation uses Xapian for searching and GDBM for storage. It +# This index implementation uses Xapian for searching and storage. It # tends to be slightly faster than Ferret for indexing and significantly faster # for searching due to precomputing thread membership. class XapianIndex < BaseIndex -- 1.6.5.2.433.g23cdb From bburky@bburky.com Wed Nov 18 02:08:00 2009 From: bburky@bburky.com (Blake Burkhart) Date: Wed, 18 Nov 2009 01:08:00 -0600 Subject: [sup-devel] [PATCH] Added Growl notifications for new messages Message-ID: <1258526534-sup-7223@Backspace.local> I use sup on a Mac and often use the Growl notification system in many apps. This would be a useful feature in sup because I often don't have my terminal window visible. The attached patch uses the ruby growl bindings (in the growl gem) to display a notification with the text that is normally displayed in the sup window when new messages are added to the inbox after polling. For the notification icon I just borrowed the Apple Mail.app icon. I realize this probably isn't something that most people want as it's Mac only, but I thought I'd share it for others. If anyone does try it, make sure you have the growl gem installed and the growlnotify command line tool installed. As this is currently it will fail if the gem is not installed. I'm not really that familiar with this binding enough to make it fail gracefully. Growl website: http://growl.info/ -- Blake Burkhart -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Added-Growl-notifications-for-new-messages.patch Type: application/octet-stream Size: 1203 bytes Desc: not available URL: From sup-bugs@masanjin.net Wed Nov 18 04:24:13 2009 From: sup-bugs@masanjin.net (James Rowe) Date: Wed, 18 Nov 2009 09:24:13 +0000 Subject: [sup-devel] [issue18] Thread loading exception with xapian In-Reply-To: <1258536253.12.0.977685357393.issue18@masanjin.net> Message-ID: <1258536253.12.0.977685357393.issue18@masanjin.net> New submission from James Rowe : When loading all threads using the xapian backend I receive the following exception: --- RuntimeError from thread: load threads for thread-index-mode wrong id called on nil ./lib/sup.rb:17:in `id' ./lib/sup/modes/thread-index-mode.rb:225:in `update' ./lib/sup/hook.rb:122:in `sort_by' ./lib/sup/modes/thread-index-mode.rb:225:in `each' ./lib/sup/modes/thread-index-mode.rb:225:in `sort_by' ./lib/sup/modes/thread-index-mode.rb:225:in `update' ./lib/sup/modes/thread-index-mode.rb:223:in `synchronize' ./lib/sup/modes/thread-index-mode.rb:223:in `update' ./lib/sup/modes/thread-index-mode.rb:637:in `__unprotected_load_n_threads' (eval):12:in `load_n_threads' ./lib/sup/modes/thread-index-mode.rb:609:in `load_n_threads_background' ./lib/sup.rb:77:in `reporting_thread' ./lib/sup.rb:75:in `initialize' ./lib/sup.rb:75:in `new' ./lib/sup.rb:75:in `reporting_thread' ./lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' ./lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' ./bin/sup:199 The message that triggers the exception is attached, luckily it was to a public ML. ---------- files: 2,S messages: 26 nosy: jnrowe priority: bug ruby_version: 1.8.7 status: unread sup_version: 0.9 title: Thread loading exception with xapian _________________________________________ Sup issue tracker _________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: 2,S Type: application/octet-stream Size: 8557 bytes Desc: not available URL: From tero@tilus.net Wed Nov 18 08:03:20 2009 From: tero@tilus.net (Tero Tilus) Date: Wed, 18 Nov 2009 15:03:20 +0200 Subject: [sup-devel] [issue14] Poll update message should accumulate changes if UI is idle In-Reply-To: <1258482740.0.0.442361884723.issue14@masanjin.net> References: <1258482740.0.0.442361884723.issue14@masanjin.net> Message-ID: <1258548374-sup-6031@tilus.net> anonymous, 2009-11-17 20:32: > Could someone who knows what they're doing help me patch the polling > update to keep a running total of the messages (Found 2 messages, 0 > to inbox), so that I can see how active mail has been since I last > touched it. Peeking into log buffer doesn't work for you? > We could keep the last update separate from the running total, if > that's valuable. What would be the appropriate starting point for the running total? Sup startup? You can (I think) write an after-poll hook to do the thing. It might look something like this (minus typos and bugs). class PollTotals cattr_accessor :all cattr_accessor :inbox end PollTotals.all ||= 0 PollTotals.inbox ||= 0 PollTotals.all += num PollTotals.inbox += num_inbox info "Total #{PollTotals.all} messages, #{PollTotals.inbox} to inbox" # or however the logger thingy worked... -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From sup-bugs@masanjin.net Wed Nov 18 08:19:49 2009 From: sup-bugs@masanjin.net (micah) Date: Wed, 18 Nov 2009 13:19:49 +0000 Subject: [sup-devel] [issue19] crash when temporary space is unavailable In-Reply-To: <1258550389.35.0.535342663935.issue19@masanjin.net> Message-ID: <1258550389.35.0.535342663935.issue19@masanjin.net> New submission from micah : My /tmp filled up. This caused sup to crash and burn horribly, leaving me with a messed up terminal and some nasty stuff on the screen: [Wed Nov 18 06:29:03 -0500 2009] ERROR: oh crap, an exception ---------------------------------------------------------------- I'm very sorry. It seems that an error occurred in Sup. Please accept my sincere apologies. If you don't mind, please send the contents of ~/.sup/exception-log.txt and a brief report of the circumstances to sup-talk at rubyforge dot orgs so that I might address this problem. Thank you! Sincerely, William ---------------------------------------------------------------- --- RuntimeError from thread: periodic poll cannot generate tempfile `/tmp/21653-12-redwood.payload' /usr/lib/ruby/1.8/tempfile.rb:52:in `initialize' /usr/lib/ruby/1.8/sup/crypto.rb:84:in `new' /usr/lib/ruby/1.8/sup/crypto.rb:84:in `verify' /usr/lib/ruby/1.8/sup/util.rb:520:in `send' THe exception log has this: --- RuntimeError from thread: periodic poll cannot generate tempfile `/tmp/21653-12-redwood.payload' /usr/lib/ruby/1.8/tempfile.rb:52:in `initialize' /usr/lib/ruby/1.8/sup/crypto.rb:84:in `new' /usr/lib/ruby/1.8/sup/crypto.rb:84:in `verify' /usr/lib/ruby/1.8/sup/util.rb:520:in `send' /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' /usr/lib/ruby/1.8/sup/message.rb:388:in `multipart_signed_to_chunks' /usr/lib/ruby/1.8/sup/message.rb:428:in `message_to_chunks' /usr/lib/ruby/1.8/sup/message.rb:239:in `load_from_source!' /usr/lib/ruby/1.8/sup/message.rb:335:in `build_from_source' /usr/lib/ruby/1.8/sup/poll.rb:145:in `each_message_from' /usr/lib/ruby/1.8/sup/maildir.rb:160:in `each' /usr/lib/ruby/1.8/sup/maildir.rb:157:in `upto' /usr/lib/ruby/1.8/sup/maildir.rb:157:in `each' /usr/lib/ruby/1.8/sup/util.rb:560:in `send' /usr/lib/ruby/1.8/sup/util.rb:560:in `__pass' /usr/lib/ruby/1.8/sup/util.rb:547:in `method_missing' /usr/lib/ruby/1.8/sup/poll.rb:139:in `each_message_from' /usr/lib/ruby/1.8/sup/poll.rb:93:in `do_poll' /usr/lib/ruby/1.8/sup/poll.rb:81:in `each' /usr/lib/ruby/1.8/sup/poll.rb:81:in `do_poll' /usr/lib/ruby/1.8/sup/poll.rb:80:in `synchronize' /usr/lib/ruby/1.8/sup/poll.rb:80:in `do_poll' /usr/lib/ruby/1.8/sup/util.rb:520:in `send' /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' /usr/lib/ruby/1.8/sup/modes/poll-mode.rb:15:in `poll' /usr/lib/ruby/1.8/sup/poll.rb:48:in `poll' /usr/lib/ruby/1.8/sup/poll.rb:65:in `start' /usr/lib/ruby/1.8/sup.rb:76:in `reporting_thread' /usr/lib/ruby/1.8/sup.rb:74:in `initialize' /usr/lib/ruby/1.8/sup.rb:74:in `new' /usr/lib/ruby/1.8/sup.rb:74:in `reporting_thread' /usr/lib/ruby/1.8/sup/poll.rb:62:in `start' /usr/lib/ruby/1.8/sup/util.rb:520:in `send' /usr/lib/ruby/1.8/sup/util.rb:520:in `method_missing' /usr/bin/sup-mail:202 I certainly don't expect sup to work when /tmp is full, but perhaps a more graceful handling of these conditions is in order? ---------- messages: 30 nosy: micah priority: bug ruby_version: 1.8 status: unread sup_version: next title: crash when temporary space is unavailable _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Wed Nov 18 09:56:31 2009 From: sup-bugs@masanjin.net (Jon Dowland) Date: Wed, 18 Nov 2009 14:56:31 +0000 Subject: [sup-devel] [issue20] Rakefile tweaks relating to dependencies In-Reply-To: <1258556191.32.0.524787040794.issue20@masanjin.net> Message-ID: <1258556191.32.0.524787040794.issue20@masanjin.net> New submission from Jon Dowland : Disclaimer: I know next to nothing about rake, and I didn't want to install sup via rubygems. I've just gone through a dance like so $ rake rake aborted! no such file to load -- resolve the dependency, rinse and repeat, until I figure out that there's no default target for the Rakefile anyway. Is it possible for rake to emit a list of all required (and missing) packages, the first time a load fails? That would be nice. Also, some dependencies did not fail in this way, and instead caused sup-config to die later on. These were highline and trollop. I've no idea why the "rake" step didn't pick up on these, they are clearly in the Rakefile... ---------- messages: 31 nosy: jon priority: feature request ruby_version: 1.8 status: unread sup_version: 44336aa8ce39ea0769ad03ec3fac483ddc0e855b title: Rakefile tweaks relating to dependencies _________________________________________ Sup issue tracker _________________________________________ From rlane@club.cc.cmu.edu Wed Nov 18 12:20:52 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Wed, 18 Nov 2009 12:20:52 -0500 Subject: [sup-devel] [PATCH] Added Growl notifications for new messages In-Reply-To: <1258526534-sup-7223@Backspace.local> References: <1258526534-sup-7223@Backspace.local> Message-ID: <1258564558-sup-4079@zyrg.net> Excerpts from Blake Burkhart's message of Wed Nov 18 02:08:00 -0500 2009: > The attached patch uses the ruby growl bindings (in the growl gem) to display > a notification with the text that is normally displayed in the sup window when > new messages are added to the inbox after polling. For the notification icon I > just borrowed the Apple Mail.app icon. I think the after-poll hook provides the variables you need. If you could refactor it into that hook it would be a nice addition to the Hooks wiki page. From markr.anderson@amd.com Wed Nov 18 14:30:49 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Wed, 18 Nov 2009 12:30:49 -0700 Subject: [sup-devel] [issue14] Poll update message should accumulate changes if UI is idle In-Reply-To: <1258548374-sup-6031@tilus.net> References: <1258482740.0.0.442361884723.issue14@masanjin.net> <1258548374-sup-6031@tilus.net> Message-ID: <1258571852-sup-3843@testarossa> Excerpts from Tero Tilus's message of Wed Nov 18 06:03:20 -0700 2009: > anonymous, 2009-11-17 20:32: > > Could someone who knows what they're doing help me patch the polling > > update to keep a running total of the messages (Found 2 messages, 0 > > to inbox), so that I can see how active mail has been since I last > > touched it. > > Peeking into log buffer doesn't work for you? Peeking into the log buffer requires me to do an action when all I want to know is a summary of the actions the program has taken while I've been away. It's actually already trying to tell me what it's done, but it's only telling me what happened as a part of the last polling action. I'd like to know the summary of the polling actions since I last *touched* sup, not just the result of the last polling action, which is often along the line of "0 messages, 0 to inbox". I don't have a memory location inside my brain dedicated to the time of my last interaction with the mail client. To make sense of the polling log I need to have some idea of what the changes are since I last looked at it, more things to remember. The computer should be able to relieve me of some of those things, at least that's what I want it to do. > > > We could keep the last update separate from the running total, if > > that's valuable. > > What would be the appropriate starting point for the running total? > Sup startup? You can (I think) write an after-poll hook to do the > thing. It might look something like this (minus typos and bugs). I want to clear the running total each time I interact with the interface, but that's too vague. I don't think I want some flag updated each time I press a key, although that would probably give me most of what I'm looking for here. I need a tighter definition of when I want to have the PollTotals cleared. Here is a short list of some possibilities. 1. Every time I press any key on the keyboard 2. Every time I intentionally visit the inbox-mode (such as 'I' or visiting the inbox-mode buffer from the buffer-list screen, not just cycling 'b', that might be an accidental visit) 3. Some new command to specifically flush the counter 4. The right thing I can't think of yet. -Mark From markr.anderson@amd.com Wed Nov 18 15:27:03 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Wed, 18 Nov 2009 13:27:03 -0700 Subject: [sup-devel] [issue14] Poll update message should accumulate changes if UI is idle In-Reply-To: <1258571852-sup-3843@testarossa> References: <1258482740.0.0.442361884723.issue14@masanjin.net> <1258548374-sup-6031@tilus.net> <1258571852-sup-3843@testarossa> Message-ID: <1258575879-sup-7642@testarossa> So I tried cattr_accessor, and that doesn't work without Rails, apparently, so I just did this: class PollTotals def PollTotals.all @@all end def PollTotals.all=(value) @@all=value end def PollTotals.inbox @@inbox end def PollTotals.inbox=(value) @@inbox=value end @@all=0 @@inbox=0 end PollTotals.all += num PollTotals.inbox += num_inbox info "Total #{PollTotals.all} messages, #{PollTotals.inbox} to inbox" # or however the logger thingy worked... However, that gives the following. Loaded 1 new message, 0 to inbox. /home/manderso/.sup/hooks/after-poll.rb:2: warning: redefine all /home/manderso/.sup/hooks/after-poll.rb:5: warning: redefine all= /home/manderso/.sup/hooks/after-poll.rb:9: warning: redefine inbox /home/manderso/.sup/hooks/after-poll.rb:12: warning: redefine inbox= It seems a bit wasteful to redefine the class every time through, is there a better hook to put this in? From bburky@bburky.com Wed Nov 18 16:52:09 2009 From: bburky@bburky.com (Blake Burkhart) Date: Wed, 18 Nov 2009 15:52:09 -0600 Subject: [sup-devel] [PATCH] Added Growl notifications for new messages In-Reply-To: <1258569836-sup-5572@Backspace.local> References: <1258526534-sup-7223@Backspace.local> <1258564558-sup-4079@zyrg.net> <1258569836-sup-5572@Backspace.local> Message-ID: <1258580571-sup-648@Backspace.local> Excerpts from Blake Burkhart's message of Wed Nov 18 12:46:03 -0600 2009: > Excerpts from Rich Lane's message of Wed Nov 18 11:20:52 -0600 2009: > > I think the after-poll hook provides the variables you need. If you > > could refactor it into that hook it would be a nice addition to the > > Hooks wiki page. > > Oh, really? I didn't really know too much about the hooks other than the basic > before-add-message one I'm using. Sure, I'll try to refactor it and add to the > wiki. Okay. I added it to the Hooks wiki page in the form of a after-poll hook. I didn't realize there were so many hooks. -- Blake Burkhart From markr.anderson@amd.com Wed Nov 18 17:50:39 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Wed, 18 Nov 2009 15:50:39 -0700 Subject: [sup-devel] thread confusion Message-ID: <1258584557-sup-3267@testarossa> I have a thread that shows up 2 messages in one view (search on a number in the title) And shows up as 1 message in another view (search-mode on a label) When I added another label to the view where I could see both messages in one thread, and '$' to commit the changes, the thread shows up properly in the label view. Any ideas what was going on? I'm using Xapian. -Mark From tero@tilus.net Thu Nov 19 00:43:02 2009 From: tero@tilus.net (Tero Tilus) Date: Thu, 19 Nov 2009 07:43:02 +0200 Subject: [sup-devel] [issue14] Poll update message should accumulate changes if UI is idle In-Reply-To: <1258575879-sup-7642@testarossa> References: <1258482740.0.0.442361884723.issue14@masanjin.net> <1258548374-sup-6031@tilus.net> <1258571852-sup-3843@testarossa> <1258575879-sup-7642@testarossa> Message-ID: <1258609244-sup-8616@tilus.net> Mark Anderson, 2009-11-18 22:27: > It seems a bit wasteful to redefine the class every time through, is > there a better hook to put this in? Put the class in poll_totals.rb and require 'poll_totals' in the hook. You might need to hardcode path to require. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From markr.anderson@amd.com Thu Nov 19 02:21:44 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Thu, 19 Nov 2009 00:21:44 -0700 Subject: [sup-devel] [issue14] Poll update message should accumulate changes if UI is idle In-Reply-To: <1258609244-sup-8616@tilus.net> References: <1258482740.0.0.442361884723.issue14@masanjin.net> <1258548374-sup-6031@tilus.net> <1258571852-sup-3843@testarossa> <1258575879-sup-7642@testarossa> <1258609244-sup-8616@tilus.net> Message-ID: <1258615176-sup-3338@testarossa> Excerpts from Tero Tilus's message of Wed Nov 18 22:43:02 -0700 2009: > Mark Anderson, 2009-11-18 22:27: > > It seems a bit wasteful to redefine the class every time through, is > > there a better hook to put this in? > > Put the class in poll_totals.rb and require 'poll_totals' in the hook. > You might need to hardcode path to require. I actually just put the class definition in startup.rb, which I prefer. It's probably not considered as "clean", but it works. -Mark From cam+sup@cammunism.org Thu Nov 19 03:13:51 2009 From: cam+sup@cammunism.org (Cameron Matheson) Date: Thu, 19 Nov 2009 01:13:51 -0700 Subject: [sup-devel] [PATCH] Make sup's textfield behave more like readline Message-ID: <1258618384-sup-3721@cammunism.org> Hello, I've noticed that when using the Ctrl-a keybinding in sup's textfield, the entire input is deleted after typing anything if C-a was the first key pressed. I've also been missing readline's C-u (deletes anything before the cursor). I've attached a patch to fix/implement these issues. The C-u implementation is a bit ugly, but I couldn't find a better way to do it in ncurses. I also switched some of the key-code integers to character-literal syntax as I thought that was a bit more readable. Thanks, Cameron -------------- next part -------------- A non-text attachment was scrubbed... Name: sup-readline.patch Type: application/octet-stream Size: 1354 bytes Desc: not available URL: From tero@tilus.net Thu Nov 19 03:30:33 2009 From: tero@tilus.net (Tero Tilus) Date: Thu, 19 Nov 2009 10:30:33 +0200 Subject: [sup-devel] [issue15] BugTracker: Feature requests shouldn't require the Ruby version In-Reply-To: <1258482964.38.0.699410028803.issue15@masanjin.net> References: <1258482964.38.0.699410028803.issue15@masanjin.net> Message-ID: <1258619263-sup-3040@tilus.net> Mark Anderson, 2009-11-17 20:36: > I was just entering a feature request, and the ticket wouldn't > accept creation without a Ruby version. For now it might be better to use 'none' in cases where version really doesn't matter at all. > I agree that Ruby version is a must-have field for bug submission, > but perhaps the web logic could detect that a feature request > doesn't have to have the Ruby version supplied. Ruby version could IMO be a list just like 'Tags'. If it is made mandatory for bugs only the list should contain 'dunno' too and the name could be 'Affected ruby versions'. Could we already kick off a discussion regarding wanted/needed changes to tracker layout? -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From markr.anderson@amd.com Thu Nov 19 17:46:19 2009 From: markr.anderson@amd.com (Mark Anderson) Date: Thu, 19 Nov 2009 15:46:19 -0700 Subject: [sup-devel] Exception log Message-ID: <1258670687-sup-3418@testarossa> I was just going through and deleting an older buffer. I don't know anything specifically about the state of the thread that was being visited. -Mark --- NoMethodError from thread: load messages for thread-view-mode undefined method `content_width' for nil:NilClass /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:876:in `from_width' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:801:in `text_for_thread_at' /home/manderso/src/sup-git/mainline/lib/sup/hook.rb:55:in `each_with_index' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:800:in `each' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:800:in `each_with_index' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:800:in `text_for_thread_at' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:751:in `update_text_for_line' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:119:in `select' /home/manderso/src/sup-git/mainline/lib/sup.rb:77:in `reporting_thread' /home/manderso/src/sup-git/mainline/lib/sup.rb:75:in `initialize' /home/manderso/src/sup-git/mainline/lib/sup.rb:75:in `new' /home/manderso/src/sup-git/mainline/lib/sup.rb:75:in `reporting_thread' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:101:in `select' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:151:in `launch_another_thread' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-index-mode.rb:133:in `launch_next_thread_after' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-view-mode.rb:518:in `dispatch' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-view-mode.rb:490:in `delete_and_then' /home/manderso/src/sup-git/mainline/lib/sup/modes/thread-view-mode.rb:465:in `delete_and_next' /home/manderso/src/sup-git/mainline/lib/sup/mode.rb:51:in `send' /home/manderso/src/sup-git/mainline/lib/sup/mode.rb:51:in `handle_input' /home/manderso/src/sup-git/mainline/lib/sup/buffer.rb:265:in `handle_input' /home/manderso/src/sup-git/mainline/bin/sup:243 From rlane@club.cc.cmu.edu Thu Nov 19 23:51:02 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 19 Nov 2009 23:51:02 -0500 Subject: [sup-devel] Correct AM/PM selector in DATE_FORMAT In-Reply-To: <1258327627-sup-6728@kronos> References: <1258327627-sup-6728@kronos> Message-ID: <1258691207-sup-5245@zyrg.net> Excerpts from William Erik Baxter's message of Sun Nov 15 18:27:37 -0500 2009: > The selector case was incorrect in DATE_FORMAT: %P instead of %p. Branch date-format-fix, merged to master. git://github.com/rlane/sup From rlane@club.cc.cmu.edu Thu Nov 19 23:51:12 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 19 Nov 2009 23:51:12 -0500 Subject: [sup-devel] [PATCH] Make sup's textfield behave more like readline In-Reply-To: <1258618384-sup-3721@cammunism.org> References: <1258618384-sup-3721@cammunism.org> Message-ID: <1258691037-sup-6789@zyrg.net> Excerpts from Cameron Matheson's message of Thu Nov 19 03:13:51 -0500 2009: > Hello, > > I've noticed that when using the Ctrl-a keybinding in sup's textfield, > the entire input is deleted after typing anything if C-a was the first > key pressed. I've also been missing readline's C-u (deletes anything > before the cursor). I've attached a patch to fix/implement these > issues. The C-u implementation is a bit ugly, but I couldn't find a > better way to do it in ncurses. > > I also switched some of the key-code integers to character-literal > syntax as I thought that was a bit more readable. > > Thanks, > Cameron I definitely like the control key literals. I'm not an ncurses expert though, so I'll hold off on merging this to give one (anyone?) a chance to comment. Branch textfield-tweaks at git://github.com/rlane/sup From rlane@club.cc.cmu.edu Thu Nov 19 23:51:17 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 19 Nov 2009 23:51:17 -0500 Subject: [sup-devel] [PATCH] Comment tweak, XapianIndex doesn't use GDBM anymore since 4d82ef88 In-Reply-To: <1258500326-17510-1-git-send-email-ingmar@exherbo.org> References: <1258500326-17510-1-git-send-email-ingmar@exherbo.org> Message-ID: <1258691742-sup-2434@zyrg.net> Excerpts from Ingmar Vanhassel's message of Tue Nov 17 18:25:26 -0500 2009: > --- > lib/sup/xapian_index.rb | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > A really minor comment tweak, but I'd still like to see it fixed... :-) Branch xapian-comment-fix, merged to master at git://github.com/rlane/sup From stevenrwalter@gmail.com Fri Nov 20 09:07:14 2009 From: stevenrwalter@gmail.com (Steven Walter) Date: Fri, 20 Nov 2009 09:07:14 -0500 Subject: [sup-devel] [PATCH] Make sup's textfield behave more like readline In-Reply-To: <1258691037-sup-6789@zyrg.net> References: <1258618384-sup-3721@cammunism.org> <1258691037-sup-6789@zyrg.net> Message-ID: On Thu, Nov 19, 2009 at 11:51 PM, Rich Lane wrote: >> I also switched some of the key-code integers to character-literal >> syntax as I thought that was a bit more readable. >> >> Thanks, >> Cameron > > I definitely like the control key literals. I'm not an ncurses expert > though, so I'll hold off on merging this to give one (anyone?) a chance > to comment. I like it. Here's C-w. -- -Steven Walter "The rotter who simpers that he sees no difference between the power of the dollar and the power of the whip, ought to learn the difference on his own hide." -Francisco d'Anconia, Atlas Shrugged -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Implement-C-W-for-textfields.patch Type: text/x-patch Size: 874 bytes Desc: not available URL: From sup-bugs@masanjin.net Fri Nov 20 13:15:35 2009 From: sup-bugs@masanjin.net (anonymous) Date: Fri, 20 Nov 2009 18:15:35 +0000 Subject: [sup-devel] [issue21] "undefined method" error on sup-sync In-Reply-To: <1258740935.07.0.108445056294.issue21@masanjin.net> Message-ID: <1258740935.07.0.108445056294.issue21@masanjin.net> New submission from anonymous: When I run "sup-sync", regardless or the source (I tried IMAP and Maildir), I get this error: $ sup-sync Scanning maildir:/home/nedludd/.mail/INBOX... /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/source.rb:88:in `done?': undefined method `>=' for true:TrueClass (NoMethodError) from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/poll.rb:137:in `each_message_from' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:146:in `block in ' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `each' from /usr/lib/ruby/gems/1.9.1/gems/sup-0.9/bin/sup-sync:141:in `' from /usr/bin/supbin/sup-sync:19:in `load' from /usr/bin/supbin/sup-sync:19:in `
' [I'm on Arch with sup 0.9 and Ruby 1.9.1] ---------- messages: 36 nosy: anonymous priority: bug ruby_version: 1.9.1 status: unread sup_version: 0.9 title: "undefined method" error on sup-sync _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Sat Nov 21 14:33:47 2009 From: sup-bugs@masanjin.net (anonymous) Date: Sat, 21 Nov 2009 19:33:47 +0000 Subject: [sup-devel] [issue22] Remove ncurses gem dependency In-Reply-To: <1258832027.7.0.329764082628.issue22@masanjin.net> Message-ID: <1258832027.7.0.329764082628.issue22@masanjin.net> New submission from anonymous: On ubuntu 9.10 there is not gem for ncurses sudo gem install ncurses ERROR: could not find gem ncurses locally or in a repository instead you must install ncurses via apt-get sudo apt-get install libncurses-ruby now when installing a gem that depends on ncurses I still run into problems: sudo gem install sup ERROR: Error installing sup: sup requires ncurses (>= 0.9.1, runtime) Now try: sudo gem install --ignore-dependencies ncurses sup ... Now execute sup /usr/lib/ruby/1.8/rubygems.rb:827:in `report_activate_error': Could not find RubyGem ncurses (>= 0.9.1) (Gem::LoadError) from /usr/lib/ruby/1.8/rubygems.rb:261:in `activate' from /usr/lib/ruby/1.8/rubygems.rb:296:in `activate' from /usr/lib/ruby/1.8/rubygems.rb:295:in `each' from /usr/lib/ruby/1.8/rubygems.rb:295:in `activate' from /usr/lib/ruby/1.8/rubygems.rb:68:in `gem' from ../bin/sup:18 To fix this issue I had to manually edit the gemspec and comment out the ncurses dependency. I thought maybe it was only ubuntu that didn't have an ncurses gem so I opened a feature request with rubygems to maybe automatically comment out ignored dependencies and they replied that there is no such gem. http://rubyforge.org/tracker/?func=detail&atid=578&aid=27468&group_id=126 ---------- messages: 37 nosy: anonymous priority: bug ruby_version: 1.8.7 status: unread sup_version: 0.9 title: Remove ncurses gem dependency _________________________________________ Sup issue tracker _________________________________________ From tero@tilus.net Sun Nov 22 04:08:21 2009 From: tero@tilus.net (Tero Tilus) Date: Sun, 22 Nov 2009 11:08:21 +0200 Subject: [sup-devel] [issue22] Remove ncurses gem dependency In-Reply-To: <1258832027.7.0.329764082628.issue22@masanjin.net> References: <1258832027.7.0.329764082628.issue22@masanjin.net> Message-ID: <1258879815-sup-3348@tilus.net> Long story short: I believe there is no reason to remove dependency. If I don't hear anything that changes my opinion, I'll close this. anonymous, 2009-11-21 21:33: > On ubuntu 9.10 there is not gem for ncurses > sudo gem install ncurses > ERROR: could not find gem ncurses locally or in a repository Rubygems has its own repo where it looks for gems no matter what distro you are on. On Debian Lenny the situation with ncurses looks like this terotil at kuovi:~$ gem list --remote ncurses *** REMOTE GEMS *** terotil at kuovi:~$ gem list ncurses *** LOCAL GEMS *** ncurses (0.9.1) terotil at kuovi:~$ I've installed ncurses, but it is not available now. This is probably temporary and due to fact that gems.rubyforge.org has been repointed to the gemcutter.org. I just got this mail * * * From: noreply To: tero Date: Sat, 21 Nov 2009 22:51:51 -0500 (EST) Subject: [RubyForge] Gem index has been shut down Labels: inbox, rubyforge Hello - You're receiving this email because you're a RubyForge project admin and a recent change probably affects you. A few days ago we repointed gems.rubyforge.org to the gemcutter.org box. This means that Nick Quaranto's excellent gemcutter app is now indexing and serving all the gems - so rather than having two gem indexes, we now have one. As a consequence of this, when you release files to RubyForge you will probably also want to do a "gem push" to get them onto gemcutter and into the main gem index. Note that you can continue to release gems (and other files) at RubyForge; it's just that gems won't automatically make it into the main gem index. Yours, The RubyForge support team http://rubyforge.org/projects/support/ -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From tero@tilus.net Mon Nov 23 16:47:55 2009 From: tero@tilus.net (Tero Tilus) Date: Mon, 23 Nov 2009 23:47:55 +0200 Subject: [sup-devel] [issue22] Remove ncurses gem dependency In-Reply-To: <1258879815-sup-3348@tilus.net> References: <1258832027.7.0.329764082628.issue22@masanjin.net> <1258879815-sup-3348@tilus.net> Message-ID: <1259011961-sup-4195@tilus.net> Sorry about asking stupid things, but why is sup depending on gem ncurses bindings instead of the one bundled with Ruby? (besides the obvious fact that a gem can't quite "depend" on extensions like it depends on other gems) ps. FYI, the ncurses gem is back online. http://gems.rubyforge.org/gems/ncurses terotil at kuovi:~$ gem list --remote ncurses *** REMOTE GEMS *** ncurses (0.9.1) -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ From cam+sup@cammunism.org Mon Nov 23 17:25:53 2009 From: cam+sup@cammunism.org (Cameron Matheson) Date: Mon, 23 Nov 2009 15:25:53 -0700 Subject: [sup-devel] [issue22] Remove ncurses gem dependency In-Reply-To: <1259011961-sup-4195@tilus.net> References: <1258832027.7.0.329764082628.issue22@masanjin.net> <1258879815-sup-3348@tilus.net> <1259011961-sup-4195@tilus.net> Message-ID: <1259014446-sup-128@cammunism.org> Excerpts from Tero Tilus's message of Mon Nov 23 14:47:55 -0700 2009: > Sorry about asking stupid things, but why is sup depending on gem > ncurses bindings instead of the one bundled with Ruby? I think the Curses module is included in the ruby standard lib, but not Ncurses (which defines the Form library that sup uses) Cam From sup-bugs@masanjin.net Tue Nov 24 13:58:38 2009 From: sup-bugs@masanjin.net (anonymous) Date: Tue, 24 Nov 2009 18:58:38 +0000 Subject: [sup-devel] [issue23] Crash shortly after startup In-Reply-To: <1259089118.99.0.85235123109.issue23@masanjin.net> Message-ID: <1259089118.99.0.85235123109.issue23@masanjin.net> New submission from anonymous: I added an IMAP source to sup using sup-add, and after that, sup crashed with the attached exception-log.txt consistantly shortly after startup. Removing the IMAP source prevented the crash. ---------- files: exception-log.txt messages: 44 nosy: anonymous priority: bug ruby_version: 1.8.7 status: unread sup_version: 0.9 title: Crash shortly after startup _________________________________________ Sup issue tracker _________________________________________ -------------- next part -------------- --- ArgumentError from thread: poll after loading inbox :(null) isn't a valid argument for IndexReader.get_document(index) /var/lib/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]' /var/lib/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:421:in `[]' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /var/lib/gems/1.8/gems/ferret-0.11.6/lib/ferret/index.rb:413:in `[]' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:257:in `build_message' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/ferret_index.rb:256:in `build_message' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:94:in `do_poll' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:151:in `each_message_from' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/imap.rb:197:in `each' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/imap.rb:185:in `upto' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/imap.rb:185:in `each' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `send' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:139:in `each_message_from' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:93:in `do_poll' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `each' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:81:in `do_poll' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `synchronize' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:80:in `do_poll' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/modes/poll-mode.rb:15:in `poll' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/poll.rb:48:in `poll' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' /var/lib/gems/1.8/gems/sup-0.9/bin/sup:196 /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize' /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new' /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.9/bin/sup:196 /var/lib/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in `call' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in `call' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background' /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:77:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `initialize' /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `new' /var/lib/gems/1.8/gems/sup-0.9/lib/sup.rb:75:in `reporting_thread' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background' /var/lib/gems/1.8/gems/sup-0.9/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads' (eval):12:in `load_threads' /var/lib/gems/1.8/gems/sup-0.9/bin/sup:196 /var/lib/gems/1.8/bin/sup:19:in `load' /var/lib/gems/1.8/bin/sup:19 From sup-bugs@masanjin.net Wed Nov 25 12:26:37 2009 From: sup-bugs@masanjin.net (Gaute Hope) Date: Wed, 25 Nov 2009 17:26:37 +0000 Subject: [sup-devel] [issue24] sup doesn't understand inline encoding of file names In-Reply-To: <1259169997.29.0.0635477316095.issue24@masanjin.net> Message-ID: <1259169997.29.0.0635477316095.issue24@masanjin.net> New submission from Gaute Hope : When I receive emails with attachments with inline encoding such as: =?ISO-8859-1?Q?framside_sm=E5_stader_STORE_VYER.jpg?= sup should convert them to: framside_sm?_stader_STORE_VYER.jpg this has been happening on all different checkouts i've tried. - gaute ---------- messages: 45 nosy: gauteh priority: bug ruby_version: 1.8.7 status: unread sup_version: stettberger/time_marks rebased on recent next title: sup doesn't understand inline encoding of file names _________________________________________ Sup issue tracker _________________________________________ From sup-bugs@masanjin.net Wed Nov 25 12:41:44 2009 From: sup-bugs@masanjin.net (Gaute Hope) Date: Wed, 25 Nov 2009 17:41:44 +0000 Subject: [sup-devel] [issue25] config option: gpg encrypt on default In-Reply-To: <1259170904.16.0.17203785843.issue25@masanjin.net> Message-ID: <1259170904.16.0.17203785843.issue25@masanjin.net> New submission from Gaute Hope : Excuse me if this already exists; An config option to make sup already have the gpg: encrypt, signed, both or none set by default when replying or creating new messages. - gaute ---------- messages: 46 nosy: gauteh priority: feature request ruby_version: 1.8.7 status: unread sup_version: git title: config option: gpg encrypt on default _________________________________________ Sup issue tracker _________________________________________ From rlane@club.cc.cmu.edu Thu Nov 26 02:55:42 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Thu, 26 Nov 2009 02:55:42 -0500 Subject: [sup-devel] encoding branch Message-ID: <1259209351-sup-4273@zyrg.net> I've pushed a branch "encoding" to my repo (git://github.com/rlane/sup) which has many fixes for the encoding issues ruby 1.9 creates. It successfully indexes the Enron and SpamAssassin corpuses, as well as all my own mail. AFAIK we've taken care of all the other ruby 1.9 issues, so sup should work fine now. Let me know if it doesn't. Caveats: Xapian-only still contains debugging code, so it will be slower From tero@tilus.net Thu Nov 26 08:10:31 2009 From: tero@tilus.net (Tero Tilus) Date: Thu, 26 Nov 2009 15:10:31 +0200 Subject: [sup-devel] [issue24] sup doesn't understand inline encoding of file names In-Reply-To: <1259169997.29.0.0635477316095.issue24@masanjin.net> References: <1259169997.29.0.0635477316095.issue24@masanjin.net> Message-ID: <1259240959-sup-1704@tilus.net> Gaute Hope, 2009-11-25 19:26: > When I receive emails with attachments with inline encoding such as: > > =?ISO-8859-1?Q?framside_sm=E5_stader_STORE_VYER.jpg?= > > sup should convert them to: framside_sm?_stader_STORE_VYER.jpg Patch attached. -- Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-RFC-2047-decode-attachment-file-names.patch Type: application/octet-stream Size: 903 bytes Desc: not available URL: From rlane@club.cc.cmu.edu Fri Nov 27 14:42:34 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 27 Nov 2009 14:42:34 -0500 Subject: [sup-devel] [issue24] sup doesn't understand inline encoding of file names In-Reply-To: <1259240959-sup-1704@tilus.net> References: <1259169997.29.0.0635477316095.issue24@masanjin.net> <1259240959-sup-1704@tilus.net> Message-ID: <1259350580-sup-2386@zyrg.net> Excerpts from Tero Tilus's message of Thu Nov 26 08:10:31 -0500 2009: > Gaute Hope, 2009-11-25 19:26: > > When I receive emails with attachments with inline encoding such as: > > > > =?ISO-8859-1?Q?framside_sm=E5_stader_STORE_VYER.jpg?= > > > > sup should convert them to: framside_sm?_stader_STORE_VYER.jpg > > Patch attached. Branch decode-attachment-filenames, merged to master. From rlane@club.cc.cmu.edu Fri Nov 27 14:42:42 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 27 Nov 2009 14:42:42 -0500 Subject: [sup-devel] [PATCH] Make sup's textfield behave more like readline In-Reply-To: References: <1258618384-sup-3721@cammunism.org> <1258691037-sup-6789@zyrg.net> Message-ID: <1259350479-sup-2904@zyrg.net> Excerpts from Steven Walter's message of Fri Nov 20 09:07:14 -0500 2009: > On Thu, Nov 19, 2009 at 11:51 PM, Rich Lane wrote: > >> I also switched some of the key-code integers to character-literal > >> syntax as I thought that was a bit more readable. > >> > >> Thanks, > >> Cameron > > > > I definitely like the control key literals. I'm not an ncurses expert > > though, so I'll hold off on merging this to give one (anyone?) a chance > > to comment. > > I like it. Here's C-w. Committed to textfield-tweaks and branch merged to master. From rlane@club.cc.cmu.edu Fri Nov 27 16:14:03 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 27 Nov 2009 16:14:03 -0500 Subject: [sup-devel] pull request Message-ID: <1259356302-sup-3408@zyrg.net> Hi William, Please pull branch master from git://github.com/rlane/sup. This includes the following topic branches: xapian-comment-fix config-ask-for-to fix-bounce-cmd display-poll-labels decode-attachment-filenames textfield-tweaks thread-view-mode-undo date-format-fix From sup-bugs@masanjin.net Sat Nov 28 10:00:20 2009 From: sup-bugs@masanjin.net (Gaute Hope) Date: Sat, 28 Nov 2009 15:00:20 +0000 Subject: [sup-devel] [issue26] spam protection doesn't work good enough for bug tracker In-Reply-To: <1259420420.18.0.727314222342.issue26@masanjin.net> Message-ID: <1259420420.18.0.727314222342.issue26@masanjin.net> New submission from Gaute Hope : I.e.: http://masanjin.net/sup-bugs/issue6 or check the history of: http://masanjin.net/sup-bugs/issue11, i reverted the changes. - gaute ---------- keyword: bugtracker messages: 54 nosy: gauteh priority: bug ruby_version: ? status: unread sup_version: ? title: spam protection doesn't work good enough for bug tracker _________________________________________ Sup issue tracker _________________________________________ From wmorgan-sup@masanjin.net Mon Nov 30 08:42:57 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 30 Nov 2009 05:42:57 -0800 Subject: [sup-devel] pull request In-Reply-To: <1259356302-sup-3408@zyrg.net> References: <1259356302-sup-3408@zyrg.net> Message-ID: <1259588530-sup-8150@masanjin.net> Reformatted excerpts from Rich Lane's message of 2009-11-27: > Please pull branch master from git://github.com/rlane/sup. Pulled, and merged into next. Awesome stuff. Thanks everyone! -- William From sup-bugs@masanjin.net Mon Nov 30 17:01:49 2009 From: sup-bugs@masanjin.net (anonymous) Date: Mon, 30 Nov 2009 22:01:49 +0000 Subject: [sup-devel] [issue27] sup-sync crashes on gpg multipart signed message In-Reply-To: <1259618509.77.0.166512535731.issue27@masanjin.net> Message-ID: <1259618509.77.0.166512535731.issue27@masanjin.net> New submission from anonymous: sup-sync seems to crash on some mails. I've tried removing the first problematic mail, only to have it crash on the next one. I've attached the one this stacktrace is from. Maybe the issue is that the entire mail is multipart/mixed, with a first and a second part. The second part is a simple text/plain footer added by Mailman, but the first part is a multipart/signed thing (with a different boundary)? Updating message maildir:/Users/marten/Mail/INBOX.Lists.NotMuch#12594169380004531; labels inbox,unread,notmuch => inbox,unread,notmuch; offset 12594169380004531 => 12594169380004531 /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/message.rb:507:in `message_to_chunks': undefined method `downcase' for nil:NilClass (NoMethodError) from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/message.rb:440:in `message_to_chunks' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/message.rb:440:in `map' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/message.rb:440:in `message_to_chunks' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/message.rb:244:in `load_from_source!' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/message.rb:340:in `build_from_source' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/poll.rb:145:in `each_message_from' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:160:in `each' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:157:in `upto' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/maildir.rb:157:in `each' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `send' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/util.rb:560:in `__pass' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/util.rb:547:in `method_missing' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/poll.rb:139:in `each_message_from' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `send' from /Library/Ruby/Gems/1.8/gems/sup-0.9/lib/sup/util.rb:520:in `method_missing' from /Library/Ruby/Gems/1.8/gems/sup-0.9/bin/sup-sync:146 from /Library/Ruby/Gems/1.8/gems/sup-0.9/bin/sup-sync:141:in `each' from /Library/Ruby/Gems/1.8/gems/sup-0.9/bin/sup-sync:141 from /usr/bin/sup-sync:19:in `load' from /usr/bin/sup-sync:19 This stacktrace starts at line 507, I had to edit in something to get at the filename in of the mail in the maildir store, so it's not quite the same as in 0.9 gem, and probably not the same as in mainline/master. 507 on my system is: 500 ## if there's a filename, we'll treat it as an attachment. 501 if filename 502 # add this to the attachments list if its not a generated html 503 # attachment (should we allow images with generated names?). 504 # Lowercase the filename because searches are easier that way 505 @attachments.push filename.downcase unless filename =~ /^sup-attachment-/ 506 add_label :attachment unless filename =~ /^sup-attachment-/ 507 content_type = m.header.content_type.downcase || "application/unknown" # sometimes RubyMail gives us nil 508 [Chunk::Attachment.new(content_type, filename, m, sibling_types)] ---------- files: sup-problematic-mail messages: 55 nosy: anonymous priority: bug ruby_version: 1.8.7 status: unread sup_version: 0.9 title: sup-sync crashes on gpg multipart signed message _________________________________________ Sup issue tracker _________________________________________ -------------- next part -------------- A non-text attachment was scrubbed... Name: sup-problematic-mail Type: application/octet-stream Size: 4531 bytes Desc: not available URL: