Hi, @coises,

I re-tested the supposed bug and I simplified the procedure which is necessary to trigger that bug !

If opened, close the Search++ plugin by clicking on the cross, at the far right

A Re-open Search++ with the Plugins > Search++ > Search... option

B Try to close the Search++ panel by clicking on the cross, at the far right => Nothing happens !?

C After some trys, if you move slightly the mouse, you should be able to close the Search++ panel

Sometimes, you’ll need to repeat the actions A ato C, up to 5 times consecutively, to trigger that bug. but this event may also occur at the first try !

I also noted that, when the bug occurs, any subsequent left click on the cross does nothing until I move very slightly the mouse, without any clicking, that is enough, then, to close the search++ panel by clicking againg onto the cross icon. Very strange, indeed !?

As I suspected that the problem could be an hardware issue with my bluethooth mouse, I disabled it and installed a classical USB mouse, instead. But, unfortunately, results were identical as well as the uncertainty regarding the manifestation of the bug !

I have different portable versions of Notepad++, but the one which is concerned is the v8.9 release where I installed, both, your Columns++ and Search++ plugins

Here is my Debug info :

Notepad++ v8.9 (64-bit) Build time: Jan 10 2026 - 02:25:19 Scintilla/Lexilla included: 5.5.8/5.4.6 Boost Regex included: 1_90 pugixml included: 1.15 nlohmann JSON included: 3.12.0 Path: D:\890_x64\Notepad++.exe Command Line: Admin mode: OFF Local Conf mode: ON Cloud Config: OFF Periodic Backup: OFF Placeholders: OFF Scintilla Rendering Mode: SC_TECHNOLOGY_DIRECTWRITE (1) Multi-instance Mode: monoInst asNotepad: OFF File Status Auto-Detection: cdEnabledNew (for current file/tab only) Dark Mode: OFF Display Info: primary monitor: 1920x1080, scaling 125% visible monitors count: 1 installed Display Class adapters: 0001: Description - Intel(R) Iris(R) Xe Graphics 0001: DriverVersion - 32.0.101.7084 OS Name: Windows 11 Pro (64-bit) OS Version: 25H2 OS Build: 26200.7462 Current ANSI codepage: 1252 Plugins: mimeTools (3.1) NppConverter (4.7) NppExport (0.4) ComparePlus (2.2) ColumnsPlusPlus (1.3.1) NppUISpy (1.2) MultiReplace (4.6.0.33) Marginalize (1) Search++ (0.5.5)

Finally, note that this portable version of N++ is installed on an USB drive

Best Regards,

guy038

@martin-honnen ,

Please be careful when forking and keeping the original name for an apparently-abandoned plugin. Sometimes, it turns out it wasn’t as abandoned as thought – something like that happened with NppConsole plugin (as obliquely mentioned in a recent Topic here): a few years ago, it appeared abandoned, so a regular here took the source code, and made their own fork, but kept the original name (thinking it would be safe, because it appeared to be no longer supported in the original channel); but then, fast forward a few more years, and the original author did provide their own upgrades to the original plugin – so now there are two competing development paths, each having version numbers not present in the chain for the other, which will make any future questions in the forum confusing, as to which NppConsole plugin is actually being talked about.

Similarly, if morbac ever decides to come back to the plugin, then your fork and the original could have conflicting and/or confusing version numbers and naming.

I would highly recommend coming up with your own name for your product, if you are planning to continue development and support on your version of the plugin. If it’s really just a one-off thing, and you aren’t planning on future bugfixes/improvements/support, then it’s up to you whether it’s worth the rename; but if you want to continue to work on the plugin, then I’d suggest the rename.

OTOH: if you can get permission from @morbac to take over completely, then it’s safe to keep the original name, because you’ve got the permission. (It’s most clear, in cases like that, if you can get write permission to the original repo – @chcg was able to do with @bruderstein’s PythonScript, and that sense of continuity makes it more obvious that his is still the “official” PythonScript.)

@rdipardo said in A question about dark mode, plugins, and an owner-draw ComboBox:

