Search++: A work in progress
-
Hello, @coises and All,
Sorry to begin with some bugs :-((
-
The
Bookmarksfeature does not seem to work at all, even if I close and re-open N++ with theBookmark lines when marking textoption already checked in theSearch++ > Toolsdialog ! -
When focus on
Search++, the two shortcutsCtrl + Shift + YorCtrl + Shift + E( which open a new dialog ) wrongly add the control charENorENQto current text typed in the Find dialog. To this purpose, note that inSettings > Preferences... > Editiing 2I personally did not check thePrevent control character (C0 only) typing into documentoption, in order to be able to include some of them in my texts or posts !- Note also that this bug happens ONLY IF you first use the shortcut. In case that you first open the
Toolsmenu and choose theCopy Marked Text...orSettings...option directly, nothing is added in the Find dialog !
- Note also that this bug happens ONLY IF you first use the shortcut. In case that you first open the
Now, regarding the two ways to do a step-wise replacement :
-
I do like your new option, in the
Toolsmenu, which TOGGLE the replacement type, on the fly, thanks to theCtrl + Jshortcut ( I noted theJforJunp ) -
But then, I suppose that the last line of the Replace dialog (
Do not jump to next matchorJump to next match) and its sub-menu ( to adopt the opposite behavior ) are rather redondant and useless ? What is your feeling about it ?
And, personally, I think that a new setting
Force the 'Do not jump to next match' behavior during theXfirst replacements, with0 < X < 9, would be interesting !Indeed :
-
When that new option would be checked :
-
If current behavior is
Jump to next matchit would force theDo not jump to next matchfor the X first replacements, then all subsequent replacements would follow the current behavior. -
If current behavior is
Do not jump to next matchit would not change anything.
-
-
When that new option would not be checked :
-
If current behavior is
Jump to next match, it would follow this behavior -
If current behavior is
Do not jump to next match, it would follow this behavior
-
Best Regards,
guy038
-
-
Hi, @coises,
@coises, very sorry about the supposed bug with the
Bookmarksfeature ! Finally, I understood that this bug happens ONLY IF you choose theICUregex engine ! If you’re using thePlainorRegexoptions, everything woks as expected ;-)) Is there a limitation to useBookmarkswhen the trueICUregex engine is active ?I even noticed that, like with the native Mark dialog, if you have, both, bookmarks and marked text in current document and that the
Bookmark lines when marking textoption, inTools, is unchecked, aRemove marks and bookmarks from active documentaction does not clear theBookmarks, as expected !BR
guy038
-
@guy038 said in Search++: A work in progress:
- When focus on
Search++, the two shortcutsCtrl + Shift + YorCtrl + Shift + E( which open a new dialog ) wrongly add the control charENorENQto current text typed in the Find dialog.
Thank you for catching that! I see it here, too. I will figure out why (no doubt it’s related to the fact that those two combinations open a dialog) and fix it.
- But then, I suppose that the last line of the Replace dialog (
Do not jump to next matchorJump to next match) and its sub-menu ( to adopt the opposite behavior ) are rather redondant and useless ? What is your feeling about it ?
I think it’s not useless because:
-
If you’re going to choose an option from the drop-down menu and you want opposite behavior, it’s easier to open one menu than two.
-
If you just click, rather than shift+click, the options on the sub-menu don’t change the Jump to next match after Replace setting, they just override it for that one command. So if you like to make a setting and keep it but only occasionally do it differently, you can do that and not have to remember to change the setting back again.
And, personally, I think that a new setting
Force the 'Do not jump to next match' behavior during theXfirst replacements, with0 < X < 9, would be interesting !This sounds to me like it would be confusing to use. Your explanation is clear enough, I don’t mean that it is confusing. But using a counter that’s invisible to the user, the behavior of the same command just changes when it counts to a certain point? I can’t see it. Why would it be likely that people would want the same number of searches without automatic find every time, under all conditions?
If others also say they want this behavior, I won’t refuse to give it a try, but… I can’t say I’m fond of the idea.
I note and admit that convenient keyboard navigation of the button drop-down menu options is sorely needed, and as yet I have no good ideas for how to provide it.
- When focus on
-
@guy038 said in Search++: A work in progress:
@coises, very sorry about the supposed bug with the
Bookmarksfeature ! Finally, I understood that this bug happens ONLY IF you choose theICUregex engine ! If you’re using thePlainorRegexoptions, everything woks as expected ;-)) Is there a limitation to useBookmarkswhen the trueICUregex engine is active ?Nothing to be sorry about — thank you for the observation, and for narrowing down to ICU. I see what’s wrong: it’s a coding error. I’ll fix it.
I even noticed that, like with the native Mark dialog, if you have, both, bookmarks and marked text in current document and that the
Bookmark lines when marking textoption, inTools, is unchecked, aRemove marks and bookmarks from active documentaction does not clear theBookmarks, as expected !If you look closely, when Bookmark lines when marking text is checked, the menu item should say Remove marks and bookmarks from active document; when Bookmark lines when marking text is not checked, that menu item should say Remove marks from active document.
(I’m not sure why I didn’t make the same change to Remove marks from multiple documents…, since it also removes bookmarks as well if Bookmark lines is checked.)
It could be that this is a confusing way to do it. I intended to make the Bookmark lines setting so that when it’s checked, bookmarks and marks “go together” for Mark and Show commands and for Remove marks; but when it’s not checked, Search++ only affects marks and does nothing with bookmarks.
Except that Add selection to marked text doesn’t also add bookmarks regardless of whether Bookmark lines is checked.
This does need refinement. There is certainly some inconsistency. I do want to preserve the ability to manipulate marks without touching bookmarks at all; but which commands should affect bookmarks, and whether I need separate commands for some kinds of bookmark manipulation, remains an open question.
-
Hello, @coises an All,
Regarding the two behaviors of the Replace command :
-
First, I suppose that a special mark/sign/icon in the
Search++title zone, to clearly identify the current behavior of theReplaceaction, would be welcome ! -
Then, the user will choose its desired behavior, simply using the
Ctrl + Jshortcut. -
And forget my idea of a new setting ! In this specific case, the user will begin using the alternate
Replacebehavior first then, after some tries, he would toogle to the usualReplacebehavior !
Now, do we need the additional sub-menu in order to occasionally use the opposite
Replacebehavior, without changing the default settings, as you expressed ?To my mind, after using this opposite behavior ( so, of course, changing the default behavior ), the user would just have to hit the
Ctrl + Jshortcut again to restore the previous default !In addition, I probably forget some edge cases and, anyway, it’s your plugin, not my baby !
BR
guy038
-
-
@guy038 said in Search++: A work in progress:
Regarding the two behaviors of the Replace command :
- First, I suppose that a special mark/sign/icon in the
Search++title zone, to clearly identify the current behavior of theReplaceaction, would be welcome !
It is indicated by the icon on the Replace button. Is there some reason that isn’t enough?
Now, do we need the additional sub-menu in order to occasionally use the opposite
Replacebehavior, without changing the default settings, as you expressed ?I agree that the “opposite jump behavior” sub-menu isn’t strictly necessary, but I don’t think it does any harm, either. To my mind, the commands on that menu are still commands that “belong to” the Replace button. If anything, it’s the Jump to next match after Replace option on the Tools menu that strikes me as logically redundant; but I wanted something to which I could assign that Ctrl+J shortcut for easy switching.
If user experience indicates that the sub-menu creates more confusion than convenience, I’ll remove it.
- First, I suppose that a special mark/sign/icon in the
-
Hello, @coises,
When I said :
- First, I suppose that a special mark/sign/icon in the
Search++title zone, to clearly identify the current behavior of theReplaceaction, would be welcome !
You answered me :
It is indicated by the icon on the Replace button . Is there some reason that isn’t enough?
🡪 replace then jump to a new match forward 🡨 replace then jump to a new match backward 🡪❚ replace and highlight replacement; next click finds a new match forward ❚🡨 replace and highlight replacement; next click finds a new match backwardYou’re certainly younger than me and/or have very good eyes ! I did notice that symbol at right of the
Replacebutton but, it seems a bit tiny !Best Regards,
guy038
P.S. :
Perhaps it would be a good idea to specify, in the manual, that :
-
All sections concerning
regular expressionsandformulaswork correctly when theregexbutton is selected ! -
When the
ICUbutton is selected, you could also point out that the important features, below, are NOT supported :-
The
\Kconstruction -
All the
Backtracking Controlverbs, like(*SKIP)or(*F) -
All the symbolic names, except for
[[:ascii.]] -
The invalid
UTF-8characters, like[[.x80.]]or[[.xff.]] -
The
\land\usyntaxes as shorthand of[[:lowercase letter:]]and[[:uppercase letter:]]( which are the[[:upper:]]and[[:lower:]]equivalents when theRegexbutton is selected ! )
-
- First, I suppose that a special mark/sign/icon in the
-
@guy038 said in Search++: A work in progress:
When I said :
- First, I suppose that a special mark/sign/icon in the
Search++title zone, to clearly identify the current behavior of theReplaceaction, would be welcome !
You answered me :
It is indicated by the icon on the Replace button . Is there some reason that isn’t enough?
🡪 replace then jump to a new match forward 🡨 replace then jump to a new match backward 🡪❚ replace and highlight replacement; next click finds a new match forward ❚🡨 replace and highlight replacement; next click finds a new match backwardYou’re certainly younger than me and/or have very good eyes ! I did notice that symbol at right of the
Replacebutton but, it seems a bit tiny !Thank you for the observation. I consider those symbols important in general (not just for this specific case) because they remind you if you’ve click-selected one of the alternatives from the drop-down menus. Before Search++ can be considered ready for a first “stable” release, I have to make sure they are clearly legible. (I used symbols instead of words because the buttons would have to be much bigger to show the full command names as used in the drop-down menus, and that in turn would make the minimum useful size of the dialog much bigger.)
I’m 68 — I don’t know if that’s younger than you. It’s surely not that my eyes are that good. One of the main things I wanted to accomplish in Search++ was using Scintilla controls for the find and replace text, partly because I’m so tired of struggling to read what I’ve typed into those boxes in Notepad++ and Columns++ searches. (The other main reason was to avoid the complications that arise with line endings and “invisible” characters in the standard Windows controls.)
So I think it’s either that I can see the difference in the two symbols because I know what I’m looking for — after all, I don’t have any trouble with the buttons and check boxes in standard search dialogs, and their font is the same as the one in the find and replace boxes — or they aren’t displaying the same on all systems. (Or both.)
For development purposes, to keep things simple, I’ve used Unicode characters for the symbols on the buttons. That has somewhat limited my choice of symbols, as well as given me no control over the size and weight (aside from finding a different symbol). It could also be the case that they display differently on different systems. Which all means that using Unicode symbol characters is a bad way to do this. At some point I will need to replace them using a different method that will be more complex, but will give me more control.
Are you using a high-dpi monitor, by any chance? At present I do not have one available for testing. I have read various information from Microsoft about it, but information without actual practice tends to turn into gibberish… at this point I don’t think I can adequately predict how this will look on high dpi.
Perhaps it would be a good idea to specify, in the manual, that :
-
All sections concerning
regular expressionsandformulaswork correctly when theregexbutton is selected ! -
When the
ICUbutton is selected, you could also point out that the important features, below, are NOT supported :-
The
\Kconstruction -
All the
Backtracking Controlverbs, like(*SKIP)or(*F) -
All the symbolic names, except for
[[:ascii.]] -
The invalid
UTF-8characters, like[[.x80.]]or[[.xff.]]
-
Indeed, my documentation says very little about the ICU search at present. At some point before a first “stable” release I will either document the ICU search more thoroughly or “hide” it so users won’t stumble on it and be confused by it.
- The
\land\usyntaxes as shorthand of[[:lowercase letter:]]and[[:uppercase letter:]]( which are the[[:upper:]]and[[:lower:]]equivalents when theRegexbutton is selected ! )
A minor note: this is a point in which Search++ Regex differs from Columns++ as a result of changes I made to use ICU as the source of information for Unicode properties instead of the mechanism I cobbled together in Columns++.
In Columns++, \l and [[:lower:]] are equivalent to [[:lowercase letter:]] (or [[:Ll:]], or \p{Ll}) — 2,283 matches in your Total_Chars.txt file.
In Search++ Regex, \l and [[:lower:]] are equivalent to (?-i)[[:lower:]] in ICU — 2,595 matches in Total_Chars.txt.
You can still use [[:lowercase letter:]] (or [[:Ll:]], or \p{Ll}) in Search++ Regex to match the same 2,283 characters as (?-i)[[:lowercase letter:]] in ICU.
Unlike ICU, both Columns++ and Search++ Regex ignore case insensitivity when matching named character classes (including the \l and \u shorthands).
- First, I suppose that a special mark/sign/icon in the
-
Hi, @coises,
Well, I’m 74. Now, with my glasses I have nearly
20/20vision in my left eye but only3/10in my right eye, due to a vascular problem in the retina that I had about10years ago :-((No, I don’t have an high-dpi monitor and here is a snapshot of the
Replacebutton, in exact size :
Of course, if I look at the button, I’m able to notice the mark
→❙, after the word Replace, but I may miss it sometimes !
Thank you, to point out the specificities and differences about the character classes regarding
Columns ++andSearch ++,So, here is a summary on this topic :
•==============================•=============•================•=========================================================================• | Regex | Columns++ | Search++ Regex | Search++ ICU | •==============================•=============•================•==============•==========================================================• | (?-i)\l | 2,283 | 2,595 | 1 | Letter l | | (?-i)[[:lower:]] | 2,283 | 2,595 | 2,595 | = (?-i)\p{Ll} + (?-i)\p{Other Lowercase} = 2,283 + 312 | | | | | | | | (?-i)\p{Ll} | 2,283 | 2,283 | 2,283 | | | (?-i)[[:lowercase letter:]] | 2,283 | 2,283 | 2,283 | | | (?-i)[[:Ll:]] | 2,283 | 2,283 | 2,283 | | •------------------------------•-------------•----------------•--------------•----------------------------------------------------------• | (?-i)\u | 1,886 | 2,006 | Invalid | ??? | | (?-i)[[:upper:]] | 1,886 | 2,006 | 2,006 | = (?-i)\p{Lu} + (?-i)\p{Other Uppercase} = 1,886 + 120 | | | | | | | | (?-i)\p{Lu} | 1,886 | 1,886 | 1,886 | | | (?-i)[[:Uppercase letter:]] | 1,886 | 1,886 | 1,886 | | | (?-i)[[:Lu:]] | 1,886 | 1,886 | 1,886 | | •==============================•=============•================•==============•==========================================================• | (?i)\l | 2,283 | 2,595 | 2 | Letters L and l | | (?i)[[:lower:]] | 2,283 | 2,595 | 4,082 | | | | | | | | | (?i)\p{Ll} | 2,283 | 2,283 | 3,729 | | | (?i)[[:lowercase letter:]] | 2,283 | 2,283 | 3,729 | | | (?i)[[:Ll:]] | 2,283 | 2,283 | 3,729 | | •------------------------------•-------------•----------------•--------------•----------------------------------------------------------• | (?i)\u | 1,886 | 2,006 | Invalid | ??? | | (?i)[[:upper:]] | 1,886 | 2,006 | 3,484 | | | | | | | | | (?i)\p{Lu} | 1,886 | 1,886 | 3,322 | | | (?i)[[:Uppercase letter:]] | 1,886 | 1,886 | 3,322 | | | (?i)[[:Lu:]] | 1,886 | 1,886 | 3,322 | | •==============================•=============•================•==============•==========================================================•Note that all the properties, below, are used internally by the Unicode Cconsortium for generating other properties and are not intended to be used stand-alone. These properties only contribute to real properties so there’s no direct support for these properties in
ICUand they all return theInvalid regular expressionmessage !\p{Jamo_Short_Name} \p{JSN} \p{Other Alphabetic} \p{OAlpha} \p{Other Default Ignorable Code Point} \p{ODI} \p{Other Grapheme Extend} \p{OGr Ext} \p{Other ID Continue} \p{OIDC} \p{Other ID Start} \p{OIDS} \p{Other Lowercase} \p{OLower} \p{Other Math} \p{OMath} \p{Other Uppercase} \p{OUpper}You can verify the number of characters, in these categories, from the files https://www.unicode.org/Public/UCD/latest/ucd/PropList.txt and https://www.unicode.org/Public/UCD/latest/ucd/Jamo.txt
Best regards
guy038
-
@guy038 said in Search++: A work in progress:
No, I don’t have an high-dpi monitor and here is a snapshot of the
Replacebutton, in exact size :
The proportion is a bit different on my system:

so it seems the display does differ from system to system. I will find a way to make those icons more recognizable and obvious… I just don’t know when.