| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
| |
* fix: add vim.deprecrate in old function
* fix: typo
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I found the root cause of denols problems:
https://github.com/neovim/neovim/pull/19797
With that pr applied (and with this revert) denols works perfectly
almost identical to vscode deno, its missing some features but I imagine
those are out of scope for lspconfig.
Problems will reappear until nvim fixes:
https://github.com/neovim/nvim-lspconfig/issues/1998
This is an ok tradeoff because `single_file_support=true`
causes other issues:
https://github.com/neovim/nvim-lspconfig/issues/2069
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
* switch to lua api for autocommands
* switch to nvim_create_user_command
* move to lua plugin initialization
NOTICE: Defining commands in server configurations will be deprecated in
future releases.
See `:help lspconfig.txt` to setup the same in an `on_attach` function.
Co-authored-by: Michael Lingelbach <m.j.lbach@gmail.com>
|
| | |
|
| | |
|
| |
|
|
|
| |
* test: add failing test
* fix(lspconfig): only consider servers that have been set up as available
|
| | |
|
| |
|
| |
Co-authored-by: komer <hyluo.1999@qq.com>
|
| |\
| |
| | |
feat(csharp_ls): add '*.fsproj' to root_dir
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Full disclaimer: I have not done any F# development myself.
This is based on the project file configuration found in the LSP server
implementation itself [1].
[1]: https://github.com/razzmatazz/csharp-language-server/blob/d887595f29af334aa2900381f5336644d9ce5e61/src/CSharpLanguageServer/RoslynHelpers.fs#L550-L554
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
| |
* feat: add qml-lsp support
* fix(qml-lsp): update qml-lsp formatting
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Signed-off-by: Marcos Lilljedahl <marcosnils@gmail.com>
|
| | |
|
| |
|
| |
See #1116, #1880, #1951, etc.
|
| | |
|
| |
|
|
|
|
|
|
| |
We no longer publish the lemminx binaries to download.jboss.org as a part of our
release process for vscode-xml, so the binaries for the latest releases of
lemminx are not there. However, they are available on the [vscode-xml
GitHub](https://github.com/redhat-developer/vscode-xml), under releases.
Signed-off-by: David Thompson <davthomp@redhat.com>
|
| | |
|
| |
|
|
|
|
| |
sourcery configuration requires 'lspconfig/util', where everything else
uses 'lspconfig.util'.
Co-authored-by: ii14 <ii14@users.noreply.github.com>
|
| |
|
|
|
| |
Sometimes simple LaTeX documents are detected as plaintex rather than
tex, meaning texlab will not be applied without a manual change of
filetype.
|
| |
|
|
| |
For information on filetypes supported by emmet-ls, see:
https://github.com/aca/emmet-ls#supported-filetypes
|
| | |
|
| | |
|
| |
|
|
|
| |
These have primarily been sourced from the VSCode extension [1].
[1] https://github.com/OmniSharp/omnisharp-vscode/blob/88ad237e1e904ad0f91d2de39c30132198a02dcb/src/omnisharp/server.ts#L345-L434
|
| |
|
|
|
|
|
|
| |
Problem:
In haskell multi-package projects there is *.cabal file in every package folder,
so util.root_pattern always find root of the package but not project.
Solution:
Adjust the condition.
|
| |
|
|
|
|
| |
- remove unneeded lsp attach
- default to single_file_support=true
fix https://github.com/neovim/nvim-lspconfig/issues/1998
|
| |
|
|
| |
Caching actually works but it throws an error, vscode-deno also doesn't seem to care about errors
https://github.com/denoland/vscode_deno/blob/196a11cead2d95c324cb772dd568ba7c2801b68a/client/src/commands.ts#L60
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If you open a file and immediately try to go to definition this error happens:
```
{["error"]={["message"]="Method not found: deno/virtualTextDocument",["code"]="-32601"}}
{["error"]={["message"]="Method not found: deno/virtualTextDocument",["code"]="-32601"}}
{["error"]={["code"]="-32601",["message"]="Method not found: deno/virtualTextDocument"}}
{["error"]={["code"]="-32601",["message"]="Method not found: deno/virtualTextDocument"}}
```
Seems to be a race condition where the virtual text handling is not ready yet.
Because this error is unhelpful and the gotodefinition works normally after
a couple of seconds, just ignore it.
|
| | |
|
| |
|
| |
https://github.com/JohnnyMorganz/StyLua#finding-the-configuration
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
```console
$ selene .
warning[unused_variable]: buf_client_names is assigned a value, but never used
┌─ lua/lspconfig/ui/lspinfo.lua:160:9
│
160 │ local buf_client_names = {}
│ ^^^^^^^^^^^^^^^^
161 │ for _, client in pairs(buf_clients) do
162 │ table.insert(buf_client_names, client.name)
│ ---------------- `table.insert` only writes to `buf_client_names`
warning[unused_variable]: client_names is assigned a value, but never used
┌─ lua/lspconfig/ui/lspinfo.lua:171:9
│
171 │ local client_names = {}
│ ^^^^^^^^^^^^
·
176 │ table.insert(client_names, client.name)
│ ------------ `table.insert` only writes to `client_names`
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
gradle-language-server doesn't work well without some kind of
`init_options.settings` parameters. There's some important stuff in:
https://github.com/microsoft/vscode-gradle/blob/a0151761aa2a6a07b64ced0dda5f6e9f01e77fd9/gradle-language-server/src/main/java/com/microsoft/gradle/GradleServices.java#L162-L169
that won't get called unless `init_options.settings` is at least defined. In
particular if `settings == null`, gradleWrapperEnabled will be `null` as well
and
https://github.com/microsoft/vscode-gradle/blob/a0151761aa2a6a07b64ced0dda5f6e9f01e77fd9/gradle-language-server/src/main/java/com/microsoft/gradle/resolver/GradleLibraryResolver.java#L106
`libFolder` won't be resolved.
Solution:
Set `init_options.settings.gradleWrapperEnabled=true` because it's a sensible
default, then `init_options.settings` isn't empty.
|
| |
|
|
|
|
|
| |
https://yarnpkg.com/features/pnp
Yarn's PnP feature changes the way packages are installed. Instead of building on the `node_modules` resolution, it introduces a single `.pnp.*js` file in the project. This file is responsible for orchestrating and resolving dependencies. The eslint LSP server will assume that regular `node_modules` resolution applies when locating the `eslint` package - which will not work in Yarn PnP projects.
To work around this, Yarn provides the ability to run Node programs in "PnP-compat" mode via `yarn exec` and `yarn node`. My understanding is that this simply hooks into the `require()` function to resolve modules via PnP instead Node's builtin module resolution.
|
| |
|
| |
The `vim.fn.expand '%:p:h'` used to acquire the directory of the opened buffer would actually be executed in the context of the floating `:LspInfo` - causing it to return the current working directory instead of the actual buffer directory (the one that was active when opening the `:LspInfo` window).
|
| | |
|
| | |
|
| |
|
| |
it should be fine for a project to have another `CMakeLists.txt`
|
| | |
|
| | |
|
| | |
|
