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. > > But in what tty should the forked editor run then? I guess the above > idea would work for spawning an editor under X, but can not be used when > running on a (remote) console. I guess the 'vim --remote' solution would > be feasable, bug I guess this is not simple enough to add as an > out-of-the-box solution.
Now I've got the basic stuff working, I'd be up for adding to it. Probably the best way would be to use a hook that could fire up something using a fork()/exec(). The way I'd see this working is that it would only be useful on a machine running X (or Wayland, or whatever the Mac GUI is called). If you have ssh'ed to a remote machine then I don't think there is a good way to manage this automatically without turning sup into screen (which I think would be a bad idea), though I wouldn't want to get in the way of imaginative hooks of course. Basically I would say that if you want to edit your message outside of sup on a remote machine (via ssh) you should use screen/tmux in split mode, or have 2 terminals that ssh to the same server, or something like that. Opening the file tends to involve typing: $ vim /tmp/sup and then pressing tab, so I don't think it's too onerous. And if you turned on X forwarding and had xsel installed you could just press <Enter> (to copy the path to the clipboard) and then paste that into the other terminal. Anyway, I'll have a think about how best to do a hook for this. I might end up doing a blocking and a non-blocking variant - the blocking variant could drop you straight back to reply-mode when it detects the editor has exited, while the non-blocking mode would make it simpler to write a hook, but you would have to manually exit async mode once editing was done. Hamish _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel