Search++: A work in progress

guy038

Hello, @coises and All,

Thanks for that new release ! Briefly :

I quickly test the Replace All button, while in ICU mode as well as the new icon for the Selection scope on command buttons => I onfirm the expecting results !
Thanks for including the Current Line Indicator and Caret settings within Search++. It’s worth to point out that if you modify these N++ settings during a N++ session, you’ll need to close and restart Notepad++ in order that these new parameters are taken in account by the Search++ plugin !
Finally the message, regarding the null matches when using a Mark or Show command, is, indeed, much more explicit !

Now, I stumbled upon a weird bug : while within a N++ session :

If Search++ panel is already opened, click on the cross, on the far right to close the Search++ dialog

Now, re-open Search++ with the Plugins > Search++ > Search... option ( Note that I use the Docking mode )

Click on the current tab ( not within the text window ! )
Click on the Search++ windows title
Sometimes, you’ll need to repeat these last two actions twice, in order to trigger that bug
Now, try to close the Search++ panel by clicking on the cross, on the far right => Nothing happens !?
Generally, after some clicks, the dialog finally closes !

Note that I mapped the Ctrl + Shift + N shortcut to the Plugins > Search++ > Search... option. So, if I use this shortcut, I’m able to actually close the Search++ dialog in that specific case and also in all the other cases !

I would consider that it’s a minor bug and I’m not 100 % certain about the steps to reproduce it : not quite obvious !

Best Regards,

guy038

Coises

@guy038 said in Search++: A work in progress:

Thanks for including the Current Line Indicator and Caret settings within Search++. It’s worth to point out that if you modify these N++ settings during a N++ session, you’ll need to close and restart Notepad++ in order that these new parameters are taken in account by the Search++ plugin !

Another way is to change between light and dark mode; that causes Search++ to reset all the appearance information it copies from the active tab. That’s because plugins get a notification when light/dark mode changes, but I don’t think there is anything that would notify Search++ when current line or caret settings change.

A good point, though: I should either document this behavior, or reset appearance every time a Search++ window gains focus.

Now, I stumbled upon a weird bug : while within a N++ session :

If Search++ panel is already opened, click on the cross, on the far right to close the Search++ dialog

Now, re-open Search++ with the Plugins > Search++ > Search... option ( Note that I use the Docking mode )

Click on the current tab ( not within the text window ! )

Click on the Search++ windows title

Sometimes, you’ll need to repeat these last two actions twice, in order to trigger that bug

Now, try to close the Search++ panel by clicking on the cross, on the far right => Nothing happens !?

Generally, after some clicks, the dialog finally closes !

Note that I mapped the Ctrl + Shift + N shortcut to the Plugins > Search++ > Search... option. So, if I use this shortcut, I’m able to actually close the Search++ dialog in that specific case and also in all the other cases !

I would consider that it’s a minor bug and I’m not 100 % certain about the steps to reproduce it : not quite obvious !

I haven’t yet been able to get this to happen on my system. Thank you for reporting it. If I can reproduce it, I’ll attempt to figure out why it happens. What’s strange is that Notepad++ manages the close button for docking dialogs. Even if I completely remove all my close (actually hide) dialog code, clicking that X still closes the docking panel and hides the search dialog. So either you have stumbled on a Notepad++ bug, or something I am doing in Search++ is interfering with normal Notepad++ behavior.

Have you ever seen this behavior with any other docking window?

guy038

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

Lachlanmax

@guy038, @coises and all,

I use the dark mode display for almost all apps and I really like it, so I think we are in agreement :)

You know what they say - join the dark mode, we have cookies… 🍪

On another note, I would like to hear your thoughts as veterans on this forum. I’m working on an AI chat plugin to streamline the use of prompting an LLM into the workflow with N++. I wonder - has anyone done it before? What would be important features to implement?

I would appreciate hearing your thoughts.

Thank you!

guy038

Hello, @lachlanmax and All,

Well, presently I’m not a modern C++ developer and I rather use the old Microsoft Qbasic or sometimes the GAWK software and, more rarely, the N++ PythonScript, in addition to N++ and its plugins, of course !

However, I’ve got some documentation on C/C++. So, I’ll probably learn a lot from scratch but I’m not sure yet if I’ll be able to make improvements to our beloved editor !

So, to my mind, you should get in touch with @Richárd-stockinger and @jw which already developed AI tools for N++. They will surely provide you with valuable advice for your project ! Refer to :

https://github.com/krazal/nppopenai

https://github.com/Qdthon/Notepad-AIPlugin

Best Regards,

guy038

P.S. :

Although you might assume that some of my regex solutions seem to have been created with the help from an IA engine, I can assure you that it’s only my modest brain that’s at shake when it comes to these resolutions !

Lachlanmax

@guy038
I wasn’t familiar with these projects. Thank you for the tip-off, I have a lot to learn from these. Glad I asked your advice.

We don’t know each other too well yet, but from your replies I get the feeling you have been coding for a while now… as a relative n00b I think it’s good to learn coding the nuts-and-bolt way, not just “vibe coding” like everyone is nowadays. (Even though I’m developing an AI plugin, so a bit of a contradiction. But I like to develop plugins that I would use personally, and I don’t use it to “vibe code”. Granted though that some might.)

tl;dr Hard work pays off!

guy038

Hi, @lachlanmax and All,

I forgot to give you the Community threads of, both, @Richárd-stockinger and @jw :

https://community.notepad-plus-plus.org/topic/24444/new-plugin-nppopenai

https://community.notepad-plus-plus.org/topic/27361/ai-plugin

BR

guy038

guy038

Hello, @coises and All,

How are you, @coises ? Pretty good, I guess ! I just uploaded a new version of the ICU.txt file which simply corrects a few typos.

https://drive.google.com/file/d/1_TwEV1oorsoWUUjL97BmptcR4fpNQ98_/view?usp=sharing

First, regarding the bug I mentioned in my two previous posts, I also detect it with native N++ and, for example, the Find Results panel :

Open the Find dialog
Do any kind of search
Click on the Find All in Current Document button

=> A Search results panel opens and displays all the occurrences of the searched string

Now :

(1) First, click once, anywhere on the blue Search results title
(2) Then, moving your mouse horizontally right to the cross, at the far right, try to close the panel => Nothing happens !
(3) Just, move down the mouse within the Search results panel then re-click on the cross => This time, the Search results panel should close, as expected.
Re-open the Search results panel, using the F7 key
Repeat the actions, 1, 2 and 3 to trigger again that bug. Sometimes, some tries are necessary to get into the problem !

Remark :

If, you accidentally double click on the Search results title bar, this panel will become a floating window. To restore its initial position, simply double-click again on the Search results title bar

Note that, in the end, this bug does not really matter because I mapped the Ctrl + Shift + N shorctut to the Search... option of your plugin. So, hitting this shortcut twice does close the plugin, anyway !

I thought of an enhancement of your Search++ plugin :

Let’s suppose that I want to mark all lines which satisfy the regex below, against the latest change.log file ( release 8.9.6 ). So :

We open or select the change.log file / tab
We open the Mark dialog ( Ctrl + M )
We check the Bookmark line, Purge for each search and Wrap around options, ONLY
MARK (?i-s)(?:\G|Q).*?T
We select the Regular expression mode
Finally, we click on the Mark All button

Two lines only are bookmarked : the very first one and the point #8 of v8.9.4. However, the total number of occurrences is 8

Notepad++ v8.9.6 vulnerability fix, regression fixes & bug-fixes:
 8. Fix quote escaping causing incorrect JSON syntax highlighting (Lexilla update related).

As you can see :

For the first line, as we are at the very begining of file, the \G alternative finds two occurrences
For the second line, the Q alternative finds the first occurrence and the \G alternative finds the five remaining occurrences

