FEATURE trumps BUG !

Interesting.

free\tsoftware
free	software
free\tsoftware
free	software
free\tsoftware
free	software
free\tsoftware
free	software

If I select free\tsoftware and do Ctrl+F3 when the last FIND mode was Regular Text, the Ctrl+F3 will go between the lines that are literally free\tsoftware. If I change the FIND mode to Extended mode, and select that same first row then hit Ctrl+F3, it finds free software from then on out. The same happens if I have Regular Expression mode as the last selected.

(The same thing happened in v8.2 and v8.3)

So yes, it does appear that Ctrl+F3 is paying attention to the search-mode setting from the Find dialog, and that if you are in Extended or Regular expression mode, select text which includes a plain-text backslash-then-character, that term will be treated as its Extended or Regex meaning when doing the Ctrl+F3 search.

(Like Alan, I typically only use Ctrl+F3 with caret-based rather than selection based, so had never run across this situation before)

My guess is that there is at lease one someone out there who had already found that out years ago, and would consider that a necessary feature, instead of a bug to be fixed, and would be very upset if that behavior was changed in a future release. Because I can see the extreme usefulness of being able to type your regex in the Notepad++ editor window, rather than in the tiny FIND dialog box, and then select the regex, and use Ctrl+F3 to start the regex search. Now that I know that exists, I might start using it … ooh, yes, it even works for (?x)-multi-line regex with comments. I can now use a full commented regular expression!

if I put the

(?x)
free    # comment
\h+
\w+
(?!!)

free\tsoftware
free	software
free\tsoftware
free	software
free\tsoftware
free	software
free\tsoftware
free	software!
free	food!
free	food

and select the first block, then Ctrl+F3, I can find all the lines that are free followed by space(s) followed by a word, not followed by an exclamation point.

Thanks for pointing me to this feature! That’s awesome! I think I will start using it when helping other people in the forum, and especially when developing FunctionList regular expressions, which I like having comments for. (I know, you wanted this bug fixed, but this is a feature that I think is awesome! I now would be quite disappointed if this feature went away.)

If you do put in a bug report, please let us know where, so that I can lobby that it be kept as-is, and instead that you be given an option as to whether it treats Ctrl+F3-searches as regular-mode searches, or whether it follows the FIND dialog settings.

Ah. I’ve actually never considered searching this way – having something preselected and not depend upon the “Select” part of the Ctrl+F3 command (Select and Find Next) not doing the selection of the word at the caret. But the usual case works and it is faster than opening up a closed Find window (or switching to it)…

So, your point is valid. It doesn’t lessen the validity of your point but how often is a user going to be affected by this? I’d guess rarely.

Much more often one might encounter the following similar thing:

• select test wanting to find all matches

• press Ctrl+F3 repeatedly; software finds many occurrences of test

• you find out later that software did not find tester, tested, testing because the Match whole word only checkbox in a closed Find window was ticked

Admittedly different, but perhaps another unintended result…

If you want to put in a bug report I encourage you to do so. See the advice on doing that HERE.

Put your caret in the first free (before the ) and press Ctrl+F3.

I’m talking aboult pressing Ctrl+F3. I mean you should

1. set extended mode
2. Select text with escaped character , which occurs multiple times in the opened file. Not just put the caret.
3. Press Ctrl+F3
4. Error: Next occurance wouln’t be selected, as character was treated as special escaped character!
   So next free\n software wouldn’t be selected but

free
software

(if it exists) would.

Figured out that find selected text via Ctrl+F3 takes into account if “Extended mode” was enabled once formerly in the past for absolute different search. So it’s interpret “\n” in selected as escape character!

I’m not sure how this comes into play, as the \ in \n is not a word character and would not be added into the search text.

Example:

this is a free\n software but what is the meaning of free really

Put your caret in the first free (before the \) and press Ctrl+F3.

The software moves the caret to the second and final free.

So how is this impacted by Extended mode?

@ultrafeel said in Suggestion: Problems with "Find selected text" via Ctrl F3:

Searched text is limited to 2047 letters length.

Yes, a design decision for a limit. If you think it is unreasonable you can open a feature request to have it changed. That doesn’t guarantee that it will be though.