Problem:
win_line() falls into infinite loop when a diff window has top filler
above its first visible buffer line, that first visible buffer line is a
closed fold, and the folded line uses normal non-empty foldtext.
Solution:
Allow flushing pending diff filler rows even when the underlying buffer
line is folded with foldtext.
AI-assisted: Codex
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem:
`api.nvim_buf_del_mark` already emits a `MarkSet` event with `col` and `line` set to 0. However, `:delmarks` currently emits no events.
Solution:
Change `:delmarks` to emit the same `col==line==0` event.
Problem: Vim9: return value of winrestcmd() cannot be executed.
Solution: Put colons before each range. (closesvim/vim#7571)
285b15fce1
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
Codelens virtual lines remain on stale rows after an external file
change and buffer reload.
Solution:
Clear codelens extmarks and cached row/version state in `on_reload`
before requesting fresh code lenses.
Problem: completionItem/resolve response's `detail` field is silently
dropped. Only `documentation` is shown in the popup.
Solution: Prepend `detail` as a fenced code block before `documentation`
in the info popup, skipping if documentation already contains it.
Problem:
After on_refresh() sends a textDocument/codeLens request, the buffer may
be deleted before the response arrives. The response callback then tries
to redraw that deleted buffer and raises Invalid buffer id error.
Solution:
Check buffer validity before redrawing.
AI-assisted: Codex
Co-authored-by: Yi Ming <ofseed@foxmail.com>
Problem:
No LuaLS types for event-data fields (ev.data). Types are only
documented ad hoc in scattered locations.
Solution:
Add runtime/lua/vim/_meta/events.lua defining vim.event.<name>.data
classes for events that provide ev.data. Reference the types from
each event's help in autocmd.txt, lsp.txt, and pack.txt.
Problem: Using `buf=0`/`win=0` context in `vim._with` should be
equivalent to using explicit buffer/window identifier respectively.
Solution: Explicitly adjust context in case of `buf=0` or `win=0`.
Problem:
Too much boilerplate needed to use Lua to impl an excmd or f_xx
function.
Solution:
- Add `nlua_call_vimfn` which takes the args typval, executes
Lua, and returns a typval.
- refactor(excmd): lua impl for :log, :lsp
Problem: Marks are not adjusted unloading a buffer that doesn't exist
on disk. E.g. extmarks are still valid (and will be beyond the
end of the buffer if the buffer is reloaded), even though the
text is lost.
Solution: Adjust marks for a cleared buffer when unloading a buffer that
doesn't exist on disk.
Problem: Calling `vim.filetype.match({ filename = '...', buf = ... })`
during startup results in an error due to not yet defined
`g:ft_ignore_pat`.
Solution: Add a guard to check `g:ft_ignore_pat` related properties only
if the variable is defined. This also allows to simplify other tests
which did not depend on `g:ft_ignore_pat` but required it explicitly
set to work.
Problem: MS-Windows: If a directory with a single character name is
included in the PATH environment variable without a trailing
path separator, executable() will not be able to find the
executable file under it.
Solution: The second argument of the after_pathsep() function is now
passed the next pointer where a path separator may exist
(Muraoka Taro).
As a specific example, the default installation path for PowerShell v7
is "C:\Program Files\PowerShell\7", but if you set this as is in the
PATH environment variable, Vim will not be able to find the pwsh.exe
command. In this case, Vim will try to search for "C:\Program
Files\PowerShell\7pwsh.exe".
Cause: The after_pathsep() function determines whether the location
passed as its second argument immediately follows a path separator.
However, in the code where the problem occurred, the second argument was
passed a location that might contain a path separator. As a result, it
was mistakenly determined that a path separator was present in cases
where the final directory name was a single character and not followed
by a path separator, and the path to search was incorrect.
closes: vim/vim#18979bd686d85dc
Co-authored-by: Muraoka Taro <koron.kaoriya@gmail.com>
* fix(api): allow silencing "Too many highlight groups" error
Problem: Using Lua's `vim.api.nvim_set_hl(0, 'New', {...})` can fail if
there are too many existing highlight groups. However, this error can
not be silenced with `pcall`.
Solution: Make it possible to silence in `nvim_set_hl` and
`nvim_get_hl_id_by_name`.
* fix(lsp): limit number of groups created by `document_color()`
Problem: A file can contain many string colors that would be highlighted
by an LSP server. If this number crosses 19999 (maximum number of
allowed highlight groups), there are general issues with creating
other highlight groups, which can break functionality outside of
`vim.lsp.document_color`.
Solution: Limit number of highlight groups that are created by
`vim.lsp.document_color` to 10000 (half of allowed maximum).
This is not a 100% solution (since there can exist more than 10000
other highlight groups), but explicitly checking number of groups is
slow and 10000 should (hopefully) be enough for most use cases.
Added the fallowing.
djangoStatement:
- querystring: Added in version Django 5.2.
- lorem: Added in version Django 1.8.
- verbatim: Added in version Django 1.10.
djangoFilter:
- force_escape: Added in version Django 1.8.
- iriencode: Added in version Django 1.8.
- json_script: Added in version 2.1.
- truncatechars_html: Added in version 1.7.
> According to current documentation the added keywords are supported [Django version 6](https://docs.djangoproject.com/en/6.0/ref/templates/builtins).
related: vim/vim#199946b26afea3b
Co-authored-by: tecis <67809811+tecis@users.noreply.github.com>
Problem:
- Builtin "Vimscript" functions (f_xx) are mostly implemented in C.
Partly that's because there is some boilerplate required to call out
to Lua.
- Calls to `vim.fn.foo()` always marshall over the Lua <=> Vimscript
("typval") bridge, even if `fn.foo()` is implemented entirely in Lua:
```
Lua => typval => Object => Lua => Object => typval => Lua.
```
Solution:
Functions declared in eval.lua with `func_lua` are implemented in
entirely in Lua (`_core/vimfn.lua`).
- `gen_eval.lua` wires `func_lua` entries to `lua_wrapper`, which handles
the typval conversion for Vimscript callers (slow path).
- `nlua_call()` detects `func_lua` functions and calls the Lua
implementation directly. This eliminates all conversion overhead for
Lua callers (fast path).
- Validate at build-time that `func`, `func_float`, and `func_lua` are
mutually exclusive.
- Migrate `hostname()` as a toy example, to show the idea.
Problem:
`test/functional/plugin/lsp_spec.lua` had grown into a large catch-all file that mixed core LSP client lifecycle coverage, `vim.lsp.buf.*` behavior, and `vim.lsp.util.*` behavior in one place.
Solution:
Split the large tests into more focused test files without changing test coverage or intended behavior.
After this change, `lsp_spec.lua` is more focused on core LSP client/config/dynamic-registration behavior.
Problem: Documentation based on patches is outdated.
Solution: Add changes to documentation in a patch.
853886722c
Trailing space was removed in later patches.
Also fix a few more misplaced error numbers from #8155.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: - Paging keys in the dialog window consume input when the user
may not expect it. The dismissable title hint intended to
mitigate that results in having to press Escape twice to
abandon the prompt.
- Mimicked "msgsep" float border is taking up unnecessary
space when window takes up the entire screen.
Solution: - Use (conventional, albeit less convenient) keys intended
for scrolling to page the dialog window:
<(Mousewheel/Page)Up/Down>, <Home/End>.
- Only set the float top border when separation is actually
necessary, i.e. window does not reach the first row.
Problem:
Difficult for us to provide default handlers for functions like
`vim.lsp.buf.definition`. When users wanted to fine-tune the default behavior,
they don't know how.
Solution:
- Document an example providing `on_list` boilerplate to make it easier for
users to modify and override.
- Also, considering that the parameters of the previous
`on_list`(`vim.lsp.ListOpts.OnList`) are compatible with the parameters of
`setqflist`, remove that custom type in favor of passing
`vim.fn.setqflist.what`.
Problem:
`TSNode:id()` returns the underlying c pointer as a string, which may include
NUL bytes. In PUC Lua, `('%s'):format('\0a\0')` returns `''` and not `'\0a\0'`
(i.e. treats the string as a c-string (which terminates at the NUL byte)).
This resulted in two different nodes being able to have the same id.
Solution:
Use concatenation `..` instead of `string.format()`.
Problem:
- Choosing a new EXX error code is tedious.
- It's possible to accidentally use an EXX error code for different
purposes.
Solution:
Add a lint check which requires EXX error codes to have a :help tag.
This also avoids duplicates because `make doc` does `:helptags ++t doc`
which fails if duplicates are found.
Problem: Sometimes automatic lockfile synchronization after `:restart`
might fail, like due to bad/absent Internet connection. This would
remove failed to install entries from the lockfile (since they are not
on disk and lockfile is meant to lock the latest plugin version on
disk).
Solution: Document that this should be treated as an unwanted update and
use steps similar to "Revert plugin after an update" use case.
Problem: Using severity names (like "ERROR", "WARN") in functions like
`vim.diganostic.get()` and `vim.diagnostic.config()` is allowed and
tested for many years now. But documentation about it can be clearer.
Solution: Explicitly mention that severity names are allowed in some
situations. Ideally, it would also require updating typing for
`vim.diagnostic.SeverityFilter`, but that looks problematic to do
robustly.
Problem: Unreliable test on Windows which sometimes fails with too many
failed retries.
Solution: Increase timeout in hopes that it will be enough to make it
pass more frequently. This should not affect fast and already working
platforms.
Problem:
Naming conventions are not automatically checked.
Solution:
Add a check to the doc generator. Eventually we should extract this
somehow, but that will require refactoring the doc generator...
Note: this also checks non-public functions, basically anything that
passes through `gen_eval_files.lua` and `gen_vimdoc.lua`. And that's
a good thing.
Problem: When closing floating windows to close a tabpage, if the current
buffer will unload, buffers contained in those floating windows
will too (unexpectedly).
Solution: Don't pass along "free_buf" argument; check 'bufhidden' for
the buffer in the to be closed float.
