Problem: Internally used commands for CTRL-Z and mouse click end up in
history. (Matthew Malcomson)
Solution: Use do_cmdline_cmd() instead of stuffing them in the readahead
buffer. (James McCoy, closesvim/vim#1395)
25b0e6b701Closes#5966Closes#5967
Problem: When checking for CTRL-C typed the GUI may detect a screen resize
and redraw the screen, causing trouble.
Solution: Set updating_screen in ui_breakcheck().
e3caa11090
v7.4.2024 changed a few function signatures of functions that we use in
Neovim-specific code, e.g. the API.
Due to that the commit for 7.4.2024 doesn't build on its own, only together with
this commit.
Problem: More buf_valid() calls can be optimized.
Solution: Use bufref_valid() instead.
NOTE: Some changes related to channels and the Python and Netbeans interfaces
were obviously left out.
7c0a2f367f
Problem: buflist_findname_stat() may find a dummy buffer.
Solution: Set the BF_DUMMY flag after loading a dummy buffer. Start
finding buffers from the end of the list.
NOTE: In Neovim, buflist_findname_stat() was replaced by
buflist_findname_file_id() in c41535d69.
ea3f2e7be4
Problem: buf_valid() can be slow when there are many buffers.
Solution: Add bufref_valid(), only go through the buffer list
when a buffer was freed.
b25f9a97e9
Problem: When there are many errors adding them to the quickfix list takes
a long time.
Solution: Add BLN_NOOPT. Don't call buf_valid() in buf_copy_options().
Remember the last file name used. When going through the buffer
list start from the end of the list. Only call buf_valid() when
autocommands were executed.
8240433f48
Problem: When update_single_line() is called recursively, or another screen
update happens while it is busy, errors may occur.
Solution: Check and update updating_screen. (Christian Brabandt)
070b33da93
patch 8.0.0280: problem setting multi-byte environment var on MS-Windows
Problem: On MS-Windows setting an environment variable with multi-byte
strings does not work well.
Solution: Use wputenv when possible. (Taro Muraoka, Ken Takata)
7c23d1d9d9cc
This was a workaround from long ago, but it doesn't seem to be needed
anymore. And it breaks the $PATH on the Windows build (AppVeyor CI).
After this change python3 (and 2) is correctly detected on AppVeyor CI.
References #5946
This allows executables to be found by :!, system(), and executable() if
they live next to ("sibling" to) nvim.exe. This is what gvim on Windows
does, and also matches the behavior of Win32 SearchPath().
c4a249a736/src/os_win32.c (L354-L370)
bridge.width and bridge.height reach ui.c:ui_refresh() when it iterates
through all UIs, so they do not need to be set directly by
tui.c:update_size().
Race found by helgrind:
==18532== Helgrind, a thread error detector
==18532== Copyright (C) 2007-2015, and GNU GPL'd, by OpenWorks LLP et al.
==18532== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==18532== Command: ./build/bin/nvim -u NONE --cmd set\ rtp+=~/.vim/bundle/vimfiler.vim,~/.vim/bundle/unite.vim --cmd runtime\ plugin/vimfiler.vim --cmd runtime\ plugin/unite.vim
==18532== Parent PID: 6477
==18532==
==18532== ---Thread-Announcement------------------------------------------
==18532==
==18532== Thread #2 was created
==18532== at 0x68FA98E: clone (clone.S:73)
==18532== by 0x5270179: create_thread (createthread.c:102)
==18532== by 0x5271BE2: pthread_create@@GLIBC_2.2.5 (pthread_create.c:679)
==18532== by 0x4C32B07: pthread_create_WRK (hg_intercepts.c:427)
==18532== by 0x4E53A3F: uv_thread_create (in /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0)
==18532== by 0x6A7154: ui_bridge_attach (ui_bridge.c:89)
==18532== by 0x6A164C: tui_start (tui.c:116)
==18532== by 0x6A4CFC: ui_builtin_start (ui.c:89)
==18532== by 0x55A825: main (main.c:433)
==18532==
==18532== ---Thread-Announcement------------------------------------------
==18532==
==18532== Thread #1 is the program's root thread
==18532==
==18532== ----------------------------------------------------------------
==18532==
==18532== Possible data race during write of size 4 at 0x770E7B4 by thread #2
==18532== Locks held: none
==18532== at 0x6A3071: update_size (tui.c:759)
==18532== by 0x6A30DB: sigwinch_cb (tui.c:269)
==18532== by 0x4D0A54: signal_event (signal.c:44)
==18532== by 0x4CDDB6: multiqueue_process_events (multiqueue.c:146)
==18532== by 0x4CD135: loop_poll_events (loop.c:56)
==18532== by 0x6A2451: tui_main (tui.c:239)
==18532== by 0x6A857A: ui_thread_run (ui_bridge.c:112)
==18532== by 0x4E539F6: ??? (in /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0)
==18532== by 0x4C32D06: mythread_wrapper (hg_intercepts.c:389)
==18532== by 0x5271423: start_thread (pthread_create.c:333)
==18532== by 0x68FA9BE: clone (clone.S:105)
==18532==
==18532== This conflicts with a previous read of size 4 by thread #1
==18532== Locks held: none
==18532== at 0x6A542A: ui_refresh (ui.c:169)
==18532== by 0x6A5870: ui_refresh_event (ui.c:181)
==18532== by 0x4CDDB6: multiqueue_process_events (multiqueue.c:146)
==18532== by 0x4CD135: loop_poll_events (loop.c:56)
==18532== by 0x5DEDB4: os_breakcheck (input.c:150)
==18532== by 0x59263D: line_breakcheck (misc1.c:2667)
==18532== by 0x621AE5: nfa_regmatch (regexp_nfa.c:6171)
==18532== by 0x61DCF7: nfa_regtry (regexp_nfa.c:6240)
==18532== Address 0x770e7b4 is 4 bytes inside a block of size 352 alloc'd
==18532== at 0x4C2EFE5: calloc (vg_replace_malloc.c:711)
==18532== by 0x57C962: xcalloc (memory.c:119)
==18532== by 0x6A6E29: ui_bridge_attach (ui_bridge.c:53)
==18532== by 0x6A164C: tui_start (tui.c:116)
==18532== by 0x6A4CFC: ui_builtin_start (ui.c:89)
==18532== by 0x55A825: main (main.c:433)
==18532== Block was alloc'd by thread #1
==18532==
==18532== ----------------------------------------------------------------
==18532==
==18532== Possible data race during write of size 4 at 0x770E7B8 by thread #2
==18532== Locks held: none
==18532== at 0x6A3085: update_size (tui.c:760)
==18532== by 0x6A30DB: sigwinch_cb (tui.c:269)
==18532== by 0x4D0A54: signal_event (signal.c:44)
==18532== by 0x4CDDB6: multiqueue_process_events (multiqueue.c:146)
==18532== by 0x4CD135: loop_poll_events (loop.c:56)
==18532== by 0x6A2451: tui_main (tui.c:239)
==18532== by 0x6A857A: ui_thread_run (ui_bridge.c:112)
==18532== by 0x4E539F6: ??? (in /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0)
==18532== by 0x4C32D06: mythread_wrapper (hg_intercepts.c:389)
==18532== by 0x5271423: start_thread (pthread_create.c:333)
==18532== by 0x68FA9BE: clone (clone.S:105)
==18532==
==18532== This conflicts with a previous read of size 4 by thread #1
==18532== Locks held: none
==18532== at 0x6A5455: ui_refresh (ui.c:170)
==18532== by 0x6A5870: ui_refresh_event (ui.c:181)
==18532== by 0x4CDDB6: multiqueue_process_events (multiqueue.c:146)
==18532== by 0x4CD135: loop_poll_events (loop.c:56)
==18532== by 0x5DEDB4: os_breakcheck (input.c:150)
==18532== by 0x59263D: line_breakcheck (misc1.c:2667)
==18532== by 0x621AE5: nfa_regmatch (regexp_nfa.c:6171)
==18532== by 0x61DCF7: nfa_regtry (regexp_nfa.c:6240)
==18532== Address 0x770e7b8 is 8 bytes inside a block of size 352 alloc'd
==18532== at 0x4C2EFE5: calloc (vg_replace_malloc.c:711)
==18532== by 0x57C962: xcalloc (memory.c:119)
==18532== by 0x6A6E29: ui_bridge_attach (ui_bridge.c:53)
==18532== by 0x6A164C: tui_start (tui.c:116)
==18532== by 0x6A4CFC: ui_builtin_start (ui.c:89)
==18532== by 0x55A825: main (main.c:433)
==18532== Block was alloc'd by thread #1
When test/functional/eval/system_spec.lua is run on its own,
helpers.os_name() was being called before a session had been created.
This caused that describe block to fail.
Turning printargs_path into a function delays the call of
helpers.os_name() until the test is being run, which ensures a session
is available.
