From ezyang@MIT.EDU Mon Jun 1 19:18:26 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 01 Jun 2009 19:18:26 -0400 Subject: [sup-talk] Attempt at reply-from hook Message-ID: <1243898254-sup-7513@javelin> Hello, I'm attempting to create a reply-from.rb hook that looks like this: if message.has_label? 'twp': Person.from_address "Edward Z. Yang " end Unfortunately, it doesn't seem to work. I'm running sup v0.7. Cheers, Edward From dom.lobue@gmail.com Mon Jun 1 21:54:58 2009 From: dom.lobue@gmail.com (Dominic LoBue) Date: Mon, 1 Jun 2009 18:54:58 -0700 Subject: [sup-talk] Need help with OfflineIMAP integration and Iconv errors Message-ID: <93de24940906011854m70b8511cv139d0c7a830fc914@mail.gmail.com> Hello, Let me start off by saying that I am incredibly impressed with sup. I'm really looking forward to being able to replace Outlook with Sup, but I'm running into some problems that are preventing a complete transition. The first problem I'm having is when ferret is parsing through my emails to build its indicies I get numerous "warning: error (Iconv::IllegalSequence) decoding message body from X" errors, This prevents a lot of my email from showing up at all. Iconv has this problem from attempting to convert from Windows-1252, UTF-8, and iso-8859-1. While I doubt its the cause of the problem, I am downloading my email from the Exchange 2003 server at work via OfflineIMAP. The other major problem I'm running into is I can't figure out how to get Sup and OfflineIMAP talking together correctly so that labels and Seen flags are uploaded back to the Exchange server. I read that there were no plans to support uploading meta-data back to IMAP servers, so I was hoping that OfflineIMAP would sidestep the problem entirely. I searched the archives but I didn't find any examples of working configs. If anyone can point me to a working example I'd greatly appreciate it. I've tried both the latest official release and the latest revision uploaded to github as of 20 minutes ago. Any help would be greatly appreciated! Dominic LoBue From wmorgan-sup@masanjin.net Tue Jun 2 10:54:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 02 Jun 2009 07:54:23 -0700 Subject: [sup-talk] utf patch needs work, i think In-Reply-To: <1243731497-sup-5619@entry> References: <1243539136-sup-9008@ntdws12.chass.utoronto.ca> <1243553511-sup-472@ntdws12.chass.utoronto.ca> <1243731497-sup-5619@entry> Message-ID: <1243954348-sup-1644@entry> Reformatted excerpts from William Morgan's message of 2009-05-30: > I suspect there's something like a tab or a weird character coming out > of the decoding (which appears to be some non-utf16 text claiming a > utf16 big-endian encoding) that is screwing with Ncurses. I've committed some changes that should remove invalid characters for your encoding before display. I think this should help. Also various display tweaks to account for multibyte characters. I still see some inconsistencies but I think it's getting better. That message renders "fine" for me now. (A bunch of nonsense Chinese characters mixed with some boxes.) I'm using utf8 in a gnome-terminal. -- William From marka@pobox.com Tue Jun 2 12:29:13 2009 From: marka@pobox.com (Mark Alexander) Date: Tue, 02 Jun 2009 09:29:13 -0700 Subject: [sup-talk] [PATCH] Handle nil charset on attachments. Message-ID: <1243959935-sup-8233@r50p> I updated to the latest 'next' branch of sup this morning, and immediately ran into a crash when viewing a message with an attachement, which was probably sent by an Outlook user. The crash was due to a nil charset; this patch fixes the crash. --- 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 3f57346..41d924b 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -98,7 +98,7 @@ EOS text = case @content_type when /^text\/plain\b/ - Iconv.easy_decode $encoding, encoded_content.charset, @raw_content + Iconv.easy_decode $encoding, encoded_content.charset || $encoding, @raw_content else HookManager.run "mime-decode", :content_type => content_type, :filename => lambda { write_to_disk }, From wmorgan-sup@masanjin.net Tue Jun 2 12:46:00 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 02 Jun 2009 09:46:00 -0700 Subject: [sup-talk] [PATCH] Handle nil charset on attachments. In-Reply-To: <1243959935-sup-8233@r50p> References: <1243959935-sup-8233@r50p> Message-ID: <1243961075-sup-6760@entry> Reformatted excerpts from Mark Alexander's message of 2009-06-02: > I updated to the latest 'next' branch of sup this morning, and > immediately ran into a crash when viewing a message with an > attachement, which was probably sent by an Outlook user. The crash > was due to a nil charset; this patch fixes the crash. Sloppy of me. Applied, thanks! -- William From ingmar.stdin@gmail.com Tue Jun 2 18:09:16 2009 From: ingmar.stdin@gmail.com (Ingmar Vanhassel) Date: Wed, 03 Jun 2009 00:09:16 +0200 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1243898254-sup-7513@javelin> References: <1243898254-sup-7513@javelin> Message-ID: <1243980495-sup-7229@cannonball> Excerpts from Edward Z. Yang's message of Tue Jun 02 01:18:26 +0200 2009: > Hello, > > I'm attempting to create a reply-from.rb hook that looks like this: > > if message.has_label? 'twp': > Person.from_address "Edward Z. Yang " > end if message.has_label? twp Person.from_address "Edward Z. Yang " end > Unfortunately, it doesn't seem to work. I'm running sup v0.7. If the above doesn't work, post some relevant error output. > Cheers, > Edward Regards, Ingmar From ezyang@MIT.EDU Tue Jun 2 22:54:02 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Tue, 02 Jun 2009 22:54:02 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1243980495-sup-7229@cannonball> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> Message-ID: <1243997614-sup-7485@javelin> Excerpts from Ingmar Vanhassel's message of Tue Jun 02 18:09:16 -0400 2009: > If the above doesn't work, post some relevant error output. It silently fails. Is there any Sup way of making debug messages in hooks? Cheers, Edward From bwalton@artsci.utoronto.ca Wed Jun 3 07:44:24 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Wed, 03 Jun 2009 07:44:24 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1243997614-sup-7485@javelin> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> Message-ID: <1244029436-sup-6141@ntdws12.chass.utoronto.ca> Excerpts from Edward Z. Yang's message of Tue Jun 02 22:54:02 -0400 2009: > It silently fails. Is there any Sup way of making debug messages in > hooks? Redwood::log "my message" Then, look in the log buffer. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ezyang@MIT.EDU Wed Jun 3 13:39:40 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 03 Jun 2009 13:39:40 -0400 Subject: [sup-talk] Sup is hanging Message-ID: <1244050695-sup-5990@javelin> Hey all, Somehow, I messed something up really bad, and now, whenever Sup attempts to poll for new messages, it hang completely, spinning the CPU. I've let it run for an appreciable amount of time, and haven't seen any change. I was wondering how I could fix this, or go about debugging it. There also seems to be a single mail source at fault, but I can't remove it without having Sup complain at me. Right now, I'm running sup as -no. Thanks, Edward From wmorgan-sup@masanjin.net Wed Jun 3 14:11:28 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 03 Jun 2009 11:11:28 -0700 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244050695-sup-5990@javelin> References: <1244050695-sup-5990@javelin> Message-ID: <1244052318-sup-6595@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-03: > Somehow, I messed something up really bad, and now, whenever Sup > attempts to poll for new messages, it hang completely, spinning the > CPU. I've let it run for an appreciable amount of time, and haven't > seen any change. I was wondering how I could fix this, or go about > debugging it. Is the curses interface hung? If not, can you see if there's activity in the poll mode or the log mode buffers? (Hit ; if you're running from git, or B if you're running 0.7.) It might be that you've somehow reset the recorded offset for a very large source, so Sup is polling a lot of stuff in the background. If it's completely hung (which would be weird), try first disabling your hooks (move them from ~/.sup/hooks to another directory) and see if that helps. If not, please describe the behavior of running sup-sync. -- William From ezyang@MIT.EDU Wed Jun 3 14:21:35 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 03 Jun 2009 14:21:35 -0400 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244050695-sup-5990@javelin> References: <1244050695-sup-5990@javelin> Message-ID: <1244053108-sup-4982@javelin> The current working theory (based on strace'ing and lsof) is that Sup is hanging on a select() call that doesn't have any timeout. The reason why this is hanging is because between opening the connection and closing it, Sup does some ridiculously slow message parsing code (that really thrashes the CPU) and by the time it's done the server has closed the connection (but we don't know about it). The fix would probably be to always set a timeout, but I don't know what code needs to be fixed for that. Cheers, Edward From ezyang@MIT.EDU Wed Jun 3 14:26:44 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 3 Jun 2009 14:26:44 -0400 (EDT) Subject: [sup-talk] Sup is hanging In-Reply-To: <1244052318-sup-6595@entry> References: <1244050695-sup-5990@javelin> <1244052318-sup-6595@entry> Message-ID: On Wed, 3 Jun 2009, William Morgan wrote: > Is the curses interface hung?> Yep. > If it's completely hung (which would be weird), try first disabling your > hooks (move them from ~/.sup/hooks to another directory) and see if that > helps. If not, please describe the behavior of running sup-sync. I can try that. I've described the behavior of sup-sync in my other email. Cheers, Edward From ezyang@MIT.EDU Wed Jun 3 14:45:59 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 3 Jun 2009 14:45:59 -0400 (EDT) Subject: [sup-talk] Sup is hanging In-Reply-To: <1244053108-sup-4982@javelin> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> Message-ID: Also, if it helps, here's the backtrace for when it's hanging on the select: /usr/lib/ruby/1.8/monitor.rb:102:in `stop': Interrupt from /usr/lib/ruby/1.8/monitor.rb:102:in `wait' from /usr/lib/ruby/1.8/net/imap.rb:972:in `get_tagged_response' from /usr/lib/ruby/1.8/net/imap.rb:1032:in `send_command' from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/1.8/net/imap.rb:1017:in `send_command' from /usr/lib/ruby/1.8/net/imap.rb:409:in `examine' from /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' from /usr/lib/ruby/1.8/net/imap.rb:407:in `examine' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:145:in `unsynchronized_scan_mailbox' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:322:in `safely' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:144:in `unsynchronized_scan_mailbox' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:192:in `unsynchronized_start_offset' from (eval):3:in `start_offset' from (eval):3:in `synchronize' from (eval):3:in `start_offset' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `send' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `__pass' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:531:in `method_missing' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:147 from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:160:in `add_messages_from' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:187:in `each' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:175:in `upto' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/imap.rb:175:in `each' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `send' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:544:in `__pass' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:531:in `method_missing' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/poll.rb:141:in `add_messages_from' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `send' from /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `method_missing' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:140 from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:135:in `each' from /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup-sync:135 from /var/lib/gems/1.8/bin/sup-sync:19:in `load' from /var/lib/gems/1.8/bin/sup-sync:19 Cheers, Edward From wmorgan-sup@masanjin.net Wed Jun 3 17:36:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 03 Jun 2009 14:36:15 -0700 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244053108-sup-4982@javelin> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> Message-ID: <1244064889-sup-9506@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-03: > The current working theory (based on strace'ing and lsof) is that Sup > is hanging on a select() call that doesn't have any timeout. The > reason why this is hanging is because between opening the connection > and closing it, Sup does some ridiculously slow message parsing code > (that really thrashes the CPU) and by the time it's done the server > has closed the connection (but we don't know about it). That may all be true, but I'd be surprised if a) Sup didn't know that the server had closed the connection, and b) that this would cause the whole thing to hang. When you don't use -n, does Sup still lock up? -- William From ezyang@MIT.EDU Wed Jun 3 17:48:56 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 3 Jun 2009 17:48:56 -0400 (EDT) Subject: [sup-talk] Sup is hanging In-Reply-To: <1244064889-sup-9506@entry> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> Message-ID: On Wed, 3 Jun 2009, William Morgan wrote: > Reformatted excerpts from Edward Z. Yang's message of 2009-06-03: >> The current working theory (based on strace'ing and lsof) is that Sup >> is hanging on a select() call that doesn't have any timeout. The >> reason why this is hanging is because between opening the connection >> and closing it, Sup does some ridiculously slow message parsing code >> (that really thrashes the CPU) and by the time it's done the server >> has closed the connection (but we don't know about it). > > That may all be true, but I'd be surprised if a) Sup didn't know that > the server had closed the connection, and It doesn't have anything to do with Sup: the system select() call is hanging; Sup (and Ruby for that matter) is out of the equation. This might be IMAP server weirdness, but that shouldn't cause Sup to freeze. > b) that this would cause the > whole thing to hang. That's what I find surprising, since Sup is multithreaded. I suppose all of the threads are blocking on the select. Sup hangs without -n. (it always hangs after it's "done fetching IMAP headers"). "done fetching IMAP headers" is the last message we get. The behavior seems to be: 1. Log reports "done fetching IMAP headers" 2. Sup begins malloc'ing like crazy. sup-sync still is able to catch signals and if you kill it you find that it's somewhere in lib/sup/message.rb, message_to_chunks. sup doesn't respond to Ctrl+C 3. After some minutes, CPU usage dies off, but Sup doesn't unfreeze. strace indicates that sup/sup-sync is waiting on a select(), and that the descriptors are TCP connections to the IMAP server. Cheers, Edward From ezyang@MIT.EDU Wed Jun 3 18:00:06 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 3 Jun 2009 18:00:06 -0400 (EDT) Subject: [sup-talk] Sup is hangingy In-Reply-To: <1244064889-sup-9506@entry> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> Message-ID: Oh hey, I managed to kill Sup: ezyang at javelin:~$ sup [Wed Jun 03 17:42:43 -0400 2009] using character set encoding "UTF-8" [Wed Jun 03 17:42:44 -0400 2009] dynamically loading setlocale() from libc.so.6 [Wed Jun 03 17:42:44 -0400 2009] setting locale... [Wed Jun 03 17:42:44 -0400 2009] locking /home/ezyang/.sup/lock... [Wed Jun 03 17:42:44 -0400 2009] crypto: detected gpg binary in /usr/bin/gpg [Wed Jun 03 17:42:44 -0400 2009] loading index... [Wed Jun 03 17:42:44 -0400 2009] loaded index of 20188 messages [Wed Jun 03 17:42:44 -0400 2009] starting curses [Wed Jun 03 17:54:47 -0400 2009] stopped cursing [Wed Jun 03 17:54:47 -0400 2009] oh crap, an exception [Wed Jun 03 17:54:47 -0400 2009] unlocking /home/ezyang/.sup/lock... ---------------------------------------------------------------- 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 ---------------------------------------------------------------- --- Interrupt from thread: main /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:109:in `write' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:245:in `draw_line_from_string' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:182:in `draw_line' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in `draw' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in `each' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in `draw' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:99:in `draw' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:303:in `draw_screen' /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:308 /var/lib/gems/1.8/bin/sup:19:in `load' /var/lib/gems/1.8/bin/sup:19 This seems... unrelated. Cheers, Edward From ezyang@MIT.EDU Wed Jun 3 21:26:01 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 03 Jun 2009 21:26:01 -0400 Subject: [sup-talk] Sup is hangingy In-Reply-To: References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> Message-ID: <1244078482-sup-4986@javelin> Ok, after a bit of fiddling, I've managed to figure out that this is two problems, not one. The first is related to a naughty IMAP server which simply stops responding after a certain number of seconds. Unfortunately, this is my workplace's IMAP server, so I can't give you a test environment. Furthermore, the code that would be appropriate to change is in Net::Imap, and thus is not easily accessible by Sup. I've worked around this by making it an unusual source. The second is a large amount of CPU thrashing as Sup parses messages. This is something we can fix, and I hope to do some more poking to help make Sup run faster in this respect. The basic behavior is Sup repeatedly allocates some amount of memory, reallocates it twice (quadrupling it in size to about 4MB), deallocates, and then does it again. I'm running ruby-prof in hopes of tickling this again. Unlike the hung IMAP server, this eventually finishes, but it is extremely obnoxious when it happens and blocks everything else. It commonly occurs when I open an email message. Cheers, Edward From ezyang@MIT.EDU Wed Jun 3 21:53:12 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 3 Jun 2009 21:53:12 -0400 (EDT) Subject: [sup-talk] Sup is hangingyy In-Reply-To: <1244078482-sup-4986@javelin> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> <1244078482-sup-4986@javelin> Message-ID: On Wed, 3 Jun 2009, Edward Z. Yang wrote: > The second is a large amount of CPU thrashing as Sup parses messages. This > is something we can fix, and I hope to do some more poking to help make > Sup run faster in this respect. The basic behavior is Sup repeatedly > allocates some amount of memory, reallocates it twice (quadrupling it > in size to about 4MB), deallocates, and then does it again. I'm running > ruby-prof in hopes of tickling this again. Unlike the hung IMAP server, > this eventually finishes, but it is extremely obnoxious when it happens > and blocks everything else. It commonly occurs when I open an email message. Here we go: http://web.mit.edu/~ezyang/Public/sup-performance.png Look at String::=~. Definitely not acceptable. Cheers, Edward From ross.macduff@gmail.com Wed Jun 3 22:04:32 2009 From: ross.macduff@gmail.com (Ross Macduff) Date: Wed, 3 Jun 2009 22:04:32 -0400 Subject: [sup-talk] (no subject) In-Reply-To: <200906010101.n5111ADJ007928@ntdws12.chass.utoronto.ca> References: <200906010101.n5111ADJ007928@ntdws12.chass.utoronto.ca> Message-ID: I merged this patch into the mainline from gitorius. Works as expected. Definitely a nice addition. Ross On Sun, May 31, 2009 at 9:01 PM, Ben Walton wrote: > >From 702b2cc1e652c1f20f4280b11355cb337291df87 Mon Sep 17 00:00:00 2001 > From: Ben Walton > Date: Sun, 31 May 2009 20:37:11 -0400 > Subject: [PATCH] Add bounce message feature > > By pressing ! in thread view mode, a message can be re-injected to the > mail system without any modification. ?The interesting/useful property > of this feature is that, because only the envelope sender changes, the > mail will show up at the new destination with the original From: > header. ?A use case for this is redirecting mail sent to an individual > into a ticket system such that the original sender gets the > auto-response. > > Signed-off-by: Ben Walton > --- > ?lib/sup/modes/thread-view-mode.rb | ? 19 +++++++++++++++++++ > ?1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb > index 42c6280..4737dde 100644 > --- a/lib/sup/modes/thread-view-mode.rb > +++ b/lib/sup/modes/thread-view-mode.rb > @@ -41,6 +41,7 @@ EOS > ?# ? ?k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N' > ? ? k.add :reply, "Reply to a message", 'r' > ? ? k.add :forward, "Forward a message or attachment", 'f' > + ? ?k.add :bounce, "Bounce message to other recipient(s)", '!' > ? ? k.add :alias, "Edit alias/nickname for a person", 'i' > ? ? k.add :edit_as_new, "Edit message as new", 'D' > ? ? k.add :save_to_disk, "Save message/attachment to disk", 's' > @@ -172,6 +173,24 @@ EOS > ? ? end > ? end > > + ?def bounce > + ? ?m = @message_lines[curpos] or return > + ? ?to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return > + > + ? ?if BufferManager.ask_yes_or_no "Really bounce to #{to.join(', ')}?" > + ? ? ?cmd = "sendmail -oem -i #{to.map { |t| t.email}.join(' ')}" > + ? ? ?begin > + ? ? ? ?IO.popen(cmd, 'w') do |sm| > + ? ? ? ? ?sm.puts m.raw_message > + ? ? ? ?end > + ? ? ? ?raise SendmailCommandFailed, "Couldn't execute #{cmd}" unless $? == 0 > + ? ? ?rescue SystemCallError, SendmailCommandFailed => e > + ? ? ? ?Redwood::log "Problem sending mail: #{e.message}" > + ? ? ? ?BufferManager.flash "Problem sending mail: #{e.message}" > + ? ? ?end > + ? ?end > + ?end > + > ? include CanAliasContacts > ? def alias > ? ? p = @person_lines[curpos] or return > -- > 1.6.3 > > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk > From wmorgan-sup@masanjin.net Wed Jun 3 22:11:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 03 Jun 2009 19:11:31 -0700 Subject: [sup-talk] Sup is hanging In-Reply-To: References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> Message-ID: <1244081477-sup-4133@entry> [resent to list] Reformatted excerpts from Edward Z. Yang's message of 2009-06-03: > That's what I find surprising, since Sup is multithreaded. I suppose > all of the threads are blocking on the select. It's possible... Ruby does use green threads and a GIL, so there's always the possibility that something in C land will block all Ruby threads, but my impression was that that was an issue mainly with third-party libraries. I believe that Net::IMAP is pure Ruby, thus using the core Ruby IO mechanisms, and I thought those were pretty good about being preemptible. Curious! -- William From wmorgan-sup@masanjin.net Wed Jun 3 22:12:25 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 03 Jun 2009 19:12:25 -0700 Subject: [sup-talk] Sup is hangingy In-Reply-To: References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> Message-ID: <1244081540-sup-7695@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-03: > Oh hey, I managed to kill Sup: > > ezyang at javelin:~$ sup > [Wed Jun 03 17:42:43 -0400 2009] using character set encoding "UTF-8" > [Wed Jun 03 17:42:44 -0400 2009] dynamically loading setlocale() from > libc.so.6 > [Wed Jun 03 17:42:44 -0400 2009] setting locale... > [Wed Jun 03 17:42:44 -0400 2009] locking /home/ezyang/.sup/lock... > [Wed Jun 03 17:42:44 -0400 2009] crypto: detected gpg binary in > /usr/bin/gpg > [Wed Jun 03 17:42:44 -0400 2009] loading index... > [Wed Jun 03 17:42:44 -0400 2009] loaded index of 20188 messages > [Wed Jun 03 17:42:44 -0400 2009] starting curses > [Wed Jun 03 17:54:47 -0400 2009] stopped cursing > [Wed Jun 03 17:54:47 -0400 2009] oh crap, an exception > [Wed Jun 03 17:54:47 -0400 2009] unlocking /home/ezyang/.sup/lock... > ---------------------------------------------------------------- > 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 > ---------------------------------------------------------------- > --- Interrupt from thread: main > > /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in > `method_missing' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:109:in `write' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:245:in > `draw_line_from_string' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:182:in > `draw_line' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in > `draw' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in > `each' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/scroll-mode.rb:48:in > `draw' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:99:in `draw' > /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:303:in > `draw_screen' > /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:308 > /var/lib/gems/1.8/bin/sup:19:in `load' > /var/lib/gems/1.8/bin/sup:19 > > This seems... unrelated. > > Cheers, > Edward -- William From wmorgan-sup@masanjin.net Wed Jun 3 22:13:58 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 03 Jun 2009 19:13:58 -0700 Subject: [sup-talk] Sup is hangingy In-Reply-To: References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> Message-ID: <1244081553-sup-5115@entry> [sorry about that last one. really not doing too well with the ol' email today.] Reformatted excerpts from Edward Z. Yang's message of 2009-06-03: > --- Interrupt from thread: main > > /usr/lib/ruby/gems/1.8/gems/ncurses-0.9.1/lib/ncurses.rb:71:in `method_missing' [snip] > > This seems... unrelated. This looks like a ctrl-c that got caught by an ncurses thread. I agree, seems unrelated. -- William From wmorgan-sup@masanjin.net Wed Jun 3 23:05:07 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Wed, 03 Jun 2009 20:05:07 -0700 Subject: [sup-talk] Need help with OfflineIMAP integration and Iconv errors In-Reply-To: <93de24940906011854m70b8511cv139d0c7a830fc914@mail.gmail.com> References: <93de24940906011854m70b8511cv139d0c7a830fc914@mail.gmail.com> Message-ID: <1244084554-sup-6080@entry> Hi Dominic, Reformatted excerpts from Dominic LoBue's message of 2009-06-01: > Let me start off by saying that I am incredibly impressed with sup. Great! That's nice to hear. > The first problem I'm having is when ferret is parsing through my > emails to build its indicies I get numerous "warning: error > (Iconv::IllegalSequence) decoding message body from X" errors, This > prevents a lot of my email from showing up at all. This is just a warning when iconv gets finnicky. It shouldn't prevent email from being indexed or from appearing. > I read that there were no plans to support uploading meta-data back to > IMAP servers, so I was hoping that OfflineIMAP would sidestep the > problem entirely. I searched the archives but I didn't find any > examples of working configs. If anyone can point me to a working > example I'd greatly appreciate it. Maildir doesn't help you either. Sup doesn't export its message state back to the source for any source type, except for certain limited cases with sup-sync-back. -- William From bwalton@artsci.utoronto.ca Thu Jun 4 12:03:10 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 4 Jun 2009 12:03:10 -0400 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and body). Message-ID: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca> This is an augment of the already existing view header (H) command, but allows viewing of all mime parts in their raw form, etc. Signed-off-by: Ben Walton --- lib/sup/modes/thread-view-mode.rb | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 42c6280..8de7ab0 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -27,6 +27,7 @@ EOS register_keymap do |k| k.add :toggle_detailed_header, "Toggle detailed header", 'h' k.add :show_header, "Show full message header", 'H' + k.add :show_message, "Show full message (raw form)", 'V' k.add :activate_chunk, "Expand/collapse or activate item", :enter k.add :expand_all_messages, "Expand/collapse all messages", 'E' k.add :edit_draft, "Edit draft", 'e' @@ -134,6 +135,13 @@ EOS end end + def show_message + m = @message_lines[curpos] or return + BufferManager.spawn_unless_exists("Raw message for #{m.id}") do + TextMode.new m.raw_message + end + end + def toggle_detailed_header m = @message_lines[curpos] or return @layout[m].state = (@layout[m].state == :detailed ? :open : :detailed) -- 1.6.3 From wmorgan-sup@masanjin.net Thu Jun 4 12:09:40 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 04 Jun 2009 09:09:40 -0700 Subject: [sup-talk] Sup is hanging In-Reply-To: References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> <1244078482-sup-4986@javelin> Message-ID: <1244130722-sup-4496@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-03: > http://web.mit.edu/~ezyang/Public/sup-performance.png > > Look at String::=~. Definitely not acceptable. Doing some profiling on my end, it looks like the majority of IMAP syncing time is spent in these five methods: Redwood::Index#load_entry_for_id (22%) Redwood::IMAP#load_message (25%) Redwood::Message#message_to_chunks (16.5%) Redwood::IMAP#load_header (14%) Redwood::Index#sync_message (13%) Four of those are essentially wrappers around IMAP or Ferret methods. The Sup-specific one is Message#message_to_chunks. But message_to_chunks and its callee text_to_chunks doesn't seem to have a major culprits. String#=~ only takes 2.3% of the CPU time, and a chunk of that is coming from RubyMail. Just for good measure, I "manually" measured the individual regexen in text_to_chunks. After parsing 100 messages from an IMAP server, which took 1m27s for me, I got: time (s) calls bqp = 0.00854 / 1789 = 209411.2 calls/second n1 = 0.00218 / 313 = 143709.8 calls/second qsp = 0.03212 / 1923 = 59873.0 calls/second n2 = 0.00202 / 312 = 154226.4 calls/second empty = 0.00061 / 90 = 146341.5 calls/second sp = 0.02570 / 1927 = 74995.1 calls/second qp = 0.03392 / 4459 = 131452.5 calls/second The names are abbreviations for the various regexen in that method. You can see that the cumulative time spent on any one regex is at most .034 seconds (qp, which is QUERY_PATTERN), and that the slowest one is qsp, QUERY_START_PATTERN. Incidentally, I can parse IMAP mailboxes at a little over 1 message/s, and mbox files at ~50 messages/second, which also suggests that the IMAP libraries are the biggest time sink here. This is all with ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]), Sup git next. Now that's all CPU stuff. There might be memory blowup issues. If nothing else, Sup leaks memory over time, but fixing that involves the getting into the hellish world of Ruby<->C land or the even more hellish internals of MRI, so I've been loathe to start down that path. You might be able to speed up sup-sync runs on IMAP by threading the network access and the parsing. But the IMAP connection seems pretty CPU-heavy so who knows. None of this answers the original question of why all Ruby threads block when Sup waits for a response from IMAP. Since I'm pretty sure the IMAP libraries are all Ruby (why they're so slow!), and that core Ruby IO should be nonblocking, this might be an interpreter bug. Are you able to pinpoint what part of MRI is blocking? -- William From mailinglist@flasht.de Thu Jun 4 17:28:58 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Thu, 04 Jun 2009 23:28:58 +0200 Subject: [sup-talk] Toggle expand/collapse of a message in threadview Message-ID: <1244150874-sup-6554@thinkpad-ubuntu> Hi! I've been wondering: Is there a way to expand/collsape the current message I'm reading when in the middle of it? I know I can press ENTER to toggle it when I'm hovering the message's header, but is it possible when I'm in the middle of a message? When reading long threads with long messages, this would really be handy, as for now I always have to go up or toggle all messages and work my way through a thread like that. It would be nice if I could simply press a key to toggle the current message I'm looking at (where the current highlighted line belongs to). Maybe I'm blind and simply haven't found this feature? Can't find it in the help menu. Thanks, Christopher. -- ================================ Christopher Bertels http://www.adztec-independent.de From wmorgan-sup@masanjin.net Thu Jun 4 23:38:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 04 Jun 2009 20:38:23 -0700 Subject: [sup-talk] Toggle expand/collapse of a message in threadview In-Reply-To: <1244150874-sup-6554@thinkpad-ubuntu> References: <1244150874-sup-6554@thinkpad-ubuntu> Message-ID: <1244172932-sup-1101@entry> Reformatted excerpts from Christopher Bertels's message of 2009-06-04: > Is there a way to expand/collsape the current message I'm reading when > in the middle of it? Good idea. I've changed this in git. Pressing enter on a text region now collapses the message. Behavior of enter on quotes, signatures, attachments, etc. is unchanged. Also, collapsing a message will make the cursor jump to the next open message. So you should be able to scan rapidly through a thread one message at a time by hitting enter to collapse it or 'n' to leave open. (And then 'p' and 'n' to review all open messages.) -- William From ezyang@MIT.EDU Fri Jun 5 01:08:10 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 05 Jun 2009 01:08:10 -0400 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244130722-sup-4496@entry> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> <1244078482-sup-4986@javelin> <1244130722-sup-4496@entry> Message-ID: <1244177820-sup-6051@javelin> Hi William, I tickled the bug and took a more careful look at the message that had triggered it, and noticed that it was an auto-generated commit message that was really long. So one possible stop-gap would be just to detect if a message is long and disable quoting if that was the case (a long message would be, say, one over 100KB). There is also a possibility that the commit message had some pathological backtracking built into it. Excerpts from William Morgan's message of Thu Jun 04 12:09:40 -0400 2009: > Redwood::Index#load_entry_for_id (22%) > Redwood::IMAP#load_message (25%) > Redwood::Message#message_to_chunks (16.5%) > Redwood::IMAP#load_header (14%) > Redwood::Index#sync_message (13%) Ok, so this isn't the same spread as when I managed to make Sup hang, so this isn't quite the same. > Now that's all CPU stuff. There might be memory blowup issues. If > nothing else, Sup leaks memory over time, but fixing that involves the > getting into the hellish world of Ruby<->C land or the even more hellish > internals of MRI, so I've been loathe to start down that path. Sup memory leakage has not been a problem; Sup will hang on a poll asynchronously (as in, UI is still responsive, but I get no more new messages) often enough that I have to quit and start sup up again. > None of this answers the original question of why all Ruby threads block > when Sup waits for a response from IMAP. Since I'm pretty sure the IMAP > libraries are all Ruby (why they're so slow!), and that core Ruby IO > should be nonblocking, this might be an interpreter bug. Are you able to > pinpoint what part of MRI is blocking? Not yet. I don't know Ruby threads well enough to know how to get more fine-grained information on thread mutex/blocking interaction. To summarize: 1. If I thrash message_to_chunks() with a very long message, I cause sup to hang. * If this case is only caused by long messages, implement a hueristic to prevent quoting from happening to long messages. * If there is something specific about the message that causes massive back-tracking, fix the regex. In either case, message_to_chunks() should not block the rest of the interface (although if we fix either or the two sub-points, this may not be a noticeable problem). 2. If an IMAP connection hangs, it occasionally causes all of Sup to block (this is rare, and comes from a pathological IMAP server. I think the ops administering the naughty IMAP server fixed it, so I am no longer seeing this hang). 3. Under less pathological cases, an IMAP connection can hang, and asynchronously blocks any further polling from taking place, resulting in no new messages. This happens commonly for me. Cheers, Edward From ezyang@MIT.EDU Fri Jun 5 01:24:36 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 05 Jun 2009 01:24:36 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244029436-sup-6141@ntdws12.chass.utoronto.ca> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> Message-ID: <1244179379-sup-6675@javelin> Excerpts from Ben Walton's message of Wed Jun 03 07:44:24 -0400 2009: > Redwood::log "my message" > > Then, look in the log buffer. I tried probing several ways. - The reply-from.rb hook is being called. - The message variable does exist. - The message.has_label? "mylabel" returns false, as the body of the if statement never gets logged. (My contention is that the message very clearly has that label, so wtf). - It is difficult to get a str representation of the message I am still stymied. Cheers, Edward From nicolas.pouillard@gmail.com Fri Jun 5 03:15:02 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Fri, 05 Jun 2009 09:15:02 +0200 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and body). In-Reply-To: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca> References: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1244186006-sup-1399@ausone.inria.fr> Excerpts from Ben Walton's message of Thu Jun 04 18:03:10 +0200 2009: > This is an augment of the already existing view header (H) command, > but allows viewing of all mime parts in their raw form, etc. I usually use '|' followed by "cat" or "less" for this purpose, but maybe a dedicated key-binding is better. -- Nicolas Pouillard http://nicolaspouillard.fr From mailinglist@flasht.de Fri Jun 5 07:02:13 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Fri, 05 Jun 2009 13:02:13 +0200 Subject: [sup-talk] Toggle expand/collapse of a message in threadview In-Reply-To: <1244172932-sup-1101@entry> References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry> Message-ID: <1244199699-sup-8610@thinkpad-ubuntu> Oh cool! Thanks, works great and exactly what I wanted! :) Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009: > Reformatted excerpts from Christopher Bertels's message of 2009-06-04: > > Is there a way to expand/collsape the current message I'm reading when > > in the middle of it? > > Good idea. I've changed this in git. Pressing enter on a text region now > collapses the message. Behavior of enter on quotes, signatures, > attachments, etc. is unchanged. > > Also, collapsing a message will make the cursor jump to the next open > message. So you should be able to scan rapidly through a thread one > message at a time by hitting enter to collapse it or 'n' to leave open. > (And then 'p' and 'n' to review all open messages.) -- ================================ Christopher Bertels http://www.adztec-independent.de From mailinglist@flasht.de Fri Jun 5 07:09:34 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Fri, 05 Jun 2009 13:09:34 +0200 Subject: [sup-talk] Toggle expand/collapse of a message in threadview In-Reply-To: <1244172932-sup-1101@entry> References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry> Message-ID: <1244199822-sup-1224@thinkpad-ubuntu> Actually, now that I've been using it a little more, I think it would be nicer that when pressing enter on a collapsed message, the cursor would stay at the header of that expanded message instead of moving to the next message header. Right now, it's always moving to the next message, even when expanding a collapsed message to read it. Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009: > Reformatted excerpts from Christopher Bertels's message of 2009-06-04: > > Is there a way to expand/collsape the current message I'm reading when > > in the middle of it? > > Good idea. I've changed this in git. Pressing enter on a text region now > collapses the message. Behavior of enter on quotes, signatures, > attachments, etc. is unchanged. > > Also, collapsing a message will make the cursor jump to the next open > message. So you should be able to scan rapidly through a thread one > message at a time by hitting enter to collapse it or 'n' to leave open. > (And then 'p' and 'n' to review all open messages.) -- ================================ Christopher Bertels http://www.adztec-independent.de From mailinglist@flasht.de Fri Jun 5 07:24:07 2009 From: mailinglist@flasht.de (Christopher Bertels) Date: Fri, 05 Jun 2009 13:24:07 +0200 Subject: [sup-talk] Toggle expand/collapse of a message in threadview In-Reply-To: <1244199822-sup-1224@thinkpad-ubuntu> References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry> <1244199822-sup-1224@thinkpad-ubuntu> Message-ID: <1244200965-sup-607@thinkpad-ubuntu> Ok, wasn't so hard. Here's the patch: diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 2b6c58b..1e014c3 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -234,10 +234,12 @@ EOS ## view. def activate_chunk chunk = @chunk_lines[curpos] or return + move_to_next = false if chunk.is_a? Chunk::Text ## if the cursor is over a text region, expand/collapse the ## entire message chunk = @message_lines[curpos] + move_to_next = true end layout = if chunk.is_a?(Message) @layout[chunk] @@ -253,7 +255,7 @@ EOS end if chunk.is_a?(Message) jump_to_message chunk - jump_to_next_open + jump_to_next_open if move_to_next end end Excerpts from Christopher Bertels's message of Fr Jun 05 13:09:34 +0200 2009: > Actually, now that I've been using it a little more, I think it would be nicer > that when pressing enter on a collapsed message, the cursor would stay at the > header of that expanded message instead of moving to the next message header. > Right now, it's always moving to the next message, even when expanding a > collapsed > message to read it. > > Excerpts from William Morgan's message of Fr Jun 05 05:38:23 +0200 2009: > > Reformatted excerpts from Christopher Bertels's message of 2009-06-04: > > > Is there a way to expand/collsape the current message I'm reading when > > > in the middle of it? > > > > Good idea. I've changed this in git. Pressing enter on a text region now > > collapses the message. Behavior of enter on quotes, signatures, > > attachments, etc. is unchanged. > > > > Also, collapsing a message will make the cursor jump to the next open > > message. So you should be able to scan rapidly through a thread one > > message at a time by hitting enter to collapse it or 'n' to leave open. > > (And then 'p' and 'n' to review all open messages.) -- ================================ Christopher Bertels http://www.adztec-independent.de From bwalton@artsci.utoronto.ca Fri Jun 5 07:30:51 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 05 Jun 2009 07:30:51 -0400 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and body). In-Reply-To: <1244186006-sup-1399@ausone.inria.fr> References: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca> <1244186006-sup-1399@ausone.inria.fr> Message-ID: <1244201417-sup-2549@ntdws12.chass.utoronto.ca> Excerpts from Nicolas Pouillard's message of Fri Jun 05 03:15:02 -0400 2009: > Excerpts from Ben Walton's message of Thu Jun 04 18:03:10 +0200 2009: > > This is an augment of the already existing view header (H) command, > > but allows viewing of all mime parts in their raw form, etc. > I usually use '|' followed by "cat" or "less" for this purpose, but maybe a > dedicated key-binding is better. Yah, I was aiming for less typing...it's something I do often enough. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dom.lobue@gmail.com Fri Jun 5 08:35:15 2009 From: dom.lobue@gmail.com (Dominic LoBue) Date: Fri, 5 Jun 2009 05:35:15 -0700 Subject: [sup-talk] sup crash while attempting to load next email after deleting previous Message-ID: <93de24940906050535p7178dedctc9f9f8c166acdf2e@mail.gmail.com> Hello, Sup just crashed on me. The last thing I did was do ,d to delete the email I was viewing and move on to the next. I had deleted several other emails previously in the exact same way with no problems. The only thing that may matter is that I had over 1000 threads loaded in the index view (I get a _lot_ of email at work :( ). I'm using a git release made from the below commit: commit a8869f951cf8ec3a4a50492290c9ca757c968f49 Author: William Morgan Date: Sun May 31 08:58:16 2009 -0700 yet another utf8 bugfix: fix string subsetting ... with a HORRIBLE SLOW HACK! And here is the exception-log: --- NoMethodError from thread: load messages for thread-view-mode undefined method `date' for nil:NilClass /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:783:in `text_for_thread_at' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:752:in `regen_text' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `map_with_index' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:641:in `each_with_index' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `each' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `each_with_index' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:346:in `map_with_index' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:752:in `regen_text' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:228:in `update' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:202:in `handle_deleted_update' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `send' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `relay' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `each' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/update.rb:27:in `relay' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `send' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/util.rb:505:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:431:in `delete_and_then' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:451:in `dispatch' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:119:in `call' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:119:in `select' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:71:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `new' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup.rb:69:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:99:in `select' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:149:in `launch_another_thread' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-index-mode.rb:131:in `launch_next_thread_after' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:457:in `dispatch' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:429:in `delete_and_then' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/modes/thread-view-mode.rb:404:in `delete_and_next' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mode.rb:50:in `send' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/mode.rb:50:in `handle_input' /usr/lib/ruby/gems/1.8/gems/sup-999/lib/sup/buffer.rb:249:in `handle_input' /usr/lib/ruby/gems/1.8/gems/sup-999/bin/sup:238 /usr/bin/sup:19:in `load' /usr/bin/sup:19 Dominic From wmorgan-sup@masanjin.net Fri Jun 5 09:23:50 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 05 Jun 2009 06:23:50 -0700 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244177820-sup-6051@javelin> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> <1244078482-sup-4986@javelin> <1244130722-sup-4496@entry> <1244177820-sup-6051@javelin> Message-ID: <1244206531-sup-5503@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-04: > I tickled the bug and took a more careful look at the message that had > triggered it This is good stuff. I think we're getting somewhere. I was hoping to have this this fixed by 0.8 but I think it's going to have to wait till 0.9. > and noticed that it was an auto-generated commit message that was > really long. So one possible stop-gap would be just to detect if a > message is long and disable quoting if that was the case (a long > message would be, say, one over 100KB). Yep, I bet that's the problem. Not parsing long messages would be fine as far as I'm concerned. Heck even 25k might be a reasonable limit (per MIME part). > There is also a possibility that the commit message had some > pathological backtracking built into it. It's possible... but I'm willing to bet that it's the sheer size. If we're still seeing this performance on smaller messages (e.g. when you start sending me emails carefully constructed to induce worst-case performance in Sup's regexen) we can wrap a timeout around the whole parse as well. > Excerpts from William Morgan's message of Thu Jun 04 12:09:40 -0400 2009: > > Redwood::Index#load_entry_for_id (22%) > > Redwood::IMAP#load_message (25%) > > Redwood::Message#message_to_chunks (16.5%) > > Redwood::IMAP#load_header (14%) > > Redwood::Index#sync_message (13%) > > Ok, so this isn't the same spread as when I managed to make Sup hang, > so this isn't quite the same. That makes sense. > 1. If I thrash message_to_chunks() with a very long message, I cause > sup to hang. This is still weird. It only makes sense if Ruby regexen block the whole interpreter when evaluating. I guess that might be the case if they're they haven't taken the (what I imagine must be trivial) step of allowing preemption during the DFA execution (or however the hell they're implemented). I guess an experiment would show this. > 2. If an IMAP connection hangs, it occasionally causes all of Sup to > block (this is rare, and comes from a pathological IMAP server. I > think the ops administering the naughty IMAP server fixed it, so > I am no longer seeing this hang). This is also still weird, and I wonder if it's not just problems 1 and 3 combining. If it comes back we will have to do some more investigation. > 3. Under less pathological cases, an IMAP connection can hang, and > asynchronously blocks any further polling from taking place, resulting > in no new messages. This happens commonly for me. This one we can fix. (Though it's something the IMAP libraries should've done for us.) If we put a timeout block around that #examine call, we should be able to reset the connection if it hangs. -- William From wmorgan-sup@masanjin.net Fri Jun 5 09:37:02 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 05 Jun 2009 06:37:02 -0700 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244179379-sup-6675@javelin> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> Message-ID: <1244208597-sup-4979@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-04: > The message.has_label? "mylabel" returns false, as the body of the if > statement never gets logged. (My contention is that the message very > clearly has that label, so wtf). Try has_label? :mylabel. Sup represents labels as symbols instead of as strings. Sorry about that. The hook system is in need of much documentation. A good environment for playing around with this stuff is to run the console: w at drspaceman:~/devel/sup$ sh devel/console.sh [...] >> Index.run_query "label:potato" => [1000] >> m = Index.build_message 1000 => # >> m.labels => [:inbox, :unread, :potato] >> m.has_label? :potato => true >> m.has_label? "potato" => false HTH. -- William From wmorgan-sup@masanjin.net Fri Jun 5 11:31:07 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 05 Jun 2009 08:31:07 -0700 Subject: [sup-talk] [PATCH] Add V to view a raw message (headers and body). In-Reply-To: <1244201417-sup-2549@ntdws12.chass.utoronto.ca> References: <1244131390-25769-1-git-send-email-bwalton@artsci.utoronto.ca> <1244186006-sup-1399@ausone.inria.fr> <1244201417-sup-2549@ntdws12.chass.utoronto.ca> Message-ID: <1244215854-sup-9273@entry> Reformatted excerpts from Ben Walton's message of 2009-06-05: > Yah, I was aiming for less typing...it's something I do often enough. Good enough for me. Applied directly to master. Thanks! -- William From wmorgan-sup@masanjin.net Fri Jun 5 11:31:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 05 Jun 2009 08:31:31 -0700 Subject: [sup-talk] Toggle expand/collapse of a message in threadview In-Reply-To: <1244200965-sup-607@thinkpad-ubuntu> References: <1244150874-sup-6554@thinkpad-ubuntu> <1244172932-sup-1101@entry> <1244199822-sup-1224@thinkpad-ubuntu> <1244200965-sup-607@thinkpad-ubuntu> Message-ID: <1244215876-sup-1528@entry> Reformatted excerpts from Christopher Bertels's message of 2009-06-05: > Ok, wasn't so hard. Here's the patch: I've applied a similar change to master. Thanks! -- William From wmorgan-sup@masanjin.net Fri Jun 5 11:36:55 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 05 Jun 2009 08:36:55 -0700 Subject: [sup-talk] [PATCH] Prettier printing of enclosed messages In-Reply-To: <4a1fe5cd.0a04d00a.1d89.ffffe1b2@mx.google.com> References: <4a1fe5cd.0a04d00a.1d89.ffffe1b2@mx.google.com> Message-ID: <1244216191-sup-6520@entry> Reformatted excerpts from Israel Herraiz's message of 2009-05-29: > this patch prints enclosed messages with only some selected headers > instead of the full headers, just as "normal" messages. Branch enclosed-message-display-tweaks, merged into next. Thanks! -- William From wmorgan-sup@masanjin.net Fri Jun 5 12:02:17 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 05 Jun 2009 09:02:17 -0700 Subject: [sup-talk] [RFC] Bounce messages In-Reply-To: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca> References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1244217075-sup-4385@entry> Hi Ben, I'm definitely interested in having this feature. But it does open up some complications because we have to be able to call the MTA in two different modes. But this might not be such a big deal because most MTAs have basic sendmail compatibility. Judging from the entries on the Sup Wiki for msmtp, ssmtp, and putmail, we should be fine just calling the account's sendmail command without -t and with the recipient email addresses. Reformatted excerpts from Ben Walton's message of 2009-05-31: > The other thing that I don't like presently is the confirmation UI. > Without resorting to a whole bounce-mode, is there a better way to > handle this in the face of (potentially) multiple recipients that may > make the question stretch outside the viewable area? You could just make it say "Bounce to #{to.size} recipients?". :) -- William From bwalton@artsci.utoronto.ca Fri Jun 5 12:20:32 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 05 Jun 2009 12:20:32 -0400 Subject: [sup-talk] [RFC] Bounce messages In-Reply-To: <1244217075-sup-4385@entry> References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca> <1244217075-sup-4385@entry> Message-ID: <1244218650-sup-2427@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Fri Jun 05 12:02:17 -0400 2009: > I'm definitely interested in having this feature. But it does open > up Great. > some complications because we have to be able to call the MTA in two > different modes. Nothing is free! :) > But this might not be such a big deal because most MTAs have basic > sendmail compatibility. Judging from the entries on the Sup Wiki for > msmtp, ssmtp, and putmail, we should be fine just calling the account's > sendmail command without -t and with the recipient email addresses. Ok, I'll rework the patch to call the default account's sendmail command with any -t stripped out. > You could just make it say "Bounce to #{to.size} recipients?". :) That would work. Still gives a chance to back out if things don't look right but not too heavy either. I'll rework this tonight. I looked at refactoring against the EditMessageMode send function the other night and that's not straight forward since the shared code is a few classes up the object tree. Moving the send message code higher in the tree isn't ideal, as it doesn't really belong there...suggestions on that? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Fri Jun 5 15:02:37 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 05 Jun 2009 12:02:37 -0700 Subject: [sup-talk] [ANN] Sup 0.8 released Message-ID: <1244228405-sup-4363@entry> I'm pleased to announce the release of Sup 0.8. Sup is a console-based email client for people with a lot of email. It supports tagging, very fast full-text search, automatic contact- list management, and more. If you're the type of person who treats email as an extension of your long-term memory, Sup is for you. Get it: gem install sup Learn it: http://sup.rubyforge.org Love it: sup-talk at rubyforge.org Excitement in 0.8: * Undo support on many operations. Yay! * Mbox splitting fixes. No more "From "-line problems. * Mail parsing speedups. * Many utf8 and widechar fixes. Display of crazy characters should be pretty close. * Outgoing email with non-ASCII headers is now properly encoded. * Email addresses are no longer permanently attached to names. This was causing problems with automated email systems that used different names with the same address. * Curses background now retains the terminal default color. This also makes Sup work better on transparent terminals. * Improve dynamic loading of setlocale for Cygwin and BSD systems. * Labels can now be removed from multiple tagged threads. * Applying operations to tagged threads is now invoked with '='. * Buffer list is betterified and is now invoked with ';'. * Zsh autocompletion support. * As always, many bugfixes and tweaks. -- William From ezyang@MIT.EDU Fri Jun 5 17:47:00 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 05 Jun 2009 17:47:00 -0400 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244227108-sup-3123@cabinet> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> <1244078482-sup-4986@javelin> <1244130722-sup-4496@entry> <1244177820-sup-6051@javelin> <1244227108-sup-3123@cabinet> Message-ID: <1244238388-sup-760@javelin> Excerpts from Marc Hartstein's message of Fri Jun 05 14:43:59 -0400 2009: > I noticed that one feature of the messages was that they contained one > extremely long line. Not sure if this information will in any way help > figure out what's going on there. Now that you mention it, the messages that tickle this bug on my side also have one extremely long line. That's very interesting. Cheers, Edward From ezyang@MIT.EDU Fri Jun 5 20:09:13 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 05 Jun 2009 20:09:13 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244208597-sup-4979@entry> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> <1244208597-sup-4979@entry> Message-ID: <1244246896-sup-4529@javelin> Excerpts from William Morgan's message of Fri Jun 05 09:37:02 -0400 2009: > Try has_label? :mylabel. Sup represents labels as symbols instead of as > strings. Great! My hook works now. This is the sort of functionality that I think is worth generalizing and implementing as a configuration twiddle (one, I think, that should be on by default.) > A good environment for playing around with this stuff is to run the console: > > w at drspaceman:~/devel/sup$ sh devel/console.sh > [...] > >> Index.run_query "label:potato" > => [1000] > >> m = Index.build_message 1000 > => # > >> m.labels > => [:inbox, :unread, :potato] > >> m.has_label? :potato > => true > >> m.has_label? "potato" > => false Nice! Cheers, Edward From ezyang@MIT.EDU Sat Jun 6 02:20:25 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 06 Jun 2009 02:20:25 -0400 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244238388-sup-760@javelin> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> <1244078482-sup-4986@javelin> <1244130722-sup-4496@entry> <1244177820-sup-6051@javelin> <1244227108-sup-3123@cabinet> <1244238388-sup-760@javelin> Message-ID: <1244267416-sup-3720@javelin> Excerpts from Edward Z. Yang's message of Fri Jun 05 17:47:00 -0400 2009: > Now that you mention it, the messages that tickle this bug on my side also > have one extremely long line. That's very interesting. Here is the culprit, laid out to bear its full shame: /\w.*:$/ I thought this was a suspicious looking regexen; a simple test confirmed my belief: line = ":a" * 10000 line =~ /\w.*:$/ Ba boom ba boom ba boom. This is a textbook case of catastrophic backtracking. I have two possible fixes, they end up being about the same time for regular cases, but the second one is more optimal for really long strings: First, the simple one: diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 5993729..0ddd3af 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -26,7 +26,7 @@ class Message QUOTE_PATTERN = /^\s{0,4}[>|\}]/ BLOCK_QUOTE_PATTERN = /^-----\s*Original Message\s*----+$/ - QUOTE_START_PATTERN = /\w.*:$/ + QUOTE_START_PATTERN = /\w\W*:$/ SIG_PATTERN = /(^-- ?$)|(^\s*----------+\s*$)|(^\s*_________+\s*$)|(^\s*--~--~-)|(^\s*--\+\+\*\*==)/ MAX_SIG_DISTANCE = 15 # lines from the end And the slightly more complicated one (but optimal for large n): diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 5993729..c5481a6 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -26,7 +26,6 @@ class Message QUOTE_PATTERN = /^\s{0,4}[>|\}]/ BLOCK_QUOTE_PATTERN = /^-----\s*Original Message\s*----+$/ - QUOTE_START_PATTERN = /\w.*:$/ SIG_PATTERN = /(^-- ?$)|(^\s*----------+\s*$)|(^\s*_________+\s*$)|(^\s*--~--~-)| MAX_SIG_DISTANCE = 15 # lines from the end @@ -449,7 +448,7 @@ private when :text newstate = nil - if line =~ QUOTE_PATTERN || (line =~ QUOTE_START_PATTERN && nextline =~ QUO + if line =~ QUOTE_PATTERN || (line =~ /:$/ && line =~ /\w/ && nextline =~ QU newstate = :quote elsif line =~ SIG_PATTERN && (lines.length - i) < MAX_SIG_DISTANCE newstate = :sig There are number of micro-optimizations that could be made to message parsing, but this will basically fix the egregious problem. Cheers, Edward From ezyang@MIT.EDU Sat Jun 6 02:54:01 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 06 Jun 2009 02:54:01 -0400 Subject: [sup-talk] Sup annoyances Message-ID: <1244270435-sup-9288@javelin> Having just submitted my first patch, I feel entitled to gripe and moan about certain aspects of Sup. The hope is that I'll get some pointers on what code to look at to fix these gripes. These gripes are independent of the hanging/other behavior in my other monster thread. (I'd say the asynchronous polling hang is my other biggest gripe, but that's not an issue for here). 1. Threads should be lazy-loaded (possibly in the background), with visible messages first. If a conversation got a new message, Sup should only take its time to load that message, and not the frickin' 24 other messages that were also incidentally there. I suspect this will require some pretty major refactoring. As a stop-gap, I should have the option of cancelling when I open a long thread (right now, I think it causes sup to crash). 2. Auto-completion sucks and should be improved. I should be able to press "c", type two letters, and then mash tab. If auto-completion actually works, then I'll blame it on dismal contacts.txt support (if I send mail to someone, there should be a configuration twiddle that saves it to contacts.txt. And then remembers it the next time I want to compose mail to them). 3. Polling and loading of threads should started, asynchronously, at the same time. Loading of threads should not hose my CPU. Loading of threads should do smart things, instead of doing an O(n) time warp. It takes forever for a mail from two months ago that is still in my inbox, because it still hasn't been addressed, to show up. This could probably be fixed with a cache file. This isn't as big of a deal if asynchronous polling hang and crashing is fixed. 4. Sup should prompt me whether or not I want to Reply All or Reply on appropriate cases, like pine. Cheers, Edward From ezyang@MIT.EDU Sat Jun 6 02:56:11 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 06 Jun 2009 02:56:11 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244270435-sup-9288@javelin> References: <1244270435-sup-9288@javelin> Message-ID: <1244271263-sup-3881@javelin> Excerpts from Edward Z. Yang's message of Sat Jun 06 02:54:01 -0400 2009: > 4. Sup should prompt me whether or not I want to Reply All or Reply on > appropriate cases, like pine. To be clear, this should be a configuration twiddle. I think I also have just remembered one more thing: 5. Killing a thread should kill it *now*, not "when Sup next restarts". Cheers, Edward From nicolas.pouillard@gmail.com Sat Jun 6 06:16:55 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sat, 06 Jun 2009 12:16:55 +0200 Subject: [sup-talk] [RFC] Bounce messages In-Reply-To: <1244217075-sup-4385@entry> References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca> <1244217075-sup-4385@entry> Message-ID: <1244283371-sup-2895@ausone.local> Excerpts from William Morgan's message of Fri Jun 05 18:02:17 +0200 2009: > Hi Ben, > > I'm definitely interested in having this feature. But it does open up > some complications because we have to be able to call the MTA in two > different modes. I don't get the purpose of this, how it is different from hitting 'D' to send again the same message? -- Nicolas Pouillard http://nicolaspouillard.fr From bwalton@artsci.utoronto.ca Sat Jun 6 08:44:15 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 06 Jun 2009 08:44:15 -0400 Subject: [sup-talk] [RFC] Bounce messages In-Reply-To: <1244283371-sup-2895@ausone.local> References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca> <1244217075-sup-4385@entry> <1244283371-sup-2895@ausone.local> Message-ID: <1244291795-sup-1695@ntdws12.chass.utoronto.ca> Excerpts from Nicolas Pouillard's message of Sat Jun 06 06:16:55 -0400 2009: > I don't get the purpose of this, how it is different from hitting 'D' to send > again the same message? Look at the From: header when you do that. It gets set to _your_ address. You could use D, edit the from address to that of the original sender and then fire to achieve the same effect (although I'm not sure how it handles attachments, etc), but that's a lot of typing for a common action. I also believe that with D, since you're injecting a new message with original content, that you'd lose much of the original header info. The idea is that when you 'bounce' the message, it's akin to you having had a .forward in place at MTA delivery time. Redirect, not forward. My biggest use case for this is bouncing mail sent to me personally asking for support into our ticket system. The original sender will see the autoreply with the ticket id, etc because the From: header contained their address. Colleagues using other mail clients lacking this feature will forward mail to the ticket system which sees them get the replies. They then have to go into the ticket and set a proper 'requester' address for further correspondence on the ticket. I remember when I discovered this feature in mutt how weird I thought it was. It wasn't long before it was in common use for me though. Does that make sense? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.pouillard@gmail.com Sat Jun 6 10:36:12 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Sat, 06 Jun 2009 16:36:12 +0200 Subject: [sup-talk] [RFC] Bounce messages In-Reply-To: <1244291795-sup-1695@ntdws12.chass.utoronto.ca> References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca> <1244217075-sup-4385@entry> <1244283371-sup-2895@ausone.local> <1244291795-sup-1695@ntdws12.chass.utoronto.ca> Message-ID: <1244298935-sup-5932@ausone.local> Excerpts from Ben Walton's message of Sat Jun 06 14:44:15 +0200 2009: > Excerpts from Nicolas Pouillard's message of Sat Jun 06 06:16:55 -0400 2009: > > I don't get the purpose of this, how it is different from hitting 'D' to send > > again the same message? > > Look at the From: header when you do that. It gets set to _your_ > address. You could use D, edit the from address to that of the > original sender and then fire to achieve the same effect (although I'm > not sure how it handles attachments, etc), but that's a lot of typing > for a common action. I also believe that with D, since you're > injecting a new message with original content, that you'd lose much of > the original header info. > > The idea is that when you 'bounce' the message, it's akin to you > having had a .forward in place at MTA delivery time. Redirect, not > forward. > > My biggest use case for this is bouncing mail sent to me personally > asking for support into our ticket system. The original sender will > see the autoreply with the ticket id, etc because the From: header > contained their address. Colleagues using other mail clients lacking > this feature will forward mail to the ticket system which sees them > get the replies. They then have to go into the ticket and set a > proper 'requester' address for further correspondence on the ticket. > > I remember when I discovered this feature in mutt how weird I thought > it was. It wasn't long before it was in common use for me though. > > Does that make sense? It does! Thanks for the explanation. -- Nicolas Pouillard http://nicolaspouillard.fr From helgedt@tihlde.org Sat Jun 6 08:03:14 2009 From: helgedt@tihlde.org (Helge Titlestad) Date: Sat, 06 Jun 2009 14:03:14 +0200 Subject: [sup-talk] [RFC] Bounce messages In-Reply-To: <1244283371-sup-2895@ausone.local> References: <1243817649-7642-1-git-send-email-bwalton@artsci.utoronto.ca> <1244217075-sup-4385@entry> <1244283371-sup-2895@ausone.local> Message-ID: <1244289688-sup-9384@colargol.tihlde.org> Excerpts from Nicolas Pouillard's message of Sat Jun 06 12:16:55 +0200 2009: > I don't get the purpose of this, how it is different from hitting 'D' to send > again the same message? One out of several differences: D doesn't include attachments. My personal use case: I have a couple of mail accounts - this one for all my normal private stuff, one gmail account mostly for sharing documents and so on. If I get a mail with an attachment that I can't read in a terminal (typically pdf) to my private account, I will bounce it to my gmail account. That preserves the whole message, and is different from both "D" (which I use to re-send mail) and forward (which I use to forward interesting stuff to other people). -- alge From ezyang@MIT.EDU Sat Jun 6 14:17:29 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sat, 06 Jun 2009 14:17:29 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244308338-sup-4735@cabinet> References: <1244270435-sup-9288@javelin> <1244271263-sup-3881@javelin> <1244308338-sup-4735@cabinet> Message-ID: <1244312041-sup-9128@javelin> Excerpts from Marc Hartstein's message of Sat Jun 06 13:16:39 -0400 2009: > sup gives you a menu to select whether to reply to Sender, Recipient, > List, or All. It's right up near the top of the reply-mode screen. Use > regular vertical movement keys to select the Reply to: line, then > horizontal movement to select an option. Yep, I know about this. > You can improve the default selection using the reply-to hook. See `sup > --list-hooks` for documentation. I didn't know about that. > I found it a little weird getting used to (coming from mutt, where I > actually used a different reply key for each mode), but the default > behavior is generally correct, and selecting from the menu isn't too > bad. The trouble is I always forget to check the To: header on my mails, and there is a ~large class of mailing list emails that don't actually do the right thing by default. Improving the heuristic may be an alternate possibility. Cheers, Edward From bwalton@artsci.utoronto.ca Sat Jun 6 15:06:49 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 06 Jun 2009 15:06:49 -0400 Subject: [sup-talk] sup/gpg In-Reply-To: <1244314253-sup-6338@cabinet> References: <1243463452-sup-1174@cabinet> <1243466444-sup-3672@ntdws12.chass.utoronto.ca> <1243622801-sup-6484@cabinet> <1243819025-sup-136@ntdws12.chass.utoronto.ca> <1244037417-sup-8346@cabinet> <1244313900-sup-578@ntdws12.chass.utoronto.ca> <1244314253-sup-6338@cabinet> Message-ID: <1244314983-sup-482@ntdws12.chass.utoronto.ca> Excerpts from Marc Hartstein's message of Sat Jun 06 14:53:55 -0400 2009: > Excerpts from Ben Walton's message of Sat Jun 06 14:45:56 -0400 2009: > > > > This just got stranger, which makes me think it may be a sup issue > > still. The thread you replied twice to earlier today has one message > > validating and the other not. See attached. > > Ok, that's totally bizarre. > > Things I can think of: > > Those were two different sup instances (I'd quit, created a branch, and > applied the discussed patch in between sending the two replies) Well, if the patch altered the behaviour, that's a possibility. > I might well have typoed my passphrase for one of the messages and not > the other, though I'm not sure which. I think it's slightly more likely > that the BAD message was the one where I made a typo, though. [I then > proceeded to enter it correctly the second time, though, so...] When I enter a bad passphrase into pinentry, sup detects this and won't send the message...to my knowledge, I'm not able to get a multipart/gpg message sent if I don't enter a proper passphrase. > Think we should move the discussion to the sup list to see if anybody > has thoughts? I think that's reasonable. My next thought is that there is a small bug in the mime parsing (or creating) code... Does anyone else have thoughts on what would cause broken gpg signatures? I've previously had issues when using gpg2 instead of gpg1, but that was completely the fault of gpg2 (or my use of it, anyway). Switching to gpg1 resolved the problem at that time. In this instance, Mark isn't able to validate my signatures and I was able to validate his until just recently...I'm now hit-and-miss with his. Thoughts? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ingmar@exherbo.org Fri Jun 5 20:35:50 2009 From: ingmar@exherbo.org (Ingmar Vanhassel) Date: Sat, 06 Jun 2009 02:35:50 +0200 Subject: [sup-talk] [PATCH] Use terminal width instead of hardcoded 80 as the wrap length. In-Reply-To: <1243439667-sup-3947@entry> References: <1243102667-sup-6007@r50p> <4c4248150905231318kab3819dw68e3a3a614241c0d@mail.gmail.com> <1243123134-sup-8032@ntdws12.chass.utoronto.ca> <1243439667-sup-3947@entry> Message-ID: <1244248537-sup-5155@cannonball> Excerpts from William Morgan's message of Wed May 27 17:58:23 +0200 2009: > Reformatted excerpts from Ben Walton's message of 2009-05-23: > > But if you leave sup's "we dont' force wrapping" rules alone, this > > makes reading mail scroll free if your terminal is wide enough and > > doesn't change the behaviour if the terminal is narrower. (Not that > > I'm against making it an option either.) > > Seems like there are three main modes of operation that would be > desirable: > > 1. wrap at 80 chars; > 2. wrap at current terminal width; > 3. don't wrap. > > (In all cases, existing line breaks in the message are left alone.) > > Would a three-way toggle irritate anyone? Works for me. From bwalton@artsci.utoronto.ca Sun Jun 7 08:33:49 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 07 Jun 2009 08:33:49 -0400 Subject: [sup-talk] exception with undomanager Message-ID: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> Hi All, I bumped into this this morning. I've not used the undo stuff much, but I tried it today. The (rough) sequence of events leading to this was: I archived two threads separately and then decided I wanted to undo the first of two actions. I hit u once and got the latest thread back and when I hit it again, sup crashed. If I get a chance I'll look into it myself, but I'm tossing it out for people more familiar with these bits to see also. Thanks -Ben $ less ~/.sup/exception-log.txt --- NoMethodError from thread: main undefined method `content_width' for nil:NilClass ./sup/modes/thread-index-mode.rb:868:in `from_width' ./sup/modes/thread-index-mode.rb:793:in `text_for_thread_at' /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `each_with_index' ./sup/modes/thread-index-mode.rb:792:in `each' ./sup/modes/thread-index-mode.rb:792:in `each_with_index' ./sup/modes/thread-index-mode.rb:792:in `text_for_thread_at' ./sup/modes/thread-index-mode.rb:753:in `regen_text' ./sup/util.rb:346:in `map_with_index' /local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `each_with_index' ./sup/util.rb:346:in `each' ./sup/util.rb:346:in `each_with_index' ./sup/util.rb:346:in `map_with_index' ./sup/modes/thread-index-mode.rb:753:in `regen_text' ./sup/modes/thread-index-mode.rb:228:in `update' ./sup/modes/thread-index-mode.rb:697:in `add_or_unhide' ./sup/modes/thread-index-mode.rb:319:in `actually_toggle_spammed' ./sup/undo.rb:28:in `call' ./sup/undo.rb:28:in `undo' ./sup/undo.rb:28:in `each' ./sup/undo.rb:28:in `undo' ./sup/util.rb:505:in `send' ./sup/util.rb:505:in `method_missing' ./sup/modes/thread-index-mode.rb:217:in `undo' ./sup/mode.rb:50:in `send' ./sup/mode.rb:50:in `handle_input' ./sup/buffer.rb:249:in `handle_input' ../bin/sup:237 -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From sup@davekap.com Sun Jun 7 19:52:10 2009 From: sup@davekap.com (David L.Kaplan) Date: Sun, 07 Jun 2009 19:52:10 -0400 Subject: [sup-talk] crash with .8 on save ($) Message-ID: <1244418650-sup-3064@ubuntu> To the best of my recollection, I had archived a few messages and then hit $ to save state. Exception file attached. Thanks for sup. Dave --- RuntimeError from thread: periodic poll trying to delete non-corresponding entry 47607 with index message-id "2ca9fdfb2b3c1c3c3981de95447977b2 at www.facebook.com" and parameter message id "988542971151613.JXQSVJUEOLXELKD at 187-45-0-136.clientes.cilnet.com.br" /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/index.rb:191:in `sync_message' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/index.rb:190:in `sync_message' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:161:in `add_messages_from' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:130:in `each' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `upto' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `each' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `send' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `__pass' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:531:in `method_missing' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:141:in `add_messages_from' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:98:in `do_poll' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `each' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `do_poll' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `synchronize' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `do_poll' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/modes/poll-mode.rb:17:in `poll' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:53:in `poll' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:70:in `start' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `new' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/poll.rb:67:in `start' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send' /home/dave/.gem/ruby/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing' /home/dave/.gem/ruby/1.8/gems/sup-0.8/bin/sup:213 /usr/bin/sup:19:in `load' /usr/bin/sup:19 From bwalton@artsci.utoronto.ca Sun Jun 7 20:02:25 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 7 Jun 2009 20:02:25 -0400 Subject: [sup-talk] (no subject) Message-ID: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> Hi All, Here's a stab at implementing a message bouncing functionality worthy of being included on mainline. The first patch adds the basic functionality with the ability to supply a command in the :bounce_sendmail option that overrides the default command used. The default is to use the sendmail command of the default account with -t removed. The second patch takes this a step further and strips the configuration option in favour of a hook named bounce-command. This hooks gets the From header of the message being bounced and an array of recipient addresses supplied by the user. I think these are in good shape, with the caveat that the mail sending (IO.popen) part could still be refactored with the code in edit-message-mode. Anyone interested can grab this code from the bw/bounce_message branch of git://code.chass.utoronto.ca/bwalton-sup.git. It merges cleanly into next as of now. Feedback welcome. Thanks -Ben From bwalton@artsci.utoronto.ca Sun Jun 7 20:02:26 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 7 Jun 2009 20:02:26 -0400 Subject: [sup-talk] [PATCH 1/2] Add message bouncing capability In-Reply-To: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1244419347-11330-2-git-send-email-bwalton@artsci.utoronto.ca> Bouncing a message is akin to redirecting a mail with a .forward entry. It is passed back to the mail system as it sits on disk. By pressing ! while viewing a message, you can now re-inject it to the mail system using either the command defined in bounce_sendmail or the sendmail command for the default account with any instance of -t removed. The user is prompted for the recipients of the message and is offered a chance to confirm the bounce before it is sent. The message is _not_ stored in the sent box, as this doesn't make sense with bounced messages (and would not show up uniquely anyway). The bounce_sendmail configuration item allows users that require different sendmail commands depending on where the bounce is destined to write a wrapper around their local mail tools to pick and choose the appropriate injection method for the message based on the addresses passed in. Most systems can likely use: sendmail -oem -i Signed-off-by: Ben Walton --- lib/sup.rb | 1 + lib/sup/modes/thread-view-mode.rb | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 34 insertions(+), 0 deletions(-) diff --git a/lib/sup.rb b/lib/sup.rb index 96510b2..76444c9 100644 --- a/lib/sup.rb +++ b/lib/sup.rb @@ -207,6 +207,7 @@ else :confirm_top_posting => true, :discard_snippets_from_encrypted_messages => false, :default_attachment_save_dir => "", + :bounce_sendmail => "", } begin FileUtils.mkdir_p Redwood::BASE_DIR diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 42c6280..8842e59 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -41,6 +41,7 @@ EOS # k.add :collapse_non_new_messages, "Collapse all but unread messages", 'N' k.add :reply, "Reply to a message", 'r' k.add :forward, "Forward a message or attachment", 'f' + k.add :bounce, "Bounce message to other recipient(s)", '!' k.add :alias, "Edit alias/nickname for a person", 'i' k.add :edit_as_new, "Edit message as new", 'D' k.add :save_to_disk, "Save message/attachment to disk", 's' @@ -172,6 +173,38 @@ EOS end end + def bounce + m = @message_lines[curpos] or return + to = BufferManager.ask_for_contacts(:people, "Bounce To: ") or return + + defcmd = AccountManager.default_account.sendmail.sub(/\s(\-(ti|it|t))\b/) do |match| + case "$1" + when '-t' then '' + else ' -i' + end + end + + cmd = case $config[:bounce_sendmail] + when nil, /^$/ then defcmd + else $config[:bounce_sendmail] + end + ' ' + to.map { |t| t.email }.join(' ') + + bt = to.size > 1 ? "#{to.size} recipients" : to.to_s + + if BufferManager.ask_yes_or_no "Really bounce to #{bt}?" + Redwood::log "Bounce Command: #{cmd}" + begin + IO.popen(cmd, 'w') do |sm| + sm.puts m.raw_message + end + raise SendmailCommandFailed, "Couldn't execute #{cmd}" unless $? == 0 + rescue SystemCallError, SendmailCommandFailed => e + Redwood::log "Problem sending mail: #{e.message}" + BufferManager.flash "Problem sending mail: #{e.message}" + end + end + end + include CanAliasContacts def alias p = @person_lines[curpos] or return -- 1.6.3 From bwalton@artsci.utoronto.ca Sun Jun 7 20:02:27 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sun, 7 Jun 2009 20:02:27 -0400 Subject: [sup-talk] [PATCH 2/2] Bounce Message Hook In-Reply-To: <1244419347-11330-2-git-send-email-bwalton@artsci.utoronto.ca> References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> <1244419347-11330-2-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1244419347-11330-3-git-send-email-bwalton@artsci.utoronto.ca> Determine the command used to bounce a message based on a Hook instead of a configuration option. Instead of writing an external script that can send the message properly based on the recipient addresses, rely on a hook that can return the command based on the From header in the mail being bounced as well as the intended recipients. This is more in line with the sup philosophy. The default is still to strip any -t from the sendmail command of the default account. Signed-off-by: Ben Walton --- lib/sup.rb | 1 - lib/sup/modes/thread-view-mode.rb | 16 ++++++++++++++-- 2 files changed, 14 insertions(+), 3 deletions(-) diff --git a/lib/sup.rb b/lib/sup.rb index 76444c9..96510b2 100644 --- a/lib/sup.rb +++ b/lib/sup.rb @@ -207,7 +207,6 @@ else :confirm_top_posting => true, :discard_snippets_from_encrypted_messages => false, :default_attachment_save_dir => "", - :bounce_sendmail => "", } begin FileUtils.mkdir_p Redwood::BASE_DIR diff --git a/lib/sup/modes/thread-view-mode.rb b/lib/sup/modes/thread-view-mode.rb index 8842e59..76a1d1e 100644 --- a/lib/sup/modes/thread-view-mode.rb +++ b/lib/sup/modes/thread-view-mode.rb @@ -24,6 +24,18 @@ Return value: None. The variable 'headers' should be modified in place. EOS + HookManager.register "bounce-command", < m.from, :to => to when nil, /^$/ then defcmd - else $config[:bounce_sendmail] + else hookcmd end + ' ' + to.map { |t| t.email }.join(' ') bt = to.size > 1 ? "#{to.size} recipients" : to.to_s -- 1.6.3 From garoth@gmail.com Mon Jun 8 08:55:14 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 8 Jun 2009 08:55:14 -0400 Subject: [sup-talk] Fwd: [REQUEST] reply-to-list In-Reply-To: <80055d7c0906080553t41909b18j6c4a0f8fd119fa36@mail.gmail.com> References: <80055d7c0906080553t41909b18j6c4a0f8fd119fa36@mail.gmail.com> Message-ID: <80055d7c0906080555h37e2b551i606e60dbdd5414f2@mail.gmail.com> Hello there, Today I was told to read http://liw.iki.fi/liw/log/2003-Enemies-of-Carlotta.html. It suggests that a good mailing client should have a reply-to-list button since mailing lists should not add themselves as a reply-to. The reply-to-list uses the standard List-ID header to know where to reply to. As far as I can tell from ?-ing around the client, sup does not have this feature (though kudos for having a button for unsubscribe, which I find mildly curious but cool). I'm told that the mutt key for this is l (ell), which I guess is reasonable. Also, hello to the mailing list :) Cheers, -AT From bwalton@artsci.utoronto.ca Mon Jun 8 09:03:11 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 08 Jun 2009 09:03:11 -0400 Subject: [sup-talk] Fwd: [REQUEST] reply-to-list In-Reply-To: <80055d7c0906080555h37e2b551i606e60dbdd5414f2@mail.gmail.com> References: <80055d7c0906080553t41909b18j6c4a0f8fd119fa36@mail.gmail.com> <80055d7c0906080555h37e2b551i606e60dbdd5414f2@mail.gmail.com> Message-ID: <1244466128-sup-135@ntdws12.chass.utoronto.ca> Excerpts from Andrei Thorp's message of Mon Jun 08 08:55:14 -0400 2009: > As far as I can tell from ?-ing around the client, sup does not have > this feature (though kudos for having a button for unsubscribe, which > I find mildly curious but cool). > > I'm told that the mutt key for this is l (ell), which I guess is reasonable. Sup handles this in a smarter way. When you hit r to reply to a message, if it's detected as a list post, the 'reply to' menu selection defaults to 'Mailing list.' You can toggle this selection with the arrow keys. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From joe@talkhouse.com Mon Jun 8 11:21:52 2009 From: joe@talkhouse.com (=?ISO-8859-1?Q?Joe_W=F6lfel?=) Date: Mon, 8 Jun 2009 11:21:52 -0400 Subject: [sup-talk] Can't seem to send mail Message-ID: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> First, Sup awesome. It's saves an incredible amount of time searching through mail! I haven't been able to send messages with it yet though. I can only search and read. I used sup-config to configure imap. According to the config.yaml file it's using sendmail -oem -ti to send. If I try to send a message it claims it's sent, but no such luck. Do I need to do something else in addition? Actually, I'd like to be able to send from multiple accounts and I'm not sure how to setup Sup to do that. From garoth@gmail.com Mon Jun 8 11:50:47 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 8 Jun 2009 11:50:47 -0400 Subject: [sup-talk] Can't seem to send mail In-Reply-To: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> Message-ID: <80055d7c0906080850o2f861903v5b3a51effb215e0b@mail.gmail.com> Well, as far as I can tell, sup doesn't actually send mail itself, and can't. As such, it uses sendmail by default. Therefore, if you want it to send mail properly, you want to set up sendmail to send your mail. If you're sending through something sane, it probably uses smtp. Today, I installed msmtp and am using it with sup successfully to accomplish this, though you have to change the sendmail command to /usr/bin/msmtp -t. Alternatively, you could run your own mail server and use the sendmail that comes with that. From bwalton@artsci.utoronto.ca Mon Jun 8 11:52:51 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 08 Jun 2009 11:52:51 -0400 Subject: [sup-talk] Can't seem to send mail In-Reply-To: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> Message-ID: <1244476264-sup-5281@ntdws12.chass.utoronto.ca> Excerpts from Joe W?lfel's message of Mon Jun 08 11:21:52 -0400 2009: > I haven't been able to send messages with it yet though. I can only > search and read. I used sup-config to configure imap. According to > the config.yaml file it's using sendmail -oem -ti to send. If I try > to send a message it claims it's sent, but no such luck. Do I need > to do something else in addition? Actually, I'd like to be able to > send from multiple accounts and I'm not sure how to setup Sup to do > that. Check the log buffer first to see if sup reports errors interacting with (whatever is masquerading as) sendmail on your system...if there aren't errors there, check the mail logs on your system, since it has left the land of sup...If it doesn't make it to your index as a sent item, I suspect that the sendmail command may not be working correctly. HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon Jun 8 13:18:30 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 10:18:30 -0700 Subject: [sup-talk] exception with undomanager In-Reply-To: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> Message-ID: <1244481362-sup-970@entry> Reformatted excerpts from Ben Walton's message of 2009-06-07: > I bumped into this this morning. I've not used the undo stuff much, > but I tried it today. The (rough) sequence of events leading to this > was: I archived two threads separately and then decided I wanted to > undo the first of two actions. I hit u once and got the latest thread > back and when I hit it again, sup crashed. If I get a chance I'll > look into it myself, but I'm tossing it out for people more familiar > with these bits to see also. Something like this seems to happen fairly frequently. I think it's a (shudder) threading issue. Something is killing a buffer (possibly the user) while it's being redrawn and this happens. I need to stick another mutex in there somewhere. Or rewrite Sup for Ruby 1.9 with fibers instead of threads. -- William From wmorgan-sup@masanjin.net Mon Jun 8 13:23:43 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 10:23:43 -0700 Subject: [sup-talk] sup/gpg In-Reply-To: <1244314983-sup-482@ntdws12.chass.utoronto.ca> References: <1243463452-sup-1174@cabinet> <1243466444-sup-3672@ntdws12.chass.utoronto.ca> <1243622801-sup-6484@cabinet> <1243819025-sup-136@ntdws12.chass.utoronto.ca> <1244037417-sup-8346@cabinet> <1244313900-sup-578@ntdws12.chass.utoronto.ca> <1244314253-sup-6338@cabinet> <1244314983-sup-482@ntdws12.chass.utoronto.ca> Message-ID: <1244481592-sup-4821@entry> Reformatted excerpts from Ben Walton's message of 2009-06-06: > Excerpts from Marc Hartstein's message of Sat Jun 06 14:53:55 -0400 2009: > > Excerpts from Ben Walton's message of Sat Jun 06 14:45:56 -0400 2009: > > Those were two different sup instances (I'd quit, created a branch, and > > applied the discussed patch in between sending the two replies) > > Well, if the patch altered the behaviour, that's a possibility. What was the patch? > > I might well have typoed my passphrase for one of the messages and not > > the other, though I'm not sure which. I think it's slightly more likely > > that the BAD message was the one where I made a typo, though. [I then > > proceeded to enter it correctly the second time, though, so...] > > When I enter a bad passphrase into pinentry, sup detects this and > won't send the message...to my knowledge, I'm not able to get a > multipart/gpg message sent if I don't enter a proper passphrase. Yeah, an incorrect passphrase will error out, it won't produce a bad message. > I think that's reasonable. My next thought is that there is a small > bug in the mime parsing (or creating) code... That is where I would start looking. If you tweak crypto.rb so that it dumps the payload somewhere (look in #format_payload), you can then compare that to what ends up in your sent.mbox. Also you can look at encrypting messages to yourself. Are you able to decrypt them reliably? If not, is there a pattern? (Non-ASCII in the headers, body, etc.?) -- William From wmorgan-sup@masanjin.net Mon Jun 8 14:00:23 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 11:00:23 -0700 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244270435-sup-9288@javelin> References: <1244270435-sup-9288@javelin> Message-ID: <1244481844-sup-9094@entry> Hi Edward, I think these are by and large legitimate gripes and I'd be delighted to have someone motivated to fix them! Reformatted excerpts from Edward Z. Yang's message of 2009-06-05: > 1. Threads should be lazy-loaded (possibly in the background), with > visible messages first. FWIW, this is particularly egregious in a direct IMAP connection, and those of us who have switched to Maildir or who use mbox aren't punished. But it would be very cool to have this. > If a conversation got a new message, Sup should only take its time to > load that message, and not the frickin' 24 other messages that were > also incidentally there. I suspect this will require some pretty > major refactoring. It might not be too bad. Turn off the call to m.load_from_source! on line 106 of thread-index-mode.rb, add a Queue to ThreadViewMode containing messages to call #load_from_source! on, don't call m.chunks in ThreadViewMode#regen_text unless the message has been loaded, start a thread that pops messages from the queue, calls #load_from_source! on them, and then calls regen_text when an open message has been loaded... and you're 90% of the way there. > 2. Auto-completion sucks and should be improved. I should be able > to press "c", type two letters, and then mash tab. If auto-completion > actually works, then I'll blame it on dismal contacts.txt support The auto-completion is awesome. Adding a recipient to the contacts list is a good idea. > 3. Polling and loading of threads should started, asynchronously, at > the same time. > Loading of threads should not hose my CPU. Agreed. Please fix. > Loading of threads should do smart things, instead of doing an O(n) > time warp. It's definitely worse than O(n). Loading threads could be sped up dramatically by storing the thread structure somewhere (either cached or just for every thread), since Sup does a lot of extra work rethreading everything every time you start it up. FWIW I'm doing this the right way in Sup 2.0. > 4. Sup should prompt me whether or not I want to Reply All or Reply on > appropriate cases, like pine. There have been a couple similar requests like this recently, though it's not clear if everyone has known about the ability to change the reply mode and about the reply-to hook. Since hitting 'r' defaults to replying to the sender alone (except for mailing list messages), I'd be ok with adding a Mutt-style reply-to-all key that starts up reply-mode with the 'reply to all' mode active. -- William From wmorgan-sup@masanjin.net Mon Jun 8 14:09:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 11:09:52 -0700 Subject: [sup-talk] Sup is hanging In-Reply-To: <1244267416-sup-3720@javelin> References: <1244050695-sup-5990@javelin> <1244053108-sup-4982@javelin> <1244064889-sup-9506@entry> <1244078482-sup-4986@javelin> <1244130722-sup-4496@entry> <1244177820-sup-6051@javelin> <1244227108-sup-3123@cabinet> <1244238388-sup-760@javelin> <1244267416-sup-3720@javelin> Message-ID: <1244484134-sup-5651@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-05: > - if line =~ QUOTE_PATTERN || (line =~ QUOTE_START_PATTERN && nextline =~ QUO > + if line =~ QUOTE_PATTERN || (line =~ /:$/ && line =~ /\w/ && nextline =~ QU Seems fine to me. I've applied that change directly to master. Not only are there millions of optimiziations for this stuff, there are millions of tweaks to improve detection precision and recall. Thanks for your help with this, Edward! -- William From joe@talkhouse.com Mon Jun 8 14:05:34 2009 From: joe@talkhouse.com (=?ISO-8859-1?Q?Joe_W=F6lfel?=) Date: Mon, 8 Jun 2009 14:05:34 -0400 Subject: [sup-talk] Can't seem to send mail In-Reply-To: <1244476264-sup-5281@ntdws12.chass.utoronto.ca> References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> <1244476264-sup-5281@ntdws12.chass.utoronto.ca> Message-ID: On Jun 8, 2009, at 11:52 AM, Ben Walton wrote: > Excerpts from Joe W?lfel's message of Mon Jun 08 11:21:52 -0400 2009: >> I haven't been able to send messages with it yet though. I can only >> search and read. I used sup-config to configure imap. According >> to >> the config.yaml file it's using sendmail -oem -ti to send. If I try >> to send a message it claims it's sent, but no such luck. Do I need >> to do something else in addition? Actually, I'd like to be able to >> send from multiple accounts and I'm not sure how to setup Sup to do >> that. > > Check the log buffer first to see if sup reports errors interacting > with (whatever is masquerading as) sendmail on your system...if there > aren't errors there, check the mail logs on your system, since it has > left the land of sup...If it doesn't make it to your index as a sent > item, I suspect that the sendmail command may not be working > correctly. > > HTH > -Ben > > -- > Ben Walton > Systems Programmer - CHASS > University of Toronto > C:416.407.5610 | W:416.978.4302 > > GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu > Contact me to arrange for a CAcert assurance meeting. > _______________________________________________ > sup-talk mailing list > sup-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/sup-talk It looks like sendmail isn't functioning and doesn't generate any errors. Maybe it's a mac problem. I haven't tried it on anything else yet. From ezyang@MIT.EDU Mon Jun 8 14:18:41 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 14:18:41 -0400 Subject: [sup-talk] exception with undomanager In-Reply-To: <1244481362-sup-970@entry> References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> <1244481362-sup-970@entry> Message-ID: <1244485084-sup-973@javelin> Excerpts from William Morgan's message of Mon Jun 08 13:18:30 -0400 2009: > Something like this seems to happen fairly frequently. I think it's a > (shudder) threading issue. Something is killing a buffer (possibly the > user) while it's being redrawn and this happens. I need to stick another > mutex in there somewhere. Or rewrite Sup for Ruby 1.9 with fibers > instead of threads. The unfortunate bit about Ruby 1.9 is that the majority of libraries sup uses aren't on 1.9 yet... Cheers, Edward From wmorgan-sup@masanjin.net Mon Jun 8 14:25:10 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 11:25:10 -0700 Subject: [sup-talk] sup/gpg In-Reply-To: <1244483397-sup-3035@cabinet> References: <1243463452-sup-1174@cabinet> <1243466444-sup-3672@ntdws12.chass.utoronto.ca> <1243622801-sup-6484@cabinet> <1243819025-sup-136@ntdws12.chass.utoronto.ca> <1244037417-sup-8346@cabinet> <1244313900-sup-578@ntdws12.chass.utoronto.ca> <1244314253-sup-6338@cabinet> <1244314983-sup-482@ntdws12.chass.utoronto.ca> <1244481592-sup-4821@entry> <1244483397-sup-3035@cabinet> Message-ID: <1244485140-sup-1973@entry> Reformatted excerpts from Marc Hartstein's message of 2009-06-08: > The regexp fix for messages with very long lines. Yeah, that shouldn't change anything. Doesn't even change Sup's output! > Yeah, it bounces me back to pinentry, where I proceeded to enter it > correctly. It *shouldn't* produce a bad message, it was just one of > the only things I could think of that had changed between the two > messages which might have led to different behavior. Except the message content, I guess. :) > > Also you can look at encrypting messages to yourself. Are you able > > to decrypt them reliably? If not, is there a pattern? (Non-ASCII in > > the headers, body, etc.?) > > I expect this will have the same behavior as checking signatures on > messages I send, no? It should; I was just suggesting it as an alternative approach to figuring out what was causing the problem. Then Ben isn't in the loop any more and you can spend all night happily debuggin this. :) > Ben is using gpg 1 after correspondents complained the switch to gpg 2 > caused his messages to have bad signatures. Was he using Sup the entire time? > I am using gpg 2.0.11 > > I see *all* Ben's messages as having bad signatures, and see all my > own (either in sent.mbox or bounced back to me from the list) as good. > I also see Ben's signatures as bad when looking at the same messages > through mutt. I see the same thing going back to his first signed > message to sup-talk, and also in his direct emails to me. > > Ben sees most of my signatures as good, but has recently experienced > an intermittent issue where my signatures are bad. It sounds like there might be some possibility that it's a GPG version incompatibility, though I'd be a little surprised if that were really the case. It might be helpful if you guys could do a control experiment with Mutt, since I have a fair amount of faith in its GPG implementation. -- William From garoth@gmail.com Mon Jun 8 14:42:28 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 8 Jun 2009 14:42:28 -0400 Subject: [sup-talk] Can't seem to send mail In-Reply-To: References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> <1244476264-sup-5281@ntdws12.chass.utoronto.ca> Message-ID: <80055d7c0906081142w63a5ddf3w2d7c06fd174b3740@mail.gmail.com> Heh. # file /usr/sbin/sendmail /usr/sbin/sendmail: symbolic link to `/bin/true' Fail. (or it would be ;) -AT From bwalton@artsci.utoronto.ca Mon Jun 8 14:44:50 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 08 Jun 2009 14:44:50 -0400 Subject: [sup-talk] Can't seem to send mail In-Reply-To: References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> <1244476264-sup-5281@ntdws12.chass.utoronto.ca> Message-ID: <1244486438-sup-3501@ntdws12.chass.utoronto.ca> Excerpts from Joe W?lfel's message of Mon Jun 08 14:05:34 -0400 2009: > It looks like sendmail isn't functioning and doesn't generate any > errors. Maybe it's a mac problem. I haven't tried it on anything > else yet. Personally, I don't think sendmail has _ever_ been functional, but that's just the grumpy side of me that has to configure it on clunky old boxes still! :) It's likely working, but has a local delivery setup configured. Try using `mailq` to see if anything is sitting in the outbound queue. You may also want to look in /var/spool/mail for mbox files sitting there with the messages (or bounces) sent from sup. If you want to get your hands dirty, I recommend exim as the replacment for sendmail. I like it's configuration and acl setup better than postfix, but that would also work. If you just want to send mail quickly and easily, try msmtp or a similar package. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From bwalton@artsci.utoronto.ca Mon Jun 8 14:50:19 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 08 Jun 2009 14:50:19 -0400 Subject: [sup-talk] exception with undomanager In-Reply-To: <1244485084-sup-973@javelin> References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> <1244481362-sup-970@entry> <1244485084-sup-973@javelin> Message-ID: <1244486944-sup-293@ntdws12.chass.utoronto.ca> Excerpts from Edward Z. Yang's message of Mon Jun 08 14:18:41 -0400 2009: > The unfortunate bit about Ruby 1.9 is that the majority of libraries sup uses > aren't on 1.9 yet... ...and some platforms don't have packages for it yet, which puts more onus on the user to get it up and going... -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon Jun 8 14:59:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 11:59:04 -0700 Subject: [sup-talk] exception with undomanager In-Reply-To: <1244485084-sup-973@javelin> References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> <1244481362-sup-970@entry> <1244485084-sup-973@javelin> Message-ID: <1244487518-sup-3141@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-08: > The unfortunate bit about Ruby 1.9 is that the majority of libraries > sup uses aren't on 1.9 yet... Not a serious suggestion. One rewrite going at a time is my rule. :) -- William From ezyang@MIT.EDU Mon Jun 8 15:02:28 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 15:02:28 -0400 Subject: [sup-talk] exception with undomanager In-Reply-To: <1244486944-sup-293@ntdws12.chass.utoronto.ca> References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> <1244481362-sup-970@entry> <1244485084-sup-973@javelin> <1244486944-sup-293@ntdws12.chass.utoronto.ca> Message-ID: <1244487681-sup-5778@javelin> Excerpts from Ben Walton's message of Mon Jun 08 14:50:19 -0400 2009: > ...and some platforms don't have packages for it yet, which puts more > onus on the user to get it up and going... Ruby is basically not usable with your package manager. You *have* to roll the gems yourself. Cheers, Edward From bwalton@artsci.utoronto.ca Mon Jun 8 15:20:31 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 08 Jun 2009 15:20:31 -0400 Subject: [sup-talk] exception with undomanager In-Reply-To: <1244487681-sup-5778@javelin> References: <1244377876-sup-7845@ntdws12.chass.utoronto.ca> <1244481362-sup-970@entry> <1244485084-sup-973@javelin> <1244486944-sup-293@ntdws12.chass.utoronto.ca> <1244487681-sup-5778@javelin> Message-ID: <1244488618-sup-3388@ntdws12.chass.utoronto.ca> Excerpts from Edward Z. Yang's message of Mon Jun 08 15:02:28 -0400 2009: > Ruby is basically not usable with your package manager. You *have* to > roll the gems yourself. I realize this. Gems are awesome and gems suck. I'm talking about the matz ruby interpreter itself. In some instances, not only would the user need all of the gems, but they'd need a 1.9 ruby too...that a big commitment to run a mail client. [As a side note, Debian/Ubuntu do package many of the gems, but it's a round hole, square peg affair.] Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From joe@talkhouse.com Mon Jun 8 16:03:58 2009 From: joe@talkhouse.com (=?ISO-8859-1?Q?Joe_W=F6lfel?=) Date: Mon, 8 Jun 2009 16:03:58 -0400 Subject: [sup-talk] Can't seem to send mail In-Reply-To: <1244486438-sup-3501@ntdws12.chass.utoronto.ca> References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> <1244476264-sup-5281@ntdws12.chass.utoronto.ca> <1244486438-sup-3501@ntdws12.chass.utoronto.ca> Message-ID: On Jun 8, 2009, at 2:44 PM, Ben Walton wrote: > Excerpts from Joe W?lfel's message of Mon Jun 08 14:05:34 -0400 2009: >> It looks like sendmail isn't functioning and doesn't generate any >> errors. Maybe it's a mac problem. I haven't tried it on anything >> else yet. > > Personally, I don't think sendmail has _ever_ been functional, but > that's just the grumpy side of me that has to configure it on clunky > old boxes still! :) > > It's likely working, but has a local delivery setup configured. Try > using `mailq` to see if anything is sitting in the outbound queue. > You may also want to look in /var/spool/mail for mbox files sitting > there with the messages (or bounces) sent from sup. > > If you want to get your hands dirty, I recommend exim as the > replacment for sendmail. I like it's configuration and acl setup > better than postfix, but that would also work. If you just want to > send mail quickly and easily, try msmtp or a similar package. Thanks. Looks like msmtp did the trick. Debugging sendmail was more than I cared to take on. From garoth@gmail.com Mon Jun 8 16:53:42 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 8 Jun 2009 16:53:42 -0400 Subject: [sup-talk] Can't seem to send mail In-Reply-To: References: <5A0B9D69-9D14-4E57-8BB1-1CE4E3AF4E65@talkhouse.com> <1244476264-sup-5281@ntdws12.chass.utoronto.ca> <1244486438-sup-3501@ntdws12.chass.utoronto.ca> Message-ID: <80055d7c0906081353s276ed18o156f12d8df981e28@mail.gmail.com> > Thanks. ?Looks like msmtp did the trick. ?Debugging sendmail was more than I Yeah, it sure is scary. Glad that helped. Cheers, -AT From wmorgan-sup@masanjin.net Mon Jun 8 17:34:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 14:34:31 -0700 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244246896-sup-4529@javelin> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> <1244208597-sup-4979@entry> <1244246896-sup-4529@javelin> Message-ID: <1244496654-sup-5759@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-05: > Great! My hook works now. This is the sort of functionality that I > think is worth generalizing and implementing as a configuration > twiddle (one, I think, that should be on by default.) I have a strong preference for hooks over configuration variables. Look at the .muttrc documentation for why. -- William From ezyang@MIT.EDU Mon Jun 8 17:59:39 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 17:59:39 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244496654-sup-5759@entry> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> <1244208597-sup-4979@entry> <1244246896-sup-4529@javelin> <1244496654-sup-5759@entry> Message-ID: <1244498316-sup-1297@javelin> Excerpts from William Morgan's message of Mon Jun 08 17:34:31 -0400 2009: > I have a strong preference for hooks over configuration variables. Look > at the .muttrc documentation for why. There's an interesting usability argument there. Right now, I still (possibly naively) believe that if you organize your configuration properly, you can have an arbitrarily large amount of it. What's your opinion on making this default behavior, with no configuration twiddle? Cheers, Edward From ezyang@MIT.EDU Mon Jun 8 19:14:32 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 19:14:32 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244481844-sup-9094@entry> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> Message-ID: <1244502545-sup-9840@javelin> Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009: > It might not be too bad. Turn off the call to m.load_from_source! on > line 106 of thread-index-mode.rb, add a Queue to ThreadViewMode > containing messages to call #load_from_source! on, don't call m.chunks > in ThreadViewMode#regen_text unless the message has been loaded, start a > thread that pops messages from the queue, calls #load_from_source! on > them, and then calls regen_text when an open message has been loaded... > and you're 90% of the way there. A few questions: * How do I tell if a message is shown on the screen or not? * The implementation you describe still downloads the messages sequentially, which are usually not the messages we want to download first. I don't mind sup blocking on downloading a message, as long as it's one or two, which means I don't strictly need threads: I just need some API for, when a new message is opened, downloading it and then rendering it. What do you think of this? > The auto-completion is awesome. Adding a recipient to the contacts list is > a good idea. Does contacts.rb apply to people.txt or contacts.txt? > It's definitely worse than O(n). Loading threads could be sped up > dramatically by storing the thread structure somewhere (either cached or > just for every thread), since Sup does a lot of extra work rethreading > everything every time you start it up. FWIW I'm doing this the right way > in Sup 2.0. Can you backport it easily to Sup 1.0? > There have been a couple similar requests like this recently, though > it's not clear if everyone has known about the ability to change the > reply mode and about the reply-to hook. Since hitting 'r' defaults to > replying to the sender alone (except for mailing list messages), I'd be > ok with adding a Mutt-style reply-to-all key that starts up reply-mode > with the 'reply to all' mode active. The explicit prompt makes me think about who I want to send the message to. I frequently forget to move the little knob with Sup's behavior. Cheers, Edward From wmorgan-sup@masanjin.net Mon Jun 8 19:46:39 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 08 Jun 2009 16:46:39 -0700 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244502545-sup-9840@javelin> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> Message-ID: <1244503985-sup-8587@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-08: > * How do I tell if a message is shown on the screen or not? If m is the message, @layout[m].state will be :open, :detailed or :closed. If it's not :closed, it is visible. > * The implementation you describe still downloads the messages > sequentially, which are usually not the messages we want to download > first. Only if you add them to the Queue sequentially. You could instead add the ones with :unread or :starred labels first. And ideally if you expand a collapsed unloaded message, that should be pushed to the head of the Queue. > I don't mind sup blocking on downloading a message, as long > as it's one or two, which means I don't strictly need threads: I > just need some API for, when a new message is opened, downloading it > and then rendering it. What do you think of this? So you would only preload the new/starred ones, and load the others only when they're expanded? I think that simply removing that call in thread-index-mode.rb would accomplish this. I'd rather have the threaded version, since loading a thread of 100 new messages sucks, but either way would be an improvement. > > The auto-completion is awesome. Adding a recipient to the contacts > > list is a good idea. > > Does contacts.rb apply to people.txt or contacts.txt? contacts.txt. people.txt is deprecated. In fact I'm surprised you have one. > > It's definitely worse than O(n). Loading threads could be sped up > > dramatically by storing the thread structure somewhere (either > > cached or just for every thread), since Sup does a lot of extra work > > rethreading everything every time you start it up. FWIW I'm doing > > this the right way in Sup 2.0. > > Can you backport it easily to Sup 1.0? No, it's completely different. It would be easier to rewrite from scratch for the existing Sup. > The explicit prompt makes me think about who I want to send the > message to. I frequently forget to move the little knob with Sup's > behavior. When do you want it to prompt you? Is this a yes/no prompt? -- William From ezyang@MIT.EDU Mon Jun 8 20:12:44 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 20:12:44 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244502124-sup-7043@cabinet> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> <1244208597-sup-4979@entry> <1244246896-sup-4529@javelin> <1244496654-sup-5759@entry> <1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet> Message-ID: <1244506097-sup-8895@javelin> Excerpts from Marc Hartstein's message of Mon Jun 08 19:09:16 -0400 2009: > Reading the thread, it's not clear exactly what your hook does, or what > behavior you want as the default. I didn't see anything which said what > you were trying to accomplish. My apologies. My sup email comes from three distinct sources, and as part of my configuration they get a label as such (mit, twp or ita). This label is the most visible way of telling me which source my mail came from. I am subscribed to numerous mailing lists, however, which do not explicitly list my mail address in To or CC. As a result, Sup defaults to my "main address". What I would like Sup to do is look at the label, find the appropriate source, and use the email in the source to populate the From field. This is different from what you describe below. > Attempting to figure it out from your code samples, I'm guessing that > you're trying to get sup to always reply with a from address of the > known address of yours found in the recipient list of the email being > relied to, if any? If Sup doesn't do the correct thing in this case, this additional hook would be useful. > I do get the sense that there might be a lot of people out there who > want to use the default (always use default account) behavior, so I'm > not sure about switching the default. I wouldn't exactly be against it, > though. I would argue that most people have at least a personal and a work email account, and that it is not appropriate to conflate the two. They can write a hook that overrides an address (or, horror horror, a twiddle in sources) to do it. Cheers, Edward From garoth@gmail.com Mon Jun 8 20:37:53 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 8 Jun 2009 17:37:53 -0700 Subject: [sup-talk] Gmail Labels Sidebar Message-ID: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> Hello there, As some of you probably remember, there is a handy sidebar in Gmail which lists your tags and how many e-mails you have in each one. What I do with this is have e-mail skip my inbox, get a mailing list tag applied to it, and then get archived, at which point it shows up in my labels sidebar. I have my "important" mail in my inbox, and the mailing lists with updates are clearly marked. Any suggestions as to what sup users do to have this kind of workflow? It's preferable for me because it keeps things tidy, I can see the new mails, and I get >50 e-mails per day. It'd be a shame to have them all fall into my inbox and spam it up, which I prefer to keep clean for "needs to be taken care of immediately" type e-mail. Thanks, -AT From bwalton@artsci.utoronto.ca Mon Jun 8 21:05:06 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 08 Jun 2009 21:05:06 -0400 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> Message-ID: <1244509454-sup-1208@ntdws12.chass.utoronto.ca> Excerpts from Andrei Thorp's message of Mon Jun 08 20:37:53 -0400 2009: > Any suggestions as to what sup users do to have this kind of workflow? > It's preferable for me because it keeps things tidy, I can see the new > mails, and I get >50 e-mails per day. It'd be a shame to have them all > fall into my inbox and spam it up, which I prefer to keep clean for > "needs to be taken care of immediately" type e-mail. Use the Label view. Hit L followed by enter. HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 235 bytes Desc: not available URL: From ezyang@MIT.EDU Mon Jun 8 22:13:17 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 22:13:17 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244503985-sup-8587@entry> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> Message-ID: <1244506405-sup-5117@javelin> Thanks for the answers to the technical questions. Excerpts from William Morgan's message of Mon Jun 08 19:46:39 -0400 2009: > So you would only preload the new/starred ones, and load the others only > when they're expanded? I think that simply removing that call in > thread-index-mode.rb would accomplish this. > > I'd rather have the threaded version, since loading a thread of 100 new > messages sucks, but either way would be an improvement. I am somewhat skeptical of your described change, but I will try it out and report back. The threaded version would certainly be a nice thing. > contacts.txt. people.txt is deprecated. In fact I'm surprised you have > one. Um... my contacts.txt is empty, and people.txt has lots of entries in it. > No, it's completely different. It would be easier to rewrite from > scratch for the existing Sup. Savvy. > > The explicit prompt makes me think about who I want to send the > > message to. I frequently forget to move the little knob with Sup's > > behavior. > > When do you want it to prompt you? Is this a yes/no prompt? Yes. (to yes/no). Cheers, Edward From ezyang@MIT.EDU Mon Jun 8 22:14:30 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 22:14:30 -0400 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244509454-sup-1208@ntdws12.chass.utoronto.ca> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> Message-ID: <1244513641-sup-360@javelin> Excerpts from Ben Walton's message of Mon Jun 08 21:05:06 -0400 2009: > Use the Label view. Hit L followed by enter. I think what he's looking for is the information about his labels to always be present, as opposed to something he has to remind himself to check. Cheers, Edward From ezyang@MIT.EDU Mon Jun 8 22:23:44 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 22:23:44 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244506405-sup-5117@javelin> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> <1244506405-sup-5117@javelin> Message-ID: <1244514081-sup-2943@javelin> Excerpts from Edward Z. Yang's message of Mon Jun 08 22:13:17 -0400 2009: > I am somewhat skeptical of your described change, but I will try it > out and report back. The threaded version would certainly be a nice > thing. It works, although it acts a bit strangely when there are still threads loading into memory. >From b2518f113118e489e22a1c2085b33a9c18721f97 Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Mon, 8 Jun 2009 22:21:01 -0400 Subject: [PATCH] Remove message pre-loading; optimizes for the common case. Signed-off-by: Edward Z. Yang --- lib/sup/modes/thread-index-mode.rb | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 9b44ee3..29de39a 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -103,7 +103,6 @@ EOS t.each_with_index do |(m, *o), i| next unless m BufferManager.say "#{message} (#{i}/#{num})", sid if t.size > 1 - m.load_from_source! end end mode = ThreadViewMode.new t, @hidden_labels, self -- 1.6.0.4 From bwalton@artsci.utoronto.ca Mon Jun 8 22:24:42 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 08 Jun 2009 22:24:42 -0400 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244513641-sup-360@javelin> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> Message-ID: <1244514031-sup-2335@ntdws12.chass.utoronto.ca> Excerpts from Edward Z. Yang's message of Mon Jun 08 22:14:30 -0400 2009: > I think what he's looking for is the information about his labels > to always be present, as opposed to something he has to remind > himself to check. So something similar to the folder view hack/patch for mutt? That doesn't exist in sup. The closest you get is having the 'All Labels' buffer open. You can jump to a view of all messages with that label by hitting enter on the selected label. Moving back to it is simple with the buffer rolling keys. I believe that some people operate from this buffer instead of the inbox one. Not my cup of tea though. HTH. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ezyang@MIT.EDU Mon Jun 8 22:35:04 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 22:35:04 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244514081-sup-2943@javelin> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> <1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin> Message-ID: <1244514851-sup-1414@javelin> Excerpts from Edward Z. Yang's message of Mon Jun 08 22:23:44 -0400 2009: > It works, although it acts a bit strangely when there are still > threads loading into memory. I think I've been able to pin down this behavior more precisely, and it's not just this patches fault: displaying messages seems to block on having all of the threads present. Does this ring a bell? Cheers, Edward From ezyang@MIT.EDU Mon Jun 8 22:38:08 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 22:38:08 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244481844-sup-9094@entry> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> Message-ID: <1244515056-sup-4758@javelin> Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009: > > 3. Polling and loading of threads should started, asynchronously, at > > the same time. > > > Loading of threads should not hose my CPU. > > Agreed. Please fix. It appears that polling blocks on loading threads, so it doesn't help to fix that until we fix the thread loading code. Cheers, Edward From ezyang@MIT.EDU Mon Jun 8 23:00:55 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Mon, 08 Jun 2009 23:00:55 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244481844-sup-9094@entry> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> Message-ID: <1244515897-sup-539@javelin> Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009: > It's definitely worse than O(n). Loading threads could be sped up > dramatically by storing the thread structure somewhere (either cached or > just for every thread), since Sup does a lot of extra work rethreading > everything every time you start it up. FWIW I'm doing this the right way > in Sup 2.0. I'm thinking about how to do this, and one of the first I'm blockers I'm running against is that it's not quite obvious what's invoking the thread building code thread.rb. As for caching the thread, I'm thinking of generating a unique ID for each thread and sticking that on every message. Whether or not this will actually help depends a lot on what the answer to the above question is. Cheers, Edward From ezyang@MIT.EDU Tue Jun 9 00:06:40 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Tue, 09 Jun 2009 00:06:40 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244518550-sup-6361@cabinet> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> <1244208597-sup-4979@entry> <1244246896-sup-4529@javelin> <1244496654-sup-5759@entry> <1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet> <1244506097-sup-8895@javelin> <1244518550-sup-6361@cabinet> Message-ID: <1244519893-sup-7418@javelin> Excerpts from Marc Hartstein's message of Mon Jun 08 23:46:48 -0400 2009: > I think that's beyond what I'd personally think of as a "configuration > twiddle", though... Perhaps. > You'd do it by, what, having a 1:1 mapping between email addresses and > labels somewhere in the configuration, anything coming to the email > address gets the label, and any reply to a message with the label > (however it got it) gets the email address? Yes. > (It's also not as though the hook to only use your default address is > hard to write.) Indeed. Cheers, Edward From tarko@lanparty.ee Tue Jun 9 06:00:13 2009 From: tarko@lanparty.ee (Tarko Tikan) Date: Tue, 09 Jun 2009 13:00:13 +0300 Subject: [sup-talk] display_length issue with special-characters on non-UTF8 terminal Message-ID: <1244536704-sup-7027@valgus> hey, When String.display_length was introduced in recent update, it broke the length for non-UTF8 strings that contain the special characters. Wrong length results corrupted display (line ends chopped off). Terminal is iso-8859-15 and it's detected by sup correctly. I've tracked it down to /./u regexp. Here are some examples: irb(main):001:0> "asd".scan(/./u) => ["a", "s", "d"] irb(main):002:0> "asd????".scan(/./u) => ["a", "s", "d", "\365\374\344\366"] irb(main):017:0> "asd???".scan(/./u) => ["a", "s", "d"] irb(main):008:0* "asd".scan(/./) => ["a", "s", "d"] irb(main):009:0> "asd????".scan(/./) => ["a", "s", "d", "\365", "\374", "\344", "\366"] Expecting UTF8 gives unexpected results :) Also, old behaviour of String.length gives correct results with these test cases. -- tarko From garoth@gmail.com Tue Jun 9 09:33:15 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 9 Jun 2009 09:33:15 -0400 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244514031-sup-2335@ntdws12.chass.utoronto.ca> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> Message-ID: <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> Yeah, I guess that makes sense. It is a rather nice interface actually, I didn't really think about it for some reason. And I guess there are probably some configuration options to skip inbox and attach labels to stuff matching stuff automatically, with procmail. I think I saw a page about that somewhere. I guess there is probably a way to programatically access this kind of information also, but are there any command line tools I can use to query for this kind of stuff? If so, I can hack my window manager's panels to display the mails in these labels, which would be pretty rad. (My WM is "Awesome" btw -- that's the name.) Any suggestions for quickly getting this labels-has-unread-messages info outside of sup? Thanks guys! :) -AT From garoth@gmail.com Tue Jun 9 09:42:29 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 9 Jun 2009 09:42:29 -0400 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> Message-ID: <80055d7c0906090642h421964f2t41d52290042469bc@mail.gmail.com> On Tue, Jun 9, 2009 at 9:33 AM, Andrei Thorp wrote: > Yeah, I guess that makes sense. It is a rather nice interface > actually, I didn't really think about it for some reason. I just actually ran a quick test (with 0.8) and it looks like the label-list-mode fails to update automatically D: What I did was put on the label-list-mode, manually send myself an e-mail, re-run fetchmail to grab it (I get a notification via procmail saying it came in). Then I remember that sup polls at intervals, so I wait. Eventually, the status bar at the bottom says that there is a new message in the inbox, but the Inbox label does not get updated in my view. It still says 0/0. I press x to go back to the inbox screen, it has the mail. I go back to label-list-mode, and now it registers it. So I guess I'd call that a bug actually, and it's unlikely that people operate out of this mode habitually or else this would have probably been found. (Unless it already has?) Cheers, -AT From marcus-sup@bar-coded.net Tue Jun 9 10:11:08 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Tue, 09 Jun 2009 15:11:08 +0100 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> Message-ID: <1244556424-sup-1426@tomsk> On 9.6.2009, Andrei Thorp wrote: > Any suggestions for quickly getting this labels-has-unread-messages > info outside of sup? Attached is a labels mode outside of sup... Useful for conky etc. Just pipe the output to a file (warnings errors etc wont go to the file) William - if you want to add this to sup/bin feel free. Its basically the regen_text method lifted and edited slightly from the label-list-mode It might need a few more tweaks - I'm not sure it needs to load/save/unlock the index really. They're there because they came for free with the copy and paste of bin/sup-tweak-labels :) Marcus -------------- next part -------------- A non-text attachment was scrubbed... Name: sup-list-labels Type: application/octet-stream Size: 1773 bytes Desc: not available URL: From marcus-sup@bar-coded.net Tue Jun 9 10:24:35 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Tue, 09 Jun 2009 15:24:35 +0100 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244556424-sup-1426@tomsk> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> <1244556424-sup-1426@tomsk> Message-ID: <1244557461-sup-4140@tomsk> On 9.6.2009, I wrote: > On 9.6.2009, Andrei Thorp wrote: > > Any suggestions for quickly getting this labels-has-unread-messages > > info outside of sup? > > Attached is a labels mode outside of sup... Useful for conky etc. Just > pipe the output to a file (warnings errors etc wont go to the file) Oh and I forgot - if you want to kick off sup from a click on one of these labels (assuming you can do something like that in your WM) you can call sup with --search "label:somelabel" to get that label displayed. Marcus From marcus-sup@bar-coded.net Tue Jun 9 10:29:55 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Tue, 09 Jun 2009 15:29:55 +0100 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244556424-sup-1426@tomsk> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> <1244556424-sup-1426@tomsk> Message-ID: <1244557672-sup-7417@tomsk> On 9.6.2009, I wrote: > William - if you want to add this to sup/bin feel free. Its basically > the regen_text method lifted and edited slightly from the > label-list-mode You might want to delete lines 24-26 as well to save the warning about uninitialised variable. At some point I'll post my version with a query which is a little less hurried, but doesnt work quite how I want yet. Marcus From garoth@gmail.com Tue Jun 9 10:37:54 2009 From: garoth@gmail.com (Andrei Thorp) Date: Tue, 9 Jun 2009 10:37:54 -0400 Subject: [sup-talk] Fwd: Gmail Labels Sidebar In-Reply-To: <80055d7c0906090735x581d27a2pfeb3ca2d470bb099@mail.gmail.com> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> <1244556424-sup-1426@tomsk> <1244557461-sup-4140@tomsk> <80055d7c0906090735x581d27a2pfeb3ca2d470bb099@mail.gmail.com> Message-ID: <80055d7c0906090737g46f9f3b3y7ee00b91dbe08f22@mail.gmail.com> > Oh and I forgot - if you want to kick off sup from a click on one of > these labels (assuming you can do something like that in your WM) you > can call sup with --search "label:somelabel" to get that label > displayed. Damn, that's a great idea! I didn't even think about that. /me checks up on what else sup has in its cli flags. Cheers, -AT PS. Well, while I'm here, I guess I'll also mention this fairly obvious script line that just outputs the unread messages in a filtered list: sup-list-labels 2> /dev/null | grep -E "Inbox|Sent" | sed -r "s/^ *([A-Za-z]*).* ([0-9]+) unread/\1: \2/" So to go through this: ?- Pipe the stderr to /dev/null (we don't want to see the messages) ?- grep for either "Inbox" or "Sent" -- you can put lots more |blah|blah there ?- sed magic to extract and reformat the data This might be useful for outputting somewhere like in a shell prompt or panel. PPS. argh, still not using sup for this mailing list so I replied to an individual. Forwarded D: PPPS. Sorry that it wrapped my sed command there, but I'm sure you get the idea. PPPPS. Sorry about the unfashionable amount of PSes ;) From wmorgan-sup@masanjin.net Tue Jun 9 12:52:37 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 09 Jun 2009 09:52:37 -0700 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244518550-sup-6361@cabinet> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> <1244208597-sup-4979@entry> <1244246896-sup-4529@javelin> <1244496654-sup-5759@entry> <1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet> <1244506097-sup-8895@javelin> <1244518550-sup-6361@cabinet> Message-ID: <1244565962-sup-4211@entry> Reformatted excerpts from Marc Hartstein's message of 2009-06-08: > I think that's beyond what I'd personally think of as a "configuration > twiddle", though... I tend to agree. I completely understand the use case, and I agree it's probably a common one, but this is exactly the kind of thing I want to address with hooks instead of with configuration. (Not that there's *really* a distinction between these two things in the first place.) Then when the next guy comes along and says, "I like this but I want my from address based on X instead of the label", I can also avoid having to do any work. Edward, if you want to invest time on making this particular scheme easy for users, I would be happy to include contributed hooks as part of the Sup distribution, and you can supply one that reads a simple configuration file and produces this behavior. -- William From wmorgan-sup@masanjin.net Tue Jun 9 13:32:53 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 09 Jun 2009 10:32:53 -0700 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244506405-sup-5117@javelin> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> <1244506405-sup-5117@javelin> Message-ID: <1244567126-sup-1563@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-08: > Excerpts from William Morgan's message of Mon Jun 08 19:46:39 -0400 2009: > > contacts.txt. people.txt is deprecated. In fact I'm surprised you have > > one. > > Um... my contacts.txt is empty, and people.txt has lots of entries in it. Does your people.txt have a really old timestamp? That file doesn't get touched by any version of Sup later less than three months old. Do you add people to your contact list with 'i'? If not, contacts.txt will be empty. > > When do you want it to prompt you? Is this a yes/no prompt? > > Yes. (to yes/no). So... once you write the email and you press 'y' it prompts you whether you want to send it? Or when you press 'r' it prompts you whether you really want to reply? -- William From wmorgan-sup@masanjin.net Tue Jun 9 13:40:38 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 09 Jun 2009 10:40:38 -0700 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244514851-sup-1414@javelin> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> <1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin> <1244514851-sup-1414@javelin> Message-ID: <1244569129-sup-4112@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-08: > I think I've been able to pin down this behavior more precisely, > and it's not just this patches fault: displaying messages seems to > block on having all of the threads present. Does this ring a bell? Not entirely sure what you mean by "having all the threads present", but opening a thread-view-mode buffer doesn't block on anything, at least with that patch applied. Without the patch, it blocks on loading the message body for every message in that particular thread from the server. -- William From wmorgan-sup@masanjin.net Tue Jun 9 13:45:45 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 09 Jun 2009 10:45:45 -0700 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244515056-sup-4758@javelin> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244515056-sup-4758@javelin> Message-ID: <1244569341-sup-7836@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-08: > Excerpts from William Morgan's message of Mon Jun 08 14:00:23 -0400 2009: > > > 3. Polling and loading of threads should started, asynchronously, > > > at the same time. > > > > > Loading of threads should not hose my CPU. > > > > Agreed. Please fix. > > It appears that polling blocks on loading threads, so it doesn't help > to fix that until we fix the thread loading code. My "agreed, please fix" was in response to "loading of threads should not hose my CPU". Polling currently blocks on loading threads, but that's an explicit block. I forget why I did that now. You can unblock it and see if it makes life better. (bin/sup circa line 205.) -- William From wmorgan-sup@masanjin.net Tue Jun 9 13:48:59 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Tue, 09 Jun 2009 10:48:59 -0700 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244514081-sup-2943@javelin> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> <1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin> Message-ID: <1244569567-sup-7515@entry> Reformatted excerpts from Edward Z. Yang's message of 2009-06-08: > From: Edward Z. Yang > Date: Mon, 8 Jun 2009 22:21:01 -0400 > Subject: [PATCH] Remove message pre-loading; optimizes for the common case. The problem with this patch as is is that loading a large thread composed of entirely new messages still requires loading all the message bodies from the server, which can take a couple seconds, but now there's no indication of what's happening. So either the fancy background loading needs to happen, or somehow a message needs to be displayed when the bodies are being loaded. -- William From bwalton@artsci.utoronto.ca Tue Jun 9 20:55:45 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 09 Jun 2009 20:55:45 -0400 Subject: [sup-talk] lockmanager Message-ID: <1244595206-sup-6689@ntdws12.chass.utoronto.ca> Hi William, I've attached the base LockManager class that I'm envisioning for sup. It's still rough, but the basic functionality is in place. I think it should stand up to the potential contention between PollManager and SentManager. If it looks reasonable, I'll flesh it out with some timeouts and exception handling. Let me know. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: lock.rb Type: application/octet-stream Size: 3575 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ezyang@MIT.EDU Wed Jun 10 01:44:54 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 10 Jun 2009 01:44:54 -0400 Subject: [sup-talk] [PATCH] before-search hook Message-ID: <1244612627-sup-982@javelin> >From a5c72844e8195df7a8eabd5ea592507599de72cb Mon Sep 17 00:00:00 2001 From: Edward Z. Yang Date: Wed, 10 Jun 2009 01:42:50 -0400 Subject: [PATCH] Add before-search hook, for shortcuts for custom search queries. Signed-off-by: Edward Z. Yang --- lib/sup/hook.rb | 4 ++++ lib/sup/index.rb | 12 +++++++++++- 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/lib/sup/hook.rb b/lib/sup/hook.rb index 0a0a2f6..d446aa3 100644 --- a/lib/sup/hook.rb +++ b/lib/sup/hook.rb @@ -19,6 +19,10 @@ class HookManager attr_writer :__locals + ## an annoying gotcha here is that if you try something + ## like var = var.foo(), var will magically get allocated + ## to Nil and method_missing will never get called. Stick + ## to mutation, kiddos! def method_missing m, *a case @__locals[m] when Proc diff --git a/lib/sup/index.rb b/lib/sup/index.rb index e403570..19556f0 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -25,6 +25,13 @@ class Index include Singleton + HookManager.register "before-search", < subs) + + subs = subs.gsub(/\b(to|from):(\S+)\b/) do field, name = $1, $2 if(p = ContactManager.contact_for(name)) [field, p.email] -- 1.6.0.4 From joe@talkhouse.com Wed Jun 10 13:21:58 2009 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=) Date: Wed, 10 Jun 2009 13:21:58 -0400 Subject: [sup-talk] IMAP alternative for Sup? Message-ID: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local> I am using sup with IMAP. I connect via multiple accounts using multiple machines. This is not surprisingly very slow. Is there an IMAP alternative that caches all messages locally that is not too complicated to setup with Sup? Thanks, Joe From ezyang@MIT.EDU Wed Jun 10 13:25:08 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 10 Jun 2009 13:25:08 -0400 Subject: [sup-talk] IMAP alternative for Sup? In-Reply-To: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local> References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local> Message-ID: <1244654688-sup-4183@javelin> Excerpts from Joe W?lfel's message of Wed Jun 10 13:21:58 -0400 2009: > I am using sup with IMAP. I connect via multiple accounts using multiple > machines. This is not surprisingly very slow. Is there an IMAP alternative > that caches all messages locally that is not too complicated to setup with Sup? The solution commonly recommended is OfflineImap. I have not tried this myself. Cheers, Edward From joe@talkhouse.com Wed Jun 10 10:42:34 2009 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=) Date: Wed, 10 Jun 2009 10:42:34 -0400 Subject: [sup-talk] IMAP alternative works well with sup? Message-ID: <1244644197-sup-9224@joe-wolfels-power-mac-g5.local> I've been using sup with IMAP and retrieving messages from 3rd party providers is not surprisingly slow. Is there a good alternative that will cache messages locally that isn't complicated to setup with sup? I use multiple machines with multiple accounts. Thanks, Joe From bachjh@googlemail.com Wed Jun 10 13:50:49 2009 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=) Date: Wed, 10 Jun 2009 19:50:49 +0200 Subject: [sup-talk] sup and ncursesw Message-ID: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com> Hi all, I recently installed sup 0.8 and find I am having problems with umlauts and accented characters. There is a patch for the ncurses-0.9.1 gem on the sup wiki ("utf8-issues") which allows the characters to be displayed correctly, but after applying the patch I can't enter proper text. Hitting 'c' for compose works, but entering '123' for subject ends in a subject line such as: Subject: P<85>??P<85>???C" ?C" (it's a different set of confused characters each time) Similar when searching for messages using '\' or 'L'. I am on ubuntu 9.04 with libncursesw5{,-dev} version 5.7+20090207, sup 0.8. Any hints? cheers, - J?rg-Hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang@MIT.EDU Wed Jun 10 17:51:01 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 10 Jun 2009 17:51:01 -0400 Subject: [sup-talk] [PATCH] before-search hook In-Reply-To: <1244612627-sup-982@javelin> References: <1244612627-sup-982@javelin> Message-ID: <1244670591-sup-7078@javelin> For the curious, here is the hook that I'm using with this: subs.gsub!(/\bmy:unread\b/) do "is:unread !label:inbox" end Cheers, Edward From ezyang@MIT.EDU Wed Jun 10 23:18:46 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 10 Jun 2009 23:18:46 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244569129-sup-4112@entry> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> <1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin> <1244514851-sup-1414@javelin> <1244569129-sup-4112@entry> Message-ID: <1244690240-sup-884@javelin> Excerpts from William Morgan's message of Tue Jun 09 13:40:38 -0400 2009: > Not entirely sure what you mean by "having all the threads present", but > opening a thread-view-mode buffer doesn't block on anything, at least > with that patch applied. Without the patch, it blocks on loading the > message body for every message in that particular thread from the > server. Yeah. I mean what I mean: it *shouldn't* block on anything, but as far as I can tell from manual testing, thread-view-mode doesn't open up until I'm done threading the index. Maybe that's why. Cheers, Edward From ezyang@MIT.EDU Wed Jun 10 23:19:32 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 10 Jun 2009 23:19:32 -0400 Subject: [sup-talk] Sup annoyances In-Reply-To: <1244569567-sup-7515@entry> References: <1244270435-sup-9288@javelin> <1244481844-sup-9094@entry> <1244502545-sup-9840@javelin> <1244503985-sup-8587@entry> <1244506405-sup-5117@javelin> <1244514081-sup-2943@javelin> <1244569567-sup-7515@entry> Message-ID: <1244690337-sup-2840@javelin> Excerpts from William Morgan's message of Tue Jun 09 13:48:59 -0400 2009: > The problem with this patch as is is that loading a large thread > composed of entirely new messages still requires loading all the message > bodies from the server, which can take a couple seconds, but now there's > no indication of what's happening. So either the fancy background > loading needs to happen, or somehow a message needs to be displayed when > the bodies are being loaded. Understood. There's also another odd bug where the headers for the open messages "blow up" (get split into three lines each) which gets fixed when you collapse and the expand the headers again. Cheers, Edward From ezyang@MIT.EDU Wed Jun 10 23:38:12 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Wed, 10 Jun 2009 23:38:12 -0400 Subject: [sup-talk] Attempt at reply-from hook In-Reply-To: <1244565962-sup-4211@entry> References: <1243898254-sup-7513@javelin> <1243980495-sup-7229@cannonball> <1243997614-sup-7485@javelin> <1244029436-sup-6141@ntdws12.chass.utoronto.ca> <1244179379-sup-6675@javelin> <1244208597-sup-4979@entry> <1244246896-sup-4529@javelin> <1244496654-sup-5759@entry> <1244498316-sup-1297@javelin> <1244502124-sup-7043@cabinet> <1244506097-sup-8895@javelin> <1244518550-sup-6361@cabinet> <1244565962-sup-4211@entry> Message-ID: <1244691413-sup-727@javelin> Excerpts from William Morgan's message of Tue Jun 09 12:52:37 -0400 2009: > Edward, if you want to invest time on making this particular scheme easy > for users, I would be happy to include contributed hooks as part of the > Sup distribution, and you can supply one that reads a simple > configuration file and produces this behavior. The thing is that this needs no configuration: sources.yaml will tell us the correspondence between label and email. If anything, I would bill this as an improvement to the "From" detection algorithm. Cheers, Edward From marcus-sup@bar-coded.net Thu Jun 11 05:05:38 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Thu, 11 Jun 2009 10:05:38 +0100 Subject: [sup-talk] Sup locking up Message-ID: <1244710855-sup-1368@tomsk> Hi - Something new has started happening in sup ? I think this is what Edward was talking about, but it appears to lock up every now and again in a way that it never used to. Once its locked up it doesnt come back and I dont seem to be able to ctrl-c/d/z out of it. Its only started in the last few days and I dont think its my IMAP server. Oddly its breaking my screen session as well which is odder still - the screen with sup running is locked completely (I can create new shells from screen and use them fine, its just the sup session within screen). Anyone else seeing this (running next branch)? Marcus From bwalton@artsci.utoronto.ca Thu Jun 11 07:23:49 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 11 Jun 2009 07:23:49 -0400 Subject: [sup-talk] Sup locking up In-Reply-To: <1244710855-sup-1368@tomsk> References: <1244710855-sup-1368@tomsk> Message-ID: <1244719333-sup-9770@ntdws12.chass.utoronto.ca> Excerpts from Marcus Williams's message of Thu Jun 11 05:05:38 -0400 2009: > Anyone else seeing this (running next branch)? No...and I'm running from the most recent next with a few local patches (message bouncing, currently). I run in screen as well. Is there anything constant about when the lockup occurs? Has anything else about your system/setup changed that could impact this? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From usul@aruba.it Thu Jun 11 07:39:29 2009 From: usul@aruba.it (Fabio Riga) Date: Thu, 11 Jun 2009 13:39:29 +0200 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1244717279-sup-5999@viajero> References: <1244717279-sup-5999@viajero> Message-ID: <1244719933-sup-4261@viajero> Excerpts from Fabio Riga's message of Thu Jun 11 12:48:59 +0200 2009: > a sup-sync, there are no Sent messages in index. Maybe it's a problem > with locale (it) as sup-sync -a sup://sent gives me a lot of lines like: > > [Thu Jun 11 12:32:36 +0200 2009] found invalid date in potential mbox > split line, not splitting: "From usul at aruba.it Thu Jun 11 11:45:37 +0200 > 2009\n" > Scanned 14, added 0, updated 14 messages from sup://sent. > Hello again, I translated with a script names of days and months in ~/.sup/sent.mbox, then made a sup-sync -a sup://sent.mbox and run $ LANG=C sup All is fine, I just need to remember to launch sup this way. Maybe it needs some work on localization? Cheers, Fabio -- Fabio Riga 348 4458014 - fabio at comunicattiva.it ComunicAttiva S.a.s. di Silvana D'Agata & C. via Campestre,189 - Sesto San Giovanni (MI) - Italia tel. 02 97373202 - fax 02 97373474 From garoth@gmail.com Thu Jun 11 09:17:12 2009 From: garoth@gmail.com (Andrei Thorp) Date: Thu, 11 Jun 2009 09:17:12 -0400 Subject: [sup-talk] [BUG?] label-list-mode doesn't update Message-ID: <80055d7c0906110617j2b9a33cene229c1dd28170003@mail.gmail.com> This is forwarded from the middle of another thread. I figured it got lost. On Tue, Jun 9, 2009 at 9:33 AM, Andrei Thorp wrote: > Yeah, I guess that makes sense. It is a rather nice interface > actually, I didn't really think about it for some reason. I just actually ran a quick test (with 0.8) and it looks like the label-list-mode fails to update automatically D: What I did was put on the label-list-mode, manually send myself an e-mail, re-run fetchmail to grab it (I get a notification via procmail saying it came in). Then I remember that sup polls at intervals, so I wait. Eventually, the status bar at the bottom says that there is a new message in the inbox, but the Inbox label does not get updated in my view. It still says 0/0. I press x to go back to the inbox screen, it has the mail. I go back to label-list-mode, and now it registers it. So I guess I'd call that a bug actually, and it's unlikely that people operate out of this mode habitually or else this would have probably been found. (Unless it already has?) Cheers, -AT From marcus-sup@bar-coded.net Thu Jun 11 10:23:28 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Thu, 11 Jun 2009 15:23:28 +0100 Subject: [sup-talk] Sup locking up In-Reply-To: <1244719333-sup-9770@ntdws12.chass.utoronto.ca> References: <1244710855-sup-1368@tomsk> <1244719333-sup-9770@ntdws12.chass.utoronto.ca> Message-ID: <1244730053-sup-6905@tomsk> On 11.6.2009, Ben Walton wrote: > No...and I'm running from the most recent next with a few local > patches (message bouncing, currently). I run in screen as well. Mmmmm. Strange. > Is there anything constant about when the lockup occurs? Has anything > else about your system/setup changed that could impact this? I _think_ it occurs during a poll for new messages. Its difficult to tell though because like I say that "window" in screen gets completely blocked, only killing sup will get out of it (kill -9 rather than a ctrl-c/z/d). Its very odd. Nothing has changed on my box bar sup in recent weeks. Marcus From bwalton@artsci.utoronto.ca Thu Jun 11 11:46:19 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 11 Jun 2009 11:46:19 -0400 Subject: [sup-talk] Sup locking up In-Reply-To: <1244730053-sup-6905@tomsk> References: <1244710855-sup-1368@tomsk> <1244719333-sup-9770@ntdws12.chass.utoronto.ca> <1244730053-sup-6905@tomsk> Message-ID: <1244735117-sup-6933@ntdws12.chass.utoronto.ca> Excerpts from Marcus Williams's message of Thu Jun 11 10:23:28 -0400 2009: > I _think_ it occurs during a poll for new messages. Its difficult to > tell though because like I say that "window" in screen gets completely > blocked, only killing sup will get out of it (kill -9 rather than a > ctrl-c/z/d). Its very odd. Can you strace/truss/whatever the ruby process running sup to see what it's doing? > Nothing has changed on my box bar sup in recent weeks. ...ok. At least that rules out most external interference. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From garoth@gmail.com Thu Jun 11 13:58:26 2009 From: garoth@gmail.com (Andrei Thorp) Date: Thu, 11 Jun 2009 13:58:26 -0400 Subject: [sup-talk] Sup locking up In-Reply-To: <1244735117-sup-6933@ntdws12.chass.utoronto.ca> References: <1244710855-sup-1368@tomsk> <1244719333-sup-9770@ntdws12.chass.utoronto.ca> <1244730053-sup-6905@tomsk> <1244735117-sup-6933@ntdws12.chass.utoronto.ca> Message-ID: <80055d7c0906111058q128b5eb7na8931a8b75b0d0bf@mail.gmail.com> Yeah... I have a theory. Have you learned some new stuff about screen lately? Screen has this binding that pretty much makes it freeze up. I guess I'm talking about http://savannah.gnu.org/bugs/?11610 which applies to screen 4.0.0, which is the one people have. Try maybe running sup out of screen for a while and see if it can happen then. Another test: if screen locks up but sup respects regular kill (not -9), sup's not locked up itself. -AT From marcus-sup@bar-coded.net Thu Jun 11 15:09:19 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Thu, 11 Jun 2009 20:09:19 +0100 Subject: [sup-talk] Sup locking up In-Reply-To: <80055d7c0906111058q128b5eb7na8931a8b75b0d0bf@mail.gmail.com> References: <1244710855-sup-1368@tomsk> <1244719333-sup-9770@ntdws12.chass.utoronto.ca> <1244730053-sup-6905@tomsk> <1244735117-sup-6933@ntdws12.chass.utoronto.ca> <80055d7c0906111058q128b5eb7na8931a8b75b0d0bf@mail.gmail.com> Message-ID: <1244747053-sup-4797@tomsk> On 11.6.2009, Andrei Thorp wrote: > I have a theory. Have you learned some new stuff about screen lately? > Screen has this binding that pretty much makes it freeze up. I guess > I'm talking about http://savannah.gnu.org/bugs/?11610 which applies to > screen 4.0.0, which is the one people have. I dont think debian has this problem, although I may have hit ctrl-a and then s by accident (I actually tried ctrl-q thinking that I had hit ctrl-s by accident when it hung but nothing happened... forgetting that I was in screen so would need to prepend ctrl-a). Its a bit wierd that its happened to me recently and not before though if this is what it was - I leave sup running in screen as it makes imap bearable and havnt run into this problem until recently when its happened a couple of times. I'll keep an eye on it and see if it happens again. Marcus From bwalton@artsci.utoronto.ca Thu Jun 11 19:50:33 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Thu, 11 Jun 2009 19:50:33 -0400 Subject: [sup-talk] (no subject) In-Reply-To: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1244764138-sup-2909@ntdws12.chass.utoronto.ca> Excerpts from Ben Walton's message of Sun Jun 07 20:02:25 -0400 2009: Hi William, > Here's a stab at implementing a message bouncing functionality worthy > of being included on mainline. Is there something you don't like about these patches or have you just been too busy to look at them? I could collapse them into a single patch, thus removing any trace of using $config instead of a Hook, to keep the history cleaner if you'd prefer. If there is something else you'd like to see changed before picking it up, let me know. Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. From usul@aruba.it Thu Jun 11 06:48:59 2009 From: usul@aruba.it (Fabio Riga) Date: Thu, 11 Jun 2009 12:48:59 +0200 Subject: [sup-talk] Crash after sending a message Message-ID: <1244717279-sup-5999@viajero> Hi all, First of all, Sup is a great peace of software because it's a superior and simplified Mutt, it's fast, it isn't web-based (I hate web-based client...) and... Well, great job! I started using 0.7, with no problems at all, excepting those crappy character on screen... Since upgrading to 0.8 my screen looks very nice, but when I send a message, Sup crashes badly. It seems a problem with Ferret failing indexing my Sent box (attached exception-log). After a sup-sync, there are no Sent messages in index. Maybe it's a problem with locale (it) as sup-sync -a sup://sent gives me a lot of lines like: [Thu Jun 11 12:32:36 +0200 2009] found invalid date in potential mbox split line, not splitting: "From usul at aruba.it gio giu 11 11:45:37 +0200 2009\n" Scanned 14, added 0, updated 14 messages from sup://sent. _My sent messages are much more then 14!_ Anyway, messages are sent before the crash.. like this one! Ideas? Thanks, Fabio -- Fabio Riga 348 4458014 - fabio at comunicattiva.it ComunicAttiva S.a.s. di Silvana D'Agata & C. via Campestre,189 - Sesto San Giovanni (MI) - Italia tel. 02 97373202 - fax 02 97373474 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: exception-log.txt URL: From wmorgan-sup@masanjin.net Thu Jun 11 23:44:41 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Thu, 11 Jun 2009 20:44:41 -0700 Subject: [sup-talk] (no subject) In-Reply-To: <1244764138-sup-2909@ntdws12.chass.utoronto.ca> References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> <1244764138-sup-2909@ntdws12.chass.utoronto.ca> Message-ID: <1244778083-sup-4566@entry> Reformatted excerpts from Ben Walton's message of 2009-06-11: > Is there something you don't like about these patches or have you just > been too busy to look at them? Just been busy. Sorry! My Sup time tends to be very bursty. I realize that's not great for contributors. Please have patience with your poor maintainer and feel free to keep bugging me. -- William From ezyang@MIT.EDU Fri Jun 12 00:38:42 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 12 Jun 2009 00:38:42 -0400 Subject: [sup-talk] Sup locking up In-Reply-To: <1244735117-sup-6933@ntdws12.chass.utoronto.ca> References: <1244710855-sup-1368@tomsk> <1244719333-sup-9770@ntdws12.chass.utoronto.ca> <1244730053-sup-6905@tomsk> <1244735117-sup-6933@ntdws12.chass.utoronto.ca> Message-ID: <1244781466-sup-4096@javelin> Excerpts from Ben Walton's message of Thu Jun 11 11:46:19 -0400 2009: > Can you strace/truss/whatever the ruby process running sup to see what > it's doing? Seconded. You can attach strace to Sup while it's running, and it will give you a good fingerprint for what the process is doing when it locks up. Cheers, Edward From bwalton@artsci.utoronto.ca Fri Jun 12 09:15:05 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 12 Jun 2009 09:15:05 -0400 Subject: [sup-talk] (no subject) In-Reply-To: <1244778083-sup-4566@entry> References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> <1244764138-sup-2909@ntdws12.chass.utoronto.ca> <1244778083-sup-4566@entry> Message-ID: <1244812410-sup-2627@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Thu Jun 11 23:44:41 -0400 2009: > Reformatted excerpts from Ben Walton's message of 2009-06-11: > > Is there something you don't like about these patches or have you just > > been too busy to look at them? > > Just been busy. Sorry! My Sup time tends to be very bursty. I realize > that's not great for contributors. Please have patience with your poor > maintainer and feel free to keep bugging me. No problem. You're just very quick to respond typically, so I wanted to make sure that it hadn't fallen through the cracks... Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From joe@talkhouse.com Fri Jun 12 09:21:11 2009 From: joe@talkhouse.com (=?utf-8?q?Joe_W=C3=B6lfel?=) Date: Fri, 12 Jun 2009 09:21:11 -0400 Subject: [sup-talk] IMAP alternative for Sup? In-Reply-To: <1244654688-sup-4183@javelin> References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local> <1244654688-sup-4183@javelin> Message-ID: <1244812462-sup-9446@joe-wolfels-power-mac-g5.local> Excerpts from Edward Z. Yang's message of Wed Jun 10 13:25:08 -0400 2009: > Excerpts from Joe W?lfel's message of Wed Jun 10 13:21:58 -0400 2009: > > I am using sup with IMAP. I connect via multiple accounts using multiple > > machines. This is not surprisingly very slow. Is there an IMAP alternative > > that caches all messages locally that is not too complicated to setup with Sup? > > The solution commonly recommended is OfflineImap. I have not tried this myself. > > Cheers, > Edward That did the trick. Now everything is instantaneous. Also, I noticed that Sup's polling mechanism no longer locks up. With IMAP I used to have to restart Sup on occasion. Now that doesn't seem to happen. I'm not sure if that's relevant to the that other sup-talk thread on locking but maybe it's helpful info . Thanks, Joe From ezyang@MIT.EDU Fri Jun 12 10:14:26 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Fri, 12 Jun 2009 10:14:26 -0400 Subject: [sup-talk] IMAP alternative for Sup? In-Reply-To: <1244812462-sup-9446@joe-wolfels-power-mac-g5.local> References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local> <1244654688-sup-4183@javelin> <1244812462-sup-9446@joe-wolfels-power-mac-g5.local> Message-ID: <1244815945-sup-5020@javelin> Excerpts from Joe W?lfel's message of Fri Jun 12 09:21:11 -0400 2009: > Also, I noticed that Sup's polling mechanism no longer locks up. With IMAP I > used to have to restart Sup on occasion. Now that doesn't seem to happen. I'm > not sure if that's relevant to the that other sup-talk thread on locking but > maybe it's helpful info . This is probably because OfflineIMAP polls more frequently. I've had good results getting rid of the lock up by decreasing Sup's polling time (unfortunately it's hard-coded in Sup). Cheers, Edward From bwalton@artsci.utoronto.ca Fri Jun 12 10:34:48 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Fri, 12 Jun 2009 10:34:48 -0400 Subject: [sup-talk] IMAP alternative for Sup? In-Reply-To: <1244815945-sup-5020@javelin> References: <1244654260-sup-7022@joe-wolfels-power-mac-g5.local> <1244654688-sup-4183@javelin> <1244812462-sup-9446@joe-wolfels-power-mac-g5.local> <1244815945-sup-5020@javelin> Message-ID: <1244817210-sup-9892@ntdws12.chass.utoronto.ca> Excerpts from Edward Z. Yang's message of Fri Jun 12 10:14:26 -0400 2009: > This is probably because OfflineIMAP polls more frequently. I've > had good results getting rid of the lock up by decreasing Sup's > polling time (unfortunately it's hard-coded in Sup). This is one thing that would be a good candiate for a $config setting, or maybe even a per-source value if you're in the unfortunate position of polling multiple imap servers. Fortunately, I don't have to deal with imap myself. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Fri Jun 12 14:23:05 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 11:23:05 -0700 Subject: [sup-talk] (no subject) In-Reply-To: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> References: <1244419347-11330-1-git-send-email-bwalton@artsci.utoronto.ca> Message-ID: <1244830970-sup-1069@entry> Reformatted excerpts from Ben Walton's message of 2009-06-07: > Here's a stab at implementing a message bouncing functionality worthy > of being included on mainline. Looks good. I've merged this into next. Thanks! -- William From wmorgan-sup@masanjin.net Fri Jun 12 14:56:09 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 11:56:09 -0700 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244514031-sup-2335@ntdws12.chass.utoronto.ca> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> Message-ID: <1244832722-sup-9953@entry> Reformatted excerpts from Ben Walton's message of 2009-06-08: > So something similar to the folder view hack/patch for mutt? That > doesn't exist in sup. The closest you get is having the 'All Labels' > buffer open. You can jump to a view of all messages with that label > by hitting enter on the selected label. FWIW, there is some preliminary support for having multiple Sup buffers sharing the screen. (There's a notion of focus, and x/y/w/h values for each buffer.) If someone is very excited about having this behavior from mutt, that's how I'd try and implement it. -- William From garoth@gmail.com Fri Jun 12 15:03:38 2009 From: garoth@gmail.com (Andrei Thorp) Date: Fri, 12 Jun 2009 15:03:38 -0400 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244832722-sup-9953@entry> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <1244832722-sup-9953@entry> Message-ID: <80055d7c0906121203g53b1e428q8abd035548331e49@mail.gmail.com> On Fri, Jun 12, 2009 at 2:56 PM, William Morgan wrote: > Reformatted excerpts from Ben Walton's message of 2009-06-08: >> So something similar to the folder view hack/patch for mutt? ?That >> doesn't exist in sup. ?The closest you get is having the 'All Labels' >> buffer open. ?You can jump to a view of all messages with that label >> by hitting enter on the selected label. > > FWIW, there is some preliminary support for having multiple Sup buffers > sharing the screen. (There's a notion of focus, and x/y/w/h values for > each buffer.) If someone is very excited about having this behavior from > mutt, that's how I'd try and implement it. That is indeed very exciting. Mutt's sidebar is actually very poor and limiting. If this could handle it with arbitrary splitting, this would be amazingly amazing. Thanks :) -AT From wmorgan-sup@masanjin.net Fri Jun 12 15:10:27 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 12:10:27 -0700 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244556424-sup-1426@tomsk> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> <1244556424-sup-1426@tomsk> Message-ID: <1244833003-sup-9212@entry> Reformatted excerpts from Marcus Williams's message of 2009-06-09: > William - if you want to add this to sup/bin feel free. Its basically > the regen_text method lifted and edited slightly from the > label-list-mode Nice idea. I'd add such a thing, but I think you can make it significantly simpler. (As you point out, locking the index is not necessary.) Something like: #!/usr/bin/env ruby require 'sup' i = Redwood::Index.new; i.load l = Redwood::LabelManager.new File.join(ENV["HOME"], ".sup", "labels.txt") l.all_labels. map { |label| [label, l.string_for(label)] }. sort_by { |label, name| name }. each do |label, name| total = i.num_results_for :label => label unread = (label == :unread)? total : i.num_results_for(:labels => [label, :unread]) printf "%20s: %6d messages, %6d unread\n", name, total, unread end puts "yay" -- William From wmorgan-sup@masanjin.net Fri Jun 12 15:14:31 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 12:14:31 -0700 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <80055d7c0906090642h421964f2t41d52290042469bc@mail.gmail.com> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> <80055d7c0906090642h421964f2t41d52290042469bc@mail.gmail.com> Message-ID: <1244833856-sup-5874@entry> Reformatted excerpts from Andrei Thorp's message of 2009-06-09: > What I did was put on the label-list-mode, manually send myself an > e-mail, re-run fetchmail to grab it (I get a notification via procmail > saying it came in). Then I remember that sup polls at intervals, so I > wait. You can press "P" to force a poll. > Eventually, the status bar at the bottom says that there is a new > message in the inbox, but the Inbox label does not get updated in my > view. It still says 0/0. Yep, currently label-list-mode only updates when one of three things happens: - it gets created - it gets focus (you switch to it from another buffer) - you press '@' Also, it only reflects the index state, so if you read a new message something and don't press "$", it won't reflect that change. I'd happily accept patches for any of those issues. :) -- William From wmorgan-sup@masanjin.net Fri Jun 12 15:18:11 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 12:18:11 -0700 Subject: [sup-talk] display_length issue with special-characters on non-UTF8 terminal In-Reply-To: <1244536704-sup-7027@valgus> References: <1244536704-sup-7027@valgus> Message-ID: <1244834230-sup-1200@entry> Reformatted excerpts from Tarko Tikan's message of 2009-06-09: > When String.display_length was introduced in recent update, it broke > the length for non-UTF8 strings that contain the special characters. > Wrong length results corrupted display (line ends chopped off). That's a good point. I got a little utf8-centric with those changes. (I'm assuming that your terminal encoding is not UTF-8.) Does this patch fix the issue? If so, I will release an 0.8.1. --- cut here --- diff --git a/lib/sup.rb b/lib/sup.rb index 4f59eaa..20835ae 100644 --- a/lib/sup.rb +++ b/lib/sup.rb @@ -244,7 +244,7 @@ end Redwood::log "using character set encoding #{$encoding.inspect}" else Redwood::log "warning: can't find character set by using locale, defaulting - $encoding = "utf-8" + $encoding = "UTF-8" end ## now everything else (which can feel free to call Redwood::log at load time) diff --git a/lib/sup/util.rb b/lib/sup/util.rb index 8a3004f..d5310bc 100644 --- a/lib/sup/util.rb +++ b/lib/sup/util.rb @@ -172,7 +172,13 @@ class Object end class String - def display_length; scan(/./u).size end + def display_length + if $encoding == "UTF-8" + scan(/./u).size + else + size + end + end def camel_to_hyphy self.gsub(/([a-z])([A-Z0-9])/, '\1-\2').downcase -- William From wmorgan-sup@masanjin.net Fri Jun 12 15:29:46 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 12:29:46 -0700 Subject: [sup-talk] [PATCH] Use terminal width instead of hardcoded 80 as the wrap length. In-Reply-To: <1244392518-sup-9746@cabinet> References: <1243102667-sup-6007@r50p> <4c4248150905231318kab3819dw68e3a3a614241c0d@mail.gmail.com> <1243123134-sup-8032@ntdws12.chass.utoronto.ca> <1243439667-sup-3947@entry> <1244392518-sup-9746@cabinet> Message-ID: <1244834906-sup-7818@entry> Reformatted excerpts from Marc Hartstein's message of 2009-06-07: > Do we currently honor format=flowed email? No. > If we don't, it would be desirable to take this into account when > designing the display wrapping options, and it seems like it would be > worth implementing down the road. Yes, I suppose so. > It might be useful to be able to specify the wrap margin to something > other than 80. I don't know if anybody would actually use this, > though. I will leave that kind of thing for the Sup GUI clients. :) -- William From rlane@club.cc.cmu.edu Fri Jun 12 15:35:52 2009 From: rlane@club.cc.cmu.edu (Rich Lane) Date: Fri, 12 Jun 2009 12:35:52 -0700 Subject: [sup-talk] [PATCH] fixes for ruby1.9 Message-ID: <1244835352-10370-1-git-send-email-rlane@club.cc.cmu.edu> Change colons in case statements to 'then' Fix a block that didn't take enough arguments Rename variables to avoid shadowing warnings Use String.ord (and define it for 1.8) Use DL::Importer on 1.9 Make require 'fastthread' optional Copy in RE_UTF8 --- bin/sup | 5 +-- lib/sup.rb | 4 +++ lib/sup/index.rb | 1 - lib/sup/keymap.rb | 52 ++++++++++++++++++------------------ lib/sup/message-chunks.rb | 4 +- lib/sup/message.rb | 4 +- lib/sup/modes/edit-message-mode.rb | 5 +++- lib/sup/util.rb | 46 ++++++++++++++++++-------------- 8 files changed, 66 insertions(+), 55 deletions(-) diff --git a/bin/sup b/bin/sup index 9abe1b5..302ad7c 100755 --- a/bin/sup +++ b/bin/sup @@ -5,7 +5,6 @@ require 'ncurses' require 'curses' require 'fileutils' require 'trollop' -require 'fastthread' require "sup" BIN_VERSION = "git" @@ -89,7 +88,7 @@ end ## BSD users: if libc.so.6 is not found, try installing compat6x. require 'dl/import' module LibC - extend DL::Importable + extend DL.const_defined?(:Importer) ? DL::Importer : DL::Importable setlocale_lib = case Config::CONFIG['arch'] when /darwin/; "libc.dylib" when /cygwin/; "cygwin1.dll" @@ -202,7 +201,7 @@ begin end end unless $opts[:no_initial_poll] - imode.load_threads :num => ibuf.content_height, :when_done => lambda { reporting_thread("poll after loading inbox") { sleep 1; PollManager.poll } unless $opts[:no_threads] || $opts[:no_initial_poll] } + imode.load_threads :num => ibuf.content_height, :when_done => lambda { |num| reporting_thread("poll after loading inbox") { sleep 1; PollManager.poll } unless $opts[:no_threads] || $opts[:no_initial_poll] } if $opts[:compose] ComposeMode.spawn_nicely :to_default => $opts[:compose] diff --git a/lib/sup.rb b/lib/sup.rb index 4f59eaa..dea9355 100644 --- a/lib/sup.rb +++ b/lib/sup.rb @@ -5,6 +5,10 @@ require 'thread' require 'fileutils' require 'gettext' require 'curses' +begin + require 'fastthread' +rescue LoadError +end class Object ## this is for debugging purposes because i keep calling #id on the diff --git a/lib/sup/index.rb b/lib/sup/index.rb index e403570..ca01ee7 100644 --- a/lib/sup/index.rb +++ b/lib/sup/index.rb @@ -2,7 +2,6 @@ require 'fileutils' require 'ferret' -require 'fastthread' begin require 'chronic' diff --git a/lib/sup/keymap.rb b/lib/sup/keymap.rb index 76c7139..cb039e4 100644 --- a/lib/sup/keymap.rb +++ b/lib/sup/keymap.rb @@ -9,22 +9,22 @@ class Keymap def self.keysym_to_keycode k case k - when :down: Curses::KEY_DOWN - when :up: Curses::KEY_UP - when :left: Curses::KEY_LEFT - when :right: Curses::KEY_RIGHT - when :page_down: Curses::KEY_NPAGE - when :page_up: Curses::KEY_PPAGE - when :backspace: Curses::KEY_BACKSPACE - when :home: Curses::KEY_HOME - when :end: Curses::KEY_END - when :ctrl_l: "\f"[0] - when :ctrl_g: "\a"[0] - when :tab: "\t"[0] - when :enter, :return: 10 #Curses::KEY_ENTER + when :down then Curses::KEY_DOWN + when :up then Curses::KEY_UP + when :left then Curses::KEY_LEFT + when :right then Curses::KEY_RIGHT + when :page_down then Curses::KEY_NPAGE + when :page_up then Curses::KEY_PPAGE + when :backspace then Curses::KEY_BACKSPACE + when :home then Curses::KEY_HOME + when :end then Curses::KEY_END + when :ctrl_l then "\f".ord + when :ctrl_g then "\a".ord + when :tab then "\t".ord + when :enter, :return then 10 #Curses::KEY_ENTER else if k.is_a?(String) && k.length == 1 - k[0] + k.ord else raise ArgumentError, "unknown key name '#{k}'" end @@ -33,18 +33,18 @@ class Keymap def self.keysym_to_string k case k - when :down: "" - when :up: "" - when :left: "" - when :right: "" - when :page_down: "" - when :page_up: "" - when :backspace: "" - when :home: "" - when :end: "" - when :enter, :return: "" - when :tab: "tab" - when " ": "" + when :down then "" + when :up then "" + when :left then "" + when :right then "" + when :page_down then "" + when :page_up then "" + when :backspace then "" + when :home then "" + when :end then "" + when :enter, :return then "" + when :tab then "tab" + when " " then "" else Curses::keyname(keysym_to_keycode(k)) end diff --git a/lib/sup/message-chunks.rb b/lib/sup/message-chunks.rb index ba07d35..a9f1a77 100644 --- a/lib/sup/message-chunks.rb +++ b/lib/sup/message-chunks.rb @@ -252,8 +252,8 @@ EOS def patina_color case status - when :valid: :cryptosig_valid_color - when :invalid: :cryptosig_invalid_color + when :valid then :cryptosig_valid_color + when :invalid then :cryptosig_invalid_color else :cryptosig_unknown_color end end diff --git a/lib/sup/message.rb b/lib/sup/message.rb index 805c2f7..8525fdf 100644 --- a/lib/sup/message.rb +++ b/lib/sup/message.rb @@ -414,8 +414,8 @@ private elsif m.header["Content-Type"] && m.header["Content-Type"] !~ /^text\/plain/ extension = case m.header["Content-Type"] - when /text\/html/: "html" - when /image\/(.*)/: $1 + when /text\/html/ then "html" + when /image\/(.*)/ then $1 end ["sup-attachment-#{Time.now.to_i}-#{rand 10000}", extension].join(".") diff --git a/lib/sup/modes/edit-message-mode.rb b/lib/sup/modes/edit-message-mode.rb index d7bd41c..74bdfb7 100644 --- a/lib/sup/modes/edit-message-mode.rb +++ b/lib/sup/modes/edit-message-mode.rb @@ -2,7 +2,10 @@ require 'tempfile' require 'socket' # just for gethostname! require 'pathname' require 'rmail' -require 'jcode' # for RE_UTF8 + +# from jcode.rb, not included in ruby 1.9 +PATTERN_UTF8 = '[\xc0-\xdf][\x80-\xbf]|[\xe0-\xef][\x80-\xbf][\x80-\xbf]' +RE_UTF8 = Regexp.new(PATTERN_UTF8, 0, 'n') module Redwood diff --git a/lib/sup/util.rb b/lib/sup/util.rb index 8a3004f..1513c42 100644 --- a/lib/sup/util.rb +++ b/lib/sup/util.rb @@ -133,8 +133,8 @@ class Object ## clone of java-style whole-method synchronization ## assumes a @mutex variable ## TODO: clean up, try harder to avoid namespace collisions - def synchronized *meth - meth.each do + def synchronized *methods + methods.each do |meth| class_eval <<-EOF alias unsynchronized_#{meth} #{meth} def #{meth}(*a, &b) @@ -144,8 +144,8 @@ class Object end end - def ignore_concurrent_calls *meth - meth.each do + def ignore_concurrent_calls *methods + methods.each do |meth| mutex = "@__concurrent_protector_#{meth}" flag = "@__concurrent_flag_#{meth}" oldmeth = "__unprotected_#{meth}" @@ -205,7 +205,7 @@ class String region_start = 0 while pos <= length newpos = case state - when :escaped_instring, :escaped_outstring: pos + when :escaped_instring, :escaped_outstring then pos else index(/[,"\\]/, pos) end @@ -219,26 +219,26 @@ class String case char when ?" state = case state - when :outstring: :instring - when :instring: :outstring - when :escaped_instring: :instring - when :escaped_outstring: :outstring + when :outstring then :instring + when :instring then :outstring + when :escaped_instring then :instring + when :escaped_outstring then :outstring end when ?,, nil state = case state - when :outstring, :escaped_outstring: + when :outstring, :escaped_outstring then ret << self[region_start ... newpos].gsub(/^\s+|\s+$/, "") region_start = newpos + 1 :outstring - when :instring: :instring - when :escaped_instring: :instring + when :instring then :instring + when :escaped_instring then :instring end when ?\\ state = case state - when :instring: :escaped_instring - when :outstring: :escaped_outstring - when :escaped_instring: :instring - when :escaped_outstring: :outstring + when :instring then :escaped_instring + when :outstring then :escaped_outstring + when :escaped_instring then :instring + when :escaped_outstring then :outstring end end pos = newpos + 1 @@ -274,6 +274,12 @@ class String gsub(/\t/, " ").gsub(/\r/, "") end + if not defined? ord + def ord + self[0] + end + end + ## takes a space-separated list of words, and returns an array of symbols. ## typically used in Sup for translating Ferret's representation of a list ## of labels (a string) to an array of label symbols. @@ -628,10 +634,10 @@ class Iconv def self.easy_decode target, charset, text return text if charset =~ /^(x-unknown|unknown[-_ ]?8bit|ascii[-_ ]?7[-_ ]?bit)$/i charset = case charset - when /UTF[-_ ]?8/i: "utf-8" - when /(iso[-_ ])?latin[-_ ]?1$/i: "ISO-8859-1" - when /iso[-_ ]?8859[-_ ]?15/i: 'ISO-8859-15' - when /unicode[-_ ]1[-_ ]1[-_ ]utf[-_]7/i: "utf-7" + when /UTF[-_ ]?8/i then "utf-8" + when /(iso[-_ ])?latin[-_ ]?1$/i then "ISO-8859-1" + when /iso[-_ ]?8859[-_ ]?15/i then 'ISO-8859-15' + when /unicode[-_ ]1[-_ ]1[-_ ]utf[-_]7/i then "utf-7" else charset end -- 1.6.0.4 From wmorgan-sup@masanjin.net Fri Jun 12 15:54:26 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 12:54:26 -0700 Subject: [sup-talk] sup -c while sup is running? In-Reply-To: <1244646784-sup-7039@cabinet> References: <1244646784-sup-7039@cabinet> Message-ID: <1244835514-sup-3886@entry> Reformatted excerpts from Marc Hartstein's message of 2009-06-10: > How difficult would it be to allow sup -c to be run while sup is > already running? The goal would be to be able to use sup as a mailto: > handler effectively. Not that difficult. In general, N Sup processes should be able to run as long as N-1 of them are readonly wrt the index and sources file. (I think!) So sup -c could launch either with a readonly inbox buffer, or without one at all. (Which would be faster, if the intention is just to quit after sending.) However, to be safe, locking should be added to the sent.mbox to prevent multiple Sup processing from overwriting each other's sent messages. Ben Walton's lock manager I think will be perfect for this. -- William From wmorgan-sup@masanjin.net Fri Jun 12 16:03:22 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 13:03:22 -0700 Subject: [sup-talk] sup and ncursesw In-Reply-To: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com> References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com> Message-ID: <1244836517-sup-5520@entry> Hi J?rg-Hendrik, Reformatted excerpts from J?rg-Hendrik Bach's message of 2009-06-10: > I recently installed sup 0.8 and find I am having problems with > umlauts and accented characters. There is a patch for the > ncurses-0.9.1 gem on the sup wiki ("utf8-issues") which allows the > characters to be displayed correctly, but after applying the patch I > can't enter proper text. What is your environment's character set? (Should be the first line of output logged by Sup.) What is your terminal emulator? Do other widechar ncurses programs work? And what's the behavior without the patch to ncurses.so? -- William From marcus-sup@bar-coded.net Fri Jun 12 16:18:10 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Fri, 12 Jun 2009 21:18:10 +0100 Subject: [sup-talk] Gmail Labels Sidebar In-Reply-To: <1244833003-sup-9212@entry> References: <80055d7c0906081737s4dd3e205t2f3e69423ef48e17@mail.gmail.com> <1244509454-sup-1208@ntdws12.chass.utoronto.ca> <1244513641-sup-360@javelin> <1244514031-sup-2335@ntdws12.chass.utoronto.ca> <80055d7c0906090633t2a7aecd6i30578a9976697e4e@mail.gmail.com> <1244556424-sup-1426@tomsk> <1244833003-sup-9212@entry> Message-ID: <1244837827-sup-6632@tomsk> On 12.6.2009, William Morgan wrote: > Nice idea. I'd add such a thing, but I think you can make it > significantly simpler. (As you point out, locking the index is not > necessary.) Simpler is good - it was a quick hack anyway :) You version works out of the box so it would be a nice addition to sup/bin Marcus From marcus-sup@bar-coded.net Fri Jun 12 16:46:32 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Fri, 12 Jun 2009 21:46:32 +0100 Subject: [sup-talk] [PATCH] Minimalist view Message-ID: <1244839497-sup-547@tomsk> Adds a keypress to toggle to a minimalist view in thread index mode. This removes the date, authors and number of threads from the view leaving more room for labels/snippets --- lib/sup/modes/thread-index-mode.rb | 34 +++++++++++++++++++++++++++------- 1 files changed, 27 insertions(+), 7 deletions(-) diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 0bd8110..5fa4f4c 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -45,6 +45,7 @@ EOS k.add :apply_to_tagged, "Apply next command to all tagged threads", '+', '=' k.add :join_threads, "Force tagged threads to be joined into the same thread", '#' k.add :undo, "Undo the previous action", 'u' + k.add :toggle_minimalist, "Toggle minimalist view", '~' end def initialize hidden_labels=[], load_thread_opts={} @@ -62,6 +63,8 @@ EOS @hidden_labels = hidden_labels + LabelManager::HIDDEN_RESERVED_LABELS @date_width = DATE_WIDTH + @minimal = false + @interrupt_search = false initialize_threads # defines @ts and @ts_mutex @@ -261,6 +264,11 @@ EOS end end + def toggle_minimalist + @minimal = !@minimal + regen_text + end + def toggle_starred t = cursor_thread or return undo = actually_toggle_starred t @@ -833,13 +841,25 @@ protected size_widget_text = sprintf "%#{ @size_widget_width}s", size_widget - [ - [:tagged_color, @tags.tagged?(t) ? ">" : " "], - [:none, sprintf("%#{@date_width}s", date)], - (starred ? [:starred_color, "*"] : [:none, " "]), - ] + - from + - [ + + if @minimal + if size_widget!="" + size_widget_text = "+" + else + size_widget_text = " " + end + line = [] + else + line = [ + [:tagged_color, @tags.tagged?(t) ? ">" : " "], + [:none, sprintf("%#{@date_width}s", date)], + (starred ? [:starred_color, "*"] : [:none, " "]), + ] + from + end + + + line + + [ [subj_color, size_widget_text], [:to_me_color, t.labels.member?(:attachment) ? "@" : " "], [:to_me_color, dp ? ">" : (p ? '+' : " ")], -- 1.5.4.1 From me@nicholasbs.net Fri Jun 12 18:14:55 2009 From: me@nicholasbs.net (Nicholas Bergson-Shilcock) Date: Fri, 12 Jun 2009 18:14:55 -0400 Subject: [sup-talk] Transitioning to OfflineIMAP Message-ID: <1244844014-sup-6606@twoface> Hi, I've been using sup for the past year and love it. In an attempt to speed things up, I'm hoping to switch to using OfflineIMAP and a maildir source (I'm currently using straight IMAP). I've installed and configured OfflineIMAP and have downloaded all of my messages. Before I go any further, I wanted to know if sup supported any sort of "graceful" account transitioning -- I'd ideally like to switch to my new maildir source without losing the index information I have for my IMAP source. The obvious way of switching over (removing my old source and adding the new one) would mean essentially starting over. Is this what I have to do or is there another way for me to switch? Thanks! (And thanks for making sup such a joy to use!) -Nick From wmorgan-sup@masanjin.net Fri Jun 12 20:24:44 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Fri, 12 Jun 2009 17:24:44 -0700 Subject: [sup-talk] Transitioning to OfflineIMAP In-Reply-To: <1244844014-sup-6606@twoface> References: <1244844014-sup-6606@twoface> Message-ID: <1244852427-sup-5831@entry> Reformatted excerpts from Nicholas Bergson-Shilcock's message of 2009-06-12: > Before I go any further, I wanted to know if sup supported any sort of > "graceful" account transitioning -- I'd ideally like to switch to my > new maildir source without losing the index information I have for my > IMAP source. The obvious way of switching over (removing my old source > and adding the new one) would mean essentially starting over. Is this > what I have to do or is there another way for me to switch? I wouldn't call it graceful, exactly, but you should be able to preserve state by running sup-dump on the original source, drop the index (move your ~/.sup/ferret directory somewhere else), edit your source.yaml file, and use sup-sync --restored --restore to scan over the new source and restore the state for each message. It will take a while. Try it on a subset of messages first if possible to make sure it's working. Post any questions and I'll try and help you. -- William From tarko@lanparty.ee Sat Jun 13 07:13:06 2009 From: tarko@lanparty.ee (Tarko Tikan) Date: Sat, 13 Jun 2009 14:13:06 +0300 Subject: [sup-talk] display_length issue with special-characters on non-UTF8 terminal In-Reply-To: <1244834230-sup-1200@entry> References: <1244536704-sup-7027@valgus> <1244834230-sup-1200@entry> Message-ID: <1244891132-sup-2424@valgus> > (I'm assuming that your terminal encoding is not UTF-8.) No, it's not. > Does this patch fix the issue? If so, I will release an 0.8.1. Yes it does. To me, this approach felt "hackish" so I didn't come up with a patch :) But I still don't have better idea how to fix it so it'll have to stay like this. > + if $encoding == "UTF-8" > + scan(/./u).size > + else > + size > + end It would probably be correct to use: if $encoding == "UTF-8" scan(/./u).size else length end Thats because scan returns a array (hence using the size), without scan you are just invoking on string and it's correct to use length (for some reason size works too, backward compatibility?) -- tarko From bachjh@googlemail.com Sat Jun 13 10:17:51 2009 From: bachjh@googlemail.com (=?UTF-8?B?SsO2cmctSGVuZHJpayBCYWNo?=) Date: Sat, 13 Jun 2009 16:17:51 +0200 Subject: [sup-talk] sup and ncursesw In-Reply-To: <1244836517-sup-5520@entry> References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com> <1244836517-sup-5520@entry> Message-ID: <91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com> 2009/6/12 William Morgan > > What is your environment's character set? (Should be the first line of > output logged by Sup.) What is your terminal emulator? And what's the > behavior without the patch to ncurses.so? After playing around a bit i think the behaviour might be related to a problem with locale. I reinstalled ruby, rubygems, ncurses and sup. No patch to ncurses this time. Using gnome-terminal or xterm with "TERM=xterm" now lets umlauts etc look like, e.g. "JM-CM-6rg-Hendrik"). The reported character set is "utf8". The same happens when using urxvt with TERM=rxvt-unicode. However, calling sup like this: $ LC_ALL=en_GB.iso-8859-15 sup results in different behaviour in the two emulators: xterm looks OK when viewing the inbox, but inserts boxed question marks in thread-view. rxvt-unicode displays everything correctly, but drops the last character of a line when a non-ASCII element is somewhere in the line. In both variants sup reports the character set correctly as iso-8859-15. So I guess I could simply work in urxvt and that's OK, then. Do other widechar ncurses programs work? The only other ncurses-based program I am aware of using is midnight commander, and it seems to be working fine. But I don't know whether it uses the widechar variant. cheers, - J?rg-Hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From aep@exys.org Sun Jun 14 00:37:13 2009 From: aep@exys.org (Arvid Picciani) Date: Sat, 13 Jun 2009 21:37:13 -0700 Subject: [sup-talk] Sup won't save state Message-ID: <1244954212-sup-8783@andariel> Hi, I'm trying out sup and I totally like the concept so far, unfortunately it doesn't work correctly for me. 1) It doesn't save its state. The next time I open it up, read messages are new again. 2) when pressing c, to compose a new message, it asks for a Subject. Later in vim I see the Subject field contains random characters instead. 3) Most input "dialogs" (?) can't be killed. Pressing ESC does nothing. The only to chancel such an operation is to kill sup. 4) It behaves very odd when two clients are using the same imap account. Yes, the docs state that, but not how to work around that when you _have_ to use two clients. Currently I'm trying to use offlineimap, unfortunately that's broken. Thank you, Arvid From bwalton@artsci.utoronto.ca Sat Jun 13 21:36:41 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Sat, 13 Jun 2009 21:36:41 -0400 Subject: [sup-talk] [PATCH] Minimalist view In-Reply-To: <1244839497-sup-547@tomsk> References: <1244839497-sup-547@tomsk> Message-ID: <1244943297-sup-5509@ntdws12.chass.utoronto.ca> Excerpts from Marcus Williams's message of Fri Jun 12 16:46:32 -0400 2009: > Adds a keypress to toggle to a minimalist view in thread index mode. > This removes the date, authors and number of threads from the view > leaving more room for labels/snippets This patch looks sound, but I wonder if a Hook might be in order to make the alternate display customizable? Not a bad idea at all though. -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From marcus-sup@bar-coded.net Sun Jun 14 09:17:38 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Sun, 14 Jun 2009 14:17:38 +0100 Subject: [sup-talk] [PATCH] Minimalist view In-Reply-To: <1244943297-sup-5509@ntdws12.chass.utoronto.ca> References: <1244839497-sup-547@tomsk> <1244943297-sup-5509@ntdws12.chass.utoronto.ca> Message-ID: <1244985302-sup-9505@tomsk> On 14.6.2009, Ben Walton wrote: > This patch looks sound, but I wonder if a Hook might be in order to > make the alternate display customizable? Not a bad idea at all > though. Slightly ahead of you :) This is the default view for my next patch which implements exactly that hook. I'm just wandering through my local commits and cleaning stuff up for submission so hopefully a few more to come as well. Marcus From aep@exys.org Sun Jun 14 20:51:18 2009 From: aep@exys.org (Arvid Picciani) Date: Sun, 14 Jun 2009 17:51:18 -0700 Subject: [sup-talk] Sup won't save state In-Reply-To: <1244954212-sup-8783@andariel> References: <1244954212-sup-8783@andariel> Message-ID: <1245026779-sup-3938@andariel> Sorry, still takes a little to get used to sup. I have no clue what was on and off list, but I assume this was off, so I'm going to repost it: > $ in inbox mode to save, or at intervals. does clean shutdown not do > this automatically? "clean shutdown" is one of the reasons I went away from Gui crap. It almost never works for me. I don't even know how to shut down a Linux computer "cleanly" other then by clicking some button on some Gui menu, which I don't have, so most Gui programs just crash and leave me next time with some ridiculous "recovery assistant". Sup does exactly that and it's highly annoying. It doesn't even work. Why the hell are you trying to kill a non existent sup instance? Maybe I should just alias sup="rm .sup/lock;sup" End of rant. So how do I configure sup to save automatically? PS: the encrypt/reply to menu on the reply view is pretty cool :) From aep@exys.org Sun Jun 14 20:58:31 2009 From: aep@exys.org (Arvid Picciani) Date: Sun, 14 Jun 2009 17:58:31 -0700 Subject: [sup-talk] Wrong messages in thread Message-ID: <1245027174-sup-4117@andariel> Two more questions :P 1) Some messages end up in the wrong thread. When there is no other useful info, sup appears to guess a thread by the Subject similarity. Unfortunately that ends up being very wrong for my university mailing list, since they have no List-Id, but the full university name in the Subject and people won't learn to write meaningful Subjects. [blablablalblalbafooomal uni blabla] hi is displayed in the same thread with [blablablalblalbafooomal uni blabla] hello although those are two different threads. Can I manually fix those? 2) how's that address book generated? I have sup-talk-request and sup-talk-something but not sup-talk. thanks -- Arvid From ezyang@MIT.EDU Sun Jun 14 13:36:08 2009 From: ezyang@MIT.EDU (Edward Z. Yang) Date: Sun, 14 Jun 2009 13:36:08 -0400 Subject: [sup-talk] Wrong messages in thread In-Reply-To: <1245027174-sup-4117@andariel> References: <1245027174-sup-4117@andariel> Message-ID: <1245000912-sup-6454@javelin> Excerpts from Arvid Picciani's message of Sun Jun 14 20:58:31 -0400 2009: > 2) how's that address book generated? > I have sup-talk-request and sup-talk-something > but not sup-talk. When you edit an address in thread-view-mode using i it gets added to your address book. Ideally, stuff should get added when you compose and email the first time. This is a patch I want to make at some point. Cheers, Edward From garoth@gmail.com Sun Jun 14 16:35:57 2009 From: garoth@gmail.com (Andrei Thorp) Date: Sun, 14 Jun 2009 13:35:57 -0700 Subject: [sup-talk] Sup won't save state In-Reply-To: <1245026779-sup-3938@andariel> References: <1244954212-sup-8783@andariel> <1245026779-sup-3938@andariel> Message-ID: <80055d7c0906141335r31848e05ydfc8557b0d1d9ca6@mail.gmail.com> Yeah, sorry, I replied to person accidentally while on handheld. Thanks for forwarding. Anyway, yeah, wish saving in sup was better. Don't really know anything better than sup-sync. -AT From nicolas.pouillard@gmail.com Mon Jun 15 08:03:58 2009 From: nicolas.pouillard@gmail.com (Nicolas Pouillard) Date: Mon, 15 Jun 2009 14:03:58 +0200 Subject: [sup-talk] Wrong messages in thread In-Reply-To: <1245000912-sup-6454@javelin> References: <1245027174-sup-4117@andariel> <1245000912-sup-6454@javelin> Message-ID: <1245067390-sup-2318@ausone.inria.fr> Excerpts from Edward Z. Yang's message of Sun Jun 14 19:36:08 +0200 2009: > Excerpts from Arvid Picciani's message of Sun Jun 14 20:58:31 -0400 2009: > > 2) how's that address book generated? > > I have sup-talk-request and sup-talk-something > > but not sup-talk. > > When you edit an address in thread-view-mode using i it gets added > to your address book. Ideally, stuff should get added when you compose > and email the first time. This is a patch I want to make at some point. Yes it would be great to automatically prompt for adding the contact when we send a message to someone not yet in contacts. -- Nicolas Pouillard http://nicolaspouillard.fr From wmorgan-sup@masanjin.net Mon Jun 15 09:34:29 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 06:34:29 -0700 Subject: [sup-talk] Wrong messages in thread In-Reply-To: <1245027174-sup-4117@andariel> References: <1245027174-sup-4117@andariel> Message-ID: <1245072716-sup-829@entry> Reformatted excerpts from Arvid Picciani's message of 2009-06-14: > 1) Some messages end up in the wrong thread. When there is no other > useful info, sup appears to guess a thread by the Subject similarity. Sup does not do this. If you're seeing messages with different subjects in the same thread, a later one contains a reference to an earlier one. Sometimes this happens if people reply to a mailing list message and change the subject as a way of starting a new message. You can confirm this by examining the in-reply-to and references headers of the later message. > 2) how's that address book generated? > I have sup-talk-request and sup-talk-something > but not sup-talk. By manually adding contacts, e.g. with 'i' in thread-view-mode, plus a couple recent contacts automatically drawn from the index. -- William From wmorgan-sup@masanjin.net Mon Jun 15 09:37:15 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 06:37:15 -0700 Subject: [sup-talk] Sup won't save state In-Reply-To: <1244954212-sup-8783@andariel> References: <1244954212-sup-8783@andariel> Message-ID: <1245072900-sup-2799@entry> Reformatted excerpts from Arvid Picciani's message of 2009-06-13: > 1) It doesn't save its state. The next time I open it up, read > messages are new again. How are you quitting Sup? > 2) when pressing c, to compose a new message, it asks for a Subject. > Later in vim I see the Subject field contains random characters > instead. Strange. Are they related in any way? Can you give an example? > 3) Most input "dialogs" (?) can't be killed. Pressing ESC does > nothing. The only to chancel such an operation is to kill sup. Ctrl-g. > 4) It behaves very odd when two clients are using the same imap > account. Yes, the docs state that, but not how to work around that > when you _have_ to use two clients. If you change the IMAP folder via another client, you'll have to run sup-sync --changed on that source before running Sup. Sup should detect this and tell you. What "odd" behavior are you seeing? -- William From wmorgan-sup@masanjin.net Mon Jun 15 09:42:04 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 06:42:04 -0700 Subject: [sup-talk] Sup won't save state In-Reply-To: <1245026779-sup-3938@andariel> References: <1244954212-sup-8783@andariel> <1245026779-sup-3938@andariel> Message-ID: <1245073093-sup-5388@entry> Reformatted excerpts from Arvid Picciani's message of 2009-06-14: > "clean shutdown" is one of the reasons I went away from Gui crap. Clean shutdown has nothing to do with GUI vs not GUI. > I don't even know how to shut down a Linux computer "cleanly" other > then by clicking some button on some Gui menu, which I don't have, > so most Gui programs just crash and leave me next time with some > ridiculous "recovery assistant". > Sup does exactly that and it's highly annoying. It doesn't even work. It's hard to guess what you're doing here, but it sounds like you're pressing ctrl-c to kill Sup and then pressing y at the "die ungracefully now?" prompt. You may want to read the new user guide: http://sup.rubyforge.org/NewUserGuide.txt. -- William From wmorgan-sup@masanjin.net Mon Jun 15 09:50:37 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 06:50:37 -0700 Subject: [sup-talk] [PATCH] Minimalist view In-Reply-To: <1244943297-sup-5509@ntdws12.chass.utoronto.ca> References: <1244839497-sup-547@tomsk> <1244943297-sup-5509@ntdws12.chass.utoronto.ca> Message-ID: <1245073371-sup-3704@entry> Reformatted excerpts from Ben Walton's message of 2009-06-13: > This patch looks sound, but I wonder if a Hook might be in order to > make the alternate display customizable? Not a bad idea at all > though. Yeah, I would generally like to have this type of thing done through hooks, but if a lot of people like this mode then I could integrate it directly. -- William From bwalton@artsci.utoronto.ca Mon Jun 15 09:54:01 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 15 Jun 2009 09:54:01 -0400 Subject: [sup-talk] [PATCH] Minimalist view In-Reply-To: <1245073371-sup-3704@entry> References: <1244839497-sup-547@tomsk> <1244943297-sup-5509@ntdws12.chass.utoronto.ca> <1245073371-sup-3704@entry> Message-ID: <1245073954-sup-8198@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Mon Jun 15 09:50:37 -0400 2009: > Yeah, I would generally like to have this type of thing done through > hooks, but if a lot of people like this mode then I could integrate it > directly. What about a Hook with this as the default alternate view if the Hook isn't set? I'd also suggest changing the name from minimalist to alternate, since if there is a hook available, it may not actually be a minimal view? Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon Jun 15 10:04:52 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 07:04:52 -0700 Subject: [sup-talk] sup and ncursesw In-Reply-To: <91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com> References: <91de50e10906101050p2d23a74cy1bbfe2e80e69cca2@mail.gmail.com> <1244836517-sup-5520@entry> <91de50e10906130717x3a6d6097g5249ed6bb17fbfcf@mail.gmail.com> Message-ID: <1245074133-sup-9338@entry> Reformatted excerpts from J?rg-Hendrik Bach's message of 2009-06-13: > After playing around a bit i think the behaviour might be related to a > problem with locale. Yeah, this stuff is all tricky to get working right. I recommend first trying to get to the point where you can cat and less files with funny characters in them, and then introduce something like Sup. (And that's typically the point where you see the difference between ncurses.so with and without the patch.) > Using gnome-terminal or xterm with "TERM=xterm" now lets umlauts etc > look like, e.g. "JM-CM-6rg-Hendrik"). The reported character set is > "utf8". Probably the umlauts themselves aren't in utf8. I have had success with gnome-terminal and TERM=xterm, so I bet you can get this combo to work. Try changing your locale from utf8 to en_GB.iso-8859-15 here (if you're using Ubuntu, you can edit /etc/default/locale an re-log in, then `locale` to check.) -- William From wmorgan-sup@masanjin.net Mon Jun 15 10:10:30 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 07:10:30 -0700 Subject: [sup-talk] display_length issue with special-characters on non-UTF8 terminal In-Reply-To: <1244891132-sup-2424@valgus> References: <1244536704-sup-7027@valgus> <1244834230-sup-1200@entry> <1244891132-sup-2424@valgus> Message-ID: <1245074739-sup-3954@entry> Reformatted excerpts from Tarko Tikan's message of 2009-06-13: > Yes it does. To me, this approach felt "hackish" so I didn't come up > with a patch :) But I still don't have better idea how to fix it so > it'll have to stay like this. It's hackish because Ruby 1.8 has shitty multibyte support. The only reason it works at all is because byte length is character length (at least most of the time) in your encoding. There is a multibyte gem out there that I'm keeping an eye on. Also Ruby 1.9.1 allegedgly fixes this problem. > Thats because scan returns a array (hence using the size), without > scan you are just invoking on string and it's correct to use length > (for some reason size works too, backward compatibility?) Size and length are synonmys for both arrays and strings. I used size there for symmetry. -- William From garoth@gmail.com Mon Jun 15 11:20:58 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 15 Jun 2009 11:20:58 -0400 Subject: [sup-talk] Sup won't save state In-Reply-To: <1245072900-sup-2799@entry> References: <1244954212-sup-8783@andariel> <1245072900-sup-2799@entry> Message-ID: <80055d7c0906150820o3ef05759j23a54e0f889594b7@mail.gmail.com> >> 2) when pressing c, to compose a new message, it asks for a Subject. >> Later in vim I see the Subject field contains random characters >> instead. > > Strange. Are they related in any way? Can you give an example? When this happened to me, they were absolutely unrelated, looked like trying to vim a bit of a binary file... But went away randomly a few days later. -AT From wmorgan-sup@masanjin.net Mon Jun 15 12:32:42 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 09:32:42 -0700 Subject: [sup-talk] [PATCH] fixes for ruby1.9 In-Reply-To: <1244835352-10370-1-git-send-email-rlane@club.cc.cmu.edu> References: <1244835352-10370-1-git-send-email-rlane@club.cc.cmu.edu> Message-ID: <1245083484-sup-9468@entry> Reformatted excerpts from Rich Lane's message of 2009-06-12: > Change colons in case statements to 'then' > Fix a block that didn't take enough arguments > Rename variables to avoid shadowing warnings > Use String.ord (and define it for 1.8) > Use DL::Importer on 1.9 > Make require 'fastthread' optional Thanks for this. I've applied it directly to master. Now if someone would just upgrade Ferret to 1.9, we might be able to actually run Sup! -- William From wmorgan-sup@masanjin.net Mon Jun 15 12:53:47 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 09:53:47 -0700 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1244719933-sup-4261@viajero> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> Message-ID: <1245084718-sup-1647@entry> Reformatted excerpts from Fabio Riga's message of 2009-06-11: > All is fine, I just need to remember to launch sup this way. Maybe it > needs some work on localization? Sorry about that. The problem is that Sup was writing an invalid sent.mbox file in certain locales, including yours, and then dying when it couldn't parse its own file. If you update to the latest git, this should be fixed for new messages, and you shouldn't need the LANG=C hack. Please let me know if you have any more problems. -- William From wmorgan-sup@masanjin.net Mon Jun 15 13:24:08 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 10:24:08 -0700 Subject: [sup-talk] lockmanager In-Reply-To: <1244595206-sup-6689@ntdws12.chass.utoronto.ca> References: <1244595206-sup-6689@ntdws12.chass.utoronto.ca> Message-ID: <1245084879-sup-6794@entry> Hi Ben, Reformatted excerpts from Ben Walton's message of 2009-06-09: > I've attached the base LockManager class that I'm envisioning for sup. Sorry for the delay. This looks good. Using a mutex to protect the file-locking seems like the right idea. Carry on! -- William From bwalton@artsci.utoronto.ca Mon Jun 15 13:39:15 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Mon, 15 Jun 2009 13:39:15 -0400 Subject: [sup-talk] lockmanager In-Reply-To: <1245084879-sup-6794@entry> References: <1244595206-sup-6689@ntdws12.chass.utoronto.ca> <1245084879-sup-6794@entry> Message-ID: <1245087383-sup-5205@ntdws12.chass.utoronto.ca> Excerpts from William Morgan's message of Mon Jun 15 13:24:08 -0400 2009: > Sorry for the delay. This looks good. Using a mutex to protect the > file-locking seems like the right idea. Carry on! Yah, now that 'stupid Kobe' beat the Magic last night, my evenings should have more time for completing this. I'm just about finished integrating it with the mbox code. I've branched this from bw/flexible_sent, since I thought it made more sense to go from that than from master w/o the flexible sent parts...it should still merge decently for you, I think. The next hurdle will be testing, which I'll need help for, since my only mbox is sup://sent, which is now legacy only (and at some point when I'm bored will disappear completely). Thanks -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wmorgan-sup@masanjin.net Mon Jun 15 13:44:25 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 10:44:25 -0700 Subject: [sup-talk] [PATCH] before-search hook In-Reply-To: <1244612627-sup-982@javelin> References: <1244612627-sup-982@javelin> Message-ID: <1245087294-sup-6276@entry> Hi Edward, Thanks for the patch. I'm interested in integrating it into Sup mainline. A couple comments: 1. Can you rename it to custom-search? I think that's a better description. 2. I would rather have the hook return a value. So this: > - subs = s.gsub(/\b(to|from):(\S+)\b/) do > + subs = String.new s > + HookManager.run("before-search", :subs => subs) I would rather see as: subs = HookManager.run("before-search", :subs => s) || s 3. It's not really an issue of mutation vs no mutation. The problem is that the parameter names in hooks are method calls, not variables. So while "subs = subs.gsub(...)" causes a 'subs' local variable to be created and initialized to nil, both "x = subs.gsub(...)" and "subs = self.subs.gsub(...)" work fine. This is probably less of an issue when the hook is returning a values, but if you could change the comments to be a warning about shadowing method calls instead that would be better. Thanks! -- William From wmorgan-sup@masanjin.net Mon Jun 15 13:50:21 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 10:50:21 -0700 Subject: [sup-talk] lockmanager In-Reply-To: <1245087383-sup-5205@ntdws12.chass.utoronto.ca> References: <1244595206-sup-6689@ntdws12.chass.utoronto.ca> <1245084879-sup-6794@entry> <1245087383-sup-5205@ntdws12.chass.utoronto.ca> Message-ID: <1245088148-sup-5245@entry> Reformatted excerpts from Ben Walton's message of 2009-06-15: > I've branched this from bw/flexible_sent, since I thought it made more > sense to go from that than from master w/o the flexible sent > parts...it should still merge decently for you, I think. That's fine. As long as it doesn't branch from next, I'm happy. > The next hurdle will be testing, which I'll need help for, since my > only mbox is sup://sent, which is now legacy only (and at some point > when I'm bored will disappear completely). Although the addressess are (trivially) mangled, you can use something like http://rubyforge.org/pipermail/sup-talk/2009-June.txt. -- William From garoth@gmail.com Mon Jun 15 14:45:35 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 15 Jun 2009 14:45:35 -0400 Subject: [sup-talk] [BUG] Sup Overload Message-ID: <80055d7c0906151145r493c07c2h7a68d776f49ce91a@mail.gmail.com> Hello there! Exciting fresh new sup crash. What's happened is that I just imported a zillion new messages from several new sources. I downloaded all the mail from 4 mailing lists in my gmail account. Anyway, so they all appeared as new in my inbox. I started holding a as they appeared to archive them. Sup blew up. See attached exception log. Cheers. -AT -------------- next part -------------- --- RuntimeError from thread: poll after loading inbox unknown drawable object: nil in # for line 35 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:200:in `draw_line' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/line-cursor-mode.rb:39:in `draw_line' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `draw' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/scroll-mode.rb:48:in `draw' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/line-cursor-mode.rb:24:in `draw' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:99:in `draw' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:83:in `redraw' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/buffer.rb:303:in `draw_screen' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:187:in `handle_added_update' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `relay' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/update.rb:27:in `relay' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:162:in `add_messages_from' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:130:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `upto' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/maildir.rb:127:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:544:in `__pass' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:531:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:141:in `add_messages_from' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:98:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `each' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:86:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `synchronize' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:85:in `do_poll' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/poll-mode.rb:17:in `poll' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/poll.rb:53:in `poll' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `send' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/util.rb:505:in `method_missing' /usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206 /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:663:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:663:in `__unprotected_load_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:605:in `call' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:605:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:71:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `initialize' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `new' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup.rb:69:in `reporting_thread' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:603:in `load_n_threads_background' /usr/lib/ruby/gems/1.8/gems/sup-0.8/lib/sup/modes/thread-index-mode.rb:673:in `__unprotected_load_threads' (eval):12:in `load_threads' /usr/lib/ruby/gems/1.8/gems/sup-0.8/bin/sup:206 /usr/bin/sup:19:in `load' /usr/bin/sup:19 From garoth@gmail.com Mon Jun 15 14:47:22 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 15 Jun 2009 14:47:22 -0400 Subject: [sup-talk] [BUG] Can't handle spaces in paths Message-ID: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com> Hey there, I just downloaded a whole lot of mail from my gmail account via offlineimap, and tried to add a source with a space. In short, sup doesn't like this. It tries to do a split somewhere and it doesn't work out for it so well :) Not much of a bug, I ln -s'd around it. Maybe something that could be handled somehow though? I tried quotes and whitespace backslashing in shell, but no go. Cheers! -AT From guillaume.quintard@gmail.com Mon Jun 15 15:05:37 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 15 Jun 2009 21:05:37 +0200 Subject: [sup-talk] [BUG] Can't handle spaces in paths In-Reply-To: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com> References: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com> Message-ID: <1245092672-sup-7673@altis> Excerpts from Andrei Thorp's message of Mon Jun 15 20:47:22 +0200 2009: > Not much of a bug, I ln -s'd around it. Maybe something that could be > handled somehow though? I tried quotes and whitespace backslashing in > shell, but no go. > Did you put a '\' before the spaces? -- Guillaume From garoth@gmail.com Mon Jun 15 15:07:50 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 15 Jun 2009 15:07:50 -0400 Subject: [sup-talk] [BUG] Can't handle spaces in paths In-Reply-To: <1245092672-sup-7673@altis> References: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com> <1245092672-sup-7673@altis> Message-ID: <80055d7c0906151207p95bbae4w5846acb8f03044da@mail.gmail.com> >> I tried quotes and whitespace backslashing in shell, but no go. >> > Did you put a '\' before the spaces? > > -- > Guillaume That's what I was referring to ^ Also, I should mention that I tried sup-add as well as sup-config for this operation. -AT From guillaume.quintard@gmail.com Mon Jun 15 15:11:04 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 15 Jun 2009 21:11:04 +0200 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1245084718-sup-1647@entry> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> <1245084718-sup-1647@entry> Message-ID: <1245092885-sup-1794@altis> Excerpts from William Morgan's message of Mon Jun 15 18:53:47 +0200 2009: > Please let me know if you have any more problems. Still have it here, arg., with next. There is a sense of tragic in the fact that I know that after sending that mail to get help, sup will inevitably crash :-) -- Guillaume From wmorgan-sup@masanjin.net Mon Jun 15 15:17:20 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 12:17:20 -0700 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1245092885-sup-1794@altis> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> <1245084718-sup-1647@entry> <1245092885-sup-1794@altis> Message-ID: <1245093278-sup-4366@entry> Reformatted excerpts from Guillaume Quintard's message of 2009-06-15: > Still have it here, arg., with next. You probably still have broken lines in your sent.mbox. This fix only works for new messages, so you'll have to edit sent.mbox by hand. Look for "From " lines that have a localized timestamp in them, and change them to something that Time.parse can parse. It's probably possible to write a script to do this if you have a large number of htem. -- William From wmorgan-sup@masanjin.net Mon Jun 15 15:18:28 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 12:18:28 -0700 Subject: [sup-talk] [BUG] Can't handle spaces in paths In-Reply-To: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com> References: <80055d7c0906151147h826d5beg7e5c56092149cd54@mail.gmail.com> Message-ID: <1245093476-sup-4708@entry> Reformatted excerpts from Andrei Thorp's message of 2009-06-15: > I just downloaded a whole lot of mail from my gmail account via > offlineimap, and tried to add a source with a space. In short, sup > doesn't like this. It tries to do a split somewhere and it doesn't > work out for it so well :) Try putting a %20 instead of a space. A sad consequence of using URIs to specify sources. -- William From garoth@gmail.com Mon Jun 15 15:44:13 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 15 Jun 2009 15:44:13 -0400 Subject: [sup-talk] Yet Another Offlineimap Thread (YAOT) Message-ID: <80055d7c0906151244y1d66a4b1g8df4e3aa1d544c4f@mail.gmail.com> Hello! So I decided today to finally jump in and try to use sup for my main gmail account and not just my work stuff. I've set up offlineimap and downloaded the mail that I care for. Questions: - Does imap support a way to say which mails have been read and not? I think it probably does. If this is the case, can sup-sync-back somehow do this? It'd be nice if my gmail understood when a mail has been read, so when I sync back up with offlineimap, it's all savvy. - I vaguely saw some tricks here for how to reply with different e-mail addresses and stuff. I'd like to execute a whole different command when replying in some situations, so that my mail gets sent through gmail's smtp server instead of my work's one, for example. How would I achieve this? - I don't see a daemon mode for offlineimap. I guess the expected usage is to make it quiet and put it in a cron/regular script? Am I correct? Thanks! -AT From guillaume.quintard@gmail.com Mon Jun 15 17:30:13 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Mon, 15 Jun 2009 23:30:13 +0200 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1245093278-sup-4366@entry> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> <1245084718-sup-1647@entry> <1245092885-sup-1794@altis> <1245093278-sup-4366@entry> Message-ID: <1245101169-sup-9937@altis> Excerpts from William Morgan's message of Mon Jun 15 21:17:20 +0200 2009: > You probably still have broken lines in your sent.mbox. This fix only > works for new messages, so you'll have to edit sent.mbox by hand. Look > for "From " lines that have a localized timestamp in them, and change > them to something that Time.parse can parse. It's probably possible to > write a script to do this if you have a large number of htem. I think I said "save them in the mbox" to sup-config, and I still get that behaviour, so what? Do I dig in the 3.2Go .mbox (please, not that one), do I change to "save in sup://sent"? BTW, I renamed my sent.mbox, just in case. If I really have to go into the huge mbox, what should I look for exactly, I didn't quite get what the parser failed on. Regards -- Guillaume From garoth@gmail.com Mon Jun 15 21:14:14 2009 From: garoth@gmail.com (Andrei Thorp) Date: Mon, 15 Jun 2009 18:14:14 -0700 Subject: [sup-talk] [BUG] Sup Overload In-Reply-To: References: <80055d7c0906151145r493c07c2h7a68d776f49ce91a@mail.gmail.com> Message-ID: <80055d7c0906151814u2ab0fdf4n76144e27517870c8@mail.gmail.com> Forwarding to mailing list. ---------- Forwarded message ---------- From: Mark Alexander Date: Mon, Jun 15, 2009 at 2:10 PM Subject: Re: [sup-talk] [BUG] Sup Overload To: Andrei Thorp This may not be related, but at one point I found that feeding input characters to sup too quickly caused it to crash. ?I was using X cut-and-paste as a kind of poor-man's macro facility when I ran into this. ?If I recall correctly, the string I was cut-and-pasting into sup was this: ? T=N=a$ which was supposed to tag all messages, mark them as read, and archive them. ?I think it was crashing when it got to the "$", but it might have been the "a" that did it. ?I haven't tried this in a while. From wmorgan-sup@masanjin.net Mon Jun 15 22:18:05 2009 From: wmorgan-sup@masanjin.net (William Morgan) Date: Mon, 15 Jun 2009 19:18:05 -0700 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1245101169-sup-9937@altis> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> <1245084718-sup-1647@entry> <1245092885-sup-1794@altis> <1245093278-sup-4366@entry> <1245101169-sup-9937@altis> Message-ID: <1245118534-sup-3523@entry> Reformatted excerpts from Guillaume Quintard's message of 2009-06-15: > I think I said "save them in the mbox" to sup-config, and I still get > that behaviour, so what? Do I dig in the 3.2Go .mbox (please, not that > one), do I change to "save in sup://sent"? BTW, I renamed my > sent.mbox, just in case. If you're seeing that error, you should edit the "From " lines in your sent.mbox file (which is presumably not the 3.2g one). You'll see something like: From guillaume.quintard at gmail.com And a couple recent messages (i.e. at the bottom of the file) will have a that's been localized to your locale. That's what has to change. -- William From guillaume.quintard@gmail.com Tue Jun 16 04:06:48 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Tue, 16 Jun 2009 10:06:48 +0200 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1245118534-sup-3523@entry> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> <1245084718-sup-1647@entry> <1245092885-sup-1794@altis> <1245093278-sup-4366@entry> <1245101169-sup-9937@altis> <1245118534-sup-3523@entry> Message-ID: <1245139562-sup-3587@altis> Excerpts from William Morgan's message of Tue Jun 16 04:18:05 +0200 2009: > If you're seeing that error, you should edit the "From " lines in your > sent.mbox file (which is presumably not the 3.2g one). > > You'll see something like: > From guillaume.quintard at gmail.com > > And a couple recent messages (i.e. at the bottom of the file) will have > a that's been localized to your locale. That's what has to > change. So, I grep'ed "save them in the mbox" from the big mbox, and from sent.mbox, logically, I should have found 2 occurences, one in my mail, one in yours, but found only one :-(. I re-ran sup-config, told it to save in "sent", and that seems better. But I still don't know where the few messages sent during that time are. Plus, I sent a mail to one of my alternate addresses, and it popped up in the mailbox, without the "Sent" label, is that expected? -- Guillaume From bwalton@artsci.utoronto.ca Tue Jun 16 07:20:41 2009 From: bwalton@artsci.utoronto.ca (Ben Walton) Date: Tue, 16 Jun 2009 07:20:41 -0400 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1245139562-sup-3587@altis> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> <1245084718-sup-1647@entry> <1245092885-sup-1794@altis> <1245093278-sup-4366@entry> <1245101169-sup-9937@altis> <1245118534-sup-3523@entry> <1245139562-sup-3587@altis> Message-ID: <1245150910-sup-3911@ntdws12.chass.utoronto.ca> Excerpts from Guillaume Quintard's message of Tue Jun 16 04:06:48 -0400 2009: Hi Guillaume, > I re-ran sup-config, told it to save in "sent", and that seems better. > But I still don't know where the few messages sent during that time are. > Plus, I sent a mail to one of my alternate addresses, and it popped up > in the mailbox, without the "Sent" label, is that expected? The patch that allows for using any (most) sources as the outbox changed the way the sent label gets applied. When the message is polled, the label 'sent' is applied iff the source of the message matches the source uri in config.yaml. The default sent source (outbox) is sup://sent, which translates to $SUB_BASE/sent.mbox (normally ~/.sup/sent). The other small behaviour change that this introduced was that depending on poll intervals, sent messages may not be immediately added to the index, but instead are picked up on the next run...I see this with my Maildir outbox. The source used as the outbox is logged at startup, although if you've restarted sup, that log is lost to you now... HTH -Ben -- Ben Walton Systems Programmer - CHASS University of Toronto C:416.407.5610 | W:416.978.4302 GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu Contact me to arrange for a CAcert assurance meeting. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From guillaume.quintard@gmail.com Tue Jun 16 07:52:35 2009 From: guillaume.quintard@gmail.com (Guillaume Quintard) Date: Tue, 16 Jun 2009 13:52:35 +0200 Subject: [sup-talk] Crash after sending a message In-Reply-To: <1245150910-sup-3911@ntdws12.chass.utoronto.ca> References: <1244717279-sup-5999@viajero> <1244719933-sup-4261@viajero> <1245084718-sup-1647@entry> <1245092885-sup-1794@altis> <1245093278-sup-4366@entry> <1245101169-sup-9937@altis> <1245118534-sup-3523@entry> <1245139562-sup-3587@altis> <1245150910-sup-3911@ntdws12.chass.utoronto.ca> Message-ID: <1245152881-sup-3661@altis> Excerpts from Ben Walton's message of Tue Jun 16 13:20:41 +0200 2009: > The patch that allows for using any (most) sources as the outbox > changed the way the sent label gets applied. When the message is > polled, the label 'sent' is applied iff the source of the message > matches the source uri in config.yaml. The default sent source > (outbox) is sup://sent, which translates to $SUB_BASE/sent.mbox > (normally ~/.sup/sent). Well, it seems it's not the case, sent messages pop up in the mailbox without the sent label, last message got this: "From guillaume.quintard at gmail.com Tue Jun 16 13:47:26 +0200 2009" as a first line, and it's my main address, yet no label. Am I misunderstanding something? -- Guillaume From marcus-sup@bar-coded.net Tue Jun 16 08:42:08 2009 From: marcus-sup@bar-coded.net (Marcus Williams) Date: Tue, 16 Jun 2009 13:42:08 +0100 Subject: [sup-talk] [PATCH] Alternative View Message-ID: <1245156068-sup-7360@tomsk> Adds a keypress to toggle to an alternative view in thread index mode. By default this removes the date, authors and number of threads from the view leaving more room for labels/snippets This view is extendable via the alternative-view-widget hook. An example hook is included in the contrib/hooks directory that implements the standard sup view as an example. If you use this example your alternative view will not look any different to the standard sup view. It is meant to give you a base point for your edits. --- contrib/hooks/alternate-view-widget.rb | 39 ++++++++++++++++++++++ lib/sup/modes/thread-index-mode.rb | 56 ++++++++++++++++++------------- 2 files changed, 71 insertions(+), 24 deletions(-) create mode 100644 contrib/hooks/alternate-view-widget.rb diff --git a/contrib/hooks/alternate-view-widget.rb b/contrib/hooks/alternate-view-widget.rb new file mode 100644 index 0000000..cf936fd --- /dev/null +++ b/contrib/hooks/alternate-view-widget.rb @@ -0,0 +1,39 @@ +# This hook recreates the standard sup view as the alternate view +# Note that this will mean there is no difference when toggling +# between the standard and alternate views in sup. This is meant to +# serve as a starting point for your own view + +date_width = Time::TO_NICE_S_MAX_LEN +date = thread.date.to_nice_s +starred = thread.has_label? :starred + +dp = thread.direct_participants.any? { |p| AccountManager.is_account? p } +p = dp || thread.participants.any? { |p| AccountManager.is_account? p } + +snippet = thread.snippet + (thread.snippet.empty? ? "" : "...") + +subj_color = + if thread.has_label?(:draft) + :index_draft_color + elsif thread.has_label?(:unread) + :index_new_color + elsif starred + :index_starred_color + else + :index_old_color + end + +[ + [:tagged_color, tagged ? ">" : " "], + [:none, sprintf("%#{date_width}s", date)], + (starred ? [:starred_color, "*"] : [:none, " "]), +] + from + +[ + [subj_color, size_widget_text], + [:to_me_color, thread.labels.member?(:attachment) ? "@" : " "], + [:to_me_color, dp ? ">" : (p ? '+' : " ")], +] + (thread.labels - hidden_labels).map { |label| [:label_color, "#{label} "] } + +[ + [subj_color, thread.subj + (thread.subj.empty? ? "" : " ")], + [:snippet_color, snippet], +] diff --git a/lib/sup/modes/thread-index-mode.rb b/lib/sup/modes/thread-index-mode.rb index 5fa4f4c..9124dbd 100644 --- a/lib/sup/modes/thread-index-mode.rb +++ b/lib/sup/modes/thread-index-mode.rb @@ -8,6 +8,15 @@ class ThreadIndexMode < LineCursorMode MIN_FROM_WIDTH = 15 LOAD_MORE_THREAD_NUM = 20 + HookManager.register "alternate-view-widget", <