Proposal for Improvement for Plugins > Config Directory and Management in Notepad++

wonkawilly

Currently, Notepad++ manages plugin configurations by storing all plugin-related configuration files in a shared, common “Config” directory into the main N++ > Plugin dir. This approach presents several issues:

Leftover Files & Conflicts: Sometimes, uninstalling plugins leaves residual files, which may cause clutter or other issues.
Difficulty in Transfer & Customization: Moving individual plugins between different Notepad++ versions or portable setups is cumbersome, as it involves manually managing the shared Config directory and if the user doesn’t know what are the files related to that specific plugin is not always easy to transfer the customization done from the source to the destination.
Risk of Overwrites: Multiple plugins may use files with identical names (e.g., Config.ini, hypothetically), risking overwrites and configuration corruption or incompatibilities due to overlapping configuration files names.
Complex File Management: Finding specific plugin settings within the shared Config directory is challenging, especially when troubleshooting or modifying settings.
Suggested Improvement
Each plugin should have its own dedicated directory structure, for example:

Plugins/
 └── PluginName/
      └── Config/
           └── Plugin configuration files

Benefits of this approach:

Cleaner Uninstallations: Removing a plugin involves just deleting its entire directory, ensuring no clutter due to leftovers will happen.
Enhanced Portability & Flexibility: Moving or copying individual plugins with their configurations becomes straightforward, supporting multiple Notepad++ setups or versions on the same or on different computers.
Reduced config files Overwrite Risks: Separate Config sub-directories prevents configuration files from different plugins overwriting each other.
Simpler Customization & Troubleshooting: Locating and editing plugin-specific settings becomes easier.
Support for Selective Transfers: Users can copy/transfer specific plugins and their settings without affecting others.

Additional Features that might be of interest

Config Preservation on Uninstall: Incorporating an option in the Plugin Admin/Manager to retain configuration files during uninstallation of one or more plugin for example in case of plugin dll file corruption, will allow quick reinstallation with previous settings completely intact and will also allow a clean install, by a further option that overwrites existing config files into the PluginName/cConfig directory or, of course, deleting the dir and performing a total fresh install of the plugin.
Granular Transfer & Backup: at the moment it is possible to import just the dll file (one at a time) with the import plugin function, but no config or customization files are imported, So this will also facilitates transferring individual plugins between computers, maintaining user preferences, and even doing a transfer with multiple plugins and relative preferences all at once, by just selecting the main directories and checking a “import Config directory” option check box for each plugin or just for those the user wants to imports plugins with existing preferences and relative customization,
Improved Directory Structure: Implementing this as standard philosophy, would be a significant step forward in plugin management, reducing conflicts among plugins and improving user experience during updates or even when creating portable Notepad++ optimized for specific tasks that contain just a subset of plugins e.g. one for the computer one different with a subset for a portable thumb-drive

In summary, adopting a per-plugin directory structure with dedicated Config sub-directories would greatly improve plugin management, enhance stability, reduce or even prevent some conflicts among plugins or their preference files and offer more flexibility to users.

Further suggestions are appreciated,

Thank you.

PeterJones

Do not read this if you don’t want a critique of your ideas.

Currently, Notepad++ manages plugin configurations by storing all plugin-related configuration files in a shared, common “Config” directory into the main N++ > Plugin dir.

Notepad++ plugins manage their own configurations, most using the suggested plugins\Config\ directory or a subdirectory thereof.

Leftover Files & Conflicts: Sometimes, uninstalling plugins leaves residual files, which may cause clutter or other issues.

Alas, clutter is the bane of uninstallations.

Difficulty in Transfer & Customization: Moving individual plugins between different Notepad++ versions or portable setups is cumbersome, as it involves manually managing the shared Config directory and if the user doesn’t know what are the files related to that specific plugin is not always easy to transfer the customization done from the source to the destination.

If the user doesn’t choose to learn the configuration structure, that could be difficult.

Risk of Overwrites: Multiple plugins may use files with identical names (e.g., Config.ini), risking overwrites and configuration corruption or incompatibilities due to overlapping configuration files names.

I obviously don’t know all plugins, but could you actually name any plugins that use any naming scheme as horrific as config.ini without also including their own subdirectory? Or any two plugins that actually have conflicting names without using their own subdirectories? Or is this just a hypothetical problem that doesn’t exist in the real world?

Complex File Management: Finding specific plugin settings within the shared Config directory is challenging, especially when troubleshooting or modifying settings.

Most plugins name their config files after the plugin (or an abbreviation thereof), and any plugin worth its salt should document the name of the configuration file(s), at least if it’s not patently obvious. (The worst offender I’ve seen is NppExec, which uses names like NppExec.ini and npec_cmdhistory.txt and npes_last.txt.)

Each plugin should have its own dedicated directory structure, for example:
Plugins/
 └── PluginName/
      └── Config/
           └── Plugin configuration files

