Wrong insertion of text, in the new FIND and REPLACE dialogs

guy038

Hi, All,

Holidays are over and I’m back home. So, let’s resume our discussion. I’m quite sure there are a lot of problems with the new Search and Replace dialog, in the v8.8.4 relaease, because of the new feature :

 4. Increase search input length from 2046 to 16383.

I assume that :

The Maximum Size for Auto-Checking "In selection", in Settings > Preferences... > Searching, is set to 0
The Search mode of the Find dialog is set to Normal
All other options of the Find dialog are unckecked

If I chose these preferences about searching :

And if I consider the text below :

1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

Select the first 1,024 digits, above, leaving the remainder 567890
Open the Find dialog ( Ctrl + F )

=> You correctly see the first 1,024 characters of this single line are filled in the Find field and can be matched again !

Close the Find dialog ( Esc )
Select the first 1,025 digits, above, leaving the remainder 67890
Open the Find dialog ( Ctrl + F )
Hit the Delete key to suppress any text in the Find field ( IMPORTANT )
Close the Find dialog ( Esc )
Re-open the Find dialog ( Ctrl + F )

=> The Find field is totally empty ?!

I would have expected that the first 1,025 characters would have been filled in the Find field, because of my preference :

Fill Find Field with Selected Text , which is checked

And this should be true from 1,025 to 16,383 digits, which is the new limit !

Can anyone confirm this simple test ?

Note that I found out other oddities, that I will develop later. Everything in its own time !

Best Regards,

guy038

Alan Kilborn

@guy038 said:

Can anyone confirm this simple test ?

Yes.

Alan Kilborn

The problem when selecting 1025+ characters as a pre-step is because of this line of code:

https://github.com/notepad-plus-plus/notepad-plus-plus/blob/dab30de9c677165fcd7f9cc045b4529ab0c4f7b7/PowerEditor/src/NppCommands.cpp#L1380

FINDREPLACE_INSELECTION_THRESHOLD_DEFAULT is set to 1024, here:

https://github.com/notepad-plus-plus/notepad-plus-plus/blob/dab30de9c677165fcd7f9cc045b4529ab0c4f7b7/PowerEditor/src/Parameters.h#L167

Probably the check against that constant should not be made if Maximum Size for Auto-Checking "In selection", in Settings > Preferences… > Searching, is set to 0.

guy038

Hello @alan-kilborn and All,

Many thanks, Alan, for detecting the problem : your assumption is surely exact ! So, this is a FIRST bug regarding the Search feature

Now, here is the SECOND bug :

Whatever the search mode chosen, any selected text, up to the limit ( 2046 or 16823 ), can be pasted in the Find what: zone ( with Ctrl + V ) ONLY IF that text does not contain any CR character. As soon as a single CR character is met, the pasted text stopped at the last character before that CR char.

And guess what : I was able to reproduce this behavior even with the last Win XP version of Notepad++ which is the 7.9.2 release !

In other words, any text pasted in the Find what: zone is not complete when you usually works with Windows or Mac files ! Is there any reason for this behavior ?

Thanks, to all, for your investigations !

Best Regards,

guy038

P.S. :

However, note that if a text does not contain any CR character, you can paste, as expected, up to 16,382 characters in the Find what: zone, which may be searched later !

PeterJones

@guy038 said in Wrong insertion of text, in the new FIND and REPLACE dialogs:

ONLY IF that text does not contain any CR character

This was the root cause in the recent How to replace two separate lines discussion.

Is there any reason for this behavior ?

Reason that I know for certain: No.
Reason that I can guess: probably because Don’s original development was focused on single-line replacement, and wasn’t focused on multi-line search-and-replace; and since extended or regex modes allow \r\n for multiline searches, being able to paste in a multi-line search (or replace) field probably never felt like a priority to Don.
Reason that is researchable: given the recent “replace two separate lines” discussion, I am quite certain there are more instances in this forum, if you can find the right search terms. And probably one or more open or closed Issues in the GitHub issue tracker. I would definitely do some detailed searching there, because it would very much surprise me if Don hadn’t weighed in on multi-line search/replace improvements before, so there’s probably a canonical answer somewhere in the ~17000 Issues; though good luck finding such a needle in a haystack.

guy038

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

Peter, I suppose that your second assumption should be the right one. I also verified this same behavior regarding the Replace with zone

Thus, until this behavior will be improved, the Copy/Paste operations, within the Find/Replace dialog, works correctly for Unix-style files only !

However, I noticed that the Incremental Search is OK, regarding this problem :

Select any text with some line-endings, whatever they are
Open the Incremental Search panel ( Ctrl + Alt + I )

=> All the multi-lines block is pasted in the Find zone

Click on the > button to find the next occurrence
If you select an other multi-lines block of text, simply redo a Ctrl + Alt + I operation

=> This new text should appear in the Find zone

Click on the > button to find the next occurrence

And I pleased to note that, as expected, for the v8.8.4 release, you can paste up to 16,382 characters in the Find zone of the Incremental Search panel ! For older versions, you can paste till 2,046 chars

Best Regards,

guy038

mpheath

@guy038

The Find/Replace/… dialog is using ComboBox controls for Find what and Replace with. A ComboBox is a single line control so once it reaches the CR then it truncates the string to that position and discards the rest. The type of control chosen limits the pasting of text by the user.

