Color modification of style 15 of the "OScript" language via the "Style Configurator", not taken in account, on next N++ start



  • Hi, All,

    Out of curiosity, I recently searched the differences between the configuration files, of my last N++ release ( v7.8.3 ) :

    • lang.model.xml and langs.xml

    • Stylers.model.xml and stylers.xml

    And it happened that the lang.model.xml and langs.xml files were identical but the Stylers.model.xml and stylers.xml files were quite different !


    To be sure, I extracted a fresh 7.8.3 N++ release, from the npp.7.8.3.bin.zip archive, in any folder and did the following test :

    • I started Notepad++

    • I chose the Settings > Style configurator... option

    • In order to see the Save & Close button active, I ticked and, immediately, unticked the Enable global font option

    • I then clicked on the Save & Close button ( Normally, no change should have occurred ! )

    • I closed Notepad++

    • I compared the Stylers.model.xml and stylers.xml files, with an external tool and, again, the same lot of differences appeared


    Back to my usual Notepad++ configuration, I realized that Notepad ++ make some syntax adjustments, the first time you’re using the Style Configurator`

    • It changes any tabulation to 4 space chars

    • It adds a space after the last ", right before />, ending a line

    • It rewrites any hexadecimal number, of the fgColor and bgColor attributes, in uppercase

    • It adds a fontStyle="0" attribute, before /> ending a line, if that line does not contain this attribute


    In other words, if you run these 4 regex S/R, below, against the stylers.model.xml and save the modifications,
    any subsequent comparison, between this new stylers.model.xml and your present stylers.xml file, should show only the style changes you have chosen, personally !

    SEARCH    \t                                       REPLACE    \x20\x20\x20\x20           3 occurrences
    
    SEARCH    "/>$                                     REPLACE    "\x20/>                    7 occurrences
    
    SEARCH    (?-i)(f|b)gColor="\K[[:xdigit:]]+"       REPLACE    \U$0                   2,423 occurrences
    
    SEARCH    (?-i)^(?!.+fontStyle=").+\K(?=\x20/>)    REPLACE    \x20fontStyle="0"         25 occurrences
    

    And, indeed, I found two personal changes :

    • I changed the default Courier New global font

    • I changed the foreground inactive tabs color from Grey to Black


    However a third difference remained, related to the OScript language :

            <LexerType name="oscript" desc="OScript" ext="">
                <WordsStyle name="DEFAULT TEXT STYLE" styleID="0" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
                <WordsStyle name="SINGLE-LINE COMMENT" styleID="1" fgColor="007F00" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
                ...
                ...
                ...
                <WordsStyle name="LABEL TO JUMP TO WITH THE GOTO STATEMENT" styleID="13" fgColor="FF00FF" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
                <WordsStyle name="KEYWORDS" styleID="14" fgColor="00007F" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" keywordClass="type2" />
                <WordsStyle name="KEYWORDS" styleID="15" fgColor="0000FF" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" keywordClass="type3" />
                <WordsStyle name="STATIC BUILT-IN OBJECT" styleID="16" fgColor="007F7F" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" keywordClass="type4" />
                ...
                ...
            </LexerType>
    

    In stylers.model.xml, we have the line :

                <WordsStyle name="KEYWORDS" styleID="15" fgColor="0000FF" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" keywordClass="type3" />
    

    And in stylers.xml, we have the line :

                <WordsStyle name="KEYWORDS" styleID="15" fgColor="00007F" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" keywordClass="type3" />
    

    Even, if I tried, via the Style Configurator, to put, again, the pure blue color 0000FF for the foreground of KEYWORDS of class type3, the color remains 00007F, after restarting Notepad++ !?

    The only work-around is :

    • Close any Notepad++ instance

    • Find out the location of your active stylers.xml file

    • With Microsoft Notepad, or any editor different from N++, write the value 0000FF or any desired value, as the foreground color for style ID="15" of the OScript language and save the modifications

    • Re-start Notepad++

    However, note that any other styling modification, from within the Style Configurator, will give again the 00007F wrong value, on N++ start !

    I verified that this bug still happens with the last v7.8.4 release !


    So, guys, could you do a quick test and verify my assumptions ! If I’m right, I’ll create a new issue, although I don’t need at all the OScript language, presently ;-))

    Best Regards,

    guy038



  • @guy038 said in Color modification of style 15 of the "OScript" language via the "Style Configurator", not taken in account, on next N++ start:

    So, guys, could you do a quick test and verify my assumptions ! If I’m right

    Very nearly. When I replicated your procedure exactly, I got the same results: after editing something else in style configurator – even if I immediately undo it (like toggling and untoggling a checkbox in the GLOBALS style) – then hitting save, when i look at the stylers.xml, styleID=“15” has changed back to fgColor="00007F".

    However, I noticed that both 14 and 15 were called KEYWORDS, and #14 has the value 00007F. If I change styleID=“14” to something different as well, then follow the same sequence, styleID=“15” changes to match whatever value styleID=“14” uses. I think, because they are both called name="KEYWORDS", the data from the #14 is overwriting the data for the #15 after it’s gone through XML->internal-data-structure->XML round-trip.

    If I change to

                <WordsStyle name="KEYWORDS" styleID="14" fgColor="987654" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" keywordClass="type2" />
                <WordsStyle name="KEYWORDS2" styleID="15" fgColor="1234AB" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" keywordClass="type3" />
    

    so that they have separate names and different fgColor, then go through the same sequence, #15 keeps its independent value.

    I really think the bug is caused by both #14 and #15 having the same name attribute value.



  • Hi, @PeterJones and All,

    Ah… Many thanks for your clever deduction. The fact that this language has two identical attributes should have tipped me off !

    So, the simple and obvious solution is to give two different names to these two attributes : for instance, Keywords1 and Keywords2


    Now, after scanning the stylers.model.xml, I realized that 2 other languages also contain identical attributes : BaanC and txt2tags :

            <LexerType name="baanc" desc="BaanC" ext="">
                <WordsStyle name="DEFAULT" styleID="32" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
                ....
                <WordsStyle name="DEFAULT" styleID="8" fgColor="000000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
                ....
            </LexerType>
    
    
            <LexerType name="txt2tags" desc="txt2tags" ext="">
                ....
                <WordsStyle name="LIST" styleID="13" fgColor="E300EE" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
                <WordsStyle name="LIST" styleID="14" fgColor="E300EE" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
                ....
            </LexerType>
    

    And I did verify that, if I chose :

    • The name attributes DEFAULT1 and DEFAULT2 for the BaanC language

    • The name attributes LIST1 and LIST2 for the txt2tags language

    The foreground and background colors of these four attributes can be modified independently and are kept, after a N++ restart ;-))

    So, I’m about to create a GitHub issue, although a simple differentiation is possible by modifying the stylers.xml file !

    Done ! See :

    https://github.com/notepad-plus-plus/notepad-plus-plus/issues/7965

    Best Regards,

    guy038



  • Since I had downloaded SciTE yesterday, and noticed that it has a .properties file for each of the lexer languages, I decided to go look at how Scintilla’s configuration named/labeled those entries, to see if it gave a hint as to the purpose:

    baan.properties

    # Default
    style.baan.32=$(font.baan.monospace)
    # Identifiers
    style.baan.8=$(font.baan.monospace)
    

    txt2tags.properties

    # list
    style.txt2tags.13=fore:#E300EE
    # list
    style.txt2tags.14=fore:#E300EE
    

    (so txt2tags does duplicate the “name” (comment) for those two IDs)

    oscript.properties

    # Type available in the language, in kernel or code modules.
    # See the property keywords4 above.
    style.oscript.14=fore:#00007F
    # Global function in the language, in kernel or code modules.
    # See the property keywords5 above.
    style.oscript.15=fore:#0000FF
    

    Maybe I could get more hints by looking at source code for the lexers… but I think this is enough effort on this for now. :-)

    So, I would say

    • baanc #32 = DEFAULT
      baanc #8 = IDENTIFIERS
    • txt2tags #13 = LIST
      txt2tags #14 = LIST2
      • this naming convention has precedent: #19 and #20 are already CODE and CODE2
    • oscript #14 = TYPE
      oscript #15 = GLOBAL FUNCTION


  • Names can be, afaik, whatever one wants as long as there are unique and
    the ids match the ones from the SciLexer.h header file.



  • @Ekopalypse said in Color modification of style 15 of the "OScript" language via the "Style Configurator", not taken in account, on next N++ start:

    Names can be, afaik, whatever one wants as long as there are unique and
    the ids match the ones from the SciLexer.h header file.

    I believe you are correct. However, they should be meaningful – and the best default value (to me) would be what Scintilla calls them internally. And the worst default would be a value that collides with another and causes the values for one to be applied to the other. :-)




Log in to reply