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
