xparq / notepad-plusplus-gilded Goto Github PK

(For many others, separate issues may probably come, just for the sake of explicit documentation.)

If an installed plugin

a) is not found (silent disabling now, which is fine), or
b) fails to load properly (error box, which is also fine),

do not remove it from the "Installed" tab of Plugins Admin, unless the user answers "NO" to the "Do you want it to be removed?" question.

Show the problematic plugin, but in a different color (grayed, or red), or otherwise mark it up as broken.

See also: #4

It's mainly about cutting off the ATL dependencies, and some code facelifting here and there, things like replacing CString with something standalone, and those ComCriticalSection to std::mutex stuff etc.

Quite possibly breaking changes, so would be nice to take them seriously. ;)
Thankfully, though, their scope seems to be limited.
So, analyse that scope first, before deciding what exactly to test!

I'm not sure what level of access the current scripting plugins provide, hopefully there's nothing much to do about this already.

See #7 about the "philosophical" difference between this version and the original NP++, though.

Learn from Bernie Greenberg's Multics MacEmacs lesson: scripting is not an addon, not an afterthought. That is actually one of the main, critical features!

So handle it like that. Instant scriptability should be supported right from the core.
Now, the specific language does not matter: there can still be several ones provided, as plugins.

It is the workflow that matters: add or change command ("macro") should be always available in every single context. That's the point: full frontal exposure of the editor itself, the less "core-only" the better (think of the kernel vs. user space duality).

If there's a breaking problem with the plugin subsystem (i.e. nppPluginsList.dll could not be loaded; see #1), NP++ now silently removes the related menu item, confusing users.

See also: #3