[HTML] Feature request: Please add option for more than 1 keyword list in HTML Lexer (for PHP keywords)

[mdrmdrmdr]

I recently tried to add the most recent PHP V8.3.10 keywords, constants and language constructs to stylers.xml and langs.xml from Notepad++. As it did not work es expected, I asked here in the Notepad++ community how to do it. They said "Lexilla issue".

Therefore I'm asking here if its possible that the HTML Lexer, which they said also is responsible for PHP, supports more than 1 keyword list?

Currently, i can define only 1 list of constant keywords in langs.xml and refer to it in stylers.xml like that:

<WordsStyle name="CONSTANT" styleID="121" fgColor="0000FF" bgColor="FFFFFF" fontName="" fontStyle="1" fontSize="" keywordClass="instre1" />

Any chance that multiple keywordClasses are possible?

As a workaround, I currently use the Notepad++ plugin EnhanceAnyLexer for all functions and language constructs. In terms of functionality. it works fine, but it also makes Notepad++ a bit sluggish. I think, a native solution with the HTML Lexer would be better.

[pryrt]

As some additional flavor: there are thousands of built-in PHP keywords; making them all the same style when lexing makes them all mentally indistinguishable, eliminating the benefit of syntax highlighting.

Most programming langauges I've run across that have even a fraction of that many built-in keywords have multiple keyword lists in their Lexilla lexers, so that you can highlight different groups of keywords with different styles. (For example, Python, which only really has a couple hundred keywords, can split them between the two keywords lists.)

But the LexHTML only allocates one keyword list (keywords5, to the SCE_HPHP_WORD style . If there were another style or two, with associated keywords-lists, it would allow users to split the thousands of PHP keywords into smaller groups, to give groups of colors that make sense to them.

I understand that you don't like having too many keywords lists in a given lexer, but only having one list for the thousands of keywords gives PHP a disadvantage in any Lexilla-based text editor, compared to other languages in that text editor that have multiple keyword lists, or compared to other code editors that don't use the Lexilla for syntax highlighting.

[nyamatongwe]

The HTML lexer allows a large number of keyword lists for each sub-language using the substyles feature. See SciTE's source code for an implementation example of substyles. You can use SciTE to view the test file lexilla/test/examples/hypertext/x.php which (in conjunction with its SciTE.properties settings) shows decrypt as a keyword through substyles.

[pryrt]

Not to trying be obtuse, but when I downloaded SciTE 5.5.1, and downloaded the SciTE source code so I had access to that hypertext/x.php file (with the SciTE.properties alongside), and then opened the x.php from that directory, it doesn't seem to treat decrypt any differently than any other non-keyword (see the lack of a difference between decrypt "xyzzy" and notAKeyword "here" in my screenshot).

So I'm not sure how that's showing it as a keyword through substyles.

And searching the SciTE source code, the only instances of any of the message-names from the substyles section are the #define, so I don't see how that helps anyone figure out how to use substyles.

[nyamatongwe]

OK, that will need some style definitions to be visible. I keep these in a parent directory as they change a lot when looking at particular issues:

style.hypertext.198=fore:#00A000,italics,$(colour.hypertext.server.php.back)

@pryrt searching the SciTE source code, the only instances of any of the message-names

SciTE uses the more C++-friendly Scintilla::Message enumeration from ScintillaMessages.h and wrappers from ScintillaCall.h like:

AllocateSubStyles = 4020,
GetSubStylesStart = 4021,
GetSubStylesLength = 4022,
GetStyleFromSubStyle = 4027,
GetPrimaryStyleFromStyle = 4028,
FreeSubStyles = 4023,
SetIdentifiers = 4024,
DistanceToSecondaryStyles = 4025,
GetSubStyleBases = 4026,

[mdrmdrmdr]

I have to admit, that I cannot contribute to this discussion... ;-)