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.
Problem: Custom operators can't act upon a forced motion. (Christian
Wellenbrock)
Solution: Add the forced motion to the mode() result. (Christian Brabandt,
closesvim/vim#3490)
5976f8ff00closes#8667closes#9476
Christian Wellenbrock:
> For (most) built in text objects it's possible to force operation on
> them to be linewise, for example by using `dVab` (`:h o_V`,
> `motion_force`). When using custom text objects (defined as mappings
> by plugins for example), this doesn't currently work.
>
> Example:
>
> onoremap x viw
>
> Open a file with a few lines each containing some words. With the
> cursor on any word, try:
>
> 1. `dw` (builtin) deletes some characters
> 2. `dVw` (builtin) deletes linewise
> 3. `dx` (from mapping) deletes some characters
> 4. `dVx` (from mapping) deletes some characters, but should delete
> linewise
ref: https://github.com/wellle/targets.vim/issues/214
ref: https://gitter.im/neovim/neovim?at=5b379ff7f1664406610e7483
There is no need to call update_screen() directly in an API function,
mode input processing invokes update_screen() as needed. And if the API
call is done in a context where redraw is disabled, then redraw is
disabled for a reason. A lot of API functions are of equal semantical
strength (nvim_call_function and nvim_execute_lua can also do whatever,
nvim_command is not special), this inconsistency has no purpose.
Problem: Using "gt" sometimes does not redraw a tab. (Jason Franklin)
Solution: Always set must_redraw in redraw_all_later().
04b4e1a424
ref bf3250a8ad (r31852304)
> I fixed it in a more general way, in that if we don't find a window
> that doesn't have the redraw type set it, then it will not set
> must_redraw, even though that's clearly intended.
ref #9152
ref #9155
NA patches:
vim-patch:8.1.0698
vim-patch:8.1.0699
Problem: When test_edit fails 'insertmode' may not be reset and the next
test may get stuck. (James McCoy)
Solution: Always reset 'insertmode' after executing a test. Avoid that an
InsertCharPre autocommand or a 'complete' function can change the
state. (closesvim/vim#3768)
8ad16da729
Problem: Look-behind match may use the wrong line number. (Dominique Pelle)
Solution: Use the line number in regsave instead of the one in behind_pos,
we may be looking at the previous line. (closesvim/vim#3749)
866f355814
Problem: When concealing is active and the screen is resized in the GUI it
is not immediately redrawn.
Solution: Use update_prepare() and update_finish() from
update_single_line().
c10f0e7cb0
Normally we consider OOM to be fatal, but the diff module has extra
functionality to handle OOM in case huge files are compared. Use
try_malloc instead of xmalloc in that case.
This file wasn't used since e1cc0fe996. That may have been
accidental, but it's not needed anymore anyway. Also the "Workaround
for hanging" is no longer relevant.