Config Files Need Updating, Too
-
@PeterJones ,
The first is what mine shows.
PythonScript plugin v2.0.0.0 uses Python 2.7.
Python 2.7.18 (v2.7.18:8d21aa21f2, Apr 20 2020, 13:25:05) [MSC v.1500 64 bit (AMD64)] Copyright (c) 2001-2020 Python Software Foundation. All Rights Reserved.
I have Python27.dll in the C:\Program Files\Notepad++\plugins\PythonScript - directory.
And, I didn’t have the Prefer option checked, in the Options menu.
Just for confirmation. -
P PeterJones referenced this topic on
-
v1.06 is available from the permalink:
- v1.05 (2024-Sep-05): Add URLs to source code, so you remember where to get an updated copy. (was not announced, since it was not a critical feature/bugfix upgrade)
- v1.06 (2024-Sep-14): IMPROVEMENT = error handling for
<installed>\themes\
permissions- The most common error is that you don’t have write permissions for the default themes, which are installed in the installation directory instead of your AppData or other config directory.
- Users have been confused when it doesn’t complete because of write permissions, because I forgot that not everyone has PythonScript set to show the Console if there’s an error, and that error isn’t intuitive to the general audience even if they look in the Console.
- I now trap that error, and I’ve added a MessageBox to inform you of the error, letting you know that if you re-run Notepad++ As Admin, then it should work.
- Some users have found that when they run As Admin, PythonScript no longer sees their user scripts from the AppData hierarchy. If that’s the case, just save another copy of the script in the Machine Scripts section while you’re running As Admin.
- Even if you get the write error on the
<installed>\themes
, your AppData or other config-directory stylers and themes and langs.xml should all be properly updated. (If you use Windows Explorer, you should be able to see the last-modified time on the AppData or other config-directory files has been updated after running the script.)
-
v1.07 is available from the permalink:
- fix global styles
- copy global-styles colors from
stylers.model.xml
tostylers.xml
(similar to what’s already done onstylers.xml
’s lexer-styles) - when updating/adding global styles in either
stylers.xml
orthemes\*.xml
, make sure global-styles don’t have extra attributes that confuse the StyleConfigurator interface
- copy global-styles colors from
running v1.07 will clean up the Global Styles attributes to match the
stylers.model.xml
, even if you’ve run a previous version of the script - fix global styles
-
@PeterJones, I used version 1.07 of the script and the copyright information on top got removed from the theme files.
They were also unmodified, straight from the install directories, version Portable v8.7.1
-
Apparently the
xml.etree
library behaves differently between Python 2.7 and 3.12 (used by PS2 and PS3 respectively).I really wish PS3 would move out of alpha and release into Plugins Admin, so that we could just stick with PythonScript 3 for sharing scripts in the forum, and not have to contend with all the headaches of keeping scripts compatible with two major versions of Python, and all the library differences that come with that.
(it also would’ve been nice if Don hadn’t allowed theme authors to submit themes with XML that have invalid top-level comments, which the XML parsing engines don’t like because it’s not valid XML)
v1.08 is available from the permalink, fixing the handling of the invalid XML in PythonScript 2.
However, I highly recommend making the switch to PythonScript 3, despite it claiming to be alpha, unless you are using a lot of ANSI characterset files rather than real unicode-based encodings. I don’t know how much longer I’ll support PythonScript 2 for this script.
-
P PeterJones referenced this topic on
-
ConfigUpdater v1.99_beta1 – Plugin Version
Initial Beta Testing Wanted
I have what I believe to be a working ConfigUpdater Plugin which implements the same functionality as the
ConfigUpdater.py
script, but without requiring the PythonScript plugin (which is a huge overhead for many normal users).For the next few days, you can download theConfigUpdater.dll
from the Artifacts listed in this GitHub build of v1.99_beta1If, like @Alan-Kilborn, you like having a copy of the “intermediate sorted” files (which don’t include any of the “updates” that the plugin grabs from the model files, but are sorted in the same order as will be in the final version of each config file, for easier comparison of what changed), then create
...\plugins\Config\ConfigUpdaterSettings.xml
before running this plugin, with the contents:<ConfigUpdaterSettings> <Setting name="DEBUG" isIntermediateSorted="1"/> </ConfigUpdaterSettings>
If it needs Elevated UAC permissions, it will ask you, and restart Notepad++: if it restarts, you will have to run the plugin command again after Notepad++ is ready. (It will also ask, once done, if you want to go back to non-Elevated mode, because running AsAdmin is a bad idea. ;-) )
For beta testing, it’s probably a good idea to keep a copy of your original langs.xml/stylers.xml/theme files
Everything else should hopefully be self-explanatory.
Please let me know if you have problems (or if everything works great).
-
@PeterJones said in Config Files Need Updating, Too:
Please let me know if you have problems (or if everything works great).
A lot of upvotes, but no comments. Must not have any bugs. :-)
Since that post, I did a few micro updates, including improved About box, and better automation of the zipfile when I create a tag.
For beta5, I added one last feature: even on portable, where you don’t need elevated permission, when it finishes the updates, it will ask if you want to restart Notepad++ (since changes won’t take effect until a restart)
If anyone was interested in testing, the v1.99_beta5 is available at https://github.com/pryrt/NppPlugin-ConfigUpdater/releases/tag/v1.99_beta5
I am planning on submitting v2.0 to the nppPluginList repo this weekend.
-
v1.99_beta6 = BugFix: better error handling if langs.xml or a stylers/themes XML file has invalid XML – under many circumstances, it will tell you there’s an error, then open the offending file and embed a scintilla Annotation on the appropriate line number. (If it cannot figure out a line number, it will just do a MessageBox with the error, and then stop processing that file.)
(Thanks to @Ekopalypse for catching the problem.)
-
@PeterJones said in Config Files Need Updating, Too:
A lot of upvotes, but no comments. Must not have any bugs. :-)
Haven’t had a chance to test it yet, so not sure if that’s true. :-)
Update: I’ve posted my Debug info and a screenshot of what I see on a Standard install to the Github page. No request to shutdown, it just shuts down after a while of looking at the spinning wheel, and then crash closes as far as I can tell.
The portable install worked fine from what I can see. It has the same ConfigUpdaterSettings.xml file settings as the one in the AppData for the standard install, but the log for the standard install is empty. The portable one has a log of the changes made.
Not sure what happened. I did initially install it to the wrong location, putting it in the Appdata directory, but it didn’t show in plugins so did not run. I then cut and copied the entire folder to the Programs folder location and it showed in the Standard install Plugins, I ran it, and the same things happened when I ran it for the first time, and everytime I run it again…consistent.
If it doesn’t change anything being as it’s the latest version of NPP, shouldn’t it not shutdown after running it with no changes?
-
As I say in my reply over there, it looks like your copy is getting stuck long before it would ask to restart – it should have printed at least
stylers.xml
in the Status dialog. When I use my Win11 installed v8.8.1, or spin up a Win10 VM with an installed v8.8.1, it works as expected for me, so I don’t know what’s happening for you. We can continue the debug over in your Issue #2 discussion.If it doesn’t change anything being as it’s the latest version of NPP, shouldn’t it not shutdown after running it with no changes?
haha, you’re funny. The “latest version of NPP” ships with themes that have many missing LexerTypes (languages) and stylers within the lexers, which is a major reason this plugin is needed. If you’ve never run the old
ConfigUpdater.py
or the plugin version, it’s guaranteed to make changes. (And even if you have run it before, because it does things like sort the languages, it always attempts to write all the themes, so will ask to restart even if it’s writing the same values back – someday, I might get my logic better to figure out how to compare the old-vs-new for the XML, and not ask to write if it doesn’t need to; but for now, that was the easiest to program.) -
@PeterJones ,
Okay, I’ll try your first suggestion, since you have VM’d a version and it works. It could be one of my plugins so I’ll start with deleting them, and report there, here. what’s up.I did run the ConfigUpdater.py, but that was for testing when you started, and I haven’t done it since then, but it’s good to know even when the latest NPP is loaded, it’s already outdated. :-)
-
@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)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.
-
@Lycan-Thrope said in Config Files Need Updating, Too:
@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.
-
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.
-
@Coises ,
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. -
@PeterJones said in Config Files Need Updating, Too:
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.
-
@Coises said in Config Files Need Updating, Too:
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
enumerationAnd 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 updateNotepad_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
andNotepad_plus_msgs.h
, and then that comparison should not be true, and it won’t go into that section of code erroneously. -
@PeterJones said in Config Files Need Updating, Too:
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).
-
@Coises ,
Glad you guys figured it out. I was really tired when testing this, and realized after I signed off and shut down the computer that I had already tested without WebTools, before I got impatient and removed all the plugins, since I started from the bottom alphabetically and was working to the top.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. :-(
-
v2.0.1, with bugfix for @Coises “Access Violation” is released on GitHub. I have “paused” my nppPluginList submission, but will most likely submit 2.0.1 to the plugin list tomorrow, unless something else is discovered.
For those who want details:
Bugfix: Fix an “Access Violation” that occurs with specific condition of old langs.xml
vs newlangs.model.xml
– when the model had<Language name="blah"><Keywords ...></Language>
but the oldlangs.xml
only had empty<Language name="blah"/>
, it would cause the plugin to crash. The logic has been fixed so it properly copies over the new<Keywords ...>
into the previously-empty<Language>
element.