But, unfortunately, there were a few growing pains in transferring from the plugin to the builtin that I was really hoping wouldn’t happen, because I had ironed out so many problems in the plugin version already.

That IS why it’s called ‘developing’. and maintainers are ‘developers’. :-)

If I ever saw a first version of anything that worked unscathed on the first try, I’d be digging through the code looking for the bomb that went undetected. :-)

Sorry to hear all that great work of yours will be obsoleted as a plugin, but hope it was your work that is being incorporated into the main program itself to alleviate the need for updating of the config files. Thanks for the work you did.

I had always felt that config-file updating should be a native feature of Notepad++, but no one else had ever put in an official feature request for it, and for features like that, it was likely to be either ignored or just rejected with “only power users would ever want that feature” nonsense, so I hadn’t wanted to “muddy the waters” by creating an issue that would make him actively not want the feature in the future. Finally, when I had time, I created my script, then later the plugin (per this Topic).

Then, soon after I released my plugin, someone just happened to make an official feature request, so it gave me an inroad, and I used what I had learned while doing the plugin to create the code that implemented it natively (it had to be done a bit differently for the embedded, so I couldn’t just copy/paste the code from my plugin, but it was done using the same concepts). So it was my work on both, and I got my end goal of people’s Themes and language-keyword lists will stay up-to-date from now on. But, unfortunately, there were a few growing pains in transferring from the plugin to the builtin that I was really hoping wouldn’t happen, because I had ironed out so many problems in the plugin version already.

If v8.8.9 updated your dark theme already, and you find the results too jarring, this FAQ explains how to fix it. That FAQ is not needed if you never ran v8.8.9, or if you were just using stylers.xml and not one of the Themes. Going forward (v8.9 or newer), Notepad++ will not create jarring results, but v8.9 cannot undo the changes made in v8.8.9, hence the FAQ.

ConfigUpdater plugin is being obsoleted for any Notepad++ newer than v8.8.9, and there is no reason to install it on more-recent Notepad++ versions.

ConfigUpdater Plugin has released v2.2.1, available thru GitHub release page, with bugfix improvements, mostly to Validation Dialog:

• Error handling for null handle ⇒ to prevent potential crashes
• Disable logfile Monitoring Mode ⇒ it triggers callbacks for many file-changed events, which can bog down setups that use plugins/scripts that add many callbacks
• Fix progress bar on ConfigUpdater dialog ⇒ makes more-visible progress as each file is processed
• ValidationDialog: say Line#123 instead of #123 in the Validation dialog error list ⇒ Makes it more clear to the user that the number is the line number, not just some internal tracking number
• ValidationDialog: Rename Done -> Close
• ValidationDialog: Rename Go to Model -> Open/Align Model in Other View
• ValidationDialog: Disabled Validate button when no file selected
• ValidationDialog: Add ephemeral “Please select a file to validate” choice as initially-selected “file” for validation, which will go away once you’ve made a choice
• ValidationDialog: Open/Align Model now allows opening the model even when there are no validation errors (or when you haven’t even validated yet)
  • it was previously not allowed because the vector it was looking at to find which line number in model-file was 0-length if there were no errors (or no validation done yet); I was able to update the logic to choose line 0 if there was no selection or no validation errors
• Update langs.xsd to check for duplicate <Keyword name="xyz"> entries
  • NOTE: if you want this feature, you have to delete the old ...\plugins\config\ConfigUpdater\langs.xsd before launching the ConfigUpdater or ValidateConfigFiles dialogs (only need to delete the file once; after it is regenerated, the new error checking will be available in the future)
• Only allow one Validator dialog ⇒ It could cause problems if more than one dialog were trying to validate at the same time, and there is no compelling reason for allowing multiple instances of that dialog

more likely you’re just overworked and missed

Typo fixed

ConfigUpdater Plugin has released v2.1.0 v2.2.0, available thru GitHub release page, with improvements to Validation Dialog:

