connection from any channel or stdio will unblock
remote_ui_wait_for_attach. Wait on stdio only if
only —embed specified, if both —embed and
—listen then wait on any channel.
Problem: `os_doskip` seems to be unnecessary since everything that sets it to true also returns an error, and `errmsg` being non-`NULL` already skips most of the processing.
Solution: Remove `os_doskip`.
While the interfaces for setting number and boolean options are now unified by #25394, there is still a separate `set_string_option` function that is used for setting a string option. This PR removes that function and merges it with set_option.
BREAKING CHANGE: `v:option_old` is now the old global value for all global-local options, instead of just string global-local options. Local value for a global-local number/boolean option is now unset when the option is set (e.g. using `:set` or `nvim_set_option_value`) without a scope, which means they now behave the same way as string options.
Ref: #25672
runtime(doc): all secure options should note this restriction in the documentation (vim/vim#13448)
Problem: Not all secure options document their status
Solution: Describe secure context :set restrictions in each help entry
8ebdbc9e6d
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: With 'smoothscroll' set, "w_skipcol" is not reset when unsetting 'wrap'.
Resulting in incorrect calculation of the cursor position.
Solution: Reset "w_skipcol" when unsetting 'wrap'.
fixes: vim/vim#12970closes: vim/vim#134391bf1bf569b
Problem: TextChangedI may not always trigger
Solution: trigger it in more cases: for insert/
append/change operations, and when
opening a new line,
fixes: vim/vim#13367closes: vim/vim#133754bca4897a1
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security] disallow setting env in restricted mode
Solution: Setting environment variables in restricted mode could
potentially be used to execute shell commands. Disallow this.
restricted mode: disable allow setting of environment variables
Setting environment variables in restricted mode, may have some unwanted
consequences. So, for example by setting $GCONV_PATH in restricted mode
and then calling the iconv() function, one may be able to execute some
unwanted payload, because the `iconv_open()` function internally uses
the `$GCONV_PATH` variable to find its conversion data.
So let's disable setting environment variables, even so this is no
complete protection, since we are not clearing the existing environment.
I tried a few ways but wasn't successful :(
One could also argue to disable the iconv() function completely in
restricted mode, but who knows what other API functions can be
influenced by setting some other unrelated environment variables.
So let's leave it as it is currently.
closes: vim/vim#13394
See: https://huntr.com/bounties/b0a2eda1-459c-4e36-98e6-0cc7d7faccfe/6b89dd6a72
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: Completion menu may be wrong
Solution: Check for the original direction of the completion menu,
add more tests, make it work with 'noselect'
completion: move in right direction when filling completion_info()
When moving through the insert completion menu and switching directions,
we need to make sure we start at the correct position in the list and
move correctly forward/backwards through it, so that we do not skip
entries and the selected item points to the correct entry in the list
of completion entries generated by the completion_info() function.
The general case is this:
1) CTRL-X CTRL-N, we will traverse the list starting from
compl_first_match and then go forwards (using the cp->next pointer)
through the list (skipping the very first entry, which has the
CP_ORIGINAL_TEXT flag set (since that is the empty/non-selected entry
2) CTRL-X CTRL-P, we will traverse the list starting from
compl_first_match (which now points to the last entry). The previous
entry will have the CP_ORIGINAL_TEXT flag set, so we need to start
traversing the list from the second prev pointer.
There are in fact 2 special cases after starting the completion menu
with CTRL-X:
3) CTRL-N and then going backwards by pressing CTRL-P again.
compl_first_match will point to the same entry as in step 1 above,
but since compl_dir_foward() has been switched by pressing CTRL-P
to backwards we need to pretend to be in still in case 1 and still
traverse the list in forward direction using the cp_next pointer
4) CTRL-P and then going forwards by pressing CTRL-N again.
compl_first_match will point to the same entry as in step 2 above,
but since compl_dir_foward() has been switched by pressing CTRL-N
to forwards we need to pretend to be in still in case 2 and still
traverse the list in backward direction using the cp_prev pointer
For the 'noselect' case however, this is slightly different again. When
going backwards, we only need to go one cp_prev pointer back. And
resting of the direction works again slightly different. So we need to
take the noselect option into account when deciding in which direction
to iterate through the list of matches.
related: vim/vim#13402
related: vim/vim#12971closes: vim/vim#13408daef8c7437
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: [security] overflow in :history
Solution: Check that value fits into int
The get_list_range() function, used to parse numbers for the :history
and :clist command internally uses long variables to store the numbers.
However function arguments are integer pointers, which can then
overflow.
Check that the return value from the vim_str2nr() function is not larger
than INT_MAX and if yes, bail out with an error. I guess nobody uses a
cmdline/clist history that needs so many entries... (famous last words).
It is only a moderate vulnerability, so impact should be low.
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-q22m-h7m2-9mgm9198c1f2b1
N/A patch:
vim-patch:9.0.2073: typo in quickfix.c comments
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem:
`win_get_bordertext_col` returns column < 1 for right or center
aligned text, if its length is more than window width.
Solution:
Return max(resulting_column, 1)
Problem: cannot use buffer-number for errorformat
Solution: add support for parsing a buffer number using '%b' in
'errorformat'
closes: vim/vim#13419b731800522
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: EXPAND flag set for filetype option
Solution: Remove P_EXPAND flag from the 'filetype' option
Remove P_EXPAND flag from the 'filetype' option
Problem: P_EXPAND flag is erroneously set for 'filetype' option
Solution: Remove the P_EXPAND flag
This flag is used by string options that accept file path values. See
:help set_env.
This appears to have been included in d5e8c92 and resulted from an
incorrect implementation of 'filetype' completion.
See vim/vim#12900 for a small discussion.
related: vim/vim#12900closes: vim/vim#134163932072ab4
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
Problem: #25716 removed the logic for getting the correct value of the `'modified'` option when using `nvim_buf_get_option()`. So the function now returns an incorrect value of `'modified'` for scratch buffers.
Solution: Re-add the logic for getting the correct value of `'modified'`. Also make it so that the logic only exists in one place instead of being duplicated across multiple places in the code.
Problem: With lots of events, UI flush may be delayed for too long.
Solution: Flush UI when no input is available. This still flushes less
frequently than before #25629, when a flush also happens when
typeahead buffer is empty but input is available.
`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: no digraph for quadruple prime
Solution: add quadruple prime digraph using 4'
closes: vim/vim#1338047416d1a74
Co-authored-by: Jonathan Wright <quaggy@gmail.com>
Problem: Vim9: crash with deferred function call and exception
Solution: Save and restore exception state
Crash when a deferred function is called after an exception and another
exception is thrown
closes: vim/vim#13376closes: vim/vim#13377c59c1e0d88
The change in check_due_timer() is N/A as Nvim calls timer callbacks on
the main loop.
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Problem: trim(): hard to use default mask (partly revert v9.0.2040)
Solution: use default mask when it is empty
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
Currently, an empty 'mask' will make 'trim()' call return 'text' value
that is passed in unmodified. It is unlikely that someone is using it,
so the chances of scripts being broken by this change are low.
Also, this reverts commit 9.0.2040 (which uses v:none for the default
and requires to use an empty string instead).
closes: vim/vim#133588079917447
vim-patch:9.0.2040: trim(): hard to use default mask
Problem: trim(): hard to use default mask
Solution: Use default 'mask' when it is v:none
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
'v:none' is already used to mean "use the default argument value" in
user defined functions. See |none-function_argument| in help.
closes: vim/vim#133636e6386716f
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>
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>
Problem: completion shows current word after completion restart
Solution: remove the word being completed after completion restart
The word being completed is shown in a completion list after completion
restart, because it isn't removed from the current buffer before
searching for matches.
Also adjust `Test_complete_add_onechar` to match the new behavior.
closes: vim/vim#133492e3cd52fa0
Co-authored-by: nwounkn <nwounkn@gmail.com>
