The Vim plugin causes errors with fugitive / :Gdiff about tern

[Olical]

I think this fix would involve not sending the request if fname points to a non existent file at this line. Am I on the right track? If so I'd be happy to fix this. I think you're doing an amazing job so far but I'd like to start helping with these Vim issues if I can.

[marijnh]

That might be a partial solution (and probably a good idea in general. The Emacs mode already does it). I wonder why the plugin didn't send the content of the file along with the request, though -- b:bufferSentAt is initialized to -1, so the test of whether the server has an up-to-date representation of the file should always fail.

[Olical]

Well here is the error output I get when I run :Gdiff (file names changed for privacy):

Error detected while processing BufLeave Auto commands for "*.js":
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "<string>", line 167, in tern_sendBufferIfDirty
  File "<string>", line 155, in tern_sendBuffer
  File "<string>", line 48, in tern_findServer
  File "<string>", line 53, in tern_startServer
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 1228, in _execute_child
    raise child_exception
OSError: [Errno 2] No such file or directory: 'fugitive:///Users/someuser/some/directory/.git//j38sk46c42bd7307c8cdfh62e4c6/path/to/directory'

I don't fully understand how it all works at the moment, but I will look into it at some point soon and see if I can get something working. Tern works really well on the whole, it just conflicts with one of my most used tools right now. It's odd that the OS error reports the directory not existing, and not the file. Might be the way fugitive reports the current path.

[marijnh]

If there is a way to reliably know whether a buffer is a real file or a make-believe one, we could simply rig tern#Enable to not enable for a buffer unless it's dealing with a real file.

I can not entirely figure out the error. I expect though, that the problem occurs when Tern tries to walk up the directory tree looking for a .tern-project file. If it starts in a non-existing directory, it'll raise an error. It probably would be an all-around good idea to catch that and simply report that the server can't be started in that situation.

[marijnh]

See attached patch for that latter problem.

[Olical]

That patch is along the lines of what I was trying to do, but I kept breaking it because I didn't know how on Earth it worked. I've dropped that line into my local version and everything works perfectly. Well done and thank you!

[marijnh]

Okay, I guess that ties this up then. Still worried about other corner cases with buffers that are not real files, but we'll see about those when they come up.

[clausreinke]

@marijnh it is up to plugins how they manage their buffers, but you can possibly check &buftype for nofile or nowrite (:help buftype)