Try passing the control’s handle to the ::SetWindowTheme function provided by the uxtheme header, using L"DarkMode_CFD" as the pszSubAppName; to restore light mode, call it with the same arguments, but change pszSubAppName to a null pointer.

Thanks, Robert. At first attempt, this doesn’t appear to solve the problem.

The colors are right with just NPPM_DARKMODESUBCLASSANDTHEME; the problem is that the static control shows unknown text instead of the selected drop-down entry, and attempting to select from the drop-down produces bizarre highlighting and tracking instead of what is expected (and still doesn’t set the static control). Adding the SetWindowTheme call doesn’t change that. Removing NPPM_DARKMODESUBCLASSANDTHEME, of course, makes everything else light, and for the control in question, SetWindowTheme only seems to change the drop-down chevron. Interestingly, NPPM_DARKMODESUBCLASSANDTHEME does get all the colors right, including in the owner-drawn drop-down; it just breaks the functionality in the process.

The problem goes away entirely if I remove the CBS_OWNERDRAWFIXED style (but then, of course, it doesn’t display as intended, showing the color associated with each indicator that can be selected). That’s why I feel like the problem is most likely to do with the sub-classing. I can’t find any clear documentation on how all that works. I don’t even know why the controls are being sub-classed, and not just themed. Maybe there is a way to exempt that control from sub-classing, and do whatever it is that the sub-classing does in my own code?

A pointer to actual documentation on this design, how it works and how it is meant to be used would be wonderful, but I’m guessing no such thing exists. :-(

JsonTools v8.5 is now available on the plugin manager for Notepad++ 8.9.3. The main change is that ANSI-encoded documents containing non-ASCII characters can now be parsed correctly.

@Murray-Sobol-1 ,

The links you pointed to were to the old 2017 pre-Notepad++-7.6 “Plugin Manager” plugin’s plugin-list. (There used to be a plugin which handled installing/uninstalling plugins in Notepad++. In v7.6, that was integrated into the core Notepad++ code, so that Don could make sure that the Plugins Admin always stayed compatible with Notepad++, rather than relying on a third party for such an important feature.) For nearly a decade, https://github.com/notepad-plus-plus/nppPluginList/ has been the home of the official list of plugins that gets shown in Plugins Admin.

@pierrecoach ,

More on the disappearance of NppCrypt and its repo can be found in this NppPluginList issue. I won’t re-iterate the details, since you can read them there if you are curiuos. But I will say that it looks like @chcg is going to try to resurrect the plugin from archives of the original source code; but it might take him some time. Until then, I’m not sure that any of the links given have any compiled DLL available. Hopefully, you don’t have any critical data that was encrypted on some other machine, that you need to decrypt with the plugin on this new setup. If you do, let us know… (Actually, if you do: do you also have access to the old machine? If so, you can copy the ...\notepad++\plugins\NppCrypt directory from the installation on that machine, and put it on your new machine.)

@Yan-Serenade

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/16719#issuecomment-4132203721

@W-Pong said in Columns++, I'd like to *retain* commas when converting to elastic tabs/spaces:

Is there a way to retain the commas?

I made a new release of Columns++ with an option to do that — an additional checkbox in the Conversion settings dialog: Keep separator character when converting to tabbed.

The new release is Columns++ version 1.3.2.

I have not marked the release stable, but I believe that there is very little chance this change will have any unanticipated negative effects. It should be safe to install.

@Mark-Olson You are right, thanx Mark.

@Vitalii-Dovgan said in NppExec Manual: CHM vs. HTML version [poll]:

Somebody, stop me! It has been 2 weeks I’ve been updating and improving the HTML form of the Manual!

Sorry, it is not possible for me to stop someone from improving documentation. ;-)

I’ve been footling around with my plugin a bit to try and generate a PR automatically when a new version is released. So - is the layout of the json files significant.

Most of the entries look like

