aboutsummaryrefslogtreecommitdiff
path: root/test/functional/ui/cmdline_spec.lua
diff options
context:
space:
mode:
authorBjörn Linse <bjorn.linse@gmail.com>2018-10-20 23:43:47 +0200
committerBjörn Linse <bjorn.linse@gmail.com>2018-10-22 11:59:02 +0200
commite598811e76a4ee6666b680545097fb06b0ba59aa (patch)
tree73553d90c1c010bcbe0e8cfef6edf97c61e671be /test/functional/ui/cmdline_spec.lua
parent565bbd1485a4c884dbfdb65b8b1c04a0c5da6b3e (diff)
downloadrneovim-e598811e76a4ee6666b680545097fb06b0ba59aa.tar.gz
rneovim-e598811e76a4ee6666b680545097fb06b0ba59aa.tar.bz2
rneovim-e598811e76a4ee6666b680545097fb06b0ba59aa.zip
ui: disable clearing almost everywhere
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.
Diffstat (limited to 'test/functional/ui/cmdline_spec.lua')
-rw-r--r--test/functional/ui/cmdline_spec.lua11
1 files changed, 5 insertions, 6 deletions
diff --git a/test/functional/ui/cmdline_spec.lua b/test/functional/ui/cmdline_spec.lua
index e86414fe5f..0ebb62f78f 100644
--- a/test/functional/ui/cmdline_spec.lua
+++ b/test/functional/ui/cmdline_spec.lua
@@ -253,7 +253,7 @@ local function test_cmdline(linegrid)
]], cmdline=expectation}
-- erase information, so we check if it is retransmitted
- command("redraw!")
+ command("mode")
screen:expect{grid=[[
^ |
{1:~ }|
@@ -320,7 +320,7 @@ local function test_cmdline(linegrid)
{{' line1'}},
}}
- command("redraw!")
+ command("mode")
screen:expect{grid=[[
^ |
{1:~ }|
@@ -411,7 +411,7 @@ local function test_cmdline(linegrid)
pos = 4,
}}}
- command("redraw!")
+ command("mode")
screen:expect{grid=[[
|
{2:[No Name] }|
@@ -435,9 +435,9 @@ local function test_cmdline(linegrid)
feed("<c-c>")
screen:expect{grid=[[
- |
+ ^ |
{2:[No Name] }|
- {1::}make^ |
+ {1::}make |
{3:[Command Line] }|
|
]], cmdline={{
@@ -446,7 +446,6 @@ local function test_cmdline(linegrid)
pos = 4,
}}}
- screen.cmdline = {}
command("redraw!")
screen:expect{grid=[[
^ |