Re: [sup-devel] editing messages outside of sup

[Ico Doornekamp <sup@zevv.nl>]

* 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