Quote from ComboBox:

Is this the right control?

Use a drop-down list to let users select a single value from a set of items that can be adequately represented with single lines of text.

Use a list or grid view instead of a combo box to display items that contain multiple lines of text …

…

A ComboBox has advantage of being a list though the disadvantage is that it is not designed for multiple lines of text.

The Incremental Search panel is using an Edit control for Find. An Edit control is a multi-line control so it does not truncate at CR.

This is why some editors use a large Edit control for their Find dialogs for pasting and viewing multiple lines of text. I am not suggesting changing controls or possible workarounds as that would need investigation and testing.

References:

FindReplaceDlg.rc#L31 Resource line of Find what using COMBOBOX
FindReplaceDlg.rc#L33 Resource line of Replace with using COMBOBOX
FindReplaceDlg.rc#L106 Resource line of incremental Find using EDITTEXT

guy038

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

Thanks, @mpheath, for your very informative post, relative to the ComboBox and EditText controls !

So, OK. I think you’re right about it. No need to change anything regarding the pasting behavior in the Find/Replace dialogues, presently. We just have to remember to change current file into an Unix file to have the opportunity to paste up to 16,383 characters, in the Find or Replace zones, when necessary.

Of course, I will create, these next days, an official issue regarding the first bug, confirmed by @alan-kilborn, with a possible solution related in this post :

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

If accepted, the work-around of using Unix-style files would even not be necessary !

Now, one advantage of increasing the search input length from 2,046 to 16,383 is when using tokens. Indeed, you can now select any multi-lines text, up to 16,383 chars, whatever their line-endings status, and, after using one of the 5 Style All Occurrences of Token options, it should highlight any identical block of text, found in the current file !

I’m also preparing an other post as I noticed that the number of bytes used, when using a UTF-8 text to be searched, differs, depending on whether :

You just select that text and open the Find dialog
You copy that text, open and clear the Find dialog, then paste that text in the Find what zone

Best Regards,

guy038

Alan Kilborn

@guy038 said in Wrong insertion of text, in the new FIND and REPLACE dialogs:

No need to change anything regarding the pasting behavior in the Find/Replace dialogues, presently

I disagree, so I created issue 16952 and will submit a PR for it soon.

guy038

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

Alan, you said in your last post :

I disagree, so I created issue 16952 and will submit a PR for it soon.

Thank you for your involvement in finding a solution to this problem !

Now, I also created an issue regarding the 1,024 bug : https://github.com/notepad-plus-plus/notepad-plus-plus/issues/16955

Do you mind investigating in this issue, as well, as you already found out the root of this problem ?

Best Regards,

guy038

Alan Kilborn

@guy038 said:

Do you mind investigating in this issue, as well, as you already found out the root of this problem ?

Yes, I will also look at that. I have special interest in that, because it is my code addition to Notepad++ that introduced the ability to set the threshold value (the field that you have set to 0). I wish I’d never done it; I started out with good intentions, but some others got involved and the feature went a little bit “wacky”.

guy038

Hello, @alan-kilborn and All,

Many thanks Alan to look into that issue, too. And, don’t be too upset about this side-effect of adding the threshold value. As we say in France, “you can’t make an omelet without breaking eggs” !

Now, I suppose that resolving the other issue 16952 is a bit delicate : we’ll have to take care about :

The extended or regular expression search mode which already allows syntaxes like abc\r\ndef
The regular expression search mode which allows multi-lines syntax for a specific regex

Therefore, I am more than willing to help and test your experimental version, if possible, in the hope of eliminating any potential problems : Notepad++'s Search/Replace/Mark feature is very powerful. So let’s take the time necessary to ensure it stays that way !

Best Regards,

guy038

Alan Kilborn

@guy038 said:

I suppose that resolving the other issue 16952 is a bit delicate

I don’t see how the 2 points you made about it are of any concern to the fix I proposed.
Also, we may run into the problem that the Notepad++ author is not interested in the fix.

guy038

Hi @alan-kilborn and All,

After some tests, I just realized that it’s already the case ; So, there should not be any problem about it. Here is what I was thinking of :

Consider this simple text :

bla bla

abcde
fghij

bla bla blah

bla bla

abcde
fghij

bla bla blah


bla bla

abcde
fghij

bla bla blah

Select the two complete lines abcde + CRLF + fghij + CRLF
Open the Find dialog ( Ctrl+ F )
Check the Wrap around option
Choose the Extended search mode

=> You see, apparently the string abcdefghij in the Find what: zone. But, indeed, it contains the real string abcde\r\nfghij\r\n. So 3 occurrences of this string can be detected !

But, if you wrongly think : “As I’m in extended mode, I should add the \r\n at the end of each line for a correct search”, nothing will be detected !

Of course, you could have found the same correct result, if, without any previous selection, you would have typed the string abcde\r\nfghij\r\n in the Find what: zone, too

Best Regards,

guy038

Alan Kilborn

@guy038 said:

After some tests

…of the version from the PR…

"…in extended mode, I should add the \r\n at the end of each line for a correct search”

Well… I think the answer to that is… don’t do it.

It’s a matter of knowing what your data is. And, admittedly, this is difficult as real \r and \n are invisible in the Find what box. But this is true also if you select some multiline text and press Ctrl+f, it’s not peculiar to the proposed new code.