Errors unreadable with cursorline in default color scheme
Nico Weber
`set cursorline` seems to override the background colors even for
characters that are in group Error. With the default color scheme,
this makes Errors unreadable: They are displayed with red background
and white text, and the default cursorline color is a light grey. If
the cursor is in the same line as the error, Errors are displayed
with a light grey background and white text -- barely readable
(tested on gvim/ubuntu and carbon vim/osx).
Any ideas what could be done about this?
Thanks,
Nico
Edward L. Fox
Edward L. Fox
On 9/10/07, Nico Weber <nicola...@gmx.de> wrote:
>
Ingo Karkat
I'm a big fan of 'set cursorline', but I have always wondered why it takes
precedence over any background colors set by syntax highlighting. Any
highlighting that uses a marker-like coloring with inverted text and background
colors suffers from very low contrast when the cursor is on that line. The
'Error' group is the best example, but many plugins (e.g. MultipleSearch.vim)
use similar highlighting, and suffer as well.
How about changing the precedence, so that 'cursorline' is only applied when
there's no background color set by a highlight group? The only problem I can
think of is that when every character in a line has a custom background color,
the cursorline would be invisible, but that's a rather pathological case, isn't it?
-- regards, ingo
PS: The best visual results would be achieved by adding / subtracting the
'cursorline' RGB values from the normal background colors, resulting in an
overall shading of the current line, with any custom highlighting "shining
through". But that algorithm would only work well for non-paletted, 24-bit RGB,
i.e. GVIM, and is thus arguably too specific to implement.
/^-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --
Tony Mechelynck
Find an appropriate color scheme, or write your own. Either change the Error
group (e.g. to _black_ on red), the CursorLine group (e.g. to underlined), or
both.
Best regards,
Tony.
--
My Favorite Drugs [Sung to My Favorite Things]
Reefers and roach clips and papers and rollers
Cocaine and procaine for twenty year molars
Reds and peyote to work out your bugs
These are a few of my favorite drugs.
Uppers and downers and methedrine freakout
Take some amphetamines, watch your brains leak out
Acid and mescaline pull out your plugs
These are a few of my favorite drugs.
Backs that are perfect for carrying monkeys
Users of heroin, often called junkies
Methadone helps then to stop being thugs
Takes them off one of my favorite drugs.
On a bad trip
When the cops come
When I lose my head
I simply take more of my favorite drugs
And then I'm not sad -- I'm dead!
Nico Weber
> the Error
> group (e.g. to _black_ on red), the CursorLine group (e.g. to
> underlined), or
> both.
I prefer Ingo's suggestion -- cursorline shouldn't override
background colors. It doesn't do it for hlsearch either atm. Even if
this is not done, the default (!) colorscheme should Just Work. And
if we expect each and every colorscheme author to manually take care
of this, we can be sure that there are going to be lots of
colorschemes that don't work with cursorline set.
Nico
Tony Mechelynck
I don't expect Bram to implement Ingo's solution, which (IIUC) requires
changing the logic in the C code (but go ahead and fork it yourself if you
want). Writing a colorscheme can be done by anyone: I have my own.
Best regards,
Tony.
--
Major Premise: Sixty men can do a piece of work sixty times as quickly
as one man.
Minor Premise: One man can dig a posthole in sixty seconds.
Conclusion: Sixty men can dig a posthole in one second.
-- Ambrose Bierce, "The Devil's Dictionary"
ap
I have a somewhat related problem :
Setting the cursorline in a vimscript does lag the cursor
like ... a good deal. Since I have not found another
language, where I can reproduce this, it may be
the syntax-file thats causing it. But I have no idea how
this is connected to the cursorline.
This is the case in terminal and gui (linux).
Can someone confirm this ?
:vim -u NONE -U NONE --noplugin ~/.vimrc
( file >~ 10 lines )
:syn enable
:set cursorline
:gui
hhhhhhhhhhlllllllllllllllllllllll
-ap
Bram Moolenaar
Nico Weber wrote:
Not much. Having the syntax background color overrule the 'cursorline'
background color will result in the cursorline to be broken in pieces or
hardly viewable. E.g., when you have a background color for strings and
a line is mostly filled with a string. This looks weird if you move the
cursor up/down.
Ideally the colors would be mixed, but that's quite difficult (and
impossible in a terminal).
--
Nothing is impossible for the man who doesn't have to do it.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Ingo Karkat
> Nico Weber wrote:
>
>> `set cursorline` seems to override the background colors even for
>> characters that are in group Error. With the default color scheme, this
>> makes Errors unreadable: They are displayed with red background and white
>> text, and the default cursorline color is a light grey. If the cursor is in
>> the same line as the error, Errors are displayed with a light grey
>> background and white text -- barely readable (tested on gvim/ubuntu and
>> carbon vim/osx).
>>
>> Any ideas what could be done about this?
>
> Not much. Having the syntax background color overrule the 'cursorline'
> background color will result in the cursorline to be broken in pieces or
> hardly viewable. E.g., when you have a background color for strings and a
> line is mostly filled with a string. This looks weird if you move the cursor
> up/down.
>
> Ideally the colors would be mixed, but that's quite difficult (and impossible
> in a terminal).
>
> E.g., when you have a background color for strings and a line is mostly
> filled with a string.
Okay, but how often (and with how many colorschemes) does this actually occur? I
personally would rather encounter an occasional "weird line" (a mere nuisance,
but still fully readable) than barely readable text (as reported with the Error
group in the default color scheme).
In fact, I have already modified my personal colorscheme (with mixed results)
because I encountered bad readability with the highlighting + cursorline
combination (but didn't want to miss the improved readability of cursorline).
-- ingo
Edward L. Fox
> [...]
> Okay, but how often (and with how many colorschemes) does this actually occur? I
> personally would rather encounter an occasional "weird line" (a mere nuisance,
> but still fully readable) than barely readable text (as reported with the Error
> group in the default color scheme).
I think It's the colorscheme's author's responsibility to keep the
colorscheme readable in any circumstances. So I think the only thing
we need to do to this issue is just a simple one-line patch to the
default colorscheme.
> In fact, I have already modified my personal colorscheme (with mixed results)
> because I encountered bad readability with the highlighting + cursorline
> combination (but didn't want to miss the improved readability of cursorline).
If your modified colorscheme is included in the official colorschemes,
I think you should post your patches to the mailing list. Thanks~
> -- ingo
>
> >
>
Tony Mechelynck
> On 9/10/07, Ingo Karkat <sw...@ingo-karkat.de> wrote:
>> [...]
>> Okay, but how often (and with how many colorschemes) does this actually occur? I
>> personally would rather encounter an occasional "weird line" (a mere nuisance,
>> but still fully readable) than barely readable text (as reported with the Error
>> group in the default color scheme).
>
> I think It's the colorscheme's author's responsibility to keep the
> colorscheme readable in any circumstances. So I think the only thing
> we need to do to this issue is just a simple one-line patch to the
> default colorscheme.
The default.vim colorscheme simply invokes the Vim or gvim defaults, whatever
they may be in the Vim version currently running; it has no ":highlight"
statements: so the patch won't go into the default colorscheme
($VIMRUNTIME/colors/default.vim) which is not even sourced when you run Vim
without a colorscheme, but in the internal default values.
>
>> In fact, I have already modified my personal colorscheme (with mixed results)
>> because I encountered bad readability with the highlighting + cursorline
>> combination (but didn't want to miss the improved readability of cursorline).
>
> If your modified colorscheme is included in the official colorschemes,
> I think you should post your patches to the mailing list. Thanks~
>
>> -- ingo
Writing a personal colorscheme is easy: I have my own
~/.vim/colors/almost-default.vim. Changing the highlighting defaults in the C
or C++ code is a different cup of tea.
Best regards,
Tony.
--
The nice thing about standards is that there are so many of them to
choose from.
-- Andrew S. Tanenbaum
Edward L. Fox
> [...]
>
> The default.vim colorscheme simply invokes the Vim or gvim defaults, whatever
> they may be in the Vim version currently running; it has no ":highlight"
> statements: so the patch won't go into the default colorscheme
> ($VIMRUNTIME/colors/default.vim) which is not even sourced when you run Vim
> without a colorscheme, but in the internal default values.
I knew that. But in fact modifying the internal default values are
also as easy as modifying the external ones. There are two ways for
working around this problem, the first way is making the "Error"
highlight darker, the other way is making the "CursorLine" and
"CursorColumn" darker.
But the first way will probably failed in many situations because
sooooo many syntax files contain "guifg=White". So I think I'll use
the second method:
Index: src/syntax.c
===================================================================
--- src/syntax.c (revision 513)
+++ src/syntax.c (working copy)
@@ -6267,9 +6267,9 @@
#endif
#ifdef FEAT_SYN_HL
CENT("CursorColumn term=reverse ctermbg=LightGrey",
- "CursorColumn term=reverse ctermbg=LightGrey guibg=Grey90"),
+ "CursorColumn term=reverse ctermbg=LightGrey guibg=Grey"),
CENT("CursorLine term=underline cterm=underline",
- "CursorLine term=underline cterm=underline guibg=Grey90"),
+ "CursorLine term=underline cterm=underline guibg=Grey"),
#endif
#ifdef FEAT_AUTOCMD
CENT("MatchParen term=reverse ctermbg=Cyan",
>
> >
> >> In fact, I have already modified my personal colorscheme (with mixed results)
> >> because I encountered bad readability with the highlighting + cursorline
> >> combination (but didn't want to miss the improved readability of cursorline).
> >
> > If your modified colorscheme is included in the official colorschemes,
> > I think you should post your patches to the mailing list. Thanks~
> >
> >> -- ingo
>
> Writing a personal colorscheme is easy: I have my own
> ~/.vim/colors/almost-default.vim. Changing the highlighting defaults in the C
> or C++ code is a different cup of tea.
We say a plate of vegetable and the Americans say a piece of cake.
Ben Schmidt
> impossible in a terminal).
>
> --
>
> Nothing is impossible for the man who doesn't have to do it.
> /// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
LOL.
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
