Validation Dialog

[pryrt]

Create a separate dialog to make a better interface for doing XSD-based validation of the Stylers/Themes/Langs XML files.

The README includes a section on Validation to explain how to use it.

resolves #14

[pryrt]

@Ekopalypse, since you mentioned in chat that you were interested in using this plugin for validating the themes, I first added a validation during the Update Config Files action in #16 (to resolve #1).

However, per #14, that interface wasn't really condusive to fixing the errors, so I have added a separate action/dialog in the plugin to do the validation.

I believe it's working now, though it could probably use some external verification that it's as usable as I think it is. ;-)

And, while testing it out, I decided that I personally don't like the validation from PR #14, since it just interrupts the config-file update. I am leaning toward just deleting the validation calls from those, and just relying on this new action. If you disagree, and think it should still do the validate-during-update, let me know. Otherwise, I'll probably end up removing validate-during-update before merging this PR.

[Ekopalypse]

I have compiled and tested the plugin from the validDlg branch.
I sympathize with the idea of not interrupting the update with the validation. However, while testing, I noticed one or two things. Since I don't know to what extent you already know them, I'll just summarize them.

If the user is not using current model.xml files, then the corresponding files are only updated to the old version. At the moment, however, I don't see how you could intercept this with the plugin. Perhaps a note in the resulting update.log?

As for validation during the update, perhaps it would be useful to only capture this in the update and not give the user the option to interrupt it during the update!? Maybe with highlighted colors?

The dialog font size of 8 is a bit too small for me, even though I only use a standard FullHD (1920x1080) monitor with 100% scaling.

What do you intend to do if a StyleID has been assigned twice
or if an entry is found that should not appear at all?
At the moment only the theme is opened and jumps to the line. Perhaps it would be useful to open the corresponding model.xml in the other view and display the corresponding entry to give the user the opportunity to understand what is actually expected?
(currently you can't scroll horizontally in the dialog to read the whole text, with model.xml open this might also be superfluous).

Please do not take this as a new feature request, it is more intended as an exchange of ideas,
I am more than happy with the current version and thank you very much.

[pryrt]

If the user is not using current model.xml files, then the corresponding files are only updated to the old version. At the moment, however, I don't see how you could intercept this with the plugin. Perhaps a note in the resulting update.log?

When you upgrade an installed Notepad++, it automatically updates the .model. files. With portable, I guess I was under the assumption that the user would bring over the new .model. when they "update" their portable. There isn't any meta-information embedded inside the XML. I suppose I could check the date of the .model. files vs the date of the notepad++.exe. I'll think about that some more.

As for validation during the update, perhaps it would be useful to only capture this in the update and not give the user the option to interrupt it during the update!? Maybe with highlighted colors?

I mean, the logfile already does highlight the "validation failed" line with ErrorList's DIFF CHANGED color (the ! line):

I'm thinking I'll just set a flag if any of the XML fail validation during update, and as they close the dialog box, give a message like "there were XML validation problems during the update: would you like to run the interactive validation dialog to work on those? YES/NO"

The dialog font size of 8 is a bit too small for me, even though I only use a standard FullHD (1920x1080) monitor with 100% scaling.

That should be easy enough to fix. :-)

What do you intend to do if a StyleID has been assigned twice or if an entry is found that should not appear at all? At the moment only the theme is opened and jumps to the line. Perhaps it would be useful to open the corresponding model.xml in the other view and display the corresponding entry to give the user the opportunity to understand what is actually expected? (currently you can't scroll horizontally in the dialog to read the whole text, with model.xml open this might also be superfluous).

Enabling horizontal scroll shouldn't be too difficult.

Unfortunately, neither of the XML libraries I am using seem to encode the file line number for any given XML element, so no easy way to ask the processed data "what language element contains the style element at line XYZ". If I can figure out a way to do something equivalent without that easy metadata search, I can try opening the correct model to the similar element.

[pryrt]

Easy fixes done: bigger font, and horizontal scroll proportional to text width.

That should go a long way toward making it better, but I will still spend some time investigating the other improvements.

[Ekopalypse]

When you upgrade an installed Notepad++, it automatically updates the .model. files. With portable, I guess I was under the assumption that the user would bring over the new .model. when they "update" their portable. There isn't any meta-information embedded inside the XML. I suppose I could check the date of the .model. files vs the date of the notepad++.exe. I'll think about that some more.

I think that's a reasonable assumption.
I'm not sure why I excluded these files in the first place ... strange.

I mean, the logfile already does highlight the "validation failed"...

Not for me, I use different lexers for different log files.
Maybe you assign the lexer explicitly for your log file?

I'm thinking I'll just set a flag if any of the XML fail validation during update, and as they close the dialog box, give a message like "there were XML validation problems during the update: would you like to run the interactive validation dialog to work on those? YES/NO"

Yes, works as well.

[pryrt]

I mean, the logfile already does highlight the "validation failed"...

Not for me, I use different lexers for different log files. Maybe you assign the lexer explicitly for your log file?

The plugin sends the NPPM_SETBUFFERLANGTYPE to L_ERRORLIST right after opening the file and just before it turns on the monitoring (tail-f) mode for the logfile. My guess is that your extension-based on-activated-or-similar checks are happening after I set the L_ERRORLIST for the file.

I guess I need to consider not using the .log extension. It's not just errors, so I didn't want it to be ConfigUpdater.err ... maybe I'll pick a custom extension, like .culog (or maybe no extension at all), to make sure that people's extension overrides don't interfere with the SETBUFFERLANGTYPE that I'm forcing.

[Ekopalypse]

The plugin sends the NPPM_SETBUFFERLANGTYPE to L_ERRORLIST

Ah, sorry it does what it's supposed to, the problem was that I didn't have an ErrorList lexer with the theme I was using and after the update and restart the default colors are set, which of course makes sense.

I think I need to consider not using the .log extension.

In my case I check the filename and not just the extension but yes, it is possible that there are scripts that respond to .log. Hmm ... without extension or custom extension, that will behave the same, I think. Can't think of a scenario right now where one would be preferable to the other.

[pryrt]

I decided ConfigUpdaterLog with no extension was best (I didn't like using a 5-character extension, and a standard 3-char ext has too much chance of collision with lexer/UDL extensions)

I have added a button to the Validation dialog (*.model.xml, though it renames to stylers.model.xml or langs.model.xml depending on selected file). If you click that button while an error is selected in the list, it will open the appropriate model file into the other View, and will do its best to align the model file with the same section as the error occurs in the failing XML.

(Because the simplest interface it will involve a new menu command, I have decided to put the download-model-files feature in a separate Issue #19, which will get a separate PR)