Unlike the normal wildmenu, the CTRL-D wild-list is not restored by
statusline redraw. (Semantics: ^D is controlled by 'wildoptions' option,
so it's in the "wild..." family.)
TODO: externalize the c_CTRL-D wild-list.
17:25:45,363 WARN - /home/quickbuild/buildagent/workspace/root/neovim/pull-requests-automated/src/nvim/ex_getln.c: In function ‘color_cmdline’:
17:25:45,363 WARN - /home/quickbuild/buildagent/workspace/root/neovim/pull-requests-automated/src/nvim/ex_getln.c:2335:8: error: variable ‘printed_errmsg’ set but not used [-Werror=unused-but-set-variable]
17:25:45,363 WARN - bool printed_errmsg = false;
17:25:45,363 WARN - ^
17:25:45,399 WARN - cc1: all warnings being treated as errors
The issue with debug mode was actually not cleaning up after `try_enter`:
location `&tstate` was pointing to got invalidated and received some “garbage”
(actually, values that got stored on the stack afterwards). But pointer to that
garbage was still stored in `msg_list`, so next attempt to check it resulted in
a crash.
Problem: when processing cycle such as
:for pat in [' \ze*', ' \zs*']
: try
: let l = matchlist('x x', pat)
: $put ='E888 NOT detected for ' . pat
: catch
: $put ='E888 detected for ' . pat
: endtry
:endfor
`:let l = …` throwing an error causes this error to be caught after
color_cmdline attempts to get callback for highlighting next line (the one with
`$put = 'E888 NOT…`). Saving/restoring state prevents this from happening.
This also attempted to fix problem with cancelling input() on error by avoiding
standard error printing facilities (assumed thrown error message is the
problem), but with no luck so far.
Problem: Redraw problem when using 'incsearch'.
Solution: Save the current view when deleting characters. (Christian
Brabandt) Fix that the '" mark is set in the wrong position. Don't
change the search start when using BS.
dda933d06c
Should speed up execution without arabic characters a bit, slowing down with
arabic characters. More necessary, this allows coloring prompt without caring
about arabic shaping at the first iteration.
As part of the refactoring in #5119, some vim_strchr() were changed to
strchr(). However, vim_strchr() behaves differently than strchr() when
c is NUL, returning NULL instead of a pointer to the NUL.
Revert the strchr() calls where it isn't known whether c is NUL, since
this causes a semantic change the surrounding code doesn't expect. In
the case of #6650, this led to a heap overrun.
Closes#6650
