The old behavior is probably not justified, for the usual reason:
terminal buffers may have interactive processes, so cursor placement is
arbitrary, therefore tracking it in the jumplist is useless (or worse).
N.B.: per the docstring for `checkpcmark()` it looks like we were
calling `checkpcmark()` and `setpcmark()` in the wrong order.
closes#3723
Lua (not LuaJIT) complains about the "^[[" strings inside the expect,
since it sees them as nested quotes. Change the quoting to [=[ ]=] to
avoid the issue.
Use unique filenames to avoid test conflicts.
Use read_file() instead of io.popen(), to ensures the file is closed.
Use helpers.rmdir(), it is far more robust than lfs.
closes#7911
vim-patch:8.0.0175: setting language on MS-Windows does not always work
vim-patch:8.0.0185: system() test fails on MS-Windows
vim-patch:8.0.1435: memory leak in test_arabic
vim-patch:8.0.0424: compiler warnings on MS-Windows
vim-patch:8.0.0434: clang version not correctly detected
vim-patch:8.0.0458: potential crash if adding list or dict to dict fails
Problem: Third item of synconcealed() changes too often. (Dominique Pelle)
Solution: Reset the sequence number at the start of each line.
cc0750dc6ecloses#7589
Fixes#7932
Nvim (tui.c) always enables SGR mouse (TUIData.unibi_ext.enable_mouse).
But if libtermkey sees key_mouse (kmous) in terminfo its terminfo driver
(driver-ti.c) will be activated, which by accident only supports X10
protocol. The libtermkey CSI driver (driver-csi.c), in contrast,
supports SGR.
We can force libtermkey to ignore the terminfo key_mouse entry by
returning NULL in the tui_tk_ti_getstr hook. That forces the CSI driver.
What is the effect of returning NULL from `tui_tk_ti_getstr()`?
- libtermkey `driver-ti.c:load_terminfo()` skips the entry.
- `termkey.c:peekkey()` iterates through all drivers, it finds
`TERMKEY_RES_NONE` for the ti driver and falls back to the CSI driver.
On some versions of macOS, pbcopy doesn't work in tmux <2.6
https://superuser.com/q/231130
Fallback to tmux in that case.
Add a healthcheck for this scenario.
vim-patch:8.0.0358: invalid memory access in C-indent code
Problem: Invalid memory access in C-indent code.
Solution: Don't go over end of empty line. (Dominique Pelle, closesvim/vim#1492)
60629d6425
vim-patch:8.0.0359: 'number' and 'relativenumber' are not properly tested
Problem: 'number' and 'relativenumber' are not properly tested.
Solution: Add tests, change old style to new style tests. (Ozaki Kiichi,
closesvim/vim#1447)
dc9a081712
Per CMAKE docs, CMAKE_HOST_SYSTEM_VERSION is the result of `uname -r`:
https://cmake.org/cmake/help/v3.4/variable/CMAKE_HOST_SYSTEM_VERSION.html?highlight=uname
A numeric version string for the system. On systems that support
uname, this variable is set to the output of uname -r. On other
systems this is set to major-minor version numbers.
On Windows it is something like "6.1", so it won't match ".*-Microsoft".
Closes#7329