• Rename *.model.xml button to Go To Model (#23), and improve its ability to align the validating XML with the model file (#25).
• Add ability to copy the selected error message to Windows Clipboard (#23)
• Allow resizing dialog (#23)
• Add easier-to-understand error message for the most-common errors (#22)
• Add help button for more details on how to use the Validation dialog (#22)

became enabled only after selecting and double clicking the error

I should probably add a single-click handler to enable that button, too. (Without any selection, it wouldn’t know where in the file to go to, so I will probably leave it disabled with no selection)

After reading the more detailed description you gave, and also, I hadn’t realized that the *.model.stylers.xml file button became enabled only after selecting and double clicking the error, that it could then open the model file, so that they could be compared. I think I was kind of lost with the new whizbang options.

I’m sorry if my head is thicker than it needs to be when it comes to noticing and using the new stuff…but the thicker head helps when I hit my head a lot, to make sure everything stays inside of it, mangled though it may be. :-)

I got it now. Thanks.

I thought using the Validate Files would correct whatever was found
…
My viewing the new aspects made me believe the validation and correction was automatic by clicking those functions … Guidance?

Sorry, I was hoping the section on Validation in the README would be enough. I guess I need to add a help button and see if I can explain things better.

The validation has occurred, and it has found errors.

Unfortunately, I cannot program enough intelligence into the plugin to be able to figure out the right/best way to fix the problems, so it does not correct errors for you. That’s why the double-click will take you to the right spot in the problematic XML file. Further, the stylers.model.xml button can be used to open the model file side-by-side with the problematic XML – and the plugin will do its best to align the model file so that it’s showing the same section of its XML as has the problem in the other (though, looking at the order that line#652 is listed, I think my alignment algorithm might need some work: that line proved assumptions wrong).

You are then supposed to compare the two, and use the semi-understandable XML error messages to help you figure out… Maybe I’ll have to figure out a way to convert the errors that the validation library spits out into something more human-readable.

• '5' is a duplocate key... indicates that there are two <WordsStyle> entries that have the same StyleID. StyleID must be unique for Notepad++ to be able to correctly map that row in the XML (or that entry in the Style Configurator’s Styles: list) to the underlying Lexilla style. When there are two with the same StyleID, Notepad++ only picks one to show in the Style Configurator and send to Lexilla. So you need to compare your XML with the model XML, and figure out what the right solution is:
  • Do you just need to pick one of the two duplicates and delete it (and if so, your human intelligence is needed to decide which is the right entry to keep and which to delete)
  • Or does one of them have the wrong styleID, and you just need to change it to a different value
• '' violates enumeration constraint... indicates that you have a keywordClass attribute on your <WordsStyle> that has an invalid value (in your case, the empty string). keywordClass needs to be one of the known types as listed in the error message, or the attribute needs to not exist at all.
  • You need to compare the failing XML to the model, and need to figure out what value of keywordClass should be there – or whether to delete the attribute altogether (if it’s not there for that styleID in the model)

along with the Download new models. I fear I may just not know what these new capabilities are supposed to perform, so I don’t want to assume what they are supposed to do.

The Download Newest Model Files grabs the most recent stylers.model.xml and langs.model.xml from the Notepad++ repo, and overwrites your possibly-out-of-date models. This will make sure that the model used when validating is the “current best practice” found in the repo. (I really thought that the README was clear on that one. Is it not?)

since I can’t screenshot the whole text since the box isn’t wide enough and it can’t be copied for inclusion in here under code format.

Created issue #23: I’ll see if I can get Ctrl+C and/or dialog resize to work. (I’ve never done either from C++; I really don’t have a lot of GUI-programming experience, so I’ve always started with “functional enough GUI for me to do what I want” for my plugins, without aiming for super-fancy features.)

I have two showing up:

One in stylers.xml

--- ConfigUpdater run at Friday, July 4, 2025 4:55:40 AM
--- Checking Styler/Theme File: 'C:\Users\camilee\AppData\Roaming\Notepad++\stylers.xml'
+ LexerStyles: Sorted LexerType elements alphabetically (keeping "searchResults" at end)
! Validation of C:\Users\camilee\AppData\Roaming\Notepad++\stylers.xml failed on line#1685:

XML validation FAILED: '2' is a duplicate key for the unique Identity Constraint 'unique-WordsStyle-styleID'.

Line#1685:
            <WordsStyle bgColor="FFFFFF" fgColor="000000" fontName="" fontSize="" fontStyle="0" name="COMMENT LINE" styleID="2"/>

…and a multiple fail in DarkModeDefault:

--- Checking Styler/Theme File: 'C:\Users\camilee\AppData\Roaming\Notepad++\themes\DarkModeDefault.xml'
+ LexerStyles: Sorted LexerType elements alphabetically (keeping "searchResults" at end)
! Validation of C:\Users\camilee\AppData\Roaming\Notepad++\themes\DarkModeDefault.xml failed on line#657:

XML validation FAILED: '5' is a duplicate key for the unique Identity Constraint 'unique-WordsStyle-styleID'.

Line#657:
            <WordsStyle name="EVENT" styleID="5" fgColor="8CD0D3" bgColor="3F3F3F" fontName="" fontStyle="1" fontSize="" keywordClass="instre2"/>
--- Checking Styler/Theme File: 'C:\Users\camilee\AppData\Roaming\Notepad++\themes\MyDarkModeDefault.xml'
+ LexerStyles: Sorted LexerType elements alphabetically (keeping "searchResults" at end)
! Validation of C:\Users\camilee\AppData\Roaming\Notepad++\themes\MyDarkModeDefault.xml failed on line#652:

XML validation FAILED: '5' is a duplicate key for the unique Identity Constraint 'unique-WordsStyle-styleID'.

Line#652:
            <WordsStyle bgColor="3F3F3F" fgColor="8CD0D3" fontName="" fontSize="" fontStyle="1" keywordClass="instre2" name="EVENT" styleID="5"/>

There are others for DarkMode as shown in this partial shot of the Validate box since I can’t screenshot the whole text since the box isn’t wide enough and it can’t be copied for inclusion in here under code format.

I see that double clicking the line, takes me to the file, and then I can double click the FunctionList view that leaves me on and that will bring up the line in the file, but the question remains…what am I supposed to change it to, or am I supposed to change it at all?

My viewing the new aspects made me believe the validation and correction was automatic by clicking those functions along with the Download new models. I fear I may just not know what these new capabilities are supposed to perform, so I don’t want to assume what they are supposed to do. Guidance?

ConfigUpdater Plugin has released v2.1.0, available thru GitHub release page.

• Add Dark Mode (Issue #7)
• Validate XML vs XSD during update (Issue #1) and interactive validation on-demand (Issue #14)
• Add ability to download most recent model XML files (Issue #19)
• Other Improvements: move config to dedicated subdirectory (Issue #6), only write XML file if it is changed (Issue #3), truncate the status logfile if it’s too big (Issue #10), make sure it only updates themes once for portable (Issue #15)

For what it’s worth, as the author of Controlled Auto-indent, I can guarantee it was the culprit. It could crash under other circumstances, too, having nothing to do with ConfigUpdater; I just hadn’t hit one of them, and if anyone else did before you, they didn’t report it.

I appreciate that, and I’ll go ahead and download it and test it against the old and new versions of ConfigUpdater. I’ve already downloaded, but not installed the new version of CU yet.

Update: It works fine under the old CU and the new CU. I tried it with CAI enabled and not enabled, and the CU ran through everything, so the crash condition from CAI appears to be gone. Glad I could help find that edge case, unknowingly. :-)

So the problem that was happening for me, was probably just the AutoIndent plugin, and I say probably because I can’t be sure the combo of it with another, possibly WebTools, couldn’t have been the culprit.

For what it’s worth, as the author of Controlled Auto-indent, I can guarantee it was the culprit. It could crash under other circumstances, too, having nothing to do with ConfigUpdater; I just hadn’t hit one of them, and if anyone else did before you, they didn’t report it.

A fixed version exists now.

For those who want details:

So the problem that was happening for me, was probably just the AutoIndent plugin, and I say probably because I can’t be sure the combo of it with another, possibly WebTools, couldn’t have been the culprit. I’d been up close to 21 hours when I shutdown and couldn’t force myself to sign back on. :-(

it’s using the L_xxxx enumeration

Thank you. It appears (since of course updates could always happen without a plugin being updated) that I’ll need to find a way to determine what is an external lexer at run time (not just what would have been an external lexer when I compiled the plugin).

Apparently ErrorList is an external lexer, and ControlledAutoIndent is picking that up as the active language at some point.

I guarantee it is not: it is a standard Lexilla lexer. Did you update your menuCmdID.h file which defines the external lexer constants?

…
No, it doesn’t look like you have:

But since it’s IDM_LANG+93 vs IDM_LANG+165, and you shouldn’t be looking at the IDM, that’s not the likely culprit (though something you should still fix)

Ah, searching for external in your plugin:

it’s using the L_xxxx enumeration values from the Notepad_plus_msgs.h::LangType enumeration

And that makes sense: Don chose to use whatever the “last” enumeration value happens to be for L_EXTERNAL, which means that every time a new built-in language is added, all plugin authors who compare vs L_EXTERNAL must update Notepad_plus_msgs.h whenever N++ does, otherwise their comparison will be off for anyone using one of the newer lexers in the most recent N++.

So definitely update menuCmdID.h and Notepad_plus_msgs.h, and then that comparison should not be true, and it won’t go into that section of code erroneously.

I’m not sure why the ConfigUpdater plugin would trigger your plugin to think there was an External Lexer (it is not a lexer plugin, after all)… but I’m glad you found that one.

Apparently ErrorList is an external lexer, and ControlledAutoIndent is picking that up as the active language at some point.

While I am looking, could you try to do CANCEL instead of YES, and see if you still get the Access Violation at langs.xml when you are not running in Admin mode?

Same result (at least, superficially). However, I realize now that the switch to Admin mode was not happening when running under the debugger; the call stack I posted was happening with Notepad++ not in Admin mode. I don’t know if there is a way I can trap an error in the debugger while running with elevated permissions.

update 2: could you go to the issues page and create a new issue (this Access Violation is separate from the freeze/crash, I think), and attach your langs.xml to the issue? Maybe with that file, I’d be able to reproduce the problem.

I will do that shortly.

Edit to add 2: The problem with ControlledAutoIndent was entirely due to a mistake in that plugin. It’s not even a “conflict,” just a straight-up error. I had no idea what would cause an “External Lexer” to be used. (The plugin keeps track of the current language so it knows what indentation rules to apply.) I made a silly mistake in the code that handles the External Lexer case, and just never hit it until now.

I’m not sure why the ConfigUpdater plugin would trigger your plugin to think there was an External Lexer (it is not a lexer plugin, after all)… but I’m glad you found that one.

Edit to add: I continue to get the Access Violation in the second phase even after removing all plugins except ConfigUpdater. I will continue to search for the causes of both errors.

Access Violation implies that there’s a null pointer someplace. I thought I’d fixed that for all the styler/themes, but with langs.xml being the last message in the status, maybe I didn’t check properly in the langs-updater. I’ll go take a look. (However, my normal debug in Win11 and my VM+Win10 tests all worked just fine for both themes and langs, so I still cannot reproduce the problem that’s causing that, so even if I find something, I’ll have to rely on you to test if I’ve actually fixed it.

While I am looking, could you try to do CANCEL instead of YES, and see if you still get the Access Violation at langs.xml when you are not running in Admin mode?

update 1: I see you posted a reply just before my post: thank you for that Call Stack: I will start my search at line 1077. :-)

update 2: could you go to the issues page and create a new issue (this Access Violation is separate from the freeze/crash, I think), and attach your langs.xml to the issue? Maybe with that file, I’d be able to reproduce the problem.

I can give you this much concerning the apparent cause of the access violation:

but I don’t know what to check to determine what might be leading to this condition. Quite possibly I have some very old version of one of these files, because as best I can remember, I have never manually edited any of them except (I think) shortcuts, and I’ve never bothered to try to upgrade them outside whatever the Notepad++ installer does.

@PeterJones ,
Report is in the Github post I just made, but the apparent problem was two off-book plugins I had tested and was playing with which are:

ControlledAutoIndent (1)
WebEdit (2.7)

I am on Windows 10. With my ControlledAutoIndent plugin installed (even when Enabled is not checked — in which state it should be doing nothing), I get the same result as @Lycan-Thrope.

When I removed it and tried again, I got through the first phase and encountered the request to restart. After answering OK, waiting for relaunch and then selecting Update Config Files again, a bunch of activity occurred, and then this came up:

This much is reproducible. I will try to investigate further. Debug info (captured before running first phase without ControlledAutoIndent):

Notepad++ v8.8.1   (64-bit)
Build time : May  3 2025 - 18:41:09
Scintilla/Lexilla included : 5.5.6/5.4.4
Boost Regex included : 1_85
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : 
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
Periodic Backup : OFF
Placeholders : OFF
Scintilla Rendering Mode : SC_TECHNOLOGY_DIRECTWRITE (1)
Multi-instance Mode : monoInst
File Status Auto-Detection : cdEnabledNew (for current file/tab only)
Dark Mode : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 22H2
OS Build : 19045.5737
Current ANSI codepage : 1252
Plugins : 
    ColumnsPlusPlus (1.2)
    ComparePlus (1.2)
    ConfigUpdater (2)
    DSpellCheck (1.5)
    mimeTools (3.1)
    NppConverter (4.6)
    NppExport (0.4)

Edit to add: I continue to get the Access Violation in the second phase even after removing all plugins except ConfigUpdater. I will continue to search for the causes of both errors.

Edit to add 2: The problem with ControlledAutoIndent was entirely due to a mistake in that plugin. It’s not even a “conflict,” just a straight-up error. I had no idea what would cause an “External Lexer” to be used. (The plugin keeps track of the current language so it knows what indentation rules to apply.) I made a silly mistake in the code that handles the External Lexer case, and just never hit it until now.

ControlledAutoIndent (1)
WebEdit (2.7)

As I mentioned in Github, they could just be incompatible with the latest Scintilla updates for all I know, but until they don’t cause a problem, I don’t need them and your plugin works fine for me with repository listed plugins. Hope this helps.