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

M Andre Z Eckenrode

I’m very certain that I’ve attempted, unsuccessfully, to paste multi-line text into FIND/REPLACE/MARK etc. string input zones many times, going back 10 years or more, though I always assumed that any line ending sequence was disallowed (I pretty much always use CRLF, myself). Of course, at least with the appropriate setting (I forget specifically, but think offhand that there is a setting for it), if you have text selected before you open the FIND/REPLACE/MARK dialog, that text then populates the FIND WHAT field, line endings and all. I just wish I could see them when they’re in there.

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.