So, I was wondering if you could alternate the colors, between the present mark color and an other one, in order to easily distinguish these occurrences ?

Now, near the end of your initial Search++ post, you said :

I plan to add a Save function that will let you save searches you might want to use again. Of course, once it is possible to save, it has to be possible to delete and rename and edit and organize… I haven’t designed a user interface for any of that yet.

I do support this future enhancement !

Best Regards,

guy038

Coises

@guy038 said:

So, I was wondering if you could alternate the colors, between the present mark color and an other one, in order to easily distinguish these occurrences ?

I have thought about the possibility of making marks designate individual spans of text rather than running together. It is possible. In fact, you can see it, if you look closely, in the Search++ search results window if you do a Find All with the change log and your regular expression. You might have to zoom to see it, but there are small white spaces between the different matches. The search results window also marks null matches with an upward-pointing chevron below the baseline.

Your idea makes sense. I believe I would have to make it an optional feature, because it is not the way marking ordinarily works in Notepad++. I also have to consider how it impacts search in marked text, though I think that would be straightforward: when marked text is separated in this way, each individual span would be searched independently. (In the current way of marking, each contiguous marked block is searched regardless of whether it came from a single match or multiple matches.) It will take some thinking to make sure what happens when marked text is already present and new marks are added which adjoin or overlap existing marks makes sense.

I do support this future enhancement

As you’ve no doubt noticed, there hasn’t been any progress on Search++ lately. I had hoped that following the point where I made the first public release I would be able to just keep going straight through to a first “stable” release, but my attention has been directed elsewhere for a time. I’ll be back.

Find/replace in files and saving searches are the two main features I want to add before I think I can close in on “stable.” These are both things that I think could cause significant changes in the programming (and maybe the user interface), so I don’t want to try to reach “stable” and then immediately destabilize everything. I’m treating their absence as a blocker.

I think I want to add a couple more options for manipulating marked text (like remove marks from selected text) to the Tools menu, and I have some known problems (like that the search results window can be painfully slow with a lot of matches in a large file, and I don’t think the routine that is supposed to make finding a match scroll so that the match won’t be hidden behind the dialog when it is non-docking works reliably yet). ICU search should either be hidden or be extended to work with most if not all of the same commands as Regex (Boost).

There is still no simple way to access the drop-down menus on the split command buttons by keyboard, and I still don’t have a good idea how to make it both possible and discoverable. I think I need to add Find and Replace commands to the plugin menu so it would be possible to set them as Notepad++ shortcuts, which would make it possible to do sequential find and/or replace while focus remains in the document.

Your suggestion here makes sense, and I need to crawl through this entire topic to see what other ideas and observations I might have forgotten. There was a suggestion in another topic about showing context (lines before and after) in the search results list: I’ll probably look at that when I look at search in files, since both will require significant changes to the way I build the search results list at present.

Coises

@guy038 said:

First, regarding the bug I mentioned in my two previous posts, I also detect it with native N++ and, for example, the Find Results panel :

Thank you for that additional information. I had a suspicion this was a Notepad++ behavior not really related to the plugin.

I have not been able to reproduce it. It is possible that it is dependent on some detail of your operating system or drivers.

Since you can reproduce it without any plugin, I suggest adding it as a Notepad++ issue if you think it is worth further investigation. It could be that others will be able to reproduce it, perhaps including someone who can run Notepad++ under debug and close in on what is going wrong.

Coises

Search++ version 0.6 is available.

The big change in this version is the addition of a Search in Files dialog:

There have been a few small fixes elsewhere — by now I’ve forgotten what they were — but mostly this release is for Find in Files. Adding that led to quite a few changes in code it shares with the existing functions, so unfortunately there could be new bugs in old functions. On the whole, though, handling of the search results list should be improved for all functions that use it.

If you don’t like to read help, at least don’t forget to try right-clicking the text entry boxes and items in the file list.

Replace in Files is planned but not yet implemented.

guy038

Hello, @coises and All,

