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

[Hamish <dmishd@gmail.com>]

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