* On Tue Apr 05 01:01:18 +0200 2011, Hamish wrote: > > 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.
Sounds very useful to me! > 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. I might have understood the details of your implementation wrong, but why would it not just be possible to act on a SIGCHLD and use wait() to retreive the pid and exitstatus of the finished process ? The pid would distinguish the different async handlers, resolving the ambiguity ? Thanks! -- :wq ^X^Cy^K^X^C^C^C^C _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel
