-
Notifications
You must be signed in to change notification settings - Fork 184
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
No client available for view if already open on ST startup #18
Comments
I think it's not uncommon to have a lot of open views when launching ST after a hot exit, we may want to avoid hammering the language server at startup. Perhaps if we begin by starting a client for the active view in Scenarios to test:
|
You are absolutely right. As a language server is activated on demand after switching to another view, the currently focused ones are interesting only. We just need to pay attention to multi view layouts, which may display several views a user might want to see information for initially even though they were not yet activated. In GitGutter I use the following function (method of the EventListener in my case) to check for visible views def is_view_visible(self):
"""Determine if the view is visible.
Only an active view of a group is visible.
Returns:
bool: True if the view is visible in any window.
"""
window = self.view.window()
if window:
view_id = self.view.id()
for group in range(window.num_groups()):
active_view = window.active_view_in_group(group)
if active_view and active_view.id() == view_id:
return True
return False |
The smallest fix for the focused view is merged, a bit more work is needed to initialize multiple visible views for a single language server at once. |
By default ST has set
hotexit: true
, which causes the previous session and all its open files to be restored the next time ST starts.LSP does not create a client object for such views. Instead the following lines are displayed.
The
pyls
is started as soon as the view is deactivated and activated again by minimizing and restoring ST window or switching to another view and return.It looks like the issue may be triggered by a bug in ST core, which prevents the
on_load
andon_activated_async
to be sent to already open views upon startup, but maybe LSP could lazily initialize lsp servers for open views in theplugin_loaded()
hook.The text was updated successfully, but these errors were encountered: