This commit changes the `offset!` directive so that instead of setting a
`metadata.range` value for the entire pattern, it will set a
`metadata.offset` value. This offset will be applied to the range only
in `vim.treesitter.get_range()`, rather than at directive application
time. This allows the offset to be applied to any and all nodes captured
by the given pattern, and removes the requirement that `#offset!` be
applied to only a single node.
The downside of this change is that plugins which read from
`metadata.range` may be thrown off course, but such plugins should
prefer `vim.treesitter.get_range()` when retrieving ranges anyway.
Note that `#trim!` still sets `metadata.range`, and
`vim.treesitter.get_range()` still reads from `metadata.range`, if it
exists.
Problem: 8defe1a declared the "more" window the most convenient place to
route messages to if it is already open for msg.pos == 'cmd'.
In usage, this doesn't appear to be the case. Appending messages
as added in that commit is still useful, but should only be done
for messages that spill 'cmdheight'.
Solution: Only append messages exceeding 'cmdheight' to the more window.
To do this, instead of immediately writing to the more buffer,
write to the cmd buffer and calculate its height. Then copy the
text and its highlights to the more buffer.
Replace direct function mappings with `<Plug>` mappings for cycling
through overloaded signatures, providing better customization options
for users. This change keeps the default mapping (`<C-s>`) for cycling
if `<Plug>(nvim.lsp.ctrl-s)` is not mapped.
Problem:
The cancel function returned by `vim.lsp.buf_request` tries to cancel
all the requests, including those that have already been completed,
causing "Cannot find request with id ... whilst attempting to cancel"
errors to be logged when it is called.
Solution:
Only cancel the requests that are present in `client.requests`.
Problem:
With these settings, copy/pasting `blockwise-visual` (with `CTRL+V`)
incorrectly pastes as a `linewise` mode because `regtype` is ignored:
vim.opt.clipboard = 'unnamedplus'
vim.g.clipboard = 'osc52'
To reproduce: press `CTRL+V` and select some characters press `p` and
observe that it is pasted in `linewise` mode.
Solution:
Enable the [clipboard.vim](https://github.com/neovim/neovim/blob/master/runtime/autoload/provider/clipboard.vim#L281-L283))
cache for function providers, so that `regtype` is maintained for the OSC52
clipboard provider.
Before this commit, I had trouble finding information about configuring
the insert mode completion. In particular, it was not clear that the
'wildopt' config that I already had in my vimrc does not apply here.
Also, `insert.txt` barely mentioned 'completeopt' except when
describing popups (I was more interested in bash-like behavior
where the unique prefix of all completions is completed first).
I'm hoping these edits will make the relevant docs easier to find.
closes: vim/vim#17515053aee01f7
Co-authored-by: Ilya Grigoriev <ilyagr@users.noreply.github.com>
Problem: A custom property containing a pair of square brackets will be
treated as a section.
Solution: Change the logic parsing a section, remove the first match
regex `%b[]`.
Signed-off-by: fortime <palfortime@gmail.com>
This commit also adds a type annotation to the returned client
capabilities table, because without it lua_ls does not provide
autocompletion for the fields within the table.
Limit heredoc matches to assignment statements. Matching these at the
top level is very slow.
closes: vim/vim#17473274efcc7e6
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: `exists()` checks should test for being equal to 1 rather than truthy, and extui check can be more restrictive.
Solution: Adjust `exists()` guards to equal 1 and use `matchparen#CursorMoved`.
Problem: Error occurs if window is invalid in the middle of parsing.
Solution: Check if window is valid in parsing.
- Error
```
vim.schedule callback: ...im/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:485: Invalid window id: 1037
stack traceback:
[C]: in function 'nvim__redraw'
...im/share/nvim/runtime/lua/vim/treesitter/highlighter.lua:485: in function 'cb'
...m/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:494: in function '_run_async_callbacks'
...m/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:550: in function <...m/share/nvim/runtime/lua/vim/treesitter/languagetree.lua:529>
```
- Reproduce script
```lua
local bufnr = vim.api.nvim_create_buf(false, true)
local many_lines = vim.fn["repeat"]({ "local test = 'a'" }, 100000)
vim.api.nvim_buf_set_lines(bufnr, 0, -1, false, many_lines)
local window = vim.api.nvim_open_win(bufnr, true, {
relative = "editor",
row = 0,
col = 0,
width = 10,
height = 10,
})
vim.bo.filetype = "lua"
vim.schedule(function()
vim.api.nvim_win_close(window, true)
end)
```
Before, only the last capture's range would be counted for injection.
Now all captured ranges will be counted in the ranges array. This is
more intuitive, and also provides a nice solution/alternative to the
"scoped injections" issue.
**Problem:** There is a lot of distracting highlight flickering when
editing a buffer with multiple open windows. This is because the
parsing/highlighting state is shared across all windows.
**Solution:** Greatly reduce flicker in window splits by scoping the
highlighter state object and the `parsing` state object to each
individual window, so there is no cross-window interference.
Problem: Current window is checked to determine whether "more" window
is open. Making it the current window is scheduled in case the
cmdwin is open so this can be too late.
"cmdline_hide" may be emitted when the topline is
temporarily invalid (after incsearch->restore_viewstate()).
Solution: Use the window visibility to determine an active "more"
window instead.
Don't nvim__redraw->flush the "cmdline_hide" event (a normal
will already happen).
