From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.52.109.137 with SMTP id hs9cs113153vdb; Mon, 4 Apr 2011 16:31:47 -0700 (PDT) Received: by 10.224.185.198 with SMTP id cp6mr2398058qab.222.1301959906874; Mon, 04 Apr 2011 16:31:46 -0700 (PDT) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id l42si11506596qco.159.2011.04.04.16.31.46; Mon, 04 Apr 2011 16:31:46 -0700 (PDT) Received-SPF: pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-devel-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-devel-bounces@rubyforge.org; dkim=neutral (body hash did not verify) header.i=@gmail.com Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 4DF001858112; Mon, 4 Apr 2011 19:31:46 -0400 (EDT) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by rubyforge.org (Postfix) with ESMTP id 003EB1858378 for ; Mon, 4 Apr 2011 19:01:26 -0400 (EDT) Received: by wwd20 with SMTP id 20so6753024wwd.23 for ; Mon, 04 Apr 2011 16:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:content-type:subject:from:to:in-reply-to :references:date:message-id:user-agent:content-transfer-encoding; bh=kA4w6bxbI/DyqtqCkx8leZO535sfGb0woLC7UHX7Cco=; b=qsiNZKZvwpajqU+YqUlkSQhSAd9jXJQE9+pPob9HIqg/OnFEtRESGnRed/MouzBsKu YClmrNc2xAXDJ/RS4b9IYFp1CW9F2fe8FXfmaPyGwezh80pXYny0bK1OuBMECpinZHHx T5RBDvB9j5ky9+Rppf70kJ3SdsvA9XOmaUpjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=content-type:subject:from:to:in-reply-to:references:date:message-id :user-agent:content-transfer-encoding; b=rY196lf86ut6PoJJ+B/BUuqo/nk66PEk4kamZVJ1tHIRMXgOOWzLsXSxXUnwzsgTqz jJUN0XIC2ypFl8pYsxx43YPXhxb2Cpe0Hx43pbs3SQiFipshxV+laFOldAKRRF0Z5c18 9FL2wE628uILKzadvsjwb1jf2cg+zxaKrz+3w= Received: by 10.227.139.89 with SMTP id d25mr7654010wbu.58.1301958086187; Mon, 04 Apr 2011 16:01:26 -0700 (PDT) Received: from localhost (cpc12-cmbg15-2-0-cust81.5-4.cable.virginmedia.com [86.30.247.82]) by mx.google.com with ESMTPS id z13sm3188002wbd.63.2011.04.04.16.01.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Apr 2011 16:01:23 -0700 (PDT) From: Hamish To: sup-devel In-reply-to: <1298833983-sup-4830@pruts.nl> References: <1298239068-sup-6985@whisper> <1298747943-sup-9749@whisper> <1298768518-sup-4041@alvh.no-ip.org> <1298774629-sup-4062@medusa> <1298819507-sup-8138@pruts.nl> <1298826314-sup-276@whisper> <1298833983-sup-4830@pruts.nl> Date: Tue, 05 Apr 2011 00:01:18 +0100 Message-Id: <1301957971-sup-1165@whisper> User-Agent: Sup/git Subject: Re: [sup-devel] editing messages outside of sup X-BeenThere: sup-devel@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sup developer discussion List-Id: Sup developer discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sup-devel-bounces@rubyforge.org Errors-To: sup-devel-bounces@rubyforge.org Excerpts from Ico Doornekamp's message of Sun Feb 27 19:44:15 +0000 2011: > > Excerpts from Ico Doornekamp's message of Sun Feb 27 15:31:14 +0000 2011: > > > > Hamish, definitely thank you for doing something about this. I > > > > actually had a general question about this problem a while back - if > > > > it is possible to edit the message independently via the approach you > > > > took in this patch, why can't the editor be fired up in a > > > > "nonblocking" kind of mode in the first place? Something like a > > > > fork()/exec() to start the editor, and then handling SIGCHLD rather > > > > than calling a variant of wait() immediately. The SIGCHLD handling > > > > could check the return code from the editor, and then update the > > > > message sending buffer appropriately. > > When the infrastructure for background-editor hooks is there, I'm ready > to try to make the hook! OK, I've pushed a change to allow hooks for this functionality. For now it is just on the async_message_edit branch (in the main gitorious repo). To quote from the hook text: Runs when 'H' is pressed in async edit mode. You can run whatever code you want here - though the default case would be launching a text editor. Your hook is assumed to not block, so you should use exec() or fork() to launch the editor. Once the hook has returned then sup will be responsive as usual. You will still need to press 'E' to exit this buffer and send the message. Variables: file_path: The full path to the file containing the message to be edited. Return value: None If the hook did block then sup would be unresponsive, which would kind of ruin the point of the exercise. So this should work fine to launch a GUI text editor - your hook could just be: fork { system "/usr/bin/gedit #{file_path} > /dev/null 2>&1" } (Note that if you don't redirect all output to /dev/null then you can end up with the screen being written all over, which gets a bit messy ...) The next step would be to have the async mode exit as soon as the forked hook code has finished. The best way I've thought of to do this is to trap SIGUSR1. As long as there was only one async mode active this would work fine, but if there were two there would be trouble. I guess I could add a return value to the hook about whether to pay attention to SIGUSR1. Then the BufferManager could know which buffer was waiting for SIGUSR1. If a second buffer called the same hook while the first was still waiting for the signal, then it should refuse to honour it. It does feel a bit messy ... I might have a go at it at some point, but if anyone has other ideas, then please shout out. Hamish _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel