Claus Reinke

@marijnh yes, but I couldn't reproduce the issue, either. We do have a related bug #24 , where I suggested various debug outputs to try and look at ( @gilligan...

@marijnh it is just a suspicion, based on the location of the errors. So far, every check (including those in #24) has tended to confirm the one-to-one buffer mapping -...

@jparera thanks. If I read that correctly, that will finally remove the ambiguity (whether or not index==bufnum).

Probably not tern-related - try googling for the error message https://www.google.de/search?q=%22cannot+import+name+MAXREPEAT%22 http://stackoverflow.com/questions/16301735/importerror-cannot-import-name-maxrepeat-with-cx-freeze seems to be a common issue, possibly involving conflicting python installs.

@DelvarWorld have you perhaps set `g:tern_show_argument_hints` to `'on_move'`? That tends to make movements sluggish, and is different from the issue here.

back to my original suspicion. 1.add a trace line to `tern_sendBuffer`, something like: `vim.command("echo 'tern_sendBuffer ' b:ternBufferSentAt")` 2.split edit two `.js` files and keep switching between the two. 3. buffer...

further tracing shows this to be related to old `.tern-port` files (which normally do not get cleared away on windows). Here's my traced code ``` def tern_sendBuffer(files=None): vim.command("echo 'tern_sendBuffer '...

If no `tern` has been started and the buffer has not been modified, no action should be taken. Determining the former might take some refactoring.

For me, this wasn't a file size issue, just a problem with the try/timeout logic - see the tracing suggestions above. The delays were caused by tern autocmds firing on...

`tern_for_vim` no longer creates `.tern-port` files by default (they are a way for tern servers to announce how they can be reached; without them, vim just starts a new server)....