Problem: Computed buffer line for mouse position does not take into
account concealed lines on the reached row.
Solution: Adjust for concealed lines at the end of the loop computing
the buffer position.
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: 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: 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: 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>
Problem:
First rtp directory is unpredictable and not in line with XDG
base spec.
Solution:
Use stdpath('data')/spell as directory if 'spellfile' is not set.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: completion: in keyword completion Ctrl_P cannot go back after
Ctrl_N
Solution: in find_compl_when_fuzzy() always return first match of array, after Ctrl_P
use compl_shown_match->cp_next instead of compl_first_match.
(glepnir)
closes: vim/vim#170433e50a28a03
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: compl_shown_match is updated when starting keyword completion
and does not include fuzzy matching.
Solution: Do not update compl_shown_match when starting keyword
completion, since it is the one already selected by the
keyword completion direction. (glepnir)
closes: vim/vim#17033e4e4d1c381
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: Redrawing during a substitute confirm prompt causes the match
highlight to disappear.
Solution: Unset `highlight_match` after the prompt has returned.
Use global highlight definitions in searchhl_spec.lua.
Problem: When `nvim_set_keymap` tries to overwrite a `<unique>` mapping,
it throws an error even when called in `pcall`.
Solution: src/nvim/mapping.c:buf_do_map no longer calls `semsg`. Its
callers now decide whether to ignore the error, or use
`semsg` (not caught)/`api_set_error` (caught by `pcall`).
These occurrences also accept string, which is used like in getline.
Also make the lnum field of vim.fn.sign_placelist.list.item optional, as it can
be omitted like vim.fn.sign_place.dict's.
Problem: Inline virtual text placed in a decor provider callback
invalidates `w_virtcol`, which must be valid for `win_line()`.
Solution: Call `validate_virtcol()` after "line" decor provider callbacks.
Problem: Scrolling up does not adjust `w_topline` for concealed lines
directly above it, resulting in (non-visual) asymmetry when
scrolling up/down.
Solution: Adjust `w_topline` for concealed lines after scrolling up.
Problem:
Upon receiving a deadly signal, Nvim doesn't write buffers even if
the option 'autowriteall' is set.
Solution:
Write to all writable buffers upon SIGHUP or SIGQUIT (but not
SIGTERM), if the option 'autowriteall' is set.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: string length wrong in get_last_inserted_save()
(after v9.1.1222)
Solution: when removing trailing ESC, also decrease the string length
(Christ van Willegen)
closes: vim/vim#16961583f5aee96
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
Remove the `set_timeout` functions for `TSParser` and instead add a timeout
parameter to the regular parse function. Remove these deprecated tree-sitter
API functions and replace them with the preferred `TSParseOptions` style.
When setting a keymap with "unique" that already exists the error
message contains the LHS of the keymap with termcodes replaced. In
particular this means that keys like <Tab> show as an actual tab
character, meaning the error message displays as "Mapping already exists
for ", which is hard to debug for users.
Instead, display the original LHS (without any simplification or parsed
termcodes). This rperesents exactly what the user passed to the `lhs`
argument of `nvim_set_keymap`, which makes it easier to find where the
offending keymap is.
Problem: Mixing vim_strsize() with mb_ptr2cells() in pum_redraw().
Solution: Change vim_strsize() to mb_string2cells() (zeertzjq).
Since vim_strsize() uses ptr2cells() for the cell width of each char, it
is strange to mix it with mb_ptr2cells(), which is used both just below
and in pum_screen_puts_with_attr(), and screen_puts_len() also uses
something similar. Meanwhile mb_string2cells() uses mb_ptr2cells() for
the cell width of each char.
Note that the vim_strsize() and mb_string2cells() actually return the
same value here, as the transstr() above makes sure the string only
contains printable chars, and ptr2cells() and mb_ptr2cells() only return
different values for unprintable chars.
closes: vim/vim#1700390e52490b3
Problem: missing test condition for 'pummaxwidth' setting, pummaxwidth
not effective when width is 32 and height is 10
(after v9.1.1250)
Solution: add missing comparison condition in pum_width()
(glepnir)
closes: vim/vim#16999532c5aec6f
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: cannot set the maximum popup menu width
(Lucas Mior)
Solution: add the new global option value 'pummaxwidth'
(glepnir)
fixes: vim/vim#10901closes: vim/vim#1694388d75934c3
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: regexp: max \U and \%U value is limited by INT_MAX but gives a
confusing error message (related: v8.1.0985).
Solution: give a better error message when the value reaches INT_MAX
When searching Vim allows to get up to 8 hex characters using the /\V
and /\%V regex atoms. However, when using "/\UFFFFFFFF" the code point is
already above what an integer variable can hold, which is 2,147,483,647.
Since patch v8.1.0985, Vim already limited the max codepoint to INT_MAX
(otherwise it caused a crash in the nfa regex engine), but instead of
error'ing out it silently fell back to parse the number as a backslash
value and not as a codepoint value and as such this "/[\UFFFFFFFF]" will
happily find a "\" or an literal "F". And this "/[\d127-\UFFFFFFFF]"
will error out as "reverse range in character class).
Interestingly, the max Unicode codepoint value is U+10FFFF which still
fits into an ordinary integer value, which means, that we don't even
need to parse 8 hex characters, but 6 should have been enough.
However, let's not limit Vim to search for only max 6 hex characters
(which would be a backward incompatible change), but instead allow all 8
characters and only if the codepoint reaches INT_MAX, give a more
precise error message (about what the max unicode codepoint value is).
This allows to search for "[\U7FFFFFFE]" (will likely return "E486
Pattern not found") and "[/\U7FFFFFF]" now errors "E1517: Value too
large, max Unicode codepoint is U+10FFFF".
While this change is straight forward on architectures where long is 8
bytes, this is not so simple on Windows or 32bit architectures where long
is 4 bytes (and therefore the test fails there). To account for that,
let's make use of the vimlong_T number type and make a few corresponding
changes in the regex engine code and cast the value to the expected data
type. This however may not work correctly on systems that doesn't have
the long long datatype (e.g. OpenVMS) and probably the test will fail
there.
fixes: vim/vim#16949closes: vim/vim#16994f2b16986a1
Co-authored-by: Christian Brabandt <cb@256bit.org>
