Open muffin4 opened 3 years ago
Hello,
By using the 'final' attribute you can ensure that no other face will override it later. For example this is from my configuration face global Whitespace rgb:363636+f
@occivink thanks for the tip! That certainly improves it.
I would however still prefer it, if the symbols were in a color based on the surrounding code/text.
Kakoune does support color blending, but since the comment
whitespace doesn't use alpha values in most (all?) colorschemes, it actually does override the value.
face global Whitespace rgb:dddddd # gray
face global comment rgba:05989a99 # cyan, as specified in my terminals' colorscheme, and AA=99
I wonder whether it would be possible to specify "the color my colorscheme is already using, but AA=99"? Also, since the comment face seems to be applied "later"(?) this has some implications on comment color also being "less intense" when not in whitespace, I think. This would however need to be done for every face in the colorscheme...
Does #4269 solve your issue?
Does #4269 solve your issue?
Sorry for not responding for such a long time. It seems that whether this works heavily depends on the colorscheme used. For bright colorschemes this doesn't make any difference:
Reproduce with:
env KAKOUNE_CONFIG_DIR=/tmp kak -e 'add-highlighter global/ show-whitespaces' /tmp/test.c
Interactively switching set-face global Whitespace default,default+fd
with +d
doesn't show any visible difference either (in white on black theme and the like). In Solarized Light it's even more prominent:
"dimmed"
"undimmed"
I think that the best thing would be to blend the current color and filter it to be dimmed.
Alternatively, the "dimming" logic needs to be reworked to blend with the background color. This is what was done in the hack here https://github.com/ljrk0/config/pull/4 since the background color is white and foreground black, 0xdddddd is the result of an effectively blended/dimmed foreground.
It seems that whether this works heavily depends on the colorscheme used.
Alternatively, the "dimming" logic needs to be reworked to blend with the background color.
Kakoune doesn't actually have any dimming logic, it just sends the encoded face information to your terminal as-is. There's a "dim" flag, but for most terminals it only affects the standard 16 colour palette, not arbitrary RGB colours.
If you're using an RGB colour scheme and want whitespace symbols to blend into their context without copying it exactly, you'll need to modify the colour in the scheme itself.
4269 only changes the default colour scheme, not other colour schemes.
Sorry, this was unclear, I was referring to the terminal emulator's colorscheme, not kakounes.
Kakoune doesn't actually have any dimming logic, it just sends the encoded face information to your terminal as-is. There's a "dim" flag, but for most terminals it only affects the standard 16 colour palette, not arbitrary RGB colours.
Ah, if it works using SGR then this does seem to be a GNOME Terminal bug? Indeed, with kitty the colours are more dimmed, even when using a bright terminal emulator color scheme.
If you're using an RGB colour scheme and want whitespace symbols to blend into their context without copying it exactly, you'll need to modify the colour in the scheme itself.
I don't think that is possible using the kakoune colourscheme, since this would require being able to set different Whitespace colours depending on the current context (in-comment, in-string, ...).
Yeah, I use alacritty and specify dimmed colours in my theme, so, it works fine. In other terminals support is limited.
The whitespace colour isn't based upon context; it's always the same regardless of it. So, whitespace colour for comments and code is the same.
Feature
An option or parameter for a highlighter to modify the current face.
Usecase
highlighting whitespace in the appropriate color for the context (like comment or string literals) but dimmed to be less intrusive
I have the following in my kakrc to display sympols on top of whitespaces in a dark grey to make whitespaces more explicit without distracting too much from the relevant buffer content.
Unfortunately other hightlighters seem to override the used facing. So whitespaces aren't always displayed with the Whitespace face. As an example: whitespace in comments is displayed with the comment's face. It would be fine for the whitespace to be displayed with the regular comment face, but dimmed (when using a dark color scheme).
56 makes mention of dimming, but it doesn't contain use cases, so I didn't feel like it was appropriate to comment there.