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

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.