* Add vim.treesitter.start() for starting treesitter highlighting via
ftplugin or autocommand (can be extended later for fold, indent,
matchpairs, ...)
* Add vim.treesitter.stop() for manually stopping treesitter
highlighting
* Enable treesitter highlighting for Lua if
`vim.g.ts_highlight_lua = true` is set in `init.lua`
* vim-patch:9.0.0314: VDM files are not recognized
Problem: VDM files are not recognized.
Solution: Add patterns for VDM files. (Alessandro Pezzoni, closesvim/vim#11004)
bf26941f40
* vim-patch:9.0.0319: Godot shader files are not recognized
Problem: Godot shader files are not recognized.
Solution: Add patterns for "gdshader". (Maxim Kim, closesvim/vim#11006)
d5c8f11905
This removes the support for defining links via
vim.treesitter.highlighter.hl_map (never documented, but plugins did
anyway), or the uppercase-only `@FooGroup.Bar` to `FooGroup` rule.
The fallback is now strictly `@foo.bar.lang` to `@foo.bar` to `@foo`,
and casing is irrelevant (as it already was outside of treesitter)
For compatibility, define default links to builting syntax groups
as defined by pre-existing color schemes
The private 'get_node_range' function from the languagetree module has
been renamed and remains private as it serve a purpose that is only
relevant inside the languagetree module.
The 'get_node_range' upstreamed from nvim-treesitter in the treesitter
module has been made public as it is in itself a utlity function.
As part of the upstream of utility functions from nvim-treesitter, this
option when set to false allows to return a table (downstream behavior).
Effectively making the switch from the downstream to the upstream
function much easier.
fix(filetype): only pass first 100 and last lines to contents check
sufficient for current content checks and avoids performance issues for
buffers with a large number of lines
fixes#19817
This starts a soft phase-out of `buf_request`.
`buf_request` is quite error prone:
- Positional `params` depend on the client because of the
`offset_encoding`. Currently if there is one client using UTF-8 offset
encoding and another using UTF-16, the positions in the request are
wrong for one of the clients. To solve this the params would need to
be created per client instead of once for all of them.
- `handler` is called *per* client but many users of it assume it is
only called once.
This can lead to a "select n + 1"
kind of problem, where the handler makes another call to `buf_request`,
multiplying the amount of requests.
(There are in fact still some places where this happens in core)
Or it leads to erratic behavior if called multiple times (E.g. the
quicklist list flickering & being overwritten)
(See hover or references implementation)
`buf_request_all` returns an aggregate of the responses which is more
sensible as it avoids this problem.
For off-spec extensions it also has the problem that it sends requests to
clients which cannot handle a given request.
Given that `buf_request` is in use by a lot of plugins this starts a
soft-phase out. Planned Steps:
- Remove from docs
- Provide an alternative, either `buf_request_all`, maybe with
extensions (params being a function), or an entirely new method.
- Mark as deprecated in 0.9
- Remove in 0.10
To note:
- `buf_request_all` currently isn't ideal either because it suffers from
the `params` problem as well.
- This implies that the `vim.lsp.with` pattern will die, because the
global handlers as they are don't fit a multi-client model, as most of
the time an aggregate is needed.
`server_capabilities` can be nil until the server is initialized.
Reproduced with:
vim.lsp.stop_client(vim.lsp.start_client {
cmd = { vim.v.progpath, '-es', '-u', 'NONE', '--headless' };
})
The change tracking used a single lines/lines_tmp table to track
changes to a buffer.
If multiple clients using incremental sync are connected to a buffer,
they both made changes to the same lines table. That resulted in an
inconsistent state.
This commit changes the didChange handling to group clients by
synchronization scheme and offset encoding.
This avoids computing the diff multiple times for clients using the
same scheme and resolves the lines/lines_tmp conflicts.
Fixes https://github.com/neovim/neovim/issues/19325
based on http://www.vim.org/scripts/script.php?script_id=1291
reformatted to match Nvim documentation style; removed irrelevant sections
Co-authored-by: dundargoc <gocundar@gmail.com>
Co-authored-by: Christian Clason <c.clason@uni-graz.at>
Co-authored-by: Lewis Russell <lewis6991@gmail.com>
The lsp client used to wait up to 500ms for a language server to
shutdown before sending a TERM signal.
The intention behind the 500ms grace period was to ensure the language
server exits to prevent stale processes, but it has the side-effect that
it can interrupt language-servers which are too slow to shutdown within
500ms. Language servers tend to write out index files or project files
on shutdown, and being interrupted during this process can cause
corruption of those files.
This changes the default to not wait at all, at the risk of leaving
stale processes around if the language server isn't well behaved.
An alternative would be to wait indefinitely, but that can cause neovim
to take several seconds to exit.
`:saveas newName` changes the name of an existing buffer.
Due to the buffer re-use it skips the lsp attach phase and immediately
sends a `didSave` notification to the server.
Servers get confused about this, because they expect a `didOpen`
notification first.
Closes https://github.com/neovim/neovim/issues/18688
`code_action` gained extra functions (`filter` and `apply`) which
`range_code_action` didn't have.
To close this gap, this adds a `range` option to `code_action` and
deprecates `range_code_action`.
The option defaults to the current selection if in visual mode.
This allows users to setup a mapping like `vim.keymap.set({'v', 'n'},
'<a-CR>', vim.lsp.buf.code_action)`
`range_code_action` used to use the `<` and `>` markers to get the
_last_ selection which required using a `<Esc><Cmd>lua
vim.lsp.buf.range_code_action()<CR>` (note the `<ESC>`) mapping.
Without some form of feedback a user cannot easily tell if the server is
still computing the result (which can take a while in large projects),
or whether the server couldn't compute the rename result.
