@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.
