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 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
memcpy is not equivalent to memmove (which is used by vim_strcat), this
could cause subtle bugs if xstrlcat is used as a replacement for
vim_strcat. But vim_strcat is inconsistent: in the `else` branch it uses
strcpy, which doesn't allow overlap.
Helped-by: oni-link <knil.ino@gmail.com>
Helped-by: James McCoy <jamessan@jamessan.com>
Helped-by: Nikolai Aleksandrovich Pavlov <kp-pav@yandex.ru>
Previously alternate branches were not accounted for properly, with this
change g- after an undo to a branch point works.
The current sequence number b_u_seq_cur is used in undo_time(), in
u_doit() this was calculated by subtracting one from the curhead
sequence number.
The curhead header entry represents the change that was just undone, so
the sequence number we want is that of the change we have moved to. This
is the sequence number of the undo head that is the uh_next element of
this curhead. That sequence number is not always one less than the
curhead sequence number -- there may have been an alternate branch at
this point.
Instead of subtracting one, we now directly find the sequence number of
curhead->uh_next.
Closes#3689
cmake: Add `desktop-install` and `icon-install` targets. `runtime`
target will trigger them.
Specification:
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys
Icons are stored system-wide in /usr/share/applications or user wide at
/usr/share/icons/hicolor/scalable/apps and can be overriden in ~/.local/share/icons
nvim.desktop file can be installed system wide or in
~/.local/share/applications/
To test without an installer:
$ xdg-desktop-menu install --novendor runtime/nvim.desktop
$ xdg-icon-resource install --novendor --mode user --size 64 contrib/nvim-icon.png
Once it is installed, you can test with gtk-launch if installed or
dmenu/rofi (drun mode)
This default causes too much confusion for terminal users. Until
a better approach is implemented, revert to the traditional default.
Better solution would be:
- Implement a right-click menu for TUI
- Set 'mouse=a' *only* if clipboard is working.
Closes#5938
Closes#731
References #851
Note: This does not remove some intentional legacy usages of strncpy.
- memcpy isn't equivalent because it doesn't check the string
length of `src`, and doesn't zero-out the remainder of `dst`.
- xstrlcpy isn't equivalent because it doesn't zero-out the
remainder of `dst`. Some Vim logic depends on that (e.g.
ex_append which calls vim_strnsave).
Helped-by: Douglas Schneider <ds3@ualberta.ca>
Helped-by: oni-link <knil.ino@gmail.com>
Helped-by: James McCoy <jamessan@jamessan.com>
As discussed in neovim/neovim#5977, it's typical for the terminfo
database to disable cursor blink as part of setting up the normal
cursor. Since this interferes with the user's control over the cursor,
we'll skip over DECRST 12 if it starts the cursor_normal entry.
Note, this doesn't handle any case where DECRST 12 is not at the start
of the entry since unibilium simply stores the given pointer. We would
need to allocate (and somewhere free) a modified copy of what we get
back from unibi_get_str to handle that.
`find_command(s->ca.cmdchar) >= 0` was established near the start of
normal_execute(). And `unshift_special(&s->ca);` "should" not ever
result in s->ca.cmdchar containing a multibyte char.
So only an assert() is needed here.
