Problem: Relative cursor position is not calculated correctly.
Solution: Always set topline, also when window is one line only.
(Robert Webb) Add more info to getwininfo() for testing.
8fcb60f961
Previously the mouse tests set 'listchars', but not 'list'. Funnily enough, the
space, where the `$` would normally appear, would still use new highlight group.
Set 'list' for good and fix the tests accordingly.
In vim, scrolling a window might mess up the cmdline. To keep it simple,
cmdline was always cleared for any window scroll. In nvim, where safe scrolling
is implemented in the TUI layer, this problem doesn't exist.
Clearing the message on scrolling, when we not do it e.g when switching tabs
is a bit weird, as the former is a much smaller context change.
A vim patch introduced the possibility to avoid the cmdlline clear for
redraws caused by async events. This case will now trivially be covered,
as the redraw is always avoided.
vim-patch:8.0.0592: if a job writes to a buffer screen is not updated
Avoid clearing the screen in most situations. NOT_VALID should be
equivalent to CLEAR unless some external force messed up the terminal,
for these situations <c-l> and :mode will still clear the screen.
Also eliminate some obsolete code in screen.c, that dealt with that in
vim drawing window 1 can mess up window 2, but this never happens in
nvim.
But what about slow terminals? There is two common meanings in which
a terminal is said to be "slow":
Most commonly (and in the sense of vim:s nottyfast) it means low
bandwidth for sending bytes from nvim to the terminal. If the screen is
very similar before and after the update_screen(CLEAR) this change
should reduce bandwidth. If the screen is quite different, but there is
no new regions of contiguous whitespace, clearing doesn't reduce
bandwidth significantly. If the new screen contains a lot of whitespace,
it will depend of if vsplits are used or not: as long as there is no
vsplits, ce is used to cheaply clear the rest of the line, so
full-screen clear is not needed to reduce bandwith. However a left
vsplit currently needs to be padded with whitespace all the way to the
separator. It is possible ec (clear N chars) can be used to reduce
bandwidth here if this is a problem. (All of this assumes that one
doesn't set Normal guibg=... on a non-BCE terminal, if you do you are
doomed regardless of this change).
Slow can also mean that drawing pixels on the screen is slow. E-ink
screens is a recent example. Avoiding clearing and redrawing the
unchanged part of the screen will always improve performance in these
cases.
helpers.skip_fragile() already skips the problematic tests
on the ASan build. But the 15s timeout plus 5s 'mousetime'
cause the tests to take 1+ minutes anyways.
Hope this will make people using feed_command less likely: this hides bugs.
Already found at least two:
1. msgpackparse() will show internal error: hash_add() in case of duplicate
keys, though it will still work correctly. Currently silenced.
2. ttimeoutlen was spelled incorrectly, resulting in option not being set when
expected. Test was still functioning somehow though. Currently fixed.
Let the terminal dictate the normal-mode cursor position. This will be
disorienting sometimes, but it is closer to what users expect vs always
going to the last line.
These tests fail on master, so it's not a regression. Changes in #4874
(parent commit) seem to work (and pass most CI), so skipping these tests
is better than blocking the changes.
- Use the default buffer text provided by before_each (avoids extra steps and
makes the tests more consistent with each other)
- Indent
- Adjust help doc
It is otherwise impossible to determine which test failed sanitizer/valgrind
check. test/functional/helpers.lua module return was changed so that tests which
do not provide after_each function to get new check will automatically fail.
- Code from Vim source.
- Removed the check for 'guioptions'
- mouse_spec.lua: test <ScrollWheelLeft> and <ScrollWheelRight>
- Move horizontal scroll logic to mouse.c
- Remove 'gui_' from the function names
- Renamed variables to be more specific (as opposed to generic p, w).
- Marked some functions as `static`
This is consistent with VIM behavior. When showing a visual selection,
VIM only extends it past the last character if eol is in listchars (even
if nolist is set).
The test was hoping to not find a tags file, but didn't actively guard
against it. In my case, I had a tags file present which was causing
different output to be generated. To fix this, let's set the tags
option to look for an unlikely filename.