Re: [vile] Detecting if vile is idle

[Brendan O'Dea]

On 7 March 2016 at 21:54, Chris Green <address@hidden> wrote:
> On Fri, Mar 04, 2016 at 11:33:42AM +0000, Chris Green wrote:
>> I want to detect if vile has been idle for a period (i.e. five minutes
>> or so) while editing a file.  Would it be possible to hijack the
>> autocolor variable and the autocolor-hook to do this?
>>
>> It will only be for one specific case where I am using vile via a
>> wrapper script and syntax highlighting isn't required.
>>
>> If I set autocolor to 300000 (five minutes) will autocolor-hook get
>> called after five minutes of idleness?  I can then do what I want by
>> 'setv $autocolor-hook <some new script>'.

You can of course set autocolor-hook to do anything you like.  It is
however only called if the buffer was recently modified, so you will
need to have changed something for it to fire the first time, and to
have made subsequent changes for it keep firing.  Note also that if
you have multiple buffers visible, it will fire once for each of them
which has been recently changed.

  setv %counter 1
  store-procedure something 'Do something periodically'
      write-message &cat 'Something! ' %counter
      setv %counter &add %counter 1
  ~endm
  setv $autocolor-hook something
  setv $autocolor 5000

If you source that file, then muck about a bit you can observe the
behaviour: it should spit out a message five(ish) seconds of idle time
after the last buffer change.

>> Can I set autocolor to such a large value (64-bit Linux machine)?

Yes, 300,000 fits easily into a 32-bit integer.  Changing the 5000 in
the example above to 300000 works fine, with the caveats noted above
about recent changes.

So in short: if it is a one-off action you want taken after five
minutes of no activity and you can initially make a change to the
buffer to tickle the recent modification bit, then this will probably
work fine.

I can think of a case were I could have used this: our revision
control system at work used to have the annoying behaviour that when
mailing out a code change for review to a colleague it would do a
bunch of sometimes long-running pre-submit checks before firing up the
editor with the contents of a boiler-plate email to said colleague.
It was not uncommon to give up waiting for the checks and wander off
to lunch, to then later wonder why they hadn't attended your code
review... only to find an xterm somewhere with the editor waiting for
the email text to be saved.  Given that in 99% of cases I would just
hit ZZ at that point, being able to do that programatically after some
idle period would have been very useful.  Fortunately the problem was
solved in a different way: the software was changed to prompt for the
email contents *first*.

--bod