\t\t\t{ \t\t\t"folder-name": "Linter++", \t\t\t"display-name": "Linter++", \t\t\t"version": "1.0.3.0", \t\t\t"npp-compatible-versions": "[8.7.5,]", \t\t\t"id": "F56573351010B62BFC75039725496C8687D53E82A3F47074F1F1B629A37A92C1", \t\t\t"repository": "https://github.com/ThosRTanner/notepad-pp-linter/releases/download/1.0.3/plugin_dll_ARM64.zip", \t\t\t"description": "Allows realtime code check against any checkstyle-compatible linter: jshint, eslint, jscs, phpcs, csslint, and many others.", \t\t\t"author": "Tom Tanner", \t\t\t"homepage": "https://github.com/thosrtanner/notepad-pp-linter" \t\t\t},

So I thought i could do my updater in python, just load up the json file, modify my entry, and dump it back, then commit

One entry (just one) uses spaces instead of tabs.

So my question is is there an official layout for these files? Is any valid json permissible (all on one line for instance), or is it expected to be formatted as 1 line per key and indented with tabs?

Would converting those spaces to tabs as part of my PR be frowned upon, or should I just read the file and modify the lines appropriately?

@rdipardo ,
Thanks for pointing out the Native AOT template — I wasn’t aware of it when I started the ARM64 migration.

I did actually try Native AOT early on, but ran into two issues: the export limitations you mentioned, and the resulting DLL size (~57 MB), which felt way too large for a Notepad++ plugin. That’s why I ended up going with DNNE — the plugin DLL stays small (~1 MB), though it comes with the .NET 8 runtime dependency.

How large are the DLLs you’re getting with the Native AOT template? Has trimming improved enough to bring the size down to something reasonable for a plugin?

@Carlos-Sánchez said in [New plugin] Smart Math:

I’m a bit lazy and haven’t got a clue

I can’t solve the first part, but for the clue:

it’s just a PR to the nppPluginList project. Since you’re working in GitHub already, I assume you know how to do the PR fork the nppPluginList repo, create your own branch in that branch, edit pl.x64.json to link to the 64-bit version, and pl.x86.json to link to the 32-bit version the id required in the JSON is just the SHA256 hash, which GitHub provides for you:
fd4a838f-9724-477d-b755-24836141dc88-image.png once you have edited both files in your branch, submit the PR from that branch

@KelltimeOG
Fixed in https://github.com/notepad-plus-plus/wingup/commit/5d89e486a5cb63251b8ed0b0e9f441a9774709ff
The fix will be in WinGUp v5.4.1, which is included in Notepad++ 8.9.3 release.

@Evelyn-Walker ,

I tested the behavior you described. In Notepad++ the Ctrl+L (Delete Line) command

That is wrong terminology, as already described above. Ctrl+L is Line Cut, not Line Delete. To use the wrong terms causes confusion for everyone. From the OP, it was acceptible, because they didn’t know better. But to post like you are an authority, but to use the incorrect terminology, is detrimental to yourself and anyone who reads the answers here.

internally performs a cut-like operation,

Of course it does. It’s literally Line Cut, so it definitionally affects the clipboard

which means the deleted line is temporarily placed into the clipboard.

It’s no more “temporarily” on the clipboard than any Ctrl+C or Ctrl+X is “temporarily” in the clipboard. It’s in the clipboard until something else replaces it, just like every other clipboard action.

Use Ctrl+Shift+L (if configured) or another plugin/command that deletes the line without copying it.

Did you come up with that alternative all on your own, or did you just reiterate what @guy038 and I had already said?

Alternatively, copy the text again after performing line deletions if you still need it in the clipboard.

That’s horrible advice.

If preserving clipboard content during line deletion is important, it could be considered as a feature request rather than a bug.

No it couldn’t, because the feature already exists. Line Delete already exists as Ctrl+Shift+L: use Line Delete if you don’t want to affect the clipboard, and Line Cut if you do want to affect the clipboard.

@Evelyn-Walker , make sure you are not using LLM or GPT or any other AI to write your posts for you: that’s expressly forbidden in this forum.

@Vitalii-Dovgan
Thanks for the feedback!
v1.1 is now out with full Unicode compliance - all Win32 API calls migrated to W variants.
Also added separate color settings for dark and light themes.

GitHub