| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is the command invoked repeatedly to make the changes:
:%s/^\(.*\)|\%(\*\(\d\+\)\)\?$\n\1|\%(\*\(\d\+\)\)\?$/\=submatch(1)..'|*'..(max([str2nr(submatch(2)),1])+max([str2nr(submatch(3)),1]))/g
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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#13361
https://github.com/vim/vim/commit/8f4fb007e4d472b09ff6bed9ffa485e0c3093699
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
|
| |
|
|
|
| |
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: famiu <famiuhaque@protonmail.com>
|
| |
|
|
|
| |
Extend the capabilities of is_os to detect more platforms such as
freebsd and openbsd. Also remove `iswin()` helper function as it can be
replaced by `is_os("win")`.
|
| |
|
|
|
|
|
| |
The old behaviour (e.g. via `set display-=msgsep`) will not be available.
Assuming that messages always are being drawn on msg_grid
(or not drawn at all, and forwarded to `ext_messages` enabled UI)
will allows some simplifcations and enhancements moving forward.
|
| |
|
| |
Cherry-picked from Vim patches 8.2.4339, 9.0.0238.
|
| |
|
|
|
|
| |
Also:
- Add a describe('shell :!') section to system_spec.
- Make the test for #16271 work on systems without powershell.
|
| |\
| |
| | |
vim-patch:8.0.{858,953,1525}
|
| | |
| |
| |
| |
| | |
User config may set $PS1 for a colored prompt.
It breaks the screen tests.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Opt in to this secret world using
set wildchar=0
" already the default, but remove if non-zero existing config:
set wildcharm=0
now you can map 'wildmode' just like any mode:
cnoremap <tab> <c-z>
function! Spacey()
return getcmdline()[-1:] == "/" ? "\<bs>" : ""
endfunc
cnoremap <expr> / wildmenumode() ? Spacey()."/<c-z>" : "/"
Possibly asked questions:
What about backwards compatibility?
====
Just do nothing and your existing 'wildchar' and 'wildcharm' will keep working.
Doesn't `<c-z>` mean suspend?
====
Not in cmdline mode. If it would then the recommended wildcharm would not
have been `<c-z>` to start with.
My config relies on `:<c-z>` being a synonym to `:<nop>`!
====
just no.
|
| |\
| |
| | |
[RFC] Wildmenu support C-E and C-Y as popupmenu
|
| | | |
|
| |/
|
|
|
|
| |
With "wildmode=longest,full" + wildoptions=pum, wildmode should show
popupmenu after Tab-Tab, not the horizontal wildmenu.
Fixes #11622
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a00eb23c27da fixed one race, but not this one:
[ ERROR ] test/functional/ui/wildmode_spec.lua @ 84: 'wildmenu' is preserved during :terminal activity
test/functional/ui/screen.lua:587: Row 1 did not match.
Expected:
|* |
| |
| |
|define jump list > |
|:sign define^ |
Actual:
|*0: !terminal_output! |
| |
| |
|define jump list > |
|:sign define^ |
To print the expect() call that would assert the current screen state, use
screen:snapshot_util(). In case of non-deterministic failures, use
screen:redraw_debug() to show all intermediate screen states.
stack traceback:
test/functional/ui/screen.lua:587: in function '_wait'
test/functional/ui/screen.lua:370: in function 'expect'
test/functional/ui/wildmode_spec.lua:22: in function 'expect_stay_unchanged'
test/functional/ui/wildmode_spec.lua:92: in function <test/functional/ui/wildmode_spec.lua:84>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ ERROR ] test/functional\ui\wildmode_spec.lua @ 84: 'wildmenu' is preserved during :terminal activity
test\functional\ui\screen.lua:587: Row 1 did not match.
Expected:
|*:sign |
|*define place |
|*jump undefine |
|*list unplace |
|*:sign ^ |
Actual:
|*0: !terminal |
|* |
|*^ |
|*~ |
|* |
stack traceback:
test\functional\ui\screen.lua:587: in function '_wait'
test\functional\ui\screen.lua:370: in function 'expect'
test/functional\ui\wildmode_spec.lua:22: in function 'expect_stay_unchanged'
test/functional\ui\wildmode_spec.lua:103: in function <test/functional\ui\wildmode_spec.lua:84>
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
* Fix wildmode=list and display+=msgsep interaction
* Add test to check ext_messages behaviour is unchanged
|
| |
|
|
|
|
| |
The test.functional.helpers and test.unit.helpers modules now include
all of the public functions from test.helpers, so there is no need to
separately require('test.helpers').
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, ordinary redraws were missing from terminal mode. Instead,
there was an async callback that invoked update_screen() on terminal
data regardless of mode (as if :redraw! was invoked by a timer).
This created some issues:
- async changes to an unrelated ordinary buffer were not always redrawn in
terminal mode
- screen cursor position was not properly updated in terminal mode (partial
fix, will be properly fixed in a follow up PR)
- ad-hoc logic was needed for interaction with special states such as
inccommand or horizontal wildmenu.
Instead redraw terminal mode just like any other state. This disables forced
redraws in cmdline mode, which were inconisent which async changes to
normal buffers (which are not redrawn in cmdline mode).
|
| |\
| |
| |
| | |
fixes #9681
|
| |/
|
|
|
|
|
| |
Since uv_os_setenv uses SetEnvironmentVariableW, _wenviron is no
updated. As a result, inconsistency occurs in completion of environment
variable names. Change to use GetEnvironmentStaringsW instead of
_wenviron to solve it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Fixes #8385
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
closes #6168
ref #5686
|
| |/
|
|
|
| |
Co-authored-by: Björn Linse <bjorn.linse@gmail.com>
Updated docs and tests.
|
| |
|
|
|
|
|
| |
Treat dialogs in the same way as "silent mode" (`nvim -es`).
References #1984
References #3901
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This might be too coarse, but it passes all tests ...
A more nuanced approach might be: only skip the windows whose
statuslines are overwritten by the wildmenu.
Closes #2255
Closes #7108
vim-patch:8.0.0710 N/A because of the changes in this commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
Hope this will make people using feed_command less likely: this hides bugs.
Already found at least two:
1. msgpackparse() will show internal error: hash_add() in case of duplicate
keys, though it will still work correctly. Currently silenced.
2. ttimeoutlen was spelled incorrectly, resulting in option not being set when
expected. Test was still functioning somehow though. Currently fixed.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
|
| | |
|
| |
|
|
| |
#2677
|
| | |
|
| |
|