First, many thanks for adding the Find in Files capability within the Search++ plugin. In addition, this search dialog allows you to filter by date range and/or size and also to choose or exclude some extensions !

Regarding the Search++ Search in Files dialog :

To my mind, the magic option is the last Filter Reg. Exp. option. Indeed, for example, from my USB key named D:, I typed in the text below, in the Filters zone :

^890_x64\\.+\.log$|^862_x64\\|^C.*\.txt

Then, the search scope would be :

All the .log files in the 890_x64 arborescence of D:
All files of the 862_x64 folder of D:
All the txt files, from the root ( D: ), whose name starts with a letter C

It’s important to emphasize that the Filters search is always a NON-SENSITIVE search. Thus, given the example above, the search would occur on file D:\..\...\...\Test.LOG and on file D:\current.txt. This remark also applies to the Extensions and Exclude options !

In order to search in a specific folder, named Music of my USB key, I have two possibilities :

Clic on the Browse button in the Folder zone, select the Music folder and choose the option None in the Filter zone
Type in D:\ ( the root ) in the Folder zone, choose the Filter Reg. Exp. option and type in ^Music\\ in the dialog

But if you’re looking for any directory of your media, with name Music, prefer this regex (^|.*\\)Music\\

Note that if you type in, for example, log;ini in the Filter Extensions option, you may use, instead, the Reg. Exp. option with the regex \.(log|ini)$

Now, is there a particular reason for not allowing the ICU search ? For some European people, the search of any text depending of a specific language could be interesting !

For example, the different searches, below, would find any file containing GREEK characters :

All Greek blocks [[[\p{In_Greek}][\p{In_GreekExt}][\p{In_AncientGreekNumbers}][\p{In_AncientGreekMusic}]]&&[\p{Assigned}]] ( = 135 + 233 + 79 +70 = 517 characters )
The Greek script \p{Grek} ( = 518 characters )
The Greek Extended script \p{SCX=Grek} ( = 531 characters )

Regarding the Search++ Results dialog :

Would it be possible to add a Purge option, like in the context menu of the N++ Search results dialog ? You could use the same label Purge for every search or some equivalent ( I do like Purge before each search )
Although written in your files list, I also noted that the number of scanned files is not reported in the Search++ Results** dialog, unlike with the N++ **Search results` dialog

For instance, the search of the string Fi within all files of my USB key gives :

- Finished; found 34 283 matches in 841 of 1771 files. in the FILE list of Search++

- 34 283 matches in 841 files: Fi, on the FIRST line of the Search++ Results dialog

- Search "Fi" (34283 hits in 841 files of 1771 searched) [RegEx: Case], on the FIRST line of the N++ Search Results

And, if possible, it would be best to include the chosen options of the current regex too, like Regex, Case,... ?!

To end with, I noticed that, within the N++ Search results, it is possible to easily see all files which has matches, without seeing the matched lines :

By hitting Ctrl and clicking on ⊟, on the first line => The search collapsed after some time and then with a simple click on ⊞
By using the Fold All option of the Context dialog and then a simple click on ⊞ of the first line

Although, within the Search++ Results dialog, you can double-click on any file header or on the Search header itself to collapse the lines, I have not been able to get the configuration below, in the Search+++ Results panel :

⊞ D:\Micro.txt
⊞ D:\862_x64\npp.8.6.2.portable.x64.7z
⊞ D:\862_x64\autoCompletion\actionscript.xml
...
...
...
⊞ D:\change_896.log
⊞ D:\Word_Frequency.txt

As usual, @coises, these ideas are only suggestions. Do as you like, of course !

Best Regards

guy038

Coises

@guy038 said:
First, many thanks for adding the Find in Files capability within the Search++ plugin.

Thank you for trying it!

It’s important to emphasize that the Filters search is always a NON-SENSITIVE search.

I made it that way by default since file and folder names are not case sensitive in Windows. You can still prefix the expression with (?-i) to make it case sensitive. I don’t know if the API I use to retrieve file paths from a folder is guaranteed always to return names in the correct case, but it appears that it does.

Now, is there a particular reason for not allowing the ICU search ?

Just the same as before — allocation of time and effort. ICU is not a “drop-in replacement” for Boost::regex; it would have significantly delayed me being able to release a public version of this had I included ICU search. Since Notepad++ users are already familiar with Boost::regex syntax, and I am more familiar with its programming interface (and so can work with it more quickly than ICU), I have prioritized Boost::regex.

I am not ruling out adding it later. I will say, though, that I plan to study and attempt to incorporate its useful unique features into Boost::regex before spending too much time trying to implement additional ICU search variants of Search++ functions. It remains to be seen whether I can successfully fork Boost::regex and extend/enhance it to make the ICU search option redundant. It definitely helps me that you are making note of ICU features you miss in Boost::regex.

Regarding the Search++ Results dialog :

Would it be possible to add a Purge option, like in the context menu of the N++ Search results dialog ? You could use the same label Purge for every search or some equivalent ( I do like Purge before each search )

That makes sense and sounds possible. I’ll add it.

Although written in your files list, I also noted that the number of scanned files is not reported in the Search++ Results** dialog, unlike with the N++ **Search results` dialog

