Apparently after parsing with options in tree-sitter, the options data
persists in the parser object, and thus successive calls to
`ts_parser_parse()` will act like `ts_parser_parse_with_options()`. This
is problematic because `languagetree.lua` makes coroutine-environment
assumptions based on if a nullptr has been returned by the parser
function. This commit makes it so that the parse options state is reset
upon a regular parse (would be nice if this was done upstream).
Fixes#33277
Problem:
executability check using `uv.fs_access`
doesn't work currently and can't work on windows
Solution:
only check for executable with `vim.fn.executable`
Problem: Computed previous buffer line count may be beyond end of
buffer. This results in signs being removed from `b_signcols`
that were never included in it, tripping an assertion.
Solution: Store the previous line count as it was before appending or
deleting lines. Use it to clamp the edited region when
clearing signs before a splice, after which it is reset.
Problem: Lines to/from which virt_lines or inline virt_text may have
moved are left valid. Similarly the modified region may be
too small to account for moved decorations after inserting
or deleting lines. `redrawOneLine()` can be replaced with
a call to `changed_lines_redraw_buf()`.
Solution: Invalidate the line after a change if there is virt_lines, or
inline virt_text in the buffer with 'wrap' enabled. Extend the
modified region for inserted or deleted lines if there may be
decorations in the buffer. Remove `redrawOneLine()`.
Simplify the logic for `changed_lines_invalidate_win()`.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem:
`vim.version.range('>=0.10'):has('0.12.0-dev')` returns false, which is
wrong per semver.
Solution:
`vim.VersionRange:has()` shouldn't have special handling for prereleases
(Why would we need it when `__eq`, `__lt`, `__le` already handle
prereleases?).
Closes#33316
Problem: tests: missing cleanup in test_filetype.vim, wrong name in
test_plugin_matchparen
Solution: Add :bwipe corresponding to :split, rename test case
closes: vim/vim#17088b0e19f9e1b
Problem: No type information for `vim.uv`.
Solution: Vendor https://github.com/LuaCATS/luv (which is what
luals bundles). This will allow other tooling to work out-of-the-box and
make these files available to users and plugins without the need for
`lazydev.nvim` etc.
Problem: tests: no test for matchparen plugin with WinScrolled event
Solution: add missing test
closes: vim/vim#1094296a0b2a6d5
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
- Help tags provide a good way to navigate the Vim documentation, but
many help documents don't use them effectively. I think one of the
reasons is that help writers have to look up help tags manually with
`:help` command, which is not very convenient.
- 'iskeyword' is only set for help buffers opened by `:help` command.
That means if I'm editing a help file, I cannot jump to tag in same
file using `Ctrl-]` unless I manually set it, which is annoying.
Solution:
- Add omni completion for Vim help tags.
- Set 'iskeyword' for `ft-help`
closes: vim/vim#170730b540c6f38
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
As checkhealth grows, it is increasingly hard to quickly glance through
the information.
Solution:
Show a summary of ok, warn, and error outputs per section.
Problem: Using wrong window in ll_resize_stack()
(after v9.1.1287)
Solution: Use "wp" instead of "curwin", even though they are always the
same value. Fix typos in documentation (zeertzjq).
closes: vim/vim#17080b71f1309a2
Problem:
Normally, `:drop +41 foo.txt` will open foo.txt with the cursor on line
41. But if foo.txt is already open, it instead is a no-op, even if the
cursor is on a different line.
Steps to reproduce:
nvim --clean foo.txt
:drop +30 foo.txt
Solution:
Handle +cmd in ex_drop().
Problem: Logic computing the new height of the modified area does not
take into account virtual lines attached to a folded line.
Solution: Remove `hasFolding()` branch and let `plines_win_full()` do its job.
Problem: If win_close() is called with a window that has quickfix stack
attached to it, the corresponding quickfix buffer will be
closed and freed after the buffer was already closed. At that
time curwin->w_buffer points to NULL, which the CHECK_CURBUF
will catch and abort if ABORT_ON_ERROR is defined
Solution: in wipe_qf_buffer() temporarily point curwin->w_buffer back to
curbuf, the window will be closed anyhow, so it shouldn't
matter that curbuf->b_nwindows isn't incremented.
closes: vim/vim#16993closes: vim/vim#16985ce80c59bfd
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem: Help files not detected when 'iskeyword' includes ":".
Solution: Do not use \< and \> in the pattern (zeertzjq).
fixes: vim/vim#17069closes: vim/vim#17071e370141bf4
Problem: An on_win-disabled decoration provider is left disabled for
the on_buf callback during the next redraw (if the provider
does not subscribe to on_end).
Solution: Move re-activation of the provider from after the on_end
callback to before the on_start callback.
Problem:
As `:h kp` says, the default value for keywordprg
should be ':help' on Windows. It is currently
always ':Man'.
Solution:
Add condition to options.lua which sets keywordprg
to ':help' if running on windows.
Problem: inline word diff treats multibyte chars as word char
(after 9.1.1243)
Solution: treat all non-alphanumeric characters as non-word characters
(Yee Cheng Chin)
Previously inline word diff simply used Vim's definition of keyword to
determine what is a word, which leads to multi-byte character classes
such as emojis and CJK (Chinese/Japanese/Korean) characters all
classifying as word characters, leading to entire sentences being
grouped as a single word which does not provide meaningful information
in a diff highlight.
Fix this by treating all non-alphanumeric characters (with class number
above 2) as non-word characters, as there is usually no benefit in using
word diff on them. These include CJK characters, emojis, and also
subscript/superscript numbers. Meanwhile, multi-byte characters like
Cyrillic and Greek letters will still continue to considered as words.
Note that this is slightly inconsistent with how words are defined
elsewhere, as Vim usually considers any character with class >=2 to be
a "word".
related: vim/vim#16881 (diff inline highlight)
closes: vim/vim#170509aa120f7ad
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