The best plugins already use their own subdirectory of the Config directory, so Plugins\Config\PluginName\____.xyz

It makes more sense to me for PluginName to be a subdirectory of Config than the other way around.

Cleaner Uninstallations: Removing a plugin involves just deleting its entire directory, ensuring no clutter due to leftovers will happen.

And most plugins involve just deleting their one config file, or their Config\PluginName directory (again, NppExec being the worst offender in this regard)

Reduced config files Overwrite Risks: Separate Config sub-directories prevents configuration files from different plugins overwriting each other.

Again, in my experience, the risk is 0, after more than a decade of plugin use. YMMV.

Support for Selective Transfers: Users can copy/transfer specific plugins and their settings without affecting others.

Irrelevant, as the same is true today.

Config Preservation on Uninstall: Incorporating an option in the Plugin Admin/Manager

Why mention the ancient and incompatible Plugin Manager. It’s irrelevant to today’s Notepad++.

to retain configuration files during uninstallation of one or more plugin

That’s literally what happens now.

for example in case of plugin dll file corruption, will allow quick reinstallation with previous settings completely intact

delete the DLL; install again.

Granular Transfer & Backup: at the moment it is possible to import just the dll file (one at a time) with the import plugin function, but no config or customization files are imported

I wish Don had removed that useless menu command when he added the builtin Plugins Admin. The only reason it existed was for people who didn’t have the old Plugins Manager plugin installed to manage their plugins in the pre-v7.6-era. And now, and even then, it was only useful, as you say, for DLL-only plugins.

With Plugins Admin, there is no reason for that old “import” command.

So this will also facilitates transferring individual plugins between computers,

You keep using this phrase. i can understand copying config files between computers, but I would always prefer installing plugins through the Plugins Admin,

And you do understand that for most people (those who install Notepad++), the plugin DLL goes in the hierarchy of the executable, whereas the plugin configs go in the AppData hierarchy – so it’s two separate hierarchies that you’re dealing with, so not as easy as you are implying.

Improved Directory Structure: Implementing this as standard philosophy,

As a philosophy, with the caveat that the order should be config\PluginName\, I am fine with it. Your post implies much more than a philosophy.

would be a significant step forward in plugin management,

hehehehe

reducing conflicts among plugins

again, name one

There’s my point-by-point analysis.

And then, of course comes the technical aspects that you’ve ignored:

Notepad++ gives easy access to %AppData%\Notepad++\Plugins\Config\ (or that installations’s equiavlent) as the root directory that it suggests for plugins to use by providing a message NPPM_GETPLUGINSCONFIGDIR… But whether or not a plugin uses that is not up to Notepad+++.
Notepad++ does not and cannnot enforce where plugins put their configs. It is completely and totally and 100% impossible for Notepad++ to enforce that: Plugins can write files (config or otherwise) in any directory that has write permission, and there is nothing Notepad++ can do to stop that.
If Notepad++ were to change what that message returned (for example, returning %AppData%\Notepad++\Plugins\Config\PluginName\ for a normal installation), it could break existing plugins (whether they are currently using that message for getting access to their own , or abusing that message to find a directory that’s relative to Notepad++'s configuration directory, since Notepad++ doesn’t provide a message for that one) – and breaking existing plugins, especially in such a drastic way, should only be done with exceedingly good reason.

Every time Don has broken backward compatibility, it has created months or years of difficulties with plugins, and headaches for all the regulars who help people here and in GitHub. I sincerely hope you are never able to convince someone to put in that feature request into GitHub for you, and that Don never gets the idea in his head to change the behavior of the existing message.

If, on the other hand, you wanted to suggest to plugin authors that they voluntarily use NPPM_GETPLUGINSCONFIGDIR\PluginName\ to house their plugin’s config files, I am all for it. (I would especially appreciate if someone can convince NppExec to move all its config files to a dedicated subdirectory).

(And if nothing else comes of it, you reminded me that I preferred that hiearchical structure, so I have given myself a TODO to move my ConfigUpdater plugin’s configuration and log files to a subdirectory, rather than just relying on the ConfigUpdater prefix in the names to help keep things clean.)

update: caveat: this is just my opinion; I don’t speak for everyone or even anyone here, nor for the Developer. I am just expressing my own vehement disagreement with the “forcing” that was strongly implied by the original post, and making it clear that I will argue against any breaking change with regards to this directory for existing plugins making use of the NPPM_GETPLUGINSCONFIGDIR in the intended manner

Ekopalypse

@wonkawilly

Everything in one directory would mean one configuration for all in the case of terminal server configurations. Bad … and also from a security point of view, if users are allowed to configure this themselves.

wonkawilly

After reading the answers, it seems that the proposal for improvement of this OP is not a real good Idea.

Thank you all for the clarifying answers.