Search++: A work in progress

guy038

Hi, @coises and All,

Thanks for your new Search++_03 release !

BTW, with native N++ search, the Shift + Enter shortcut is also available when you choose the Regular expression search mode ( with the condition that the regexBackward4PowerUser="yes" option is present within the config.xml file. May be, you could allow it as well in Search++ ?

I just discovered ICU’s features, and they’re really impressive ! Over the next few days, I’ll try to list the many Unicode properties accessible through ICU… Another whole new world is opening up to me !! Personally, I think the ICU button should remain available in future versions !

I ran into a problem while selecting characters. For example :

Put this small text in new tab



ໜໝໞໟ໠໡໢໣໤໥໦໧໨໩໪໫໬໭໮໯໰໱໲໳໴໵໶໷໸໹໺໻໼໽໾໿ༀ༁༂༃༄༅༆༇༈༉༊་༌།༎༏༐༑༒༓༔༕༖༗༘༙༚༛༜༝༞༟༠༡༢༣༤༥༦༧༨༩༪༫༬༭༮༯༰༱༲༳༴༵༶༷༸༹༺༻༼༽༾༿ཀཁགགྷངཅཆཇ཈ཉཊཋཌཌྷཎཏཐདདྷནཔཕབབྷམཙཚཛཛྷཝཞཟའཡརལཤཥསཧཨཀྵཪཫཬ཭཮཯཰ཱཱཱིིུུྲྀཷླྀཹེཻོཽཾཿ྄ཱྀྀྂྃ྅྆྇ྈྉྊྋྌྍྎྏྐྑྒྒྷྔྕྖྗ྘ྙྚྛྜྜྷྞྟྠྡྡྷྣྤྥྦྦྷྨྩྪྫྫྷྭྮྯྰྱྲླྴྵྶྷྸྐྵྺྻྼ྽྾྿࿀࿁࿂࿃࿄࿅࿆࿇࿈࿉࿊࿋࿌࿍࿎࿏࿐࿑࿒࿓࿔࿕࿖࿗࿘࿙࿚࿛࿜࿝࿞࿟࿠࿡࿢࿣࿤࿥࿦࿧࿨࿩࿪࿫࿬࿭࿮࿯࿰࿱࿲࿳࿴࿵࿶࿷࿸࿹࿺࿻࿼࿽࿾࿿ကခဂဃငစဆဇဈဉညဋဌ

Switch to this new tab
Run Plugins > Search++ > Search...
Select the ICU button
SEARCH \p{script=Tibetan}
Check the Match case option
Right click on the Find All button
Choose the Select > Select in Whole Document option

=> A selection appears with the bottom message Selected 207 matches

Without doing anything else, I use the Ctrl + C shortcut

After opening an other new tab, I was quite surprised that the 207 tibetan chars were not pasted, after a Ctrl + V operation ?!

Then, I understood that the selection is effective ONLY IF :

The Search++ plugin is closed with the x button or using the ESC key
You click again on the New 1 tab, with Search++ not on focus
You move the New 1 text one line Up or Down with the ▲ or ▼ marks of the vertical scroll bar

@coises, is this behaviour correct ?

Regarding the Unicode Word boundaries :

I had a look to https://www.regular-expressions.info/unicodeboundaries.html#word

I understood that :

When ICU selected and the Unicode word boundaries not checked, the \b regex, against our tibetan text above, counts 46 matches
When ICU selected and the Unicode word boundaries checked, the \b regex, against our tibetan text above, counts 176 matches

Quite different, indeed ! Note that if the Unicode word boundaries is not checked , the (?w)\b regex would also return 176 matches. Thus, a leading (?w) forces the use of the Unicode word boundaries option !

Then, reading https://www.regular-expressions.info/unicodeboundaries.html#grapheme, I realized that, presently, the \b regex cannot identify the different grapheme positions !

Would it be possible to add an option for this specific case, or am I asking too much ? I suppose the later is true !!

Best Regards,

guy038

Coises

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

Thanks for your new Search++_03 release !

Thank you for testing it.

BTW, with native N++ search, the Shift + Enter shortcut is also available when you choose the Regular expression search mode ( with the condition that the regexBackward4PowerUser="yes" option is present within the config.xml file. May be, you could allow it as well in Search++ ?

Regex backward… I have my doubts, but I can leave it open as something I might try to make available some day. When I’ve thought about it before, I get caught up trying to define exactly what it means to match regular expressions backward. Regular expressions can match different lengths depending on where they start. Is the previous match the one that ends at the latest possible position? The one that begins at the latest possible position? The last one that would have occurred before the current position if you matched forward repeatedly from the beginning of the text? The one that would result from reversing both the text and the regular expression (but then what do you do with backreferences)?

Shift+Enter is a different problem. Enter doesn’t work to find: since the Find and Replace boxes take multiple lines, they consume the Enter key. You can use Alt+F and Alt+R (the underlined characters on the Find and Replace buttons), but those combinations are a bit awkward. I’ve been thinking of just making Shift+Enter and Ctrl+Enter do the functions on the Find and Replace buttons — I think those would be more natural than Alt+F and Alt+R for most people (including me). But then it isn’t obvious how access to backward should work. Beyond all that, there is no standard Windows mechanism for keyboard-only access to the drop-down menus on split command buttons. Once you can get to the button without clicking it, down arrow works to open the menu; but you can’t get there with Alt+underlined letter: that does the click action. I haven’t figured out a good way to deal with all of the keyboard navigation obstacles yet.

Which is a long way of saying I don’t know which of too many possibilities I will eventually decide must take priority for keyboard actions, so I don’t know what I can/will do in that regard.

Personally, I think the ICU button should remain available in future versions !

I’ll probably leave the function there… it might be “hidden” (like a Shift-click on Regex) so it doesn’t confuse people who would probably never use it.

Choose the Select > Select in Whole Document option

=> A selection appears with the bottom message Selected 207 matches

Without doing anything else, I use the Ctrl + C shortcut

After opening an other new tab, I was quite surprised that the 207 tibetan chars were not pasted, after a Ctrl + V operation ?!

Then, I understood that the selection is effective ONLY IF :

It’s not that selection isn’t effective, it’s that keyboard focus was still in the Search++ dialog. You have to move focus to the document for the Ctrl+C to work.

You can use Ctrl+N (think “Notepad++”) to return focus to the document, or (as you discovered) click on the tab if you’re using the mouse.

This does make me think I should probably have an option, perhaps enabled by default, to return focus to the document automatically after a select operation, since wanting to copy is probably the most common reason for using select.

(I’ve been bitten by this often enough in Columns++, which works the same way. It’s just so easy to forget that focus is in the dialog, not the document.)

Note that if the Unicode word boundaries is not checked , the (?w)\b regex would also return 176 matches. Thus, a leading (?w) forces the use of the Unicode word boundaries option !

Hmmm… I’m not sure what’s happening there.

Then, reading https://www.regular-expressions.info/unicodeboundaries.html#grapheme, I realized that, presently, the \b regex cannot identify the different grapheme positions !

Would it be possible to add an option for this specific case

In both Regex and ICU, \X matches a single grapheme cluster. In Regex, (?=\X) matches a grapheme boundary; that doesn’t work in ICU. (It looks like in ICU, \X actually matches from the current position to the end of a grapheme cluster. In Regex, the match must begin and end on a grapheme cluster boundary. The Boost.Regex logic already worked that way, but I replaced/extended it to use the grapheme break algorithm specified by Unicode.) \X partially works in built-in Notepad++ search, too, but it misses some cases and falls apart entirely outside the BMP.

guy038

Hi, @Coises and All,

Don’t worry about my request for searching for regular expressions in the opposite direction: I can live without that feature !

Regarding the possibility of changing the Alt + F and Alt + R shortcuts to some anothers, I’m not really in favor of it because you would break a very old Windows standard !

BTW, when in Plain text and with focus on Search++, let’s suppose we search for the string and

Using the Alt + F shorcut does move to the next match and, in addition, the shortcut Alt + Shift + F does move to the previous match Nice, indeed !
But, if I decide, now, to use the Enter key, it wrongly add a line-break after the word and , in the Find dialog of Search++

So, to my mind, it would be better to put the focus on the Find button as soon as you hit the Alt+ F shortcut, in order to use, either, the Alt + F OR Enter and the ALT+ Shift + F OR Shift + Enter shortcuts !

Regarding my selection problem :

Oh… yes, indeed ! The solution was obvious : Ctrl + N to switch focus from the Search++ plugin to native N++ !

You said :

This does make me think I should probably have an option, perhaps enabled by default, to return focus to the document automatically after a select operation, since wanting to copy is probably the most common reason for using select.

Yes indeed; this would make sense !

Note that I personally choose the Ctrl + Shift + N shortcut for the command Plugins > Search++ > Search...

Thus, as a summary :

When focus on Notepad++, the Ctrl + Shift + N shortcut opens or puts focus on the Search++ plugin ( User shortcut )
When focus on Search++, the Ctrl + N shortcut puts focus on Notepad++ ( Search++ shortcut )
When focus on Search++, the Ctrl + O shortcut toogles between the Find and the Replace dialog of **Search++( Search++ shortcut )
When focus on Search++, the Ctrl + H shortcut re-opens or puts focus onthe Search++ Results`( Search++ shortcut )
When focus on Search++ Results, the Ctrl + O shortcut puts focus on the Search++`plugin ( Search++ shortcut )
When focus on Search++ Results, the Ctrl + Shift + N shortcut closes the Search++ Results panel and puts focus on Notepad++ ( Search++ shortcut )
When focus on Search++, the Ctrl + Shift + N shortcut closes the Search++ panel and puts focus on Notepad++ ( User shortcut )

BTW, @coises, why didn’t you choose a single shortcut ( I’m thinking about Ctrl + H ) to toggle between the Search++ plugin and the Search++ Results ? Native notepad++ just use the F7 key to shift the focus, back and forth, between the Document window and the Search results panel !

Regarding the Unicode Word Boundaries :

When I said :

Note that if the Unicode word boundaries is not checked , the (?w)\b regex would also return 176 matches. Thus, a leading (?w) forces the use of the Unicode word boundaries option !

There’s nothing weird about this assertion. It just means that the behavior of the (?w) and (?-w) modifiers act in the same way as the well-known (?s) and (?-s) modifiers which set / unset the . matches new-line option, whatever this option is physically checked or not, in native N++ search !

Regarding the Grapheme Boundaries :

No need to add any option ! I’ve just realized that, in regex mode, the simple regex (?!\X). does match any character which is not a Grapheme-Base char. Thus, a Count action would detect, for instance, the total number of accentuated characters associated to a simple latin letter !

I still need to explore all of Search++'s features and, most importantly, to compile a list of the various properties available with the ICU regular expression engine.

BR

guy038

guy038

Hello, @coises and All,

Two more points :

Open the change.log file

Let’s suppose that the N++ Find dialog is already opened and that the Find field contains the text This is a test

Now, switch back to the change.log file
Select the Updater (Installer only): text
Use the Ctrl + F shortcut

=> The previous text is updated to the new text to search : Updater (Installer only): => OK

Now, open Search++ ( with Plugins > Search++ > Search... or with my shortcut Ctrl + Shift + N )
Type in This is a test in the Find dialog of Search++
Click on the change.log tab
Select again the Updater (Installer only): text
Put the focus again on the Search++ plugin ( with Plugins > Search++ > Search... or with my shortcut Ctrl + Shift + N )

=> The text is not uptaded and remains the string This is a test ! To get it updated, you need to close and re-open Search++

Could you provide this N++ search behavior to Search++, as well ?

When the Search++ dialog is docked, it’s very easy to identify if focus is on Notepad++ or on Search++, thanks to the blue color of the title bar. However, this difference is not so obvious when the Search++ plugin is not docked ! Is there a mean to improve this difference ?

Best Regards,

guy038

Coises

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

Regarding the possibility of changing the Alt + F and Alt + R shortcuts to some anothers, I’m not really in favor of it because you would break a very old Windows standard !

True. I would not change them; I was thinking about adding Shift+Enter and Ctrl+Enter as alternatives.

Using the Alt + F shorcut does move to the next match and, in addition, the shortcut Alt + Shift + F does move to the previous match Nice, indeed !

That was a “bonus.” It hadn’t occurred to me that Shift would work that way, though now that you mention it, I can see why it does.

But, if I decide, now, to use the Enter key, it wrongly add a line-break after the word and , in the Find dialog of Search++

So, to my mind, it would be better to put the focus on the Find button as soon as you hit the Alt+ F shortcut, in order to use, either, the Alt + F OR Enter and the ALT+ Shift + F OR Shift + Enter shortcuts !

The Windows dialog manager doesn’t normally move focus for an Alt+ shortcut to a command button, it just does the command and leaves the focus unchanged. I could probably find a way to override that, but it’s not clear to me that I should. If you started using Alt+F, why not continue that way?

This does make me think I should probably have an option, perhaps enabled by default, to return focus to the document automatically after a select operation, since wanting to copy is probably the most common reason for using select.

Yes indeed; this would make sense !

It will be in the next release.

BTW, @coises, why didn’t you choose a single shortcut ( I’m thinking about Ctrl + H ) to toggle between the Search++ plugin and the Search++ Results ? Native notepad++ just use the F7 key to shift the focus, back and forth, between the Document window and the Search results panel !

I suppose I was thinking that since I can’t really make one command that handles all the focus changes — because I don’t know what the user will assign for Search++/Search in the Notepad++ shortcut mapper (if anything at all) — I would have Ctrl+N always go to the document, Ctrl+O always go to the Search dialog (though it’s Find Box unless you’re already in the Find Box, in which case it’s the Replace Box…) and Ctrl+H always go to the results (“hit list”).

It would make at least as much sense to have Ctrl+H toggle between the search dialog and the results list, though. Since you mention it, I’ll probably make that change.

There’s nothing weird about this assertion. It just means that the behavior of the (?w) and (?-w) modifiers act in the same way

Of course, you are correct.

Coises

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

Put the focus again on the Search++ plugin ( with Plugins > Search++ > Search... or with my shortcut Ctrl + Shift + N )

=> The text is not uptaded and remains the string This is a test ! To get it updated, you need to close and re-open Search++

Could you provide this N++ search behavior to Search++, as well ?

I did not realize the native dialog worked that way; I assumed it only filled when the dialog wasn’t already open.

I don’t see a reason I couldn’t do this, if it’s what people will ordinarily expect. I would have thought being able to change focus back to the dialog by keyboard without disturbing the contents of the Find box would have been more desirable, but maybe not. Users can always disable the fill option, or I could add an additional setting to let the user decide whether filling only occurs when the dialog wasn’t already open.

Ctrl+I will insert the text selected in the document into the Find (or Replace) box at any time. Since it is an insert, you have to do Ctrl+A, Ctrl+I if you want to replace.

When the Search++ dialog is docked, it’s very easy to identify if focus is on Notepad++ or on Search++, thanks to the blue color of the title bar. However, this difference is not so obvious when the Search++ plugin is not docked ! Is there a mean to improve this difference ?

Agreed, the difference is fairly subtle in light mode: the text in the title bar goes grey, and the shadow around the dialog gets a bit less. It’s a bit more visible in dark mode, where the whole title bar changes color.

I have to think about whether there is anything I can do that would make this more visually apparent without being garish or peculiar.

(Note: at present, the Search++ dialog does not fully accommodate changing between dark and light mode within a single Notepad++ session. The Scintilla controls in the regular dialog and in the docking dialog stay however they were when you first opened that type of dialog.)

Coises

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

You said :

This does make me think I should probably have an option, perhaps enabled by default, to return focus to the document automatically after a select operation, since wanting to copy is probably the most common reason for using select.

Yes indeed; this would make sense !

[…]

BTW, @coises, why didn’t you choose a single shortcut ( I’m thinking about Ctrl + H ) to toggle between the Search++ plugin and the Search++ Results ?

A few small improvements are in version 0.4:

Add wide layout for better top/bottom docking. Improve layout handling and make sure non-docking dialogs aren’t sized too small.
Add settings (checked by default) to focus the document after Select commands and after Show commands. (See help.)
Make behavior of general navigation commands (Ctrl/Ctrl+Shift + H/N/O) more consistent. (See help.)

Lachlanmax

Nice work so far. Notepad++ already has a solid search system, so making something which actually feels like an upgrade is not small thing.

What is standing out to me is that it follows the way heavy N++ users already search instead of trying to force whole new workflow. The extra scope control feels especially useful when you start doing repeated searches in same session, because built-in search can get a bit messy.

One thing I personally really miss is Find + Mark (highlight/coloring results) style workflow. Being able to keep visual marks in document while refining searches is something I use very often in native N++, so having similar option here would make it even stronger. Related to that, I also really love Bookmark option in native N++, which I am not sure is used regularly by everyone, but to me it is very helpful, being able to quickly jump between important lines makes managing large documents much easier.

It would also be very nice to see these strong features later applied to Find in Files / Find in Directory, like Notepad++ handles it now, because that is where extra scope logic and result control could become even more useful.

Hopefully I will be able to contribute something useful to this community soon also.

guy038

Hello, @coises and All,

Many thanks for your reactivity and for the Search++-04 release ! I do appreciate that you always keep the Help file up to date with the latest version and it’s a pleasure to consult it !

Bravo for the Keyboard navigation section, within the Help file and for the Focus section in the Settings dialog with their default values !

Regarding updating the Find dialog when selecting something new in a document :

In your last post, I did not notice that you spoke about the Ctrl + I shortcut. So, presently, in order to update the Find region of Search++ with current selection of current document, we have two possibilites, when Search++ is on focus :

Use the Ctrl + I or the combination Ctrl + A + Ctrl + I

or

Use the Ctrl + Shift + N shortcut to close Search++ ( Search++ shortcut )
Re-use the Ctrl + Shift + N shortcut to open again Search++ ( User shortcut )

BTW, @coises, the Help file did not mention at all that Ctrl + I shortcut !

Best Regards,

guy038

Coises

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

In your last post, I did not notice that you spoke about the Ctrl + I shortcut. So, presently, in order to update the Find region of Search++ with current selection of current document, we have two possibilites, when Search++ is on focus :

Use the Ctrl + I or the combination Ctrl + A + Ctrl + I

or

Use the Ctrl + Shift + N shortcut to close Search++ ( Search++ shortcut )

Re-use the Ctrl + Shift + N shortcut to open again Search++ ( User shortcut )

BTW, @coises, the Help file did not mention at all that Ctrl + I shortcut !

Thank you again for looking at this so closely.

The help file mentions in this section that there is a context menu on which you can also find keyboard shortcuts:

Right-click in the Find or Replace box, or use the Apps key or Shift+F10, to bring up a context menu. A number of useful commands can be found there, along with their keyboard shortcuts. The bottom section of the context menu lets you select from a history of the last ten strings you have used for searches.

I go on to mention wrapping and zooming, but I never describe the Insert/Exchange sub-menu.

in order to update the Find region of Search++ with current selection of current document, we have two possibilites, when Search++ is on focus

There are already settings to choose whether to fill the find box at all, and if you choose to fill, to set some limits on how big the selection can be.

Do you now think:

there should be another sub-setting for whether or not to replace the contents of the find box when you use the Search++ Search… menu command or the shortcut you’ve set for it to move focus from the document to a search dialog that is already visible? (If so, should it be default checked?)
if the main “Fill” box is checked, it should always fill when you use the command/shortcut, regardless of whether the dialog is visible — if someone doesn’t like it, they can just turn off filling altogether (it’s not that hard to use Ctrl+I when you want it)?
it should stay like it is (it’s not that hard to use Ctrl+I when you want it)?

My personal feeling is that it would be disconcerting to have what is in the Find field, in a visible dialog, replaced just because I used my keyboard shortcut to navigate to the dialog instead of activating it with the mouse. (If I’ve closed the dialog I probably don’t remember what was in it anyway, so the selected text is as good as anything.) Others might not see it that way — I rarely use auto-fill intentionally. Most often I’m not already looking at the thing I want to find; so just unchecking the box and turning it off completely wouldn’t affect me much.

Coises

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

Nice work so far. Notepad++ already has a solid search system, so making something which actually feels like an upgrade is not small thing.

Thank you.

One thing I personally really miss is Find + Mark (highlight/coloring results) style workflow. Being able to keep visual marks in document while refining searches is something I use very often in native N++, so having similar option here would make it even stronger.

Would you help me understand what is missing? I assume you have seen the Mark command (the simple one and its family of direction- and scope-controlled commands) on the drop-down for the Find All button, and the mark-related functions on the Tools button menu. What do I need to add? Other than…

Related to that, I also really love Bookmark option in native N++, which I am not sure is used regularly by everyone, but to me it is very helpful, being able to quickly jump between important lines makes managing large documents much easier.

I did leave that out. I’m one of those people who doesn’t use them, so I have little insight into how people do use them.

I take it the essential option here is to set a bookmark on every line that contains a match when using a Mark command. Is that it?

Do you think that is something that can be a setting — that is, something a user would ordinarily either use or not use, so it can go on the Settings dialog and any given user will “set it and forget it”? Or is bookmarking the lines containing matches something a user needs to be able to turn on and off search by search?

Can bookmarks be cleared along with marked text, or do users need independent control of unmarking text and clearing bookmarks?

Should lines containing null matches (which can’t be marked, as there is no text to mark) still be bookmarked?

It would also be very nice to see these strong features later applied to Find in Files / Find in Directory, like Notepad++ handles it now, because that is where extra scope logic and result control could become even more useful.

I’m not sure I understand what this would entail.

(I haven’t yet added the ability to search in files on disk, nor the ability to search all open documents. Those are major steps I still intend to take before I consider this ready for a “stable” release.)

Are you suggesting that some sort of marked text and/or bookmarked lines be maintained in files that have never been opened in Notepad++? It sounds confusing to me; wouldn’t users be completely “flying blind” trying to assess how their searches were actually working?

I can’t help thinking that maybe complex, chained series of searches and replacements in sets of files on disk might be better handled by a separate tool (likely a command line tool which could have an optional GUI interface) that wouldn’t have anything to do with Notepad++. I don’t know if a good, user-friendly program like that exists.