* On Sun Feb 27 03:51:05 +0100 2011, Roni Choudhury wrote: > 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. > > 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. I guess one solution could be to add master/slave pty support to sup, allowing one or more regular console based editors instances (vim, nano, joe, etc) inside sup, passing all keyboard input to the slave process except for a few (configurable) keystrokes for switching sup buffers. (I'd make an exception for running emacs inside sup, because emacs users would probably prefer running their own lisp version of sup inside emacs instead of emacs in sup) A quick proto would probably be not very hard to do, it is mostly a matter of passing keyboard commands from the master sup to the editor running in the slave pty, passing pty output back to the terminal and handling the proper signals and ioctls() for keeping track of the window size. This will work as long as all terminal control characters are simple passed transparantly from the slave editor to the terminal, but things quickly get nasty when you would want to do the terminal emulation inside sup, and this is probably necessary for properly handling screen redrawing and resizing. It's hard to guess how much work this would really be. Part of me says it should not be too hard to find a simple terminal emulation implentation in another piece of (L)GPL software and simply steal as much as possible. Another part of my fears one would likely end up reimplementing at least half of GNU screen, which is probably not a very pleasant adventure. Ico -- :wq ^X^Cy^K^X^C^C^C^C _______________________________________________ Sup-devel mailing list Sup-devel@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-devel