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
