Default styler vs. Themes
Have you ever noticed that the default styler has defined
43 different background and 130 different foreground colors?
I know that it is necessary to define the background color of the
selected line different from the default background color,
and a few others, but 43?
Is a script that would create or update an existing theme
expected to do this in a similar way?
Currently, I was under the impression that when working with a theme,
regardless of the language/lexer used, it would color the variables
the same, as well as the functions, identifiers, etc.
So I would expect all lexers defined in a theme to have the same background color
and ~20 foreground colors, plus the few used internally by Npp, such as for smart highlighting, bracket matches, etc.
Am I wrong?
Alan Kilborn last edited by Alan Kilborn
Is a script that would create or update an existing theme expected to do this in a similar way?
I would say No and that said script could be made to even “clean up” the Default styler. :-)
EDIT: I should also add that that I’m glad you are working on this!
Ekopalypse last edited by Ekopalypse
I’ve been trying to figure out what we’re dealing with here.
Warning in advance, this is going to be a bit more text,
if this is TLDR - jump to the conclusion now.
To understand the easiest way to update an existing theme from stylers.xml
or to generate a new one, I took a look at the individual lexer
configurations and tried to understand what they do.
Basically one can say that there are three types of “lexer configs”.
The ones that lex programming or programming-like language files,
the xml-, json-, yaml-, makefile-, …files of this world
and those used internally by Npp, which are sometimes lexers, sometimes indicators.
The first group of lexers treats the tokens to be colored more or less the same.
There are variables, functions, operators, etc…
Surely one can calculate a subset of them.
The third group, must even be taken over one to one.
By this I don’t mean taking over the colors one to one,
but applying the XML block one to one.
The second group is similar in what they do,
but a subset is difficult to determine,
so it makes more sense to take all the tokens.
This in turn would call into question the usefulness of the lexer grouping.
If I have 2 groups from which I have to take everything
and only one of which I can calculate a subset … then …
(waste of time writing the code ??)
Another approach would be to “normalize” the colors
and use them to create the subsets.
I mean, even inside a lexer, I don’t see much sense in defining
colors like (255,0,0) and (255,10,0), not to mention different lexers.
This means, however, that sooner or later you have to make a cut
to decide when a color is the same or not.
I have searched the web and there are different approaches
and concepts of color theory, wave dynamics, DaVinci, Goethe and Co.
Actually I didn’t want to make a color master degree… but… maybe I have to ;-)
If there is somebody who knows about this stuff
and maybe even knows an algorithm, which can determine colors
which are well visible together, then please report here.
Otherwise, here’s my conclusion:
I think that the script should have the approach to unify the colors.
That is, to normalize colors.
For updating a theme, it “tries” to integrate the existing theme colors into the new lexer config.
For the creation of a new theme, it will probably ask
to specify fore- and background colors and then a sample text,
with pre-defined sample colors is shown, which can then be changed.
Any suggestions in this regard?
(Hopefully this suspiciously awarded Nobel-Prize prose makes any sense at all)
Alan Kilborn last edited by
searched the web and there are different approaches and concepts of color theory…Actually I didn’t want to make a color master degree… but… maybe I have to ;-) If there is somebody who knows about this stuff
Surely you remember THIS THREAD ?
I had this feeling that I read about it once, but wasn’t able to find it anymore.
Thx - I have to reread it and hopefully understand what @guy038 is talking about. :-)
Oooookkkaaaayyyyy - now I’m color blind.
I go to bed.
Good night and stay healthy.
guy038 last edited by guy038
I’m quite willing to give you more explanations about my “series” of messages about colour, especially when it applies to Notepad++.
I can also send you, by e-mail, the total source text, including the different posts, without the Markdown syntax codes, of course. Easy with regexes :-))
Cheers and … stay healthy
Thank you for your offer, yes, it would be nice if you can send it to me.
I guess you are able to get my mail address from my registration, can’t you?
guy038 last edited by
I’m not really sure, because I just see an e-mail address
So, I prefer that you send me, first, a quick e-mail to :
guy038 last edited by
Did you get my other e-mail, with the latest version of the file Eko_Colors.txt ?
I did - replied a few minutes ago.
I was reminded that I still have a skeleton in the closet. :-)
I wanted to take up the topic again and hope to finish it by the end of the week.
I have a question, in the screenshot below the background color is set to 80, 80, 80.
But why can I see the 7th hex value in the 4th line?
Fore- and background color should be the same, right?
PeterJones last edited by PeterJones
background color is set to 80, 80, 80.
mspaint color picker tells me the background is set to decimal 80,80,80, and the foreground is set to hex 0x80,0x80,0x80.
edit: yeah, your pythonscript is calling with decimal arguments, not hex.
oh my … not a good sign … maybe should stop scripting for today :-D
Thank you Peter.