Thanks. I don’t know why I didn’t try 0x when # didn’t work.

But yes, having that in the documentation is a definite improvement.

The other thing I would suggest in the comments would be to phrase it:

; A colour is a number in the range 0 - 16777215.
; The notation is either pure digits or a hex notation starting with 0x or #, 
; such as 0xff00ff or #ff00ff.
; Please note: 
; * red goes in the lowest byte (0x0000FF)
; * green goes in the center byte (0x00FF00)
; * blue goes in the biggest byte (0xFF0000) 
; * this BGR order might conflict with your expectation of RGB order.
; * see Microsoft COLORREF documentation https://docs.microsoft.com/en-us/windows/win32/gdi/colorref

@LogicSequence - can I ask you how I can improve the documentation in the config file to make it easier to understand for starters?

you need to invert the red and blue value before putting into a converter to get the color to display properly (i think this is probably a bug?

No bug, really. It originates with how Windows decided to handle colors, i.e., in the COLORREF definition, see HERE.

So if you want, say, darkish purple, it would be a HEX value of #80 00 ff, but if you convert that value to DEC it won’t show properly. You have to input #ff 00 80 to get it to work. Just FYI for anyone wondering why colors aren’t working as they might have expected.

I had only previously used Eko’s pythonscript-based version. But since you asked so nice (well, actually, because I was curious as to how the interface would be), I downloaded it, and within about 10 minutes was able to get it to:

At the end of your EnhanceAnyLexerConfig.ini, add:

[xml]
16711935 = \b(KeywordLists|WordsStyle)\b

Amazingly, the plugin sees that the file has changed, and applies the changes instantly.

In case you were curious as to my figuring-out procedure, I took the example python from that file:

;[python]
;1077960 = \b(cls|self)\b
;excluded_styles = 1,3,4,6,7,12,16,17,18,19

Uncommented (removed the ;) and changed the header to [xml] instead of [python]. I then created some dummy tags in my example file that were <cls> and <self>, and saw they were a mustardy color. So that implies it was actually doing something. Then I added KeywordLists to the regex, so it said ` \b(cls|self|KeywordLists)\b, and now that tag is also mustard. Eureka!

To change the color, I know that colors are usually 0xRRGGBB or 0xBBGGRR (and I knew that Notepad++ used the latter) – it would be nice if @Ekopalypse would add a note about the color values in the example ini. So I saw your color was 0xFF00FF. (which then doesn’t matter which is red and which is blue). I converted that to decimal, which is 16711935, and replaced that. It changed to purply text! WooHoo!

I then added WordsStyle after a new | and got rid of the cls|self|, yielding the config file section I showed originally.

The excluded styles will help you avoid coloring those same terms in unwanted lexer situations, but that’s not critical from the get-go.

So, that’s working. Expanding to more keywords is up to you. For a beta plugin, that was easy enough.

( @Ekopalypse , my other suggestion would be to allow #BBGGRR as the color value as well. But great conversion from the original pythonscript, BTW.)

Nevermind stupid mistake on my part.

is there a way to Edit the Default XML highlighting to include keyword highlighting?

Nope.

Suggest you look into “EnhanceAnyLexer” plugin. It lets a default lexer do its job and then adds to it. See HERE.