And, if possible, it would be best to include the chosen options of the current regex too, like Regex, Case,... ?!

Agreed. I’ll add that information.

To end with, I noticed that, within the N++ Search results, it is possible to easily see all files which has matches, without seeing the matched lines :

By hitting Ctrl and clicking on ⊟, on the first line => The search collapsed after some time and then with a simple click on ⊞

By using the Fold All option of the Context dialog and then a simple click on ⊞ of the first line

I see your point. There is some flexibility missing. I will look for a way to make that easy to do.

Coises

@guy038 said:

Regarding the Search++ Results dialog :

Would it be possible to add a Purge option, like in the context menu of the N++ Search results dialog ? You could use the same label Purge for every search or some equivalent ( I do like Purge before each search )

A question about this. Since it is in a sense a “destructive” option, do you think it should be remembered across Notepad++ sessions, or should it have to be invoked afresh in each session where you want it enabled?

guy038

Hi, @coises,

In my opinion, this option seems more like a way of working than a delete option. So, I think this option should remain active between Notepad++ sessions. Note that it’s presently the case within the N++ Search results panel.

But, of course, on re-opening N++, the N++ Search results and the Search++ Results panels are both cleared silently, before any search !

After opening Notepad+ and a first search, involving the N++ Search results or the Search Results panels, you can easily un-check that Purge option if you plan to compare multiple searches !

BR

guy038

Coises

Search++ version 0.6.1 is available.

This update enhances the Search++ Results list, including adding more detail to the search headers, implementing an “automatically purge” toggle and recognizing single-click in the margin.

All comments, critiques and thoughts are welcome!

@guy038 said:

Would it be possible to add a Purge option, like in the context menu of the N++ Search results dialog ?

