inconsistent behavior of getchar() in gui macvim

[Ken Deeter]

Hi there,

I'm trying to write a script which implements a sort of interactive search in a code base based on an external utility (not unlike ctrl+p)

I've run into a funny problem where the behavior of the getchar() function on GUI macvim seems a bit surprising. Here are two different versions of my getchar() loop that produce very different behaviors when interacting with them:

function! InputLoopSimple()
let i = 0
let current_input = ""
while 1
redraw
let char = getchar()
let char = nr2char(char)

if char == "c"
break
endif
let current_input .= char
echo current_input . " " . i
let i += 1
endwhile
endfunction

The one above works fine as expected. It seems that when the blocking getchar() (sans argument) is called, it somehow coordinates properly such that the screen also gets redrawn for you.

Here's a different version with what I'm trying to do:

function! InputLoopComplex()
let i = 0
let current_input = ""
while 1
redraw
let char = getchar(0)
if char == 0
" make screen redraw"
sleep 1m
else
let char = nr2char(char)

if char == "c"
break
endif
let current_input .= char
endif
echo current_input . " " . i
let i += 1
endwhile
endfunction

This second version is a simplification of what I'm actually trying to do. The basic idea is that I want to use non-blocking getchar() so that in the case that there is no input, I can go and check some other things that might have happened while the input loop is running.

The two observations here are that:

a) I have to do the sleep in the middle to get the screen to redraw at all.
b) somehow macvim seems to processing the input differently. If you run the second version of the loop, and say hold down a key on your keyboard, the rate at which it processes characters is far slower than the InputLoopSimple() version. It's almost as if the key repeat rate is being ignored, and it's getting keystrokes from some kind of unbuffered source.

A related observation is that both versions of the loop work fine in terminal vim (I tested by running the Vim binary in the app bundle). I suspect this is because the terminal is actually buffering the input so that the essentially both the blocking and non-blocking versions of getchar() are reading from the same source.

So several questions here:

1) is this a bug? shouldn't non-blocking getchar(0) essentially have the same performance characteristics?

2) is there any way to trigger a screen in gui macvim redraw without having to resort to "sleep 1m" ?

If it matters, I originally ran into this problem while trying to do the same loops as above from python code using the vim python integration. The command sequence is the same in each though, as is the behavior, so I don't think it's related to that.

Thanks for any help!

Ken