09d4133 changed blocknr_T from long to int64_t, so pe_bnum is now always 64-bit. This was an incompatible change in the swapfile format for 32-bit systems, but there have been no complaints in the past 9 years so just adjust the test.
(cherry picked from commit a1ded1b113)
Problem: Using negative array index with negative width window.
Solution: Make sure the window width does not become negative.
8279af514c
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Using freed memory with cmdwin and BufEnter autocmd.
Solution: Make sure pointer to b_p_iminsert is still valid.
1c3dd8ddcb
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Reading before the start of the line.
Solution: When displaying "$" check the column is not negative.
e98c88c44c
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Confusing error when using "q:" in command line window.
Solution: Check for the situation and give a better error message.
(closesvim/vim#10756)
c963ec31a0
Co-authored-by: Bram Moolenaar <Bram@vim.org>
backport #26034
Problem:
'nofsync' may lose data if the system has a hard shutdown. #9888
Solution:
Change default to 'fsync'. This may be revisited in the future when
'nofsync' can be made safer.
Co-authored-by: Ploum <1233155+ploum@users.noreply.github.com>
Problem:
The next command after `silent !{cmd}` or `silent lua print('str')`
prints an empty line before printing a message, because these commands
set `msg_didout = true` despite not printing any messages.
Solution:
Set `msg_didout = true` only if `msg_silent == 0`
"VimEnter foo" was accepted as a valid event name for "VimEnter".
Events delimited with commas, eg. "VimEnter,BufRead", were also
accepted, even though only the first event was actually parsed.
(cherry picked from commit 1397016259)
Problem: Cursor is adjusted in window that did not change in size by
'splitkeep'.
Solution: Only check that cursor position is valid in a window that
has changed in size.
closes: vim/vim#1250916af913eee
Co-authored-by: Luuk van Baal <luukvbaal@gmail.com>
Problem: Cursor not adjusted when near top or bottom of window and
'splitkeep' is not "cursor".
Solution: Move boundary checks to outer cursor move functions, inner
functions should only return valid cursor positions. (Luuk van
Baal, closesvim/vim#12480)
a109f39ef5
Problem: Custom cmdline completion skips original cmdline when pressing
Ctrl-P at first match if completion function invokes glob().
Solution: Move orig_save into struct expand_T.
closes: vim/vim#1321628a23602e8
Problem:
Crash from:
set cmdheight=0 redrawdebug=invalid
resize -1
Solution:
Do not invalidate first `p_ch` `msg_grid` rows in `update_screen` when
scrolling the screen down after displaying a message, because they may
be used later for drawing cmdline.
Fixes#22154
Linux added these types to their userspace headers in [6.5], which
causes unit tests to fail like
```
-------- Running tests from test/unit/api/private_helpers_spec.lua
RUN vim_to_object converts true: 17.00 ms ERR
test/unit/helpers.lua:748: test/unit/helpers.lua:732: (string) '
test/unit/helpers.lua:264: ';' expected near '__s128' at line 194'
exit code: 256
stack traceback:
test/unit/helpers.lua:748: in function 'itp_parent'
test/unit/helpers.lua:784: in function <test/unit/helpers.lua:774>
```
Since we don't use these types, they can be ignored to avoid LuaJIT's C
parser choking on them.
[6.5]: 224d80c584
(cherry picked from commit 0df0e1198b)
Problem: CursorHoldI event interferes with "CTRL-G U". (Naohiro Ono)
Solution: Restore the flag for "CTRL-G U" after triggering CursorHoldI.
(closesvim/vim#8937)
5a9357d0bf
Co-authored-by: Bram Moolenaar <Bram@vim.org>
(cherry picked from commit a5445f5435)
Problem: :unhide does not check for failing to close a window.
Solution: When closing a window fails continue with the next one. Do not
try closing the autocmd window. (closesvim/vim#9984)
6f2465d336
Co-authored-by: Bram Moolenaar <Bram@vim.org>
(cherry picked from commit 6c4ef7eca6)
Problem: r_CTRL-C works differently in visual mode
Solution: Make r_CTRL-C behave consistent in visual mode
in terminal and Windows GUI
in visual mode, r CTRL-C behaves strange in Unix like environments. It
seems to end visual mode, but still is waiting for few more chars,
however it never seems to replace it by any characters and eventually
just returns back into normal mode.
In contrast in Windows GUI mode, r_CTRL-C replaces in the selected area
all characters by a literal CTRL-C.
Not sure why it behaves like this. It seems in the Windows GUI, got_int
is not set and therefore behaves as if any other normal character has
been pressed.
So remove the special casing of what happens when got_int is set and
make it always behave like in Windows GUI mode. Add a test to verify it
always behaves like replacing in the selected area each selected
character by a literal CTRL-C.
closes: vim/vim#13091closes: vim/vim#13112476733f3d0
Co-authored-by: Christian Brabandt <cb@256bit.org>
(cherry picked from commit d2678c78dc)
fix: invoke changed_bytes when rewriting tabs
When tabstop and shiftwidth are not equal, tabs are inserted as individual
spaces and then rewritten as tab characters in a second pass. That second pass
did not call changed_bytes which resulted in events being omitted.
Fixes#25092
(cherry picked from commit 7476715765)
Co-authored-by: Ilia Choly <ilia.choly@gmail.com>
Problem: Undo is synced after character find.
Solution: Set no_u_sync when calling gotchars_nop().
closes: vim/vim#13022closes: vim/vim#13024dccc29c228
(cherry picked from commit 311386c09f)
