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

From: Ico Doornekamp <sup@zevv.nl>
To: sup-devel <sup-devel@rubyforge.org>
Subject: Re: [sup-devel] editing messages outside of sup
Date: Sun, 27 Feb 2011 20:44:15 +0100	[thread overview]
Message-ID: <1298833983-sup-4830@pruts.nl> (raw)
In-Reply-To: <1298826314-sup-276@whisper>

* On Sun Feb 27 18:20:55 +0100 2011, Hamish wrote:

> 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.
> 
> 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.

I've just hooked up a few lines of code (standalone, not part of sup)
that forks two editors (one joe, one vim) in ptys and handling both
terminal outputs with select(), allowing me to 'switch' between
processes on-the-fly using a magic keystroke. Redrawing is forced before
'switching' to a process by doing a TIOCSWINSZ ioctl and sending a
SIGWINCH twice, first with a fake, then with the true window size. This
is not quite a complete rewrite of screen, but seems to work quite well.
(Although I'm sure there are plenty of cases not covered by this crude
method of switching)

When the infrastructure for background-editor hooks is there, I'm ready
to try to make the hook!

-- 
:wq
^X^Cy^K^X^C^C^C^C
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel