Excerpts from Alvaro Herrera's message of 2011-02-26 18:15:31 -0700: > Excerpts from Hamish's message of sáb feb 26 16:23:13 -0300 2011: > > Excerpts from Hamish's message of Sun Feb 20 22:02:54 +0000 2011: > > > For the moment this work is in the async_message_edit branch. If no one > > > shouts about this being a terrible idea then I'll merge it into next > > > within a week. > > > > No one shouted, so I've merged it into next. At the end of the email is > > the diff of the async_message_edit branch against where I started it. > > I like this general idea very much. The bit about having to copy/paste > the file name is a bit of a pain, though. I gave it a spin, and > excepting that one infelicity, I found it pretty neat. I noticed no > problems at all. > > The way I envision this working is with a "vim --servername foo" window > being open at the time sup starts, and then "vim --remote" would open > the file in that server each time I edit an email. Most likely, the > command to edit a file should be specified via a hook. > > Thanks for your work on this. >
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. I promise, this is not to denigrate on your work at all... I have just always been confused what would be wrong with the general approach I just described. roni _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel
