Problem: MS-Windows: Cannot interrupt gdb when program is running.
Solution: Add debugbreak() and use it in the terminal debugger.
Respect 'modified' in a prompt buffer.
4551c0a9fc
This makes it possible to restore the working directory of :terminal
buffers when reading those buffers from a session file.
Fixes#11288
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Problem: virtcol() does not check arguments to be valid, which may lead to
a crash.
Solution: Check the column to be valid. Do not decrement MAXCOL.
(closesvim/vim#5480)
b3d33d8570
Problem: Dict and list could be GC'ed while displaying error in a timer.
(Yasuhiro Matsumoto)
Solution: Block garbage collection when executing a timer. Add
test_garbagecollect_soon(). Add "no_wait_return" to
test_override(). (closesvim/vim#4571)
adc6714aac
In a multi-window scenario, it is possible to return focus to the last
accessed window via n_CTRL-W_p. However, in the case of a multi-tab
scenario, there was previously no way to return focus to the last
accessed *tab*. Here, that ability is added via n_g<tab>.
Additionally, the index of the previous tab is exposed via
tabpagenr('#'), mirroring the existing functionality of winnr('#').
Vim's documentation simply states that libcallnr() should be used "for a
function that returns an int". Based on the tests, code, and common
syscall interfaces, this should likely be taken literally instead of
trying to apply some well-defined type lipstick.
Notably, this change fixes Test_libcall_libcallnr on hppa (a 32-bit
big-endian system).
- We already find ourselves renaming nvim_execute_lua in tests and
scripts, which suggests "exec" is the verb we actually want.
- Add "exec" verb to `:help dev-api`.
Problem: Test with "man" fails on FreeBSD.
Solution: Use "-P" instead of "--pager".
c7d2a57b3a
Cherry-picked "has('bsd')" from vim-patch:8.1.0846.
Cherry-picked test_normal.vim fix from vim-patch:8.1.2358
Problem: :const cannot be followed by "| endif".
Solution: Check following command for :const. (closesvim/vim#5269)
Also fix completion after :const.
8f76e6b12b
Multiple Debian builds were failing these tests:
Failures:
From test_environ.vim:
Found errors in Test_external_env():
function RunTheTest[37]..Test_external_env line 16: Expected '' but got 'FOO=null\n'
Found errors in Test_getenv():
function RunTheTest[37]..Test_getenv line 2: Expected v:null but got v:false
Found errors in Test_setenv():
function RunTheTest[37]..Test_setenv line 5: Expected v:null but got 'null'
This is because nvim has a separate tag (`v_special`) in `typval_T` for
special variables, whereas vim re-uses the `v_number` tag.
On little-endian architectures, using the incorrect tag is not an issue
because the byte representation is the same. However, on big-endian
systems this caused the `v_number == kSpecialVarNull` checks to fail,
and the non-special code to execute.
Problem: Heredoc assignment has no room for new features. (FUJIWARA Takuya)
Solution: Require the marker does not start with a lower case character.
(closesvim/vim#4705)
2458200729
Problem: Script line numbers are not exactly right.
Solution: Handle heredoc and continuation lines better. (Ozaki Kiichi,
closesvim/vim#4611, closesvim/vim#4511)
bc2cfe4672
Problem: :let-heredoc does not trim enough.
Solution: Trim indent from the contents based on the indent of the first
line. Use let-heredoc in more tests.
e7eb92708e
- Test fnamemodify()
- Test handling of `expand("%:e:e:r")`.
- Fix :e:e:r on filenames with insufficiently many extensions
During `fnamemodify()`, ensuring that we don't go before the filename's
tail is insufficient in cases where we've already handled a ":e"
modifier, for example:
```
"path/to/this.file.ext" :e:e:r:r
^ ^-------- *fnamep
+------------- tail
```
This means for a ":r", we'll go before `*fnamep`, and outside the bounds
of the filename. This is both incorrect and causes neovim to exit with
an allocation error.
We exit because we attempt to calculate `s - *fnamep` (line 23948).
Since `s` is before `*fnamep`, we caluclate a negative length, which
ends up being interpreted as an amount to allocate, causing neovim to
exit with ENOMEM (`memory.c:xmalloc`).
We must instead ensure we don't go before `*fnamep` nor `tail`.
The check for `tail` is still relevant, for example:
```
"path/to/this.file.ext" :r:r:r
^ ^------------- tail
+--------------------- *fnamep
```
Here we don't want to go before `tail`.
close#11165