summaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)Author
2024-01-29patch 9.1.0063: GTK code can be improvedv9.1.0063lilydjwg
Problem: GTK code can be improved Solution: Improve GTK code for initial Wayland support (lilydjwg) related: #9639 Signed-off-by: lilydjwg <lilydjwg@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-29patch 9.1.0062: Internal error when :luado/perldo/pydo etc delete linesv9.1.0062zeertzjq
Problem: Internal error when :luado/perldo/pydo etc delete lines Solution: Test that the line is still valid line number (zeertzjq) closes: #13931 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-28patch 9.1.0061: UX of visual highlighting can be improvedv9.1.0061Christian Brabandt
Problem: UX of visual highlighting can be improved Solution: Improve readibility of visual highlighting, by setting better foreground and background colors The default visual highlighting currently is nice in that it overlays the actual syntax highlighting by using a separate distinct background color. However, this can cause hard to read text, because the contrast between the actual syntax element and the background color is way too low. That is an issue, that has been bothering colorschemes authors for quite some time so much, that they are defining the Visual highlighting group to use a separate foreground and background color, so that the syntax highlighting vanishes, but the text remains readable (ref: vim/colorschemes#250) So this is an attempt to perform the same fix for the default Visual highlighting and just use a default foreground and background color instead of using reverse. I also removed the hard-coded changes to the Visual highlighting in init_highlight. It's not quite clear to me, why those were there and not added directly to the highlighting_init_<dark|light> struct. closes: #13663 related: vim/colorschemes#250 Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-28patch 9.1.0060: Recorded register cannot be translated using keytrans()v9.1.0060zeertzjq
Problem: Recorded register cannot be translated using keytrans() when it involves character search (iddqd505) Solution: Record a K_IGNORE instead of a K_NOP (zeertzjq) related: #13916 closes: #13925 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0059: No event triggered before creating a windowv9.1.0059Sergey Vlasov
Problem: No event is triggered before creating a window. (Sergey Vlasov) Solution: Add the WinNewPre event (Sergey Vlasov) fixes: #10635 closes: #12761 Signed-off-by: Sergey Vlasov <sergey@vlasov.me> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0058: Cannot map Super Keys in GTK UIv9.1.0058Casey Tucker
Problem: Cannot map Super Keys in GTK UI (Casey Tucker) Solution: Enable Super Key mappings in GTK using <D-Key> (Casey Tucker) As a developer who works in both Mac and Linux using the same keyboard, it can be frustrating having to remember different key combinations or having to rely on system utilities to remap keys. This change allows `<D-z>` `<D-x>` `<D-c>` `<D-v>` etc. to be recognized by the `map` commands, along with the `<D-S-...>` shifted variants. ```vimrc if has('gui_gtk') nnoremap <D-z> u nnoremap <D-S-Z> <C-r> vnoremap <D-x> "+d vnoremap <D-c> "+y cnoremap <D-v> <C-R>+ inoremap <D-v> <C-o>"+gP nnoremap <D-v> "+P vnoremap <D-v> "-d"+P nnoremap <D-s> :w<CR> inoremap <D-s> <C-o>:w<CR> nnoremap <D-w> :q<CR> nnoremap <D-q> :qa<CR> nnoremap <D-t> :tabe<CR> nnoremap <D-S-T> :vs#<CR><C-w>T nnoremap <D-a> ggVG vnoremap <D-a> <ESC>ggVG inoremap <D-a> <ESC>ggVG nnoremap <D-f> / nnoremap <D-g> n nnoremap <D-S-G> N vnoremap <D-x> "+x endif ``` closes: #12698 Signed-off-by: Casey Tucker <dctucker@hotmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0057: MS-Windows: Key event test still failsv9.1.0057Christian Brabandt
Problem: MS-Windows: Key event test still fails Solution: Skip testing CTRL-C, since it causes an Interrupt which causes a test failure (after 9.1.0053) Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0056: wrong number of trailing spaces inserted after blockwise putv9.1.0056VanaIgr
Problem: Incorrect number of trailing spaces inserted for multibyte characters when pasting a blockwise register in blockwise visual mode (VanaIgr) Solution: Skip over trailing UTF-8 bytes when computing the number of trailing spaces (VanaIgr) When pasting in blockwise visual mode, and the register type is <CTRL-V>, Vim aligns the text after the replaced area by inserting spaces after pasted lines that are shorter than the longest line. When a shorter line contains multibyte characters, each trailing UTF-8 byte's width is counted in addition to the width of the character itself. Each trailing byte counts as being 4 cells wide (since it would be displayed as <xx>). closes: #13909 Signed-off-by: VanaIgr <vanaigranov@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0055: formatting long lines is slowv9.1.0055kawaii-Code
Problem: formatting long lines is slow (kawaii-Code) Solution: optimize gq (internal_format) for long lines (kawaii-Code) Implemented two workarounds that significantly reduce the amount of pointless calls. Ideally the algorithm would be rewritten not to be n^2, but it's too complicated with too many corner cases. closes: #13914 Signed-off-by: kawaii-Code <nia.personal.0@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0054: 'linebreak' may still apply to leading whitespacev9.1.0054zeertzjq
Problem: 'linebreak' may still apply to leading whitespace (VanaIgr) Solution: Compare pointers instead of virtual columns. (zeertzjq) related: neovim/neovim#27180 closes: #13915 Co-authored-by: VanaIgr <vanaigranov@gmail.com> Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0053: MS-Windows: Key event test still failsv9.1.0053Christian Brabandt
Problem: MS-Windows: Key event test still fails Solution: Catch more interrupts (after 9.1.0051) Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0052: Patch 9.1.0041 causes regressions for usersv9.1.0052Christian Brabandt
Problem: Patch 9.1.0041 causes regressions for users (Gleb Fotengauer-Malinovskiy) Solution: Revert 9.1.0041 and restore old behaviour Revert "patch 9.1.0041: xxd -i may generate incorrect C statements" This reverts commit 7062be13129985fe297b9a8e59c57b8f0db61b8f. Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-25patch 9.1.0051: MS-Windows: Key event test failv9.1.0051Christian Brabandt
Problem: MS-Windows: Key event test fail (after 9.1.0050) Solution: Catch Interrupt and return Ctrl-C Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23patch 9.1.0050: Win32 Keyboard handling is sub-optimalv9.1.0050Anton Sharonov
Problem: Win32 Keyboard handling is sub-optimal and has many issues with international keyboards (risa2000) (after v8.2.4807) Solution: soft-rollback the change, allow the user to select a suitable key-translation strategy (Anton Sharonov) Read about the details in the help: :h w32-experimental-keycode-trans-strategy fixes: #10615 fixes: #12595 closes: #12752 Signed-off-by: Anton Sharonov <anton.sharonov@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23patch 9.1.0049: Make "[Command Line]" a special buffer namev9.1.0049Sean Dewar
Problem: E95 is possible if a buffer called "[Command Line]" already exists when opening the cmdwin. This can also happen if the cmdwin's buffer could not be deleted when closing. Solution: Un-name the cmdwin buffer, and give it a special name instead, similar to what's done for quickfix buffers and for unnamed prompt and scratch buffers. As a result, BufFilePre/Post are no longer fired when opening the cmdwin. Add a "command" key to the dictionary returned by getbufinfo() to differentiate the cmdwin buffer instead. (Sean Dewar) NOTE: This is technically a breaking change... maybe this needs a different solution? (Or maybe this issue can be ignored...) A GitHub search reveals some plugins expect the old behaviour. However, many of those plugins also do not seem to account for the string being translated, so they are subtly broken anyway (not withstanding the fact that you can call any old buffer "[Command Line]" too...) closes: #12819 Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23patch 9.1.0048: Abort opening cmdwin if autocmds screw things upv9.1.0048Sean Dewar
Problem: Autocmds triggered from opening the cmdwin (in win_split and do_ecmd) can cause issues such as E199, as the current checks are insufficient. Solution: Commands executed from the cmdwin apply to the old curwin/buf, so they should be kept in a "suspended" state; abort if they've changed. Also abort if cmdwin/buf was tampered with, and check that curwin is correct. Try to clean up the cmdwin buffer (only if hidden and non-current to simplify things; the same approach is used when closing cmdwin normally), and add a beep. (Sean Dewar) It'd be nice to also check that curwin was *really* created by win_split, as autocommands can change curwin before it returns (so it can't be assumed to be that of the split); for now, this means that the cmdwin may not be the botwin in that case, which is probably OK. closes: #12819 Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23patch 9.1.0047: issues with temp curwin/buf while cmdwin is openv9.1.0047Sean Dewar
Problem: Things that temporarily change/restore curwin/buf (e.g: win_execute, some autocmds) may break assumptions that curwin/buf is the cmdwin when "cmdwin_type != 0", causing issues. Solution: Expose the cmdwin's real win/buf and check that instead. Also try to ensure these variables are NULL if "cmdwin_type == 0", allowing them to be used directly in most cases without checking cmdwin_type. (Sean Dewar) Alternatively, we could ban win_execute in the cmdwin and audit all places that temporarily change/restore curwin/buf, but I didn't notice any problems arising from allowing this (standard cmdwin restrictions still apply, so things that may actually break the cmdwin are still forbidden). closes: #12819 Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23patch 9.1.0046: :drop does not re-use empty bufferv9.1.0046Rocco Mao
Problem: :drop does not re-use empty buffer (Rocco Mao) Solution: Make :drop re-use an empty buffer (Rocco Mao) fixes: #13851 closes: #13881 Signed-off-by: Rocco Mao <dapeng.mao@qq.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23patch 9.1.0045: --remote-* does not ignore `wilidignore`v9.1.0045Christian Brabandt
Problem: --remote-silent applies the wildignore option to each argument, which may result in "E479: No match" (hebaronson) Solution: temporarily reset 'wildignore' setting when building the :drop command closes: #13835 Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23translation(hu): use correct encoding in header of hu po file (#13902)Zoltan Arpadffy
closes: #13900 Signed-off-by: Zoltan Arpadffy <zoltan.arpadffy@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-23translation(it): Update Italian translationAntonio Giovanni Colombo
Signed-off-by: Antonio Giovanni Colombo <azc100@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-22patch 9.1.0044: po Makefiles can be improvedv9.1.0044RestorerZ
Problem: po Makefiles can be improved Solution: Improve the style of the Makefiles, update Makefile variables, update documentation (RestorerZ) closes: #13858 closes: #13857 Signed-off-by: RestorerZ <restorer@mail2k.ru> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-22patch 9.1.0043: ml_get: invalid lnum when :s replaces visual selectionv9.1.0043Christian Brabandt
Problem: ml_get: invalid lnum when :s replaces visual selection (@ropery) Solution: substitute may decrement the number of lines in a buffer, so validate, that the bottom lines of the visual selection stays within the max buffer line fixes: #13890 closes: #13892 Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-21patch 9.1.0042: Missing test for Chuck Filetypev9.1.0042Christian Brabandt
Problem: Missing test for Chuck filetype after commit 27a4632af6753 (Christian Clason) Solution: Add a filetype test Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-19translation(sr): Update Serbian messages translation (#13889)Ivan Pešić
Signed-off-by: Ivan Pešić <27575106+eevan78@users.noreply.github.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-17patch 9.1.0041: xxd -i may generate incorrect C statementsv9.1.0041Kuratius
Problem: xxd -i may generate incorrect C statements (Kuratius) Solution: xxd: Make size type returned by -i option compatible with C standard by using type size_t instead of unsigned int (Kuratius) Also change affected tests to now correctly expect size_t's fixes: #13876 closes: #13880 Signed-off-by: Kuratius <Kuratius@gmx.net> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-17patch 9.1.0040: issue with prompt buffer and hidden bufferv9.1.0040zeertzjq
Problem: Modifying a hidden buffer still interferes with prompt buffer mode changes. Solution: Save and restore b_prompt_insert. (zeertzjq) closes: #13875 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org> Modifying hidden buffer still interferes with prompt buffer mode changes
2024-01-17patch 9.1.0039: too vague errors for 'listchars'/'fillchars'v9.1.0039zeertzjq
Problem: too vague errors for 'listchars'/'fillchars' Solution: Include the field name in error message. (zeertzjq) related: neovim/neovim#27050 closes: #13877 Co-authored-by: Cole Frankenhoff <cole.nhf@gmail.com> Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-17patch 9.1.0038: Unnecessary loop in getvcol()v9.1.0038zeertzjq
Problem: Unnecessary loop in getvcol(). Solution: Compare next char position with pos->col directly. (zeertzjq) The loop below already handles end of line before checking for posptr, and the next char is after pos->col whether pos->col is at the start or in the middle of the char in question, so neither the NUL check nor the mb_head_off() are needed when comparing the position of the next char with pos->col directly. closes: #13878 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-17patch 9.1.0037: Calling get_breakindent_win() repeatedly when computing virtcolv9.1.0037zeertzjq
Problem: Calling get_breakindent_win() repeatedly when computing virtual column, and get_breakindent_win() does a STRCMP() on the whole line since patch 9.0.0016. Solution: Cache the result, since the line doesn't change. (zeertzjq) closes: #13879 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-17patch 9.1.0036: MS-Windows: Warning about unused variablev9.1.0036John Marriott
Problem: MS-Windows: Warning about unused variable (after 9.1.0030, John Marriott) Solution: Adjust #ifdef and test for HAVE_TGETENT (John Marriott) Signed-off-by: John Marriott <basilisk@internode.on.net> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-16patch 9.1.0035: i_CTRL-] triggers InsertCharPrev9.1.0035altermo
Problem: i_CTRL-] triggers InsertCharPre Solution: Return if CTRL-] is received. InsertCharPre is supposed to be only used for chars to be inserted but i_CTRL-] triggers expansion and is not inserted into the buffer (altermo) closes: #13853 closes: #13864 Signed-off-by: altermo Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-16patch 9.1.0034: Window scrolls unexpectedly when 'scrollbind' is setv9.1.0034Christian Brabandt
Problem: Window may unexpectedly scroll when 'scrollbind' is set and setting a buffer-local option using setbufvar() (Boris Staletic) Solution: Save and restore the windows topline before opening the popup window. fixes: #13863 closes: #13869 Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-16patch 9.1.0033: Insert mode not stopped if closing prompt buffer modifies ↵v9.1.0033zeertzjq
hidden buffer Problem: Insert mode not stopped if an autocommand modifies a hidden buffer while closing a prompt buffer. Solution: Don't set b_prompt_insert if stop_insert_mode is already set. (zeertzjq) closes: #13872 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-16patch 9.1.0032: MS-Windows installer misses keymapsv9.1.0032Ken Takata
Problem: MS-Windows installer misses keymaps (Maxim Kim) Solution: Include keymaps in the installer archive (Ken Takata) fixes: vim/vim-win32-installer#331 closes: #13871 Signed-off-by: Ken Takata <kentkt@csc.jp> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-15patch 9.1.0031: Link Error on Windowsv9.1.0031Christian Brabandt
Problem: Link Error on Windows Solution: Add ifdef HAVE_TGETENT for term_strings_not_set() Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-15patch 9.1.0030: Cannot use terminal alternate fontv9.1.0030PMunch
Problem: Cannot use terminal alternate fonts (PMunch) Solution: Support terminal alternate fonts using CSI SGR 10-20 and t_CF code (PMunch) Add support for alternate font highlighting This adds support for alternate font highlighting using CSI SGR 10-20. Few terminals currently support this, but with added tool support this should improve over time. The change here is more or less taken from how colors are configured and applied, but there might be some parts I missed while implementing it. Changing fonts is done through the new `:hi ctermfont` attribute which takes a number, 0 is the normal font, and the numbers 1-9 select an "alternative" font. Which fonts are in use is up to the terminal. fixes: #13513 closes: #13537 Signed-off-by: PMunch <peterme@peterme.net> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-14patch 9.1.0029: Cannot act on various terminal response codesv9.1.0029Danek Duvall
Problem: Cannot act on various terminal response codes Solution: Add the TerminalResponseAll autocommand (Danek Duvall) closes: #13829 Signed-off-by: Danek Duvall <duvall@comfychair.org> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-14patch 9.1.0028: win32: Ctrl-D cannot be used to close a pipev9.1.0028GuyBrush
Problem: win32: Ctrl-D cannot be used to close a pipe Solution: Properly detect Ctrl-D when reading from a pipe (GuyBrush) Enabling Ctrl-D for gvim pipeline input and apply defensive programming on account of PR #12752 so that once PR 12752 is merged, CTRL-D will keep on working closes: #13849 Signed-off-by: GuyBrush <miguel.barro@live.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-13patch 9.1.0027: Vim is missing a foreach() funcv9.1.0027Ernie Rael
Problem: Vim is missing a foreach() func Solution: Implement foreach({expr1}, {expr2}) function, which applies {expr2} for each item in {expr1} without changing it (Ernie Rael) closes: #12166 Signed-off-by: Ernie Rael <errael@raelity.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0026: win32: Windows default font lackingv9.1.0026Ken Takata
Problem: win32: Windows default font lacking (@clach04) Solution: Improve default font (Ken Takata) win32: Improve default font Currently, Fixedsys is the default font on Windows. It is not suitable for recent High DPI environments. * Change the default font to Consolas. * Allow to change the default font by the translation message. E.g.: ``` msgid "DefaultFontNameForWindows" msgstr "Courier New" ``` fixes: #12919 closes: #13266 Signed-off-by: Ken Takata <kentkt@csc.jp> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0025: A few typos in tests and justify.vimv9.1.0025dundargoc
Problem: A few typos in tests and justify.vim Solution: fix them closes: #13848 Signed-off-by: dundargoc <gocdundar@gmail.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0024: z/OS (MVS) support can be improvedv9.1.0024Igor Todorovski
Problem: z/OS (MVS) support can be improved Solution: set UTF-8 as the default encoding for z/OS closes: #13821 Signed-off-by: Igor Todorovski <itodorov@ca.ibm.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0023: xxd: few problems with EBCDIC for z/OS (MVS)v9.1.0023Igor Todorovski
Problem: xxd: few problems with EBCDIC for z/OS (MVS) Solution: Fix xxd build and support ASCII and UTF-8 on z/OS (MVS) natively, add MVS guard checks with __CHARSET_LIB, support $LIBS in the Makefile (Igor Todorovski) related: #13821 Signed-off-by: Igor Todorovski <itodorov@ca.ibm.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0022: Coverity complains about improper use of negative valuev9.1.0022Christian Brabandt
Problem: Coverity complains about improper use of negative value Solution: Add a condition to validate that keytyped is larger or equal to 0 Apparently patch 9.1.0006 made it more explicit for Coverity, that the TOLOWER_LOC() macros do not handle negative values properly. However, that condition has always been there even before that, so add a condition to verify that keytyped is indeed at least 0 closes: #13824 Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0021: i_CTRL-R- doesn't work for multibyte chars in Replace modev9.1.0021zeertzjq
Problem: i_CTRL-R- doesn't work for multibyte chars in Replace mode, Coverity complains missing return value for u_save_cursor() Solution: Use mb_charlen() and del_chars() instead, handle failure mode for u_save_cursor() correctly (@zeertzjq) closes: #13846 Signed-off-by: zeertzjq <zeertzjq@outlook.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0020: Vim9: cannot compile all methods in a classv9.1.0020Yegappan Lakshmanan
Problem: Vim9: cannot compile all methods in a class Solution: Support compiling all the methods in a class using :defcompile (Yegappan Lakshmanan) closes: #13844 Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0019: cmdline may disappear when changing 'cmdheight'v9.1.0019Christian Brabandt
Problem: cmdline may disappear when changing 'cmdheight' (after Patch 9.0.0190, @markonm) Solution: always re-calculate the old_p_ch value, not only when cmdline_row was higher than expected fixes: #13822 closes: #13826 Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0018: use of #if instead of #ifdefv9.1.0018Ken Takata
Problem: use of #if instead of #ifdef Solution: use correct form of #ifdef `#if FEAT_GUI_HAIKU` was used mistakenly. Use the correct form `#ifdef FEAT_GUI_HAIKU` instead. closes: #13843 Signed-off-by: Ken Takata <kentkt@csc.jp> Signed-off-by: Christian Brabandt <cb@256bit.org>
2024-01-12patch 9.1.0017: [security]: use-after-free in eval1_emsg()v9.1.0017Yegappan Lakshmanan
Problem: use-after-free in eval1_emsg() when an empty line follows a lambda (by @yu3s) Solution: only set evalarg->eval_using_cmdline = FALSE when the *arg pointer is not null fixes: #13833 closes: #13841 Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com> Signed-off-by: Christian Brabandt <cb@256bit.org>