If the original document is same as the formatted one, there's no need to send the unchanged
document's content back which will make the client confused.
Signed-off-by: Tw <tw19881113@gmail.com>
Responding to an unimplemented notification can cause errors for some
LSP clients that do not expect to receive a response after sending a
notification. Differentiate between unimplemented requests and
notifications and only send a generic null response for the former while
silently ignoring the latter.
Questions:
- `getDocumentSymbolsInternal`: from looking at the code + cross referencing VSCode Api, looks like its just used to enumerate document symbols
(call tree: `documentSymbol()->getDocumentSymbols()->getDocumentSymbolsInternal()`)
- sanity check: are there any other places this modification needs to be propogated?
- sanity check: specifically so that symbol resolve/rename/goto def/etc aren't broken?
- error handling: unsure what the pre/post conditions are of the parse tree when `getDocumentSymbolsInternal` is invoked
so there might be superflous guards/checks
- any tests to add?
We now require the following to ge given in the cli args:
- zig_exe
- build_root
- cache_root
- global_cache_root
This fixes the path for packages that use one or more from the above to place
their files.
Currently in the log function in main, the notification method used to send logs to the client is "window/showMessage". This creates an a notification on the UI on VSCode that can cause slow downs. I propose a change to use the "window/logMessage" method instead, which is intended to be used for logging.
"selector" is now the preferred method of configuration, everything else was deprecated in SublimeLSP 4070-1.1.0: https://github.com/sublimelsp/LSP/releases/tag/4070-1.1.0
Also syncs setup.zig with the readme for the Sublime Text 3 settings (the Zig Language package name was wrong in setup.zig)
Removes the use of the notice log level.
Cleans up resulting code, the if else statement with nested switches was
converted into a single switch statement with the same behaviour, but
without relying on the enumToInt builtin.
