Weird behavior of the "In selection" option in "Search" dialogs

guy038

Hello, All,

I found out a strange behaviour, relative to the In selection option, visible in the Find, Replace and Mark dialogs. I would consider it as a small bug and I would like your opinion about it !

Here the process to reproduce the problem :

Start Notepad++
Do a selection of some words
Open, either, one of the 3 dialogs, with the Ctrl + F, Ctrl + H or Ctrl + M shortcut

=> Note that the In selection button is not automatically selected

Close the Find/Replace/Mark dialog with the Esc key
Now, increase your selection till 1,024 characters
Again, open, either, one of the 3 dialogs

=> The In selection button is still unticked

Close the Find/Replace/Mark dialog
Increase your selection of 1 char for a total of 1,025 characters
Again, open, either, one of the 3 dialogs

=> This time, the In selection button is correctly selected !

Close the Find/Replace/Mark dialog
Now, decrease your selection in order to get a 1 char selection
Again, open, either, one of the 3 dialogs

=> The In selection button is still selected

Close the Find/Replace/Mark dialog
Cancel the current selection
Again, open, either, one of the 3 dialogs

=> The In selection button is, unticked, as expected

If you close and restart Notepad++, the problem comes back : the In selection option will be automatically selected ONLY IF the selection is > 1,024 chars !

I verified that this behaviour does not depend on whatever other option is on or off and does not depends, either, on the current search mode

This behaviour still exits if you start N++ from a prompt window, with the notepad++.exe -noPlugin command

Note that I haven’t installed the latest 8.4 version yet, as I still use the 8.1.9.2 release, 64 bits, on my Win 10 laptop, with only a recent build of the ComparePlus plugin of @pnedev !

But I also, tested with the old v7.9.2 release, 32 bits, on my old Win XP machine and the problem seems identical !

Here is my debug info :

Notepad++ v8.1.9.2 (64-bit)
Build time : Nov 21 2021 - 04:30:20
Path : E:\8192_x64\notepad++.exe
Command Line : -noPlugin
Admin mode : OFF
Local Conf mode : ON
Cloud Config : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 2009
OS Build : 19044.1645
Current ANSI codepage : 1252
Plugins : none

So, is there really something strange or am I doing anything wrong ? Thanks for checking !

Best Regards,

guy038

guy038

Hi, All,

I did some other tests and it happens that the In selection behavior depends on the number of bytes of current selection ( and not the number of chars )

So, if you do the previous test with an UTF-8 encoded file, or any other Unicode encoded file, be sure that it contains only chars inferior to \x80. In that case, the number of chars and number of bytes, of current selection, are identical, so that the change , about the In selection behavior, occurs when selection reaches exactly 1,025 characters !

BR

guy038

Alan Kilborn

@guy038

So I for one am not sure about the complaint here.

It has long been known that if you invoke these functions with a lot of text selected (1024 or 1025 or more constitutes “a lot” I guess) that the assumption of the software is that you will want an “in selection” search, so it presets In selection.

If the complaint is that it is using “bytes” and not “characters” to generate the count for determining this, well, then I understand. It should count characters and not bytes.

PeterJones

@alan-kilborn said in Weird behavior of the "In selection" option in "Search" dialogs:

So I for one am not sure about the complaint here.

Alan,

I think what Guy is saying:

Start with a 1025 byte selection, and Ctrl+F will automatically enable In Selection, as expected
Close FIND window and select one byte: Ctrl+F will still have In Selection enabled, even though fewer than 1025 bytes
- Repeatedly closing FIND window and selecting new bytes will keep the In Selection, no matter how long the new selection.
The only way to get out of automatic In Selection (other than clicking the checkbox, obviously) is to select nothing (0 bytes) before opening FIND

I think Guy’s complaint is that in #2, Notepad++ doesn’t redo the selection-length calculation, even though the selection and length has changed and the FIND window has been re-opened.

Personally, that feels more like a “quirk” than a “bug”, and it doesn’t bother me. I personally don’t rely heavily on the automatic checkmark for In Selection; I just manually toggle the checkbox if the automatic doesn’t meet my needs.

@guy038 , if it helps, just think of the automatic In Selection checkmark as being “sticky”: once that bit has been toggled on (whether automatically or manually), then it “wants” to stay on (it gets “stuck”) until you manually turn it off, or until you have no selection, which unsticks it. (In a lot of the microchips I work with in my day job, they have control/status registers that you can control by writing, but some of the flag bits in those registers can be turned on by some other event in the chip to flag some condition, so you can read the status, but it won’t be cleared until you manually program that bit back to a 0; and they are called “sticky” bits. So when I see something like that in software, I just tell myself it’s a sticky bit and it seems perfectly natural to me after that.)

guy038

Hi, @alan-kilborn, @peterjones and All,

Peter, I totally agree concerning the 3 points which you described in your post !

However I’m still upset by this behavior :

Start Notepad++
Do a simple selection of, let’s say 10 characters
Now, open the Find dialog

Question : why the In selection box is not selected ?

OOOOOh ! Now I understand all the story : if the In selection option was selected, this would mind that, for ANY search, we should always deselect the In selection option, as we usually search for the string throughout the entire file and not for the string itself, of course !

Actually, I created this new topic after writing this other post :

https://community.notepad-plus-plus.org/post/76574

In the described road map, I said :

Select the specific word, which may contain one or several accentuated characters

Open the Replace dialog ( Ctrl + H )

At this time, I was expected to see the In selection option auto-selected. As it wasn’t, I had emphasized the necessity to tick the In selection option !

Everything is clear, by now ! And, on the contrary, it’s quite useful that this option is sticky, because, as soon as @socu would had selected an other word, the In selection option would still be ticked and the typed S/R :

SEARCH (?i)([aeiouy])|\w
REPLACE ?1[[=$0=]]:$0

would had correctly built a class equivalence of the selected word !

Best Regards,

guy038

PeterJones

@guy038 said in Weird behavior of the "In selection" option in "Search" dialogs:

Question : why the In selection box is not selected ?

Because some users complained that it would toggling on In selection when they only had a few characters selected, which is not what they wanted. (Searching for this really long string when abc was selected, it does not make sense to turn it on) Eventually, Don settled on 1024 characters as the compromise threshold: if there are 1024 or fewer ~~characters~~ bytes selected, then it will not automatically toggle In selection on (but it will still keep the old value); if there are more than 1024 bytes, it will automatically turn it on; if there are 0 bytes selected, it will automatically turn it off (and grey it out).

This is documented in the paragraph:

The In selection option will automatically be chosen by Notepad++ if a Find dialog window is opened when more than 1024 characters occur in the active selection. …

Though technically, I guess that should say “bytes”, not “characters”.

Alan Kilborn

@peterjones said in Weird behavior of the "In selection" option in "Search" dialogs:

I guess that should say “bytes”, not “characters”.

Or, even better, the code should be adjusted so that characters is correct.

Alan Kilborn

@peterjones said in Weird behavior of the "In selection" option in "Search" dialogs:

I think Guy’s complaint is that in #2, Notepad++ doesn’t redo the selection-length calculation, even though the selection and length has changed and the FIND window has been re-opened.

OK, this makes this thread make sense to me now, and although it appears Guy and Peter have accepted this behavior, I guess we are calling it the “sticky” behavior, to me there are lingering bugs in the In selection logic as a whole. And I don’t buy into the “sticky” argument. :-)

I’ve spent the intervening time trying to do research on when the weird behavior with In selection first started, but I was unsuccessful in this search. I found some issues (e.g. 9611) but nothing that really satisfied.