From: Roni Choudhury <roni@cs.utah.edu>
To: sup-devel <sup-devel@rubyforge.org>
Subject: Re: [sup-devel] editing messages outside of sup
Date: Sat, 26 Feb 2011 19:51:05 -0700 [thread overview]
Message-ID: <1298774629-sup-4062@medusa> (raw)
In-Reply-To: <1298768518-sup-4041@alvh.no-ip.org>
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.
>
> I like this general idea very much. The bit about having to copy/paste
> the file name is a bit of a pain, though. I gave it a spin, and
> excepting that one infelicity, I found it pretty neat. I noticed no
> problems at all.
>
> The way I envision this working is with a "vim --servername foo" window
> being open at the time sup starts, and then "vim --remote" would open
> the file in that server each time I edit an email. Most likely, the
> command to edit a file should be specified via a hook.
>
> Thanks for your work on this.
>
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.
I promise, this is not to denigrate on your work at all... I have just
always been confused what would be wrong with the general approach I
just described.
roni
_______________________________________________
Sup-devel mailing list
Sup-devel@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-devel
next prev parent reply other threads:[~2011-02-27 3:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-20 22:02 Hamish
2011-02-26 19:23 ` Hamish
2011-02-27 1:15 ` Alvaro Herrera
2011-02-27 2:51 ` Roni Choudhury [this message]
2011-02-27 15:31 ` Ico Doornekamp
2011-02-27 17:20 ` Hamish
2011-02-27 19:44 ` Ico Doornekamp
2011-04-04 23:01 ` Hamish
2011-04-05 4:38 ` Ico Doornekamp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1298774629-sup-4062@medusa \
--to=roni@cs.utah.edu \
--cc=sup-devel@rubyforge.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox