Config Files Need Updating, Too

Lycan Thrope

@PeterJones ,
After this review by you, and again, re-reading the readme file you linked, it became much clearer. I admit to having only a cursory knowledge of the xml files in reference to how they relate to the Language and stylers that are usually controlled by the dialogs, so I was a bit lost about what they were highlighting and I think that’s where most of my confusion was. I’ve learned a bit more with this help you’ve given.

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.

PeterJones

@Lycan-Thrope said in Config Files Need Updating, Too:

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)

PeterJones

ConfigUpdater Plugin v2.2.0

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)

Lycan Thrope

@PeterJones , Just a slight pointing out, that the title says, v2.2.0 and your text says v2.1.0. Am I misunderstanding, or more likely you’re just overworked and missed it. :-) Just an FYI.

PeterJones

@Lycan-Thrope said in Config Files Need Updating, Too:

more likely you’re just overworked and missed

Typo fixed

PeterJones

ConfigUpdater Plugin v2.2.1

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

PeterJones

Starting in v8.8.9, Notepad++ will propagate new Languages and new styles inside existing languages from the model file into your active Theme file. In v8.8.9, it will always use the color from the model file (so the default light-mode theme color) for added styles; in v8.9 and beyond, it will use the light-mode color from the model file if your active theme is stylers.xml, otherwise it will use the default foreground and background colors from your active theme.

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.

Lycan Thrope

@PeterJones ,
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.

PeterJones

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.

Lycan Thrope

@PeterJones said in Config Files Need Updating, Too:

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. :-)