| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As seen in the source code:
https://github.com/nwolverson/purescript-language-server/blob/db5584d79e698b02e3df12a1299d5f93262bd5ee/src/LanguageServer/IdePurescript/Main.purs#L391
Nix-related files were added to the Language server to establish the
root. This commit looks to mimic that behavior. The PureScript community
has a lot of Nix-positive users and tooling.
Additionally the docs were updated::
* Reflect the new `root_dir` + `root_pattern` list
* Include a list of ways to install the language server to your project
* Remove the specific, problematic npm install command because
** Globally installing these tools is a bad practice as teams should
maintain consistent versions in their projects and users are less
likely to remember to upgrade global packages; new documentation
suggests to add it to your project, but it doesn’t _not_ say to
install it globally if desired
** npm is _not_ the only JavaScript package manager
** JavaScript package managers are not the only way to get the language
server
** Unrelated but technically incorrect: the block was labeled as a shell
script despite it being a shell session (code block syntax `sh`
should be `console`)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Zeta-Note was retired. Marksman is a successor to the original project, but now
instead of being a "**Zettelkasten LSP** that happened to be in Markdown" it's a
"**Markdown LSP** that *also* supports Zettelkasten-like note-taking'.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Explicitly pass `--protocol=lsp` to the Dart LSP server.
Fixes #1942
Works around upstream issue dart-lang/sdk#49157
|
| | |
|
| |
|
|
|
|
|
| |
The no-argument versions of `:LspStop` and `:LspRestart` currently only apply to
buffers that have a valid root directory. It seems that these commands should stop/restart
all clients, including those associated with standalone files.
Closes #1784
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Linting is now enabled by default https://deno.com/blog/v1.22#linting-enabled-by-default-in-the-lsp
so it should not be turned off in these settings
- `tsconfig` is an outdated way to make any config changes in Deno and should not be used:
https://deno.land/manual/typescript/configuration#configuring-typescript-in-deno
> ⚠️ Deno v1.14 started supporting a more general configuration file that is no
> longer confined to specifying TypeScript compiler settings. Using
> tsconfig.json as a file name will still work, but we recommend to use
> deno.json or deno.jsonc
@jason0x43 agreed in the previous thread:
https://github.com/neovim/nvim-lspconfig/pull/1321#issuecomment-1024191242
> Currently, deno only looks for deno.json, deno.jsonc, tsconfig.json, or .git
> to determine the root. I think dropping tsconfig.json makes sense because Deno
> now has it's own preferred config file name. Having .git seems reasonable
> enough because projects will often be in git repos. I could even see enabling
> single_file mode by default for the Deno LS since making simple CLI tools is
> (theoretically) a standard use case.
If this pull request is accepted then the docs can also be simplified:
https://deno.land/manual/getting_started/setup_your_environment#neovim-06-and-nvim-lspconfig
|
| |
|
| |
on_attach is a nontrivial callback so it makes sense to check the bufnr.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two ways for sumneko to search for files, namely:
1. Lua.runtime.path
When using `require`, how to find the file based on the input name.
Setting this config to `?/init.lua` means that when you enter `require
'myfile'`, `${workspace}/myfile/init.lua` will be searched from the
loaded files. if `runtime.pathStrict` is `false`,
`${workspace}/**/myfile/init.lua` will also be searched.
If you want to load files outside the workspace, you need to set
`Lua.workspace.library` first.
2. Lua.workspace.library
In addition to the current workspace, which directories will load files
from. The files in these directories will be treated as externally
provided code libraries, and some features (such as renaming fields)
will not modify these files.
The crucial point is that `Lua.runtime.path` only applies to
the *current* workspace. Thus it makes no sense to add any absolute
directories here. Absolute directories must be added to
workspace.library, which is already the case. The default value provided
by sumneko is what you typically would expect, so we can just stick to it.
References:
- github.com/sumneko/lua-language-server/blob/076dd3e5c4e03f9cef0c57/locale/en-us/setting.lua#L5-L13
- github.com/sumneko/lua-language-server/blob/e62d964ff57cc0b37eb90831/script/config/config.lua#L151
|
| |
|
|
|
|
|
|
|
| |
* fix(beancount): fix beancount start command and config
* fix: update beancount config
* fix: add single_file_support back
* fix: fix lint
|
| | |
|
| |
|
|
|
|
|
| |
Dart supports a much simpler way of invoking the language server:
`dart language-server`. See
https://github.com/dart-lang/sdk/tree/master/pkg/analysis_server/tool/lsp_spec#running-the-server
Signed-off-by: Gavin Zhao <git@gzgz.dev>
|
| | |
|
| |
|
|
|
|
| |
Sourced from the @glint/config package README[1]
[1]: https://github.com/typed-ember/glint/blob/main/packages/config/README.md#config-specification
|
