| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
| |
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
|
| |
|
|
| |
module import
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
capabilities #1889
Previously, vim.lsp.protocol.make_client_capabilities() was used if no
capabilities were specified in either the user-provided config or the
default config (base or server).
Now, the base default config table has a capabilities key with the value
of make_client_capabilities(). When creating the finalized configuration
for a server, it simply uses the finalized config which is the
user-provided config deep extended by the default config (which now
contains the default capabilities).
This means that users will no longer have to create their own customized
capabilities tables seeded from
vim.lsp.protocol.make_client_capabilities(). They simply need to create
the parts that are new or different from the defaults and pass that as
the capabilities. The rest of the defaults are filled in automatically.
For this to work properly, some tbl_extend calls were changed to
tbl_deep_extend. tbl_extend will not recursively update nested tables,
so using it wipes out any server provided defaults in nested config keys
(such as capabilities) and won't properly fill in the "rest" of the
capabilities if the user provided a smaller capabilities key in their
config.
Changing to tbl_deep_extend ensures server-specific configuration values
are preserved and that the finalized config at least contains defaults
for all client-supported capabilities.
For example, clangd's config default has:
```
local default_capabilities = {
textDocument = {
completion = {
editsNearCursor = true,
},
},
offsetEncoding = { 'utf-8', 'utf-16' },
}
```
Prior to this commit, this was the full
vim.lsp.protocol.make_client_capabilities() extended with those extra
values. However, if a user provided their _own_ capabilities to the
setup() function, tbl_extend wiped these extra values out and replaced
it with the users' capabilities, which was likely only
vim.lsp.protocol.make_client_capabilities() with some _other_ tweaks.
Now, clangd can simply provide the extras, and the setup() function will
normalize the config with all of user-provided, server-specific, and
base default capabilities.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ocamllsp: add dune as supported language
ocaml-lsp-server-1.11.3 enables 'dune' rpc integration
(you need a running `dune build --watch` command which provides the RPC
server).
This allows to reformat `dune` files, and to see `dune` and other build
errors as soon as you change a file (e.g. quite useful on newly created
files which would otherwise show an LSP error until first build).
Signed-off-by: Edwin Török <edwin@etorok.net>
* ocamllsp: dune-project and dune-workspace also mark roots
Although most dune projects will also have a *.opam file,
this file might be generated by the build system.
Newer versions of dune have a dune-project file to mark the root though,
and users can create a dune-workspace file as well.
Note that `dune` files themselves do NOT mark the root: they can be
present in subdirs too.
The rules on how `dune` itself finds the root are documented here:
https://dune.readthedocs.io/en/stable/usage.html#finding-the-root
"The root of the current workspace is determined by looking up a
dune-workspace or dune-project file in the current directory and its
parent directories. Dune requires at least one of these two files to
operate."
Signed-off-by: Edwin Török <edwin@etorok.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Even though this file name was removed from the official docs
https://eslint.org/docs/user-guide/configuring/configuration-files#configuration-file-formats
Eslint still supports the older `.eslintrc` and it is used in tests
https://github.com/eslint/eslint/blob/9ecd42f36462331a0d697e74323a4d24f0cf02fc/tests/fixtures/.eslintrc
The loading is done by the legacy package `@eslint/eslintrc` that is
still used by eslint itself
```
~/Documents/repositories/eslint
$ npm instll && rg '".eslintrc"' ./node_modules/@eslint/eslintrc/lib -B 6
./node_modules/@eslint/eslintrc/lib/config-array-factory.js
66-const configFilenames = [
67- ".eslintrc.js",
68- ".eslintrc.cjs",
69- ".eslintrc.yaml",
70- ".eslintrc.yml",
71- ".eslintrc.json",
72: ".eslintrc",
```
|
| | |
|
| |
|
| |
The option docs have been moved to a new page.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
