Fix MultiElementHandler to work with non-gui terminals that have termguicolors set. #22
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…guicolors set.
A "MultiElement", aka a color escape sequence like '\e\[38;5;123m',
is used for "True color" terminals and/or GUI.
Setting the vim variable 'termguicolors' means "use gui colors also in the
terminal, because I know it can handle truecolors (24bit)".
In other words, you basically always want to have termguicolors set
if you are at all interested in MultiElement color escapes and are
on a non-gui terminal like for example konsole (that DOES handle
24bit colors).
The way this works (setting 'termguicolors') is that of the syntax
highligting rules the 'gui=<24bit color>' is used, not the
'cterm=<indexed terminal color>' (same for guifg, ctermfg, guibg and
ctermbg).
It is completely safe to generate syntax rules that contain both;
a GUI will use the 'gui*=' arguments, and ignore the 'cterm*='
arguments, while a non-gui terminal will use the 'cterm*=' arguments
and ignore the 'gui*=' argument UNLESS termguicolors is set, of course,
then it act likes a GUI in that regard.
Not that has("gui") is still 0 for non-gui terminals, even if they
have termguicolors set.
The right thing to do therefore is to not set for has("gui") when
dealing with color codes. One should either test if termguicolors
is set, or simpler, just generate both the 'cterm*=' and 'gui*='
argument.
Owner
|
Sounds reasonable. I'll add few review comments now, plus please provide some example to let me test it before merging. |
powerman
requested changes
Feb 5, 2023
| let fg= code | ||
| endif | ||
| let fg= code | ||
| let guifg= s:Ansi2Gui(code) |
Owner
There was a problem hiding this comment.
Probably you should define both new vars in function header, just like existing vars were defined.
| endif | ||
| " call Decho(" exe hirule: ".hirule) | ||
| let hirule=hirule." cterm=".mod." gui=".mod | ||
| if fg != ""| let hirule=hirule." ctermfg=".fg." guifg=".guifg| endif |
Owner
There was a problem hiding this comment.
Probably it makes sense to check both (fg OR guifg is set), and same on next line.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
A "MultiElement", aka a color escape sequence like '\e[38;5;123m', is used for "True color" terminals and/or GUI.
Setting the vim variable 'termguicolors' means "use gui colors also in the terminal, because I know it can handle truecolors (24bit)".
In other words, you basically always want to have termguicolors set if you are at all interested in MultiElement color escapes and are on a non-gui terminal like for example konsole (that DOES handle 24bit colors).
The way this works (setting 'termguicolors') is that of the syntax highligting rules the 'gui=<24bit color>' is used, not the 'cterm=' (same for guifg, ctermfg, guibg and ctermbg).
It is completely safe to generate syntax rules that contain both; a GUI will use the 'gui*=' arguments, and ignore the 'cterm*=' arguments, while a non-gui terminal will use the 'cterm*=' arguments and ignore the 'gui*=' argument UNLESS termguicolors is set, of course, then it act likes a GUI in that regard.
Not that has("gui") is still 0 for non-gui terminals, even if they have termguicolors set.
The right thing to do therefore is to not test for has("gui") when dealing with color codes. One should either test if termguicolors is set, or simpler, just generate both the 'cterm*=' and 'gui*=' argument.