Re: [Vimprobable-users] Editor patch, revised

[Markus D. <msd...@ar...>]

Hi Jason,

On Fri, Sep 28, 2012 at 07:30:12PM +1200, Jason Ryan wrote:
> On 27/09/12 at 10:55pm, Markus Demleitner wrote:
> > handler vimprobableedit vim -gf %s
> > 
> > in your vimprobablerc, and when hitting ^t in a text field, you'll
> > get a gvim window.
> > 
> I don't have gvim installed, so I used:
> handler vimprobableedit urxvtc -e vim %s
> 
> and the term opens, I compose my message and then, when I exit the term,
> the file exists in /tmp/vimprobableXXXX but nothing is printed to the
> text field in vimprobable.
Well, that's because urxvtc exits immedately after it's contacted the
daemon.  vimprobable thinks all is fine, reads back the (unchanged)
data and decides all is dandy.

Try 

handler vimprobableedit urxvt -e vim %s

and things should work.  I don't think there's a good way to catch
these kinds of instant-fork problems without ugly heuristics (warn when
the child process took less than 100 ms? 1000 ms? 5000 ms? Meh).

While I'm thinking about that: I'd like to give visual feedback that
the edit field is "off limits" while the external editor is active.
I'd try that with a few lines of javascript fed to webkit (switch the
element to "disabled", maybe), but if anyone has a better idea, I'd
appreciate that.

> > If people are happy with the way this works, I'd go ahead and
> > document it (plus probable bug fixing); I guess the vim -gf shold be
> > a builtin default, shouldn't it?
> > 
> Wouldn't ${EDITOR:-vi} be more appropriate? Just a thought???
The trouble with EDITOR is that it'll usually be a console editor
(not long ago there were systems that defaulted to EDITOR=ed and
VISUAL=vi...).  If I'm spawning a console editor, things will really
be confusing, and default confusing is not something I'd like to
build in.

So, given the vimprobable's target audience I'd say we have a choice
between no default and vim -gf.

Cheers,

        Markus