Although written in your files list, I also noted that the number of scanned files is not reported in the Search++ Results** dialog, unlike with the N++ **Search results` dialog

[…]

And, if possible, it would be best to include the chosen options of the current regex too, like Regex, Case,... ?!

To end with, I noticed that, within the N++ Search results, it is possible to easily see all files which has matches, without seeing the matched lines

This update addresses all those points. See the help for details about the commands in the results list.

I’m not handling folding quite the same way as Notepad++ does. (It could be that in time I will decide to try to emulate Notepad++’s appearance and behavior more closely.) What I did was add a context menu option (also available as Shift+Enter or Shift+double-click) for search header lines that toggles the fold state of all documents in that search without folding the search itself. So if you select Expand/Collapse Search, or double-click, the search folds or unfolds with the folding of documents within it unchanged. If you select Expand/Collapse Documents, or Shift+double-click, when the search is expanded, all documents within that search either expand or collapse (the opposite of whatever is the state of the first document).

I added a few other things, like clicking in a margin being equivalent to double-clicking in a header line or on the first position in a detail line. There is a purge toggle now, and search header lines include information about how many files were searched and the type of search (including modifiers).

guy038

Hello, @coises and All,

Thanks for this quick new version. And many thanks for implementing all propositions that I suggested ;-)) So far, everything seems to work nicely !

Now, one request :

Would it be possible, in the Search++ Results to prevent the displaying of the last character ( an ? sign inside a rectangle ) in all lines ( Search line, Document lines and Matched lines ) ? Personally, I think it globally makes the display harder to read ! Just a personnal appreciation

And one question :

Natively, you can swap the keyboard focus between the N++ Search results and the Current document window by hitting the F7 key. I do not see an equivalent with your Search++ plugin

I mean :

When, both, the Search++ and the Search++ Results panels are opened, you can swap the keyboard focus between them with the Ctrl + H shortcut. How to toogle between the Search++ Results and the Current document window ?

Best Regards,

guy038

guy038

Hi, @coises and All,

Sorry, but I came across a serious bug regarding the ICU search, since Search++ version v0.6

The Find in Selection, Find in Marked Text and Find in Whole Document options
The Find All in Selection, Find All in Marked Text and Find All in Whole Document options

Triggers the closure of Notepad++, without saving any configuration file and unsaved tabs

After some quick tests :

The Select, Mark and Show options,
The Count in Selection, Count in Marked Text and Count in Whole Document

Seems to work correctly in ICU mode

BR

guy038

Coises

@guy038 said:
I came across a serious bug regarding the ICU search, since Search++ version v0.6

Thank you for the detailed report. I can reproduce it… in the release version. It doesn’t happen in a debug version (which uses exactly the same code); so it’s a subtle error somewhere. I will find it.

I changed some existing code when I added Find in Files. You observation that this fault began in 0.6 will help me know where to look.

Coises

@guy038 said:

Would it be possible, in the Search++ Results to prevent the displaying of the last character ( an ? sign inside a rectangle ) in all lines ( Search line, Document lines and Matched lines ) ?

Huh. I know what must be causing that, but I don’t know why it is causing it (on your system, but not on mine). (I set line ending characters to be displayed, but then to display with zero opacity. I do this so the marks I place to indicate a zero-length match will still show when the match occurs at the end of a line. The mark must be placed on the following character, and if the character isn’t shown, neither is the mark.)

Would you tell me what font you use for Notepad++ documents (the Search++ Results window copies that from the document window) and what you have at Settings | Preferences… | MISC. for rendering mode (GDI or DirectWrite)?

If I can figure out why you see the characters, hopefully I can figure out what to change so that you (and others with the same configuration) won’t see them.

Natively, you can swap the keyboard focus between the N++ Search results and the Current document window by hitting the F7 key. I do not see an equivalent with your Search++ plugin

The problem is that Search++ can’t (or shouldn’t… see below) control what shortcut keys do when focus is in Notepad++.

From the Search++ Results window, Ctrl+N will take you to the document. To switch from the document to the Results, though, I’d have to add a Search++ Results entry on the Plugins | Search++ menu, and then you’d have to set a shortcut for that in the Notepad++ shortcut mapper. You probably wouldn’t want to give up Ctrl+N, though.

The only way to get from Notepad++ to Search++ (or any plugin) is through a shortcut that’s either manually added in Shortcut Mapper or added by default in the plugin’s setup. (I’m still not sure how conflicts are resolved when a plugin defines a shortcut key that is already defined by default, by the user or by another plugin. I did define a few shortcut keys in Columns++ for manipulating rectangular selections, but it still bothers me that it feels a little… arrogant… to do that. My plugin might not be as important to the user as something else that also wants those keys.)

I am open to suggestions on how to manage this. I agree that consistency between navigation keys used when focus is in the plugin and when focus is in Notepad++ would be desirable, I just don’t have a plausible design for it.