`SREQ_*` values are now actual typedef'd enums. `get_option_value_strict()` has also been refactored and split into two functions, `get_option_attrs()` for getting the option attributes, and `get_option_value_strict()` for getting the actual value. Moreover, it now returns an `OptVal`. Other miscellaneous refactors have also been made.
Problem: Wrong color for half of wide character next to pum scrollbar.
Solution: Redraw the screen cell with the right color. (closesvim/vim#9874)
35d8c2010e
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: [security] use-after-free with wildmenu
Solution: properly clean up the wildmenu when exiting
Fix wildchar/wildmenu/pum memory corruption with special wildchar's
Currently, using `wildchar=<Esc>` or `wildchar=<C-\>` can lead to a
memory corruption if using wildmenu+pum, or wrong states if only using
wildmenu. This is due to the code only using one single place inside the
cmdline process loop to perform wild menu clean up (by checking
`end_wildmenu`) but there are other odd situations where the loop could
have exited and we need a post-loop clean up just to be sure. If the
clean up was not done you would have a stale popup menu referring to
invalid memory, or if not using popup menu, incorrect status line (if
`laststatus=0`).
For example, if you hit `<Esc>` two times when it's wildchar, there's a
hard-coded behavior to exit command-line as a failsafe for user, and if
you hit `<C-\><C-\><C-N>` it will also exit command-line, but the clean
up code would not have hit because of specialized `<C-\>` handling.
Fix Ctrl-E / Ctrl-Y to not cancel/accept wildmenu if they are also
used for 'wildchar'/'wildcharm'. Currently they don't behave properly,
and also have potentially memory unsafe behavior as the logic is
currently not accounting for this situation and try to do both.
(Previous patch that addressed this: vim/vim#11677)
Also, correctly document Escape key behavior (double-hit it to escape)
in wildchar docs as it's previously undocumented.
In addition, block known invalid chars to be set in `wildchar` option,
such as Ctrl-C and `<CR>`. This is just to make it clear to the user
they shouldn't be set, and is not required for this bug fix.
closes: vim/vim#133618f4fb007e4
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
Problem: A few remaining cmdline completion issues with C-E/Y
Solution: Fix cmdline completion fuzzy/Ctrl-E/Ctrl-Y/options when not
used at the end
Fix cmdline completion fuzzy/Ctrl-E/Ctrl-Y/options when not used at the end
A few places in the cmdline completion code only works properly when the
user hits Tab (or 'wildchar') at the end of the cmdline, even though
it's supposed to work even in the middle of the line.
For fuzzy search, `:e ++ff`, and `:set hl=`, fix completion code to make
sure to use `xp_pattern_len` instead of assuming the entire `xp_pattern`
is the search pattern (since it contains texts after the cursor).
Fix Ctrl-E / Ctrl-Y to not jump to the end when canceling/accepting a
wildmenu completion. Also, make them work even when not using
`set wildoptions+=pum` as there is no drawback to doing so.
(Related issue where this was brought up: vim/vim#13331)
closes: vim/vim#13362209ec90b9b
Cherry-pick ex_getln.c changes from patch 9.0.2035.
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
BREAKING CHANGE: This breaks the OptionSet autocommand, as the `v:` values associated with it (`v:option_new`, `v:option_old`, `v:option_oldlocal` and `v:option_oldglobal`) are now the same type as the option, instead of all option values being converted to strings.
Problem: Cannot accurately get mouse clicking position when clicking on
a TAB or with virtual text.
Solution: Add a "coladd" field to getmousepos() result.
closes: vim/vim#13335f5a94d5165
Problem: `TextChangedI` can trigger on entering Insert mode if there
was previously a change not in Insert mode.
Solution: Make it trigger only when text is actually changed in Insert
mode.
closes: vim/vim#13265closes: vim/vim#13338d7ae263af8
Co-authored-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Problem:
The next command after `silent !{cmd}` or `silent lua print('str')`
prints an empty line before printing a message, because these commands
set `msg_didout = true` despite not printing any messages.
Solution:
Set `msg_didout = true` only if `msg_silent == 0`
Problem: Peeking and flushing output slows down execution.
Solution: Do not update the mode message when global_busy is set. Do not
flush when only peeking for a character. (Ken Takata)
cb574f4154
PROBLEM:
Currently `:echoerr` prints multi-line strings in a single line
as `:echom` does (Note: `:echon` can print multi-line strings well).
This makes stacktrace printed via echoerr difficult to read.
Example code:
try
lua error("lua stacktrace")
catch
echoerr v:exception
endtry
Output:
Error detected while processing a.vim[5]..a.vim:
line 4:
Vim(lua):E5108: Error executing lua [string ":lua"]:1: lua stacktrace^@stack traceback:^@^I[C]: in function 'error'^@^I[string ":lua"]:1: in main chunk
SOLUTION:
Allow echoerr to print multiline messages (e.g., lua exceptions),
because this command is usually used to print stacktraces.
Output after the fix:
Error detected while processing a.vim[5]..a.vim:
line 4:
Vim(lua):E5108: Error executing lua [string ":lua"]:1: lua stacktrace
stack traceback:
[C]: in function 'error'
[string ":lua"]:1: in main chunk
Problem: Vim9: in script cannot set item in uninitialized list.
Solution: When a list is NULL allocate an empty one. (closesvim/vim#8461)
e65081d1b5
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Using fnameescape() for the path argument of findfile() and finddir() is
wrong, as fnameescape() is intended to be used for parts of Ex commands,
not function arguments.
"VimEnter foo" was accepted as a valid event name for "VimEnter".
Events delimited with commas, eg. "VimEnter,BufRead", were also
accepted, even though only the first event was actually parsed.
Co-authored-by: ii14 <ii14@users.noreply.github.com>
The 'arabicshape' feature of vim is a transformation of unicode text to
make arabic and some related scripts look better at display time. In
particular the content of a cell will be adjusted depending on the
(original) content of the cells just before and after it.
This is implemented by the arabic_shape() function in nvim. Before this
commit, shaping was invoked in four different contexts:
- when rendering buffer text in win_line()
- in line_putchar() for rendering virtual text
- as part of grid_line_puts, used by messages and statuslines and
similar
- as part of draw_cmdline() for drawing the cmdline
This replaces all these with a post-processing step in grid_put_linebuf(),
which has become the entry point for all text rendering after recent
refactors.
An aim of this is to make the handling of multibyte text yet simpler.
One of the main reasons multibyte chars needs to be "parsed" into
codepoint arrays of composing chars is so that these could be inspected
for the purpose of shaping. This can likely be vastly simplified in many
contexts where only the total length (in bytes) and width of composed
char is needed.
Problem:
On Windows, "gf" fails on a filepath that has a line:column suffix.
Example:
E447: Can't find file "src/app/core/services/identity/identity.service.ts:64:23"
Solution:
- Remove ":" from 'isfname' on Windows. Colon is not a valid filename
character (except for the drive-letter).
- Handle drive letters specially in file_name_in_line().
Fixes#25160
This finalizes the long running refactor from the old TUI-focused grid
implementation where text-drawing cursor was not separated from the
visible cursor.
Still, the pattern of setting cursor position together with updating a
line was convenient. Introduce grid_line_cursor_goto() to still allow
this but now being explicit about it.
Only having batched drawing functions makes code involving drawing
a bit longer. But it is better to be explicit, and this highlights
cases where multiple small redraws can be grouped together. This was the
case for most of the changed places (messages, lastline, and :intro)
Problem:
The swapfile "E325: ATTENTION" dialog is displayed when editing a file
already open in another (running) Nvim. Usually this behavior is
annoying and irrelevant:
- "Recover" and the other options ("Open readonly", "Quit", "Abort") are
almost never wanted.
- swapfiles are less relevant for "multi-Nvim" since 'autoread' is
enabled by default.
- Even less relevant if user enables 'autowrite'.
Solution:
Define a default SwapExists handler which does the following:
1. If the swapfile is owned by a running Nvim process, automatically
chooses "(E)dit anyway" (caveat: this creates a new, extra swapfile,
which is mostly harmless and ignored except by `:recover` or `nvim -r`.
2. Shows a 1-line "ignoring swapfile..." message.
3. Users can disable the default SwapExists handler via `autocmd! nvim_swapfile`.
msg_puts_display was more complex than necessary in nvim, as in
nvim, it no longer talks directly with a terminal.
In particular we don't need to scroll the grid before emiting the last
char. The TUI already takes care of things like that, for terminals
where it matters.
Problem: Visual highlight is inconsistent on a folded line with
treesitter foldtext.
Solution: Don't added Folded highlight as it is already in background.
