Open acidrums4 opened 3 months ago
I've known about this for a while but I haven't invested the time to write a proper fix. There is an old assumption here: https://github.com/martanne/vis/blob/2d87fdc0d088b12571b0c695549106b766585a92/ui.h#L37 that the number of lexer styles is small but in new scintillua that does not seem to be the case. The function for defining styles returns a bool status but that is never checked in the lua code. HTML probably has more styles than the maximum and so a lot of them are just not getting stored and failing silently.
(Below is an outline of what I think should be done, I'm leaving it here as a good first issue for someone else to solve).
UI_STYLE_LEXER_MAX
should be increased and the lua code should check if it actually succeeds in defining the style. The maximum style id that gets defined should also be stored somewhere accessible from lua so that users/plugins that want to define their own styles know which slots are available. Also a test should be written that loops through the lexers and checks that they can successfully define all their styles (plus some headroom for users/plugin authors).
I've known about this for a while but I haven't invested the time to write a proper fix. There is an old assumption here:
https://github.com/martanne/vis/blob/2d87fdc0d088b12571b0c695549106b766585a92/ui.h#L37
that the number of lexer styles is small but in new scintillua that does not seem to be the case. The function for defining styles returns a bool status but that is never checked in the lua code. HTML probably has more styles than the maximum and so a lot of them are just not getting stored and failing silently.
(Below is an outline of what I think should be done, I'm leaving it here as a good first issue for someone else to solve).
UI_STYLE_LEXER_MAX
should be increased and the lua code should check if it actually succeeds in defining the style. The maximum style id that gets defined should also be stored somewhere accessible from lua so that users/plugins that want to define their own styles know which slots are available. Also a test should be written that loops through the lexers and checks that they can successfully define all their styles (plus some headroom for users/plugin authors).
Something about whitespace handling seems to be inherently off, as this occurs with all filetypes i tested so far. Even increasing UI_STYLE_LEXER_MAX
does not help.
the HTML attributes are being painted with a color set for the shell/terminal emulator, green, rather than the colors set in the vis theme
Setting lexers.STYLE_ATTRIBUTE on my theme allowed me to change the colors of HTML attributes. Is this a theme issue then?
Setting lexers.STYLE_ATTRIBUTE on my theme allowed me to change the colors of HTML attributes. Is this a theme issue then?
I'd like you to share your theme then, as I haven't been able to replicate that - as said, not even the default themes that are shipped with vis are using the colors set in the theme. Everyone paints HTML attributes with the same green from the terminal emulator theme (and "unknown" tags like <svg>
with the same red from the terminal emulator theme.
Problem
There's something since 0.9 going on and it's bugging me out a bit: some (text) colors set in the current theme are not being used by vis.
I've noticed this specially with HTML files - for example, the HTML attributes are being painted with a color set for the shell/terminal emulator, green, rather than the colors set in the vis theme. No matter what theme is used, those are always being painted with the green color set for the shell/terminal emulator.
On the other hand, tabs are being painted with the default text color set in the vis theme rather than the color set by lexers.STYLE_WHITESPACE.
Steps to reproduce
set showtabs
vis version (vis -v)
vis 0.9 +curses +lua +tre +acl
Terminal name/version
konsole 24.05.2
$TERM environment variable
xterm-256color