This means that all work previously done by a `_parse()` iteration will
be kept in future iterations. This prevents it from running indefinitely
in some cases where the file is very large and there are 2+ injections.
Problem:
When running an initial parse, parse() returns an empty table rather
than an actual range. In `languagetree.lua`, we manually check if
a parse was incremental to determine the changed parse region.
Solution:
- Always return a range (in the C side) from parse().
- Simplify the language tree code a bit.
- Logger no longer shows empty ranges on the initial parse.
This simplifies some logic in `languagetree.lua`, removing the need for
`_has_regions`, and removing side effects in `:included_regions()`.
Before:
- Edit is made which sets `_regions = nil`
- Upon the next call to `included_regions()` (usually right after we
marked `_regions` as `nil` due to an `_iter_regions()` call), if
`_regions` is nil, we repopulate the table (as long as the tree
actually has regions)
After:
- Edit is made which resets `_regions` if it exists
- `included_regions()` no longer needs to perform this logic itself, and
also no longer needs to read a `_has_regions` variable
Compute the diagnostics per line when `show` is called, allowing for
O(1) access for the diagnostics to display when the cursor line or the
list of diagnostics haven't changed.
Before the 7121983c45 refactoring this
loop added highlights from a `buf_hls` list that had filtered out
elements with `Attrs.None`. After the refactoring this added highlights
from `hls` directly, and those elements would fail with e.g.:
$ nvim 'man://math.h(0)'
Error detected while processing command line:
Error executing Lua callback: /usr/share/nvim/runtime/lua/man.lua:205: Invalid 'hl_group': Expected Lua string
stack traceback:
[C]: in function 'nvim_buf_add_highlight'
/usr/share/nvim/runtime/lua/man.lua:205: in function 'highlight_man_page'
/usr/share/nvim/runtime/lua/man.lua:632: in function 'init_pager'
/usr/share/nvim/runtime/plugin/man.lua:9: in function </usr/share/nvim/runtime/plugin/man.lua:6>
Problem: preinsert text completions not deleted with <C-W>/<C-U>
(ddad431, after v9.1.1059)
Solution: handle <C-W> or <C-U> specifically and clear the completion
(glepnir)
fixes: vim/vim#16557closes: vim/vim#16565001c26cd61
Problem:
The current implementation uses a global augroup for virtual lines in
diagnostics, which can lead to conflicts and unintended behavior when
multiple namespaces/buffers are involved.
Solution:
Refactor the code to use a namespace-specific augroup for virtual lines.
This ensures that each namespace has its own augroup.
Scope the clear commands to only the relevant buffer.
Problem: getchar() can't distinguish between C-I and Tab.
Solution: Add {opts} to pass extra flags to getchar() and getcharstr(),
with "number" and "simplify" keys.
related: vim/vim#10603closes: vim/vim#16554e0a2ab397f
Cherry-pick tv_dict_has_key() from patch 8.2.4683.
Problem:
`AucmdExecutable` adds 2 layers of indirection. Although formalizing
a `union` is good practice for shared interfaces, this struct is mainly
for `autocmd_register` which is internal to this module.
Solution:
- Store the cmd/fn fields directly on the `AutoCmd` struct.
- Drop `AucmdExecutable` and related structures.
Port one_function_arg() and get_function_body() from Vim.
vim-patch:8.2.2865: skipping over function body fails
Problem: Skipping over function body fails.
Solution: Do not define the function when skipping.
d87c21a918
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem:
Event handler declared with `once=true` can re-trigger itself (i.e. more
than once!) by calling `nvim_exec_autocmds` or `:doautocmd`.
Analysis:
This happens because the callback is executed before deletion/cleanup
(`aucmd_del`). And calling `aucmd_del` before `call_autocmd_callback`
breaks the autocmd execution...
Solution:
Set `ac->pat=NULL` to temporarily "delete" the autocmd, then restore it
after executing the callback.
Fix#25526
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: completion: input text deleted with preinsert when adding leader
Solution: remove compl_length and check the ptr for being equal
to pattern when preinsert is active (glepnir)
closes: vim/vim#16545bfb4eea786
Co-authored-by: glepnir <glephunter@gmail.com>
Co-authored-by: Dustin S. <dstackmasta27@gmail.com>
Co-authored-by: Ferenc Fejes <fejes@inf.elte.hu>
Co-authored-by: Maria José Solano <majosolano99@gmail.com>
Co-authored-by: Yochem van Rosmalen <git@yochem.nl>
Co-authored-by: brianhuster <phambinhanctb2004@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Problem: currently `CursorLine`, `Folded`, `StatusLineNC` highlight
groups have the same background color in default color scheme (Grey3).
This is a result of optimizing their highlighting to be different from
`Normal` but not draw too much attention.
However, this design has a usability issue as those groups are
sometimes appear together which can make it hard (but not impossible)
to differentiate between them.
This was previously partially resolved with `StatusLineNC` using Grey1
as background (and thus be different from `CursorLine` but closer to
`Normal`), but optimizing more towards it being a visible separator
between windows was decided to be more important.
Solution: make `Folded` use Grey1 and `StatusLineNC` use Grey4. This
makes all three highlight groups have different backgrounds with the
following consequences:
- Folds now have the same background as floating windows. It makes
them there differentiable only by the value of 'foldtext' (which
is usually enough). Optimizing for the case "cursor line is next
to the fold" seems to be more useful than for the case "make folds
in floating window differ by background".
- Statusline of inactive windows now draw more attention to them.
The benefits are that they are different from cursor column and
are better window separators.
- Inactive tabline (both `TabLine` and `TabLineFill`) now also draws
a bit more attention to it (as they are linked to `StatusLineNC`)
but with the benefit of also being different from `CursorLine`.
Problem: Vim doesn't highlight to be inserted text when completing
Solution: Add support for the "preinsert" 'completeopt' value
(glepnir)
Support automatically inserting the currently selected candidate word
that does not belong to the latter part of the leader.
fixes: vim/vim#3433closes: vim/vim#16403edd4ac3e89
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: `cmdline_show` is emitted unnecessarily each event
loop iteration, because `cmdline_was_last_drawn` is never set.
Solution: Keep track of whether the cmdline was last drawn to avoid
unnecessarily emitting cmdline_show. Set `redraw_state` to
emit `cmdline_pos` when emitting `CursorMovedC`. Only emit
`cmdline_pos` when cmdline was last drawn.
Problem: `TSHighlighter:destroy()` causes double-processing of the modeline
and failure of `b:undo_ftplugin`.
Solution: Disable modeline in `TSHighlighter:destroy()` by setting `modeline=false`
if executing `syntaxset` autocommands for the `FileType` event.
Co-authored-by: Daniel Petrovic <daniel.petrovic@ebcont.com>
Since these assertions all use a common function to perform the test
assertions, it's difficult to figure out which test failed:
ERROR test/unit/testutil.lua @ 785: vim_snprintf() positional arguments
test/unit/testutil.lua:757: test/unit/testutil.lua:741: (string) '
test/unit/strings_spec.lua:143: Expected objects to be the same.
Passed in:
(number) 6400
Expected:
(number) 6'
exit code: 256
Adding context to the assertion makes it clearer what the problem is:
ERROR test/unit/testutil.lua @ 785: vim_snprintf() positional arguments
test/unit/testutil.lua:757: test/unit/testutil.lua:741: (string) '
test/unit/strings_spec.lua:149: snprintf(buf, 0, "%1$0.*2$b", cdata<unsigned int>: 0xf78d0f38, cdata<int>: 0xf78dc4e0) = 001100
Expected objects to be the same.
Passed in:
(number) 6400
Expected:
(number) 6'
exit code: 256
**Problem:** In the case where the user sets the treesitter foldexpr upon startup in
their `init.lua`, the fold info will be calculated before the parser has
been loaded in, meaning folds will be properly calculated until edits or
`:e`.
**Solution:** Refresh fold information upon `VimEnter` as a sanity check
to ensure that a parser really doesn't exist before always returning
`'0'` in the foldexpr.
**Problem:** Currently, if users want to efficiently disable injections,
they have to delete the injection query files at their runtime path.
This is because we only check for existence of the files before running
the query over the entire buffer.
**Solution:** Check for existence of query files, *and* that those files
actually have captures. This will allow users to just comment out
existing queries (or better yet, just add their own injection query to
`~/.config/nvim` which contains only comments) to disable running the
query over the entire buffer (a potentially slow operation)
Problem: dircolors syntaxt termguicolors support was not taking dynamic
termguicolors changes into account.
Solution: initializing missing script-internal data on dynamic
termguicolors change.
Problem:
`nvim_win_set_config` cannot set the title and footer independently.
When only one is given, the other is reset to the default of "left".
Solution:
Reuse existing title/footer value if not provided.
While at it, also increase the maximum number of lines to check to 500.
fixes: vim/vim#1651399181205c5
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: tests: off-by-one error in CheckCWD in test_debugger.vim
Solution: Fix off-by-one in CheckCWD leading to local tests failure
(Yee Cheng Chin)
Vim's test_debugger's Test_debug_backtrace_level test will fail if you
happen to run it in a Vim repository with full path of directory being
exactly 29 characters (e.g. `/Users/bob/developing/src/vim`). The test
does term dump comparison and the printout will overflow if the CWD is
too long. It does have a function to skip to test if it detects that but
it's off by one leading to this one situation where it will fail.
The reason why the logic didn't account for this is that Vim's message
printing will overflow the text if it prints a message at exactly the
width of the terminal. This could be considered a bug / quirk but that
will be another issue.
closes: vim/vim#165173acfbb4b54
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
