Problem: When 'rnu' is set folded lines are not displayed correctly.
(Vitaly Yashin)
Solution: When only redrawing line numbers do draw folded lines.
(closesvim/vim#3484)
7701f30856
---
Explanation:
Before this patch, relative line numbers would update on a cursor
movement and overwrite fold highlighting in the line number columns.
Other operations can cause the fold highlighting to overwrite the line
number styles. Together, this causes the highlighting in the line number
columns to flicker back and forth while editing.
Test case: create `t.vim` with these contents:
set fdm=marker rnu foldcolumn=2
call setline(1, ["{{{1", "nline 1", "{{{1", "line 2"])
and then call `nvim -u NORC -S t.vim` and press `j`; observe that the fold
highlighting disappears.
Decide whether to highlight the visual-selected character under the
cursor, depending on 'guicursor' style:
- Highlight if cursor is blinking or non-block (vertical, horiz).
- Do NOT highlight if cursor is non-blinking block.
Traditionally Vim's visual selection does "reverse mode", which perhaps
conflicts with the non-blinking block cursor. But 'guicursor' defaults
to a vertical bar for selection=exclusive, and this confuses users who
expect to see the text highlighted.
closes#8983
Problem: Using an external diff program is slow and inflexible.
Solution: Include the xdiff library. (Christian Brabandt)
Use it by default.
e828b7621c
vim-patch:8.1.0360
vim-patch:8.1.0364
vim-patch:8.1.0366
vim-patch:8.1.0370
vim-patch:8.1.0377
vim-patch:8.1.0378
vim-patch:8.1.0381
vim-patch:8.1.0396
vim-patch:8.1.0432
By historical accident, Nvim defaults to background=light. So on a dark
background, `:colorscheme default` looks completely wrong.
The "smart" logic that Vim uses is confusing for anyone who uses Vim on
multiple platforms, so rather than mimic that, pick the (hopefully) most
common default.
- Since Neovim is dark-powered, we assume most users have dark backgrounds.
- Most of the GUIs tend to have a dark background by default.
ref #6289
- window_split_tab_spec.lua: Put cursor at bottom of :terminal buffer so
that it follows output.
- inccommand_spec.lua: Increase timeout to allow 2nd retry.
- Timer tests are less reliable on Travis CI macOS 10.12/10.13.
ref #6829
ref e39dade80b
ref de13113dc1
ref https://github.com/neovim/neovim/pull/9095#issuecomment-429603452
> We don't guarantee that a X ms timer is triggered during Y ms sleep
> for any X<Y, though I would expect the load to be really bad for this
> to happen with X=10ms, Y=40ms.
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.
Problem: Cursorline not removed when using 'cursorbind'. (Justin Keyes)
Solution: Store the last cursor line per window. (closesvim/vim#3488)
4a5abbd613
