Detect buffer changes in the vim plugin about tern

[clausreinke]

You might be able to get the info you want from the undotree (:help undo, :help undotree() ). Depends on vi-nocompatible undo (&cpoptions) and suitably large &undolevels.

But using the filesystem version as a fallback synchronization, with &modified as an approximation of change, tends to work (coders tend to save changes in all but the current buffer, in which they tend to edit a lot). Unless you want to go all the way towards sending diffs only.

Vim has all kinds of special purpose interfaces for tool integration, instead of one generic solution (like Emacs has). That is its main disadvantage. Even the python interface has disadvantages (not every Vim install has the required python lib, and every Vim install is bound to a specific version of that python lib), but it comes close to being generic, and most users should be able to install the required python version.

I tend to code only the minimal part in python that can't be done in Vim, so if someone prefers the perl or ruby or scheme or ... interface, they'd only have to reproduce that part in their interface.

Most of the more specific interfaces, like the netbeans one, look tempting when you first find them, but you'd have to check carefully if the specific interface serves your purpose, all the way, because if there is anything that interface can't do, you're stuck completely.

As for availability: on my windows 7, my gvims have netbeans support enabled, my git bash terminal vim does not. Given the wide variety of vim configurations out there, I would not rely on it.

[marijnh]

The problem with &modified is that saves to disk and updates to the tern server are not happening at the same time.

For autocompletion, the user is probably typing already, so we'll have to send updated context anyway. But for a feature like showing function arguments, there might be a series of queries without changes to the buffer inbetween. That's the scenario I'd like to detect. The undo history trick might work -- I'll look into it.

[marijnh]

undotree()['seq_cur'] turns out to be perfect for my purpose -- I can save the sequence number at which I sent the file over, and compare against that for later requests.

See f72099c