| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This updates the buf_ls command post v1.59.0, where the command was
promoted out of beta to general availability. The command was changed
from buf beta lsp to buf lsp serve.
|
| |
|
|
|
|
| |
This removes bufls entirely. The was a prototype from years ago that was
never finised: https://github.com/bufbuild/buf-language-server was
archived.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
ocamlls was added at #76.
It was because ocaml-lsp-server, which is official one, was too young.
In 2025, the official one works fine. On the other hand, unofficial
ocaml-language-server is not maintaned. We can no longer access its
GitHub repository.
Issue: #4115
|
| |
|
|
|
|
|
| |
Problem:
`buf_change_env` uses `vim.ui.input` but the input prompt value is never used for `client:exec_cmd` (due to async).
Solution:
Call `client:exec_cmd` in `vim.ui.input`.
|
| | |
|
| |
|
|
|
| |
The GitHub repository has changed owners. The old URL redirects to the
new repository but updating it makes it clearer which project is
referenced by the documentation.
|
| | |
|
| |
|
|
|
| |
* feat(ast_grep): update the filetypes
* revert: revert changes in side `lus/lspconfig/config` as deprecated
|
| |
|
| |
Co-authored-by: Gautham Venkataraman <gautham@dexterenergy.ai>
|
| |
|
|
|
|
|
|
| |
The root dir is already pre-resolved when the config is being passed
(when changing the code originally i looked and used wrong config type
so i missed this). So use the pre-resolved value instead of
resolving it again.
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- https://github.com/eclipse-jdtls/eclipse.jdt.ls?tab=readme-ov-file#running-from-the-command-line:
`-data` dir needs to be project-local and not shared. override cmd with
function. also use stdpath.cache like other lsp servers already do
- https://github.com/eclipse-jdtls/eclipse.jdt.ls/wiki/Running-the-JAVA-LS-server-from-the-command-line#initialize-request
`jvm_args`, `workspace`, `os_config` are not part of jdtls init_options
- https://github.com/eclipse-jdtls/eclipse.jdt.ls/blob/dbe1db974e9b4b472b8b1063fe7e5e7fc2a1fb7f/org.eclipse.jdt.ls.product/scripts/jdtls.py#L102
jdtls already sets correct shared configuration path, `-configuration`
is not needed (and it is os-specific value so current config is wrong)
Closes #4103
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using git directory as last resort before defaulting to pom.xml is
important for multi module maven projects. Example of structure:
pom.xml
submodule-a/pom.xml
submodule-b/pom.xml
If sumbodule-b depends on submodule-a (common pattern for dto/impl), the
parent usually has info about linking the 2 projects (and without that
go to definition etc will jump to compiled source that might not be
present/up t date).
This structure is also fine and do not breaks jdtls:
my-project/pom.xml
e.g its fine if working directory is git repo root (and this pattern is
also much less common than multi module maven projects that without this
change break always).
Closes #4102
Signed-off-by: Tomas Slusny <slusnucky@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
Problem: When running from a directory other than root (i.e monorepo),
ruby-lsp does not load correctly. Unsure why, previous lspconfig had
cmd_cwd set to the same as root_dir.
Solution:
Set the cmd_cwd via reuse_client(), similar to ast_grep. See #3850, #4082 for more details.
Tested both from root_dir and monorepo multi-root project.
|
| |
|
|
|
| |
This drops the dependency on the deprecated `lspconfig.util`.
Signed-off-by: Edwin Török <edwin@etorok.net>
|
| | |
|
| | |
|
| |
|
| |
Co-authored-by: Benedict Christian Smit <benedict.smit@tu-dortmund.de>
|
| |
|
|
| |
Although not common, the associated LSP (foam_ls) can handle single files just fine.
Fallback to git root, or the file's folder.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Reverts 33e318a3f0e729fb7ee82619a21172712b0ea288 (except for svelte).
fix #4074
close #4076
|
| | |
|
| |
|
|
|
|
|
|
| |
Remove custom handlers and version fix for WorkspaceEdit, as jdtls now
conforms to the LSP spec (eclipse-jdtls/eclipse.jdt.ls#1742)
See eclipse-jdtls/eclipse.jdt.ls#1695 for more background on why the
workaround was introduced. The original problem was fixed in the upstream
LSP server four years ago: remove the workaround.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
The nonstandard progress handler was added in #2153 but it can cause
some undesirable side-effects out of box ("press enter").
The original bug (mfussenegger/nvim-jdtls#327) was fixed upstream in the
language server three years ago (eclipse-jdtls/eclipse.jdt.ls#2258).
Solution:
Remove the workaround. Standard progress works.
|
| |
|
|
|
|
|
|
| |
Problem:
Some projects don't have a lockfile.
Solution:
- Fallback to ".git" as a lower-priority root-marker (Nvim 0.11.3+).
- Fallback to CWD.
|
| | |
|
| |
|
|
|
| |
* feat(zk): implement the zk.tag.list command
* refactor(zk): use workspace_required config to disable single file support
* fix(zk): remove tbl_map to avoid possible order issue
|
| |
|
|
|
|
|
|
| |
**Problem:** The built-in query linter will cause duplicate diagnostics
when running the query LSP. It is also slower and blocking, and can
cause jarring editor freezes for short times.
**Solution:** Disable it when using `ts_query_ls`. Also, set the
omnifunc to the LSP omnifunc rather than the custom `query` one.
|
| |
|
|
| |
This handler was removed a long time ago and was replaced with another handler that is already implemented here:
https://github.com/dotnet/vscode-csharp/commit/9cc41f6d2535a5cb5533dc5ae8f3a10ade16e7b5
|
| | |
|
| | |
|
| |
|
|
|
| |
Copy the approach from `lsp/elixirls.lua` to support monorepos.
fix #4052
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem:
- Diagnostics were only refreshed for the current buffer, not all buffers
managed by the client. In multi-file C# projects, this left diagnostics
stale unless the user switched buffers.
- Roslyn did not handle override method completion correctly.
Solution:
- Added `roslyn.client.completionComplexEdit` handler to apply edits for
override completions.
- Added `refresh_diagnostics` function, called on project initialization
and on `BufWritePost` / `InsertLeave` events, to proactively pull
diagnostics for all client buffers.
Rationale:
- Roslyn LSP primarily uses pull-based diagnostics. Neovim currently
only triggers diagnostic pulls on text changes in the active buffer.
This makes `debounce_text_changes` insufficient for Roslyn, as changes
in one file can affect diagnostics across the entire solution.
- The autocmds act as a server-specific workaround to mimic an
“on-save/on-idle” pull model.
|
| |
|
|
|
|
|
|
| |
Problem:
`deno.lock` is not recognized as a root marker in JavaScript related
servers.
Solution:
Add `deno.lock` as a root marker.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/lttb/gh-actions-language-server/issues/5
Implement a custom handler for the "actions/readFile" request in the
gh_actions_ls config. This handler reads the requested file from disk and
returns its contents if the file is readable. This improves integration
with the GitHub Actions language server by supporting file content
requests.
Here is how the vscode github actions extension sets the handler:
https://github.com/github/vscode-github-actions/blob/main/src/workflow/languageServer.ts#L68
TODO:
We could also provide an implementation for populating the init_options
properly, docs currently suggest an empty table. For the lsp to work properly,
it should be populated with this "shape":
init_options = {
sessionToken = session_token,
repos = {
{
id = 1008200293,
owner = org_name,
name = repo_name,
workspaceUri = "file://" .. vim.fn.getcwd(),
organizationOwned = true,
},
},
},
|
| | |
|
| |
|
|
|
| |
`vim.api.nvim_buf_create_user_command` callback is called with a table
argument that contains a parsed command. Need to use `args` or `fargs`
key to get command arguments.
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
The `pyright.organizeimports` is private, so client:exec_cmd()
fails because it refuses to run commands that are not advertised
as capabilities.
Solution:
Call client.request() to side-step the check in client:exec_cmd().
YOLO
|
| | |
|
| | |
|
| |
|
|
| |
Current code will always trigger error (unless you are already authd),
because result.code is invalid. result.userCode must be used instead.
|
| | |
|
| | |
|
| | |
|
| | |
|