kevin/neovim
1
Fork 0
mirror of https://github.com/neovim/neovim.git synced 2024-12-23 20:55:18 -07:00
Code Issues Packages Projects Releases Wiki Activity

ui: revert "gui_running" hack

Browse Source 
Plugins (YCM, dispatch.vim) use gui_running to decide behavior; so do
some colorschemes. Up to now, nvim lied about gui_running for the
benefit of colorschemes and the detriment of all _other_ plugins that
check this condition. That's counterproductive: a user employs at most
_one_ colorscheme but may use many other plugins which expect the Vim
legacy semantics of gui_running.

Moreover, colorschemes usually don't _need_ to check gui_running: they
can instead set cterm{fg,bg} and gui{fg,bg} in the same :highlight call.

It is reasonable for users who want "true color" to modify their
colorscheme once (or request upstream to do so) in order to avoid
running into quirks in any other plugins.

Closes #2782
This commit is contained in:
Justin M. Keyes 2016-02-03 00:49:32 -05:00
parent 3d15cab29d
commit 79a6983c0c
2 changed files with 0 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
src/nvim/eval.c
View File

@ -10988,8 +10988,6 @@ static void f_has(typval_T *argvars, typval_T *rettv)
#endif
} else if (STRICMP(name, "syntax_items") == 0) {
n = syntax_present(curwin);
} else if (STRICMP(name, "gui_running") == 0) {
n = ui_rgb_attached();
}
}

9
test/functional/ui/highlight_spec.lua
View File

@ -14,15 +14,6 @@ describe('color scheme compatibility', function()
request('vim_set_option', 't_Co', '88')
eq('88', request('vim_eval', '&t_Co'))
end)
it('emulates gui_running when a rgb UI is attached', function()
eq(0, request('vim_eval', 'has("gui_running")'))
local screen = Screen.new()
screen:attach()
eq(1, request('vim_eval', 'has("gui_running")'))
screen:detach()
eq(0, request('vim_eval', 'has("gui_running")'))
end)
end)