[slim-vim] Highly recommended Vim patch

[Brad Beveridge]

On 18/08/06, Brad Beveridge <brad.beveridge at gmail.com> wrote:
> Hello all, I've been spending some time sorting out some network
> problems with Slim-Vim.  Much of it boiled down to slight brokeness in
> the original async patch.  Here is the changelog.
> Fri Aug 18 18:01:21 PDT 2006  brad.beveridge at gmail.com
>   * Corrected network_io flaws.
>   * This patch addresses several flaws with the network_io callback scheme.
>    1) Network callbacks had no way of telling Vim to redraw.  if_ecl
> tried to call update_screen from within the callback, but this is
> buggy - I have had Vim crash
>    2) Callbacks used to be re-entrant (probably because of calling
> update_screen).  It was possible to trigger a callback, and that
> callback would call Vim code that could reprocess the network
> callbacks, recalling the callback.  This is certainly not an intended
> side effect.
>
>   * Fix #1: callbacks now return true (non-zero) if they want Vim to
> redraw (if_ecl assumes always redraw).  This flag effectively gets
> passed up the stack to a point where it is actually safe to call
> screen_update.
>   * Fix #2: since Vim is single threaded, we simply have to worry
> about trivial recursion, the callback function now has a static int
> that tracts the nesting level, and returns if it is non-zero.
>
> From what I can see, this has vastly improved the stability of
> Slim-Vim's callback operations - especially those that generate a lot
> of buffer output.
> Also, I have some slightly buggy patches that increase our buffer
> write speed by a couple of orders of magnitude :)  When I squash the
> last couple of bugs, I'll get them in.
>
> So, please patch your Vim with this Darcs patch!  Larry, can you
> please get this in the mainline ASAP.
> From now on, I am going to be extremely concerned with 3 areas of Slim-Vim
> 1) Incorrect display after an operation (garbled lines, etc)
> 2) Needing to press a key to update the display after an op.
> 3) Vim crashes, either to the console or the ECL repl.
>
> If you see these - tell me!
>
> Cheers
> Brad

I have noticed a bug where compiling a file with heaps of output, the
compile will hang when it is generating notes.  The problem was that
when a callback would get called, it could trigger RealWaitForChar,
which could trigger another callback - the previous patch would
prevent the network callback from happening.  However, RealWaitForChar
would return that there were chars pending, there were chars in the
network stream, but not in the keyboard input stream.  Now, whenever
we detect that our callback is already running, we trip that we want a
redraw.  Maybe not ideal, but it works.
I could only roll both patches into one, so this patch contains the
previous patch and this one.

Comment is:
Sat Aug 19 18:14:33 PDT 2006  brad.beveridge at gmail.com
  * Fixed bug where callbacks can stall in RealWaitForChar


Cheers
Brad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callback-hang.patch.gz
Type: application/x-gzip
Size: 3092 bytes
Desc: not available
Url : http://www.lispniks.com/pipermail/slim-vim/attachments/20060819/5951f773/callback-hang.patch.gz