How do you update AppData configs like contextMenu.xml?

[mere-human]

It is a mostly known thing that after a Notepad++ update, some config files aren’t updated.
Example is contextMenu.xml which may be very dated.

My question is how do you, the advanced Notepad++ users, keep your configs up to date with the latest version?

I know, it was mentioned before.
At least, from what I have found:
https://community.notepad-plus-plus.org/topic/18547/updating-notepad-using-zip-file
https://community.notepad-plus-plus.org/topic/17124/bug-in-contextmenu-xml

But I want to know the preferred way.
Do you keep the old configs?
Do you copy it manually from the install directory?
Do you download it manually?
Do you simply use the portable version?

Why am I asking?
Because, I often forget about this problem myself.
Also, I in the bug reports I often see outdated menus.

Also, what would be the preferable way to do that?
A checkbox in the installer? Or something different?

[PeterJones]

@mere-human ,

My question is how do you, the advanced Notepad++ users, keep your configs up to date with the latest version?

I diff the xml from two fresh portables, one at the old rev and one at the new. Any changes that were made I then patch into my real config files.

I had recently started working on something to automate that process, but I haven’t gotten very far.

Also, what would be the preferable way to do that?
A checkbox in the installer? Or something different?

I think any upgrade to configs should be incremental, not all-or-nothing. If the installer looked at the config files and just added in missing attributes or missing tags/sections, but left customized settings alone, that would be great. And if it were possible to have the same code somewhere else, so that portable users could do the same, even without the installer, that would be better. (Maybe store it as executable next to gup.exe, and have installer auto-run it, but allow portable users to manually run it.)

Basically, what I am describing is what I was going to put in my standalone tool. But I was going to write it in perl, and maybe some day get to the point that it was reliable enough to package it into a self-contained exe. But if someone official were working on it, I would stop bothering with my project.

[Alan Kilborn]

@PeterJones said in How do you update AppData configs like contextMenu.xml?:

I diff the xml from two fresh portables, one at the old rev and one at the new. Any changes that were made I then patch into my real config files.

Yep, exactly my procedure as well.
Always use the portable versions; never been convinced there is any advantage to using non-portable.

[mere-human]

@PeterJones said in How do you update AppData configs like contextMenu.xml?:

I think any upgrade to configs should be incremental, not all-or-nothing. If the installer looked at the config files and just added in missing attributes or missing tags/sections, but left customized settings alone, that would be great.

Like overwrite only tags present in the new contextMenu.xml but don’t touch anything else?
I suppose user’s customizations are often the new entries? Is it common to change existing menu entries?

And if it were possible to have the same code somewhere else, so that portable users could do the same, even without the installer, that would be better.

I wonder, what is the update process for portable users? I thought it’s just “grab new zip, unpack and replace”.
Because, if checking for the update in portable, it suggest you to run the installer.

But if someone official were working on it, I would stop bothering with my project.

I’m asking more from the user perspective.
Despite I’m contributing to the project, I’m far from being called an “advanced user”.
Nevertheless, it would be nice to incorporate something like this into installer or a plugin at least.

Also, thanks for the answers!

[Stefan Pendl]

Some applications track their changes to XML files using separate XML files with added, changed and deleted sections.
Comparing the differences of the current XML file of the user with the XML file that shipped with the installed release would allow applying changes to a customized file more easily.
It would be possible to have a global XML file in the installation folder and a customized XML file with only the changes in the user folder for easier updating and customization.

[mere-human]

@Stefan-Pendl said in How do you update AppData configs like contextMenu.xml?:

It would be possible to have a global XML file in the installation folder and a customized XML file with only the changes in the user folder for easier updating and customization.

This is exactly what happens now with the installed version. The global version is stored in Program Files/Notepad++ and the customized one is in AppData.

[Stefan Pendl]

Currently the entire file is saved as the users file, I suggested to only save the changes that are different from the default file to the users file.

[Ekopalypse]

…, I suggested to only save the changes that are different from the default file to the users file.

but that means it has to have its own name, otherwise it won’t
work with portable versions where EVERYTHING has to be under a root directory.