Repository: sublimelsp/LSP

Issue:
Unable to save modified file when dragged to a new window
Description
Editing typescript project, dragged a tab out to a separate window then modified some lines and tried to save. Sublime won't save unless I drag the tab back into the open project. (see sublime issue - https://github.com/sublimehq/sublime_text/issues/4623)

Steps to reproduce
Start Sublime Text, open a directory containing typescript files. (make sure to have the LSP plugin installed)
open multiple files in tabs
drag one of the tabs out to a separate window
modify the tab that's been dragged out, then try to save
Expected behavior
Expect the separate window/modified file to save.

Actual behavior
![125587999-89de6ff6-454e-4746-ba01-375f066a4c3b](https://user-images.githubusercontent.com/34407152/125639978-7c250834-f248-4ea8-8eda-3122dd66f7d8.png)


The separate window doesn't save with cmd+s (can still see the modified indication on top (circle icon/symbol)

Environment
Sublime Build: 4112
Operating system and version: macOS 11.4,


Discussion:
Created ST core issue for the root issue causing this: https://github.com/sublimehq/sublime_text/issues/4630
Closing because it seems to be a core issue. See https://github.com/sublimehq/sublime_text/issues/4630
I also encounter this annoying bug regularly. When it happens you either need to move the tab back to its original window, or save via the menu entry "File > Save".
Another workaround is to disable the Code-Actions-On-Save via a user keybinding:

```json
[
    { "keys": ["primary+s"], "command": "save", "args": {"async": true}, "context": [{"key": "lsp.session_with_capability", "operator": "equal", "operand": "textDocumentSync.willSave | textDocumentSync.willSaveWaitUntil | codeActionProvider.codeActionKinds | documentFormattingProvider | documentRangeFormattingProvider"}] },
]
```

Even if the actual cause is a ST bug, I wouldn't close and ignore this issue here, and argue that the `lsp_save` command should not be used in the way as it is now, until the upstream bug gets fixed. So I would even suggest to comment out the `lsp_save` keybinding by default and let users enable it "at their own risk". Or maybe might there be another way to circumvent the upstream bug to make it work without this issue?


Resolving patch:
diff --git a/plugin/save_command.py b/plugin/save_command.py
--- a/plugin/save_command.py
+++ b/plugin/save_command.py
@@ -1,6 +1,6 @@
 from .core.registry import LspTextCommand
 from .core.settings import userprefs
-from .core.typing import Callable, List, Type
+from .core.typing import Callable, List, Optional, Type
 from abc import ABCMeta, abstractmethod
 import sublime
 import sublime_plugin
@@ -90,6 +90,15 @@ def run(self, edit: sublime.Edit) -> None:
         else:
             self._trigger_native_save()
 
+    def is_enabled(self, event: Optional[dict] = None, point: Optional[int] = None) -> bool:
+        # Workaround to ensure that the command will run, even if a view was dragged out to a new window,
+        # see https://github.com/sublimelsp/LSP/issues/1791.
+        # The check to determine whether the keybinding for lsp_save is applicable already happens in
+        # DocumentSyncListener.on_query_context and should not be required here, if lsp_save is only used for the
+        # keybinding. A proper fix should ensure that LspTextCommand.is_enabled returns the correct value even for
+        # dragged out views and that LSP keeps working as expected.
+        return True
+
     def _trigger_on_pre_save_async(self) -> None:
         # Supermassive hack that will go away later.
         listeners = sublime_plugin.view_event_listeners.get(self.view.id(), [])


Test patch: