-
Notifications
You must be signed in to change notification settings - Fork 100
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
delays when switching windows #29
Comments
I too experience this, and also weird delays in other parts of moving around vim. I want to see if it's related to #27, because when a bunch of node procs stay open, vim eventually just locks up, even though they don't use much cpu. |
@delvarworld have you perhaps set |
It's set to 'on_hold' for me |
It is now at the point where it's just completely unusable. I have no idea what's going on, but when I open my process manager and start moving around in vim, I can see node processes spawned every time I make a move. This plugin is definitely not ready for prime time. |
back to my original suspicion. |
further tracing shows this to be related to old
if |
If no |
Is there some way for me to determine if I'm having this issue, and is there a solution to this problem? I've tried Tern for Vim for the first time today, I'm impressed with the completions it can give me, but opening files and switching between splits consistently takes around 2 seconds, which gets annoying really fast. |
Are these files huge? Tern fires off an HTTP request to update the Tern server on the file's content when you leave a buffer that was changed. Due to Vim's primitive API, it does this synchronously. Since the server is on a local loopback device, this should not take 2 seconds, though! |
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 switch, then finding an old .tern-port file, then timing out when trying to connect to the non-existing server, then starting a new server and trying again. Without any explicit tern action having been requested.. I'm not sure what happened to the autocmd aspect, but since the termination changes for windows, the old .tern-port files no longer hang around for me, which has improved the situation a lot. |
Nope they are small files, ranging from 50 to max 200 lines of code. Eg: just made a new spec file, consisted of 5 lines of code. Went to my other split: 1 second delay. Added a comment in the spec file, still 5 lines, again 1 second delay. My PC is running on 6 GB Ram, i7 processor, Windows 8.1. On a related note: What's the response time on the autocompletion itself I can expect? Right now I also have to wait between 1-2 seconds to get a response. That's pretty acceptable to me, but just wondering. With the risk of being called a total Vim noob: I can't really make sense of the tracing suggestions of clausreinke. Where exactly should I be adding these? Or, where can I find these .tern-port files? Some extra info: Would really like to get this working silky-smooth since the autocompletion is pretty amazing. |
So unless you've got an old The tracing suggestions were just my way of adding "print" statements for debugging the issue - the code is likely to have changed somewhat since then (in The issue was that Completions can take a while the first time round, as that starts the tern background process and processes the source files in question. After that, completions tend to be quick. |
Just as an update: I'm switching my development environment to Linux, where Tern does seem to work without delays! |
Sorry to thread-necro, but I'm experiencing the same issue as @FrigoEU (1-2 second delays on file switching) when using Vim 7.4 in cmder on Win8.1. I also use tern for vim on linux without issue, but am sometimes forced to use a windows machine and would love to get tern working without these annoying delays. Does anyone have a solution? |
same issue, running on osx, very small files, delay has been upwards of a minute at times, and I have not been able to quit vim, oh and I set hint argument "on_hold". When I run top, I can see that whenever I change buffers or execute a tern command( ex. tr ) a new node task is created for each buffer and each tern command, and the task does not end until I eventually have to force quit vim(console). When I remove tern( I am using pathogen ) everything goes back to normal. May try and grab an older version, have used tern for vim for about a year now on my own machine and love it, but setting up the current machine I am on for work, I am kind of at a loss. Will try and look into hacking something together in the mean time. Will report back with/if any success. |
I still can't figure out where this is coming from -- but then, I don't have much experience with vim. Further diagnostic information definitely welcome. |
I get the delay when tern server shuts itself down after five minutes of inactivity. Logic in As a workaround to fix this issue I use |
The code is supposed to immediately notice when it tries to talk to a server that's gone (the connection attempt will produce a 'connection refused' error) and start a new one. Are you running some kind of firewall or similar that might be intercepting and blocking connections to unused ports? |
I use default Windows firewall. It also doesn't help if I turn it off. diff --git a/script/tern.py b/script/tern.py
index 49e29f4..498c50f 100644
--- a/script/tern.py
+++ b/script/tern.py
@@ -235,7 +235,12 @@ def tern_sendBuffer(files=None):
tern_makeRequest(port, {"files": files or [tern_fullBuffer()]}, True)
return True
except:
- return False
+ try:
+ port, _portIsOld = tern_findServer(port)
+ tern_makeRequest(port, {"files": files or [tern_fullBuffer()]}, True)
+ return True
+ except:
+ return False
def tern_sendBufferIfDirty():
if (vim.eval("exists('b:ternInsertActive')") == "1" and With this change I only get delay on first BufLeave event. Similar check is made in |
I don't have a reproducible case yet - posting as a reminder: sometimes switching windows is delayed. Last time I saw this, I suspected the logic in
tern_sendBufferIfDirty
, because it kept happening for freshly opened, unmodified source.The text was updated successfully, but these errors were encountered: