| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
| |
* 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`
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
There are stable releases of OCaml-LSP in the the Opam package manager now, it no longer has to be pinned from Git.
|
| |
|
|
|
|
|
|
|
|
|
| |
Since [1] it is now mandatory to provide the '-cli' and '-clangd' flags
as their default values were removed. It is no longer possible to start
the server without these.
The '-fqbn' flag was also missing from the lspconfig docs, and per my
own testing and previous investigations [2] it is also a mandatory flag.
[1] https://github.com/arduino/arduino-language-server/commit/387a275a243e205ffe3da8400f5cbf5ecc6fa167
[2] https://github.com/williamboman/nvim-lsp-installer/blob/main/lua/nvim-lsp-installer/servers/arduino_language_server/README.md#necessary-extra-configuration
|
| | |
|
| |
|
|
| |
compile_commands.json (#1961)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- Updates link to the metals website
- Removes the instructions about manual bootstrapping
I removed these instructions because with `cs install metals` there is
no reason to manually bootstrap it, we actually discourage it.
Especially now that we are on a new Scala version (2.13), the old
instructions including Scala 2.12 will fail. When using `cs install`,
all of this is just handled for you.
`nvim-metals` is still the path we recommend for any metals users.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
- The docs are verbose.
- The "settings" param is not really clarified anywhere.
Solution:
- Mention the "settings" param in the README.
- Tighten up the wording.
- Remove the "Use a loop to conveniently call 'setup'..." advice in the
docs. It confuses users and doesn't really save much code.
- Start to reduce the scope of nvim-lspconfig.
- For example, it is redundant for it to document general LSP things.
Thus, the help section *lspconfig-lsp* was removed.
closes #1951
|
