vimprobable-users

[Vimprobable-users] Editor patch, revised

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

Hi,

I've taken Hannes' patch for the external editor and changed it to
emply the handler mechanism.  Basically, you say

handler vimprobableedit vim -gf %s

in your vimprobablerc, and when hitting ^t in a text field, you'll
get a gvim window.

This also fixes a bug in which the ":" protocol separator did not get
stripped from the argument in open_handler (but frankly, that code is
extremely spooky -- does anyone actually understand what all the temp
magic is supposed to do?).

One "architectural" question: I'm potentially emitting quit a bit of
diagnostics -- is give_feedback the right function for this?  Should
I do something else yet?

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?


While I'm here:  I'd like to add a toggle syntax for boolean flags,
probably along the lines of vim{perator}'s set inv{option}; this is
to support stuff like

map <C-S> set invscripts

or so.  Would anyone consider this feature bloat?


Even more featurecreepy would be to have indicators of script and
proxy in the status line (little S and P chars at the very right, I'd
guess).  Are their any strong feelings about that?

Cheers,

         Markus

Re: [Vimprobable-users] Editor patch, revised

[Jason R. <jas...@gm...>]

On 27/09/12 at 10:55pm, Markus Demleitner wrote:
> Hi,
Hi Markus - thanks for the patch.
> 
> I've taken Hannes' patch for the external editor and changed it to
> emply the handler mechanism.  Basically, you say
> 
> 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.

> This also fixes a bug in which the ":" protocol separator did not get
> stripped from the argument in open_handler (but frankly, that code is
> extremely spooky -- does anyone actually understand what all the temp
> magic is supposed to do?).
> 
> One "architectural" question: I'm potentially emitting quit a bit of
> diagnostics -- is give_feedback the right function for this?  Should
> I do something else yet?
> 
> 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…
  
Cheers,

/J

-- 

http://jasonwryan.com/  [GnuPG Key: B1BD4E40]

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

Re: [Vimprobable-users] Editor patch, revised

[Jason R. <jas...@gm...>]

On 28/09/12 at 10:19am, Markus Demleitner wrote:
> 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).

That works nicely, thanks Markus.  

> 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.
  
The default mail handler that ships is mutt, so maybe the audience will be OK
with a console editor :)

Thanks again for the work on this patch: it is much appreciated!

Cheers,

/J

-- 

http://jasonwryan.com/  [GnuPG Key: B1BD4E40]

Re: [Vimprobable-users] Editor patch, revised

[Hannes S. <ha...@yl...>]

Hi,

thanks, Markus, for this patch.

Jason Ryan <jas...@gm...> wrote:
> > I've taken Hannes' patch for the external editor and changed it to
> > emply the handler mechanism.  Basically, you say
> > 
> > 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.

This is exactly the problem I've sketched in the conclusion post of the
old thread: The symmetric spawn operation which I initially wrote is
probably not suited for quite a number of editors which will return
after the opening operation immediately. Hence my plan/suggestion to
use an asymmetric operation and watch the file for changes through
another process instead. Which, of course, would be much more complex
to implement.

The major question for me here (which I think should be decided before
any further coding) is whether we do need asymmetric operation or not.
If not, we will need to document this in the wiki as well as possible
which editors will work and which won't.

Hannes

Re: [Vimprobable-users] Editor patch, revised

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

Hi Hannes,

On Fri, Sep 28, 2012 at 05:48:34PM +0200, Hannes Schüller wrote:
> This is exactly the problem I've sketched in the conclusion post of the
> old thread: The symmetric spawn operation which I initially wrote is
> probably not suited for quite a number of editors which will return
> after the opening operation immediately. Hence my plan/suggestion to
> use an asymmetric operation and watch the file for changes through
> another process instead. Which, of course, would be much more complex
> to implement.
> 
> The major question for me here (which I think should be decided before
> any further coding) is whether we do need asymmetric operation or not.
> If not, we will need to document this in the wiki as well as possible
> which editors will work and which won't.

My opinion on this is that our most likely use cases are vim -gf or
an xterm -e <whatever>; both of them work fine, so I'd guess we're
way beyond 80/20 with what we have.

While I'd guess watching the file would be fairly easy after the
patches I just sent around (I suspect it would just be an additional
watch), it results in IMHO unresolvable functional trouble -- I think
we agree that only one "head" can edit the text at a time.  Thus, we
need to lock the browser text box while the editor "runs" and release
the lock when it exits.  By just looking at the temp file, we can't
tell when that happens, and if the editor itself detaches, we don't
know its pid either.

So, yes, I'd say what doesn't work (vim -g, urxvtc -- which is not
your average terminal emulator anyway --, what else?) on the wiki and
keep things more or less as they are.

Cheers, 

      Markus