Search++ (\W)'(\w) regex replace failure

Alan Kilborn

@Coises said:

I didn’t suggest changing the settings of the installed copy

Gotcha; didn’t catch that on the first read, sorry.

M Andre Z Eckenrode

I didn’t experiment with adding or subtracting any plugins (other than having already added Search++) in the portable version yet. but I did just open the portable again, this time via command line and -multiInst, per @Alan-Kilborn’s suggestion (thanks, Alan), while my installed version was already open. I then retried my regex, but this time got anomalous results, such as:

this
u’dos I am
that

this
’Round and ’round
that

I then undid all replacements, and redid them, with all results correct the second time around.

Quit the portable copy, then reopened it (as -multiInst) again, then redid the regex, with anomalies:

this
’Cos I am
that

this
’Round and-’-ound
that

Quit the portable copy again, then reopened it (as -multiInst) again, then redid the regex again, with slightly different anomalies:

this
’Cos I am
that

this
-’-ound and ’round
that

Talk about bizarre. But it seems we can rule out conflicts from the other plugins I use in my installed version, unless there’s some way for them (or something else) to cross-contaminate the process in active memory due to the installed version still being open.

[…shuts down both portable and installed versions; reopens portable version; retries regex…]

Nope. Still had anomalous results:

this
’Cos I am
that

this
-’-ound and ’round
that

I’m out of guesses. It’s hit or miss whether or where or how it happens.

Coises

@M-Andre-Z-Eckenrode said:

I’m out of guesses. It’s hit or miss whether or where or how it happens.

Thank you for the reports. I don’t know the cause yet either, but I now think it is very likely that it is a fault in my code which I just haven’t encountered yet.

I notice that the literal ’ is always correct; when something is wrong, it’s the \1 and \2 substitutions. I have a hunch that if you were to show line endings, in the ones where a spurious character appears before a ’ at the beginning of a line the preceding line ending would have lost its LF and become just a lone CR.

I will work on it. Thank you again for your patience and this information. The reports that it occurred in a clean, portable version are very helpful in that they tell me what it isn’t; with something I can’t readily reproduce, that’s valuable knowledge.

M Andre Z Eckenrode

@Coises said:

I notice that the literal ’ is always correct

Ah, but don’t forget in my initial post, I was sometimes getting question marks (?) instead of ’. When I first saw that, I suspected that maybe Search++ was failing to make the conversion back from UTF to ANSI, since I believe it was previously stated that text is treated internally as UTF, but I was actually working on ANSI text at the time, and a question mark is what I usually get when accidentally trying to paste a UTF character in an ANSI file. But, I guess that’s not the case.

M Andre Z Eckenrode

@Coises said:

I have a hunch that if you were to show line endings, in the ones where a spurious character appears before a ’ at the beginning of a line the preceding line ending would have lost its LF and become just a lone CR.

Here ya go… This is what happened when I just now tried it:

Note that only one CRLF became just LF (line 8), but also that in the case of what you see here as line 5, it’s actually a combination of what were lines 5 and 6 from the pre-replacement text, so an entire CRLF is now missing. I don’t particularly think that’s related to the fact that I had View > Show Symbol > Show End of Line enabled, but what do I know?

M Andre Z Eckenrode

M-Andre-Z-Eckenrode said:

Note that only one CRLF became just LF (line 8)

Correction: Only one CRLF became just CR.

guy038

Hello, @m-andre-z-eckenrode, @alan-kilborn, @coises, @mpheath, @thomas-knoefel and All,

Just an observation : if you modify the proposed replacement :

FIND (\W)'(\w)

REPLACE \1’\2

by this one :

FIND (?<=\W)'(?=\w)

REPLACE ’

No problem occurs for a step by step replacement sequence or a Replace All operation for, either, an ANSI or UTF-8 encoded file. I verified this assumption with four regex engines :

The native Search > Replace dialog of N++
The Plugins > Column++ > Search... dialog
The Plugins > Search++ > Search... dialog
The Plugins > MultiReplace > MultiReplace... dialog

May be, this result will help to resolve possible bugs, with the other regex syntaxes

Best Regards,

guy038

Coises

@m-andre-z-eckenrode:

I’ve been looking, but so far I have not found a potential cause for the results you obtained.

@guy038’s post just led me to think of something.

The debug information in the post where you asked about the failure to replace in Notepad++ showed that you have Columns++ installed.

The search and replace code Search++ uses is derived from what I used in Columns++, but I have made some changes. Would you try and see if you can get the search in Columns++ to misbehave under the same circumstances as the one in Search++? (It’s fine to use the installed version of Notepad++ for this test.)

Knowing whether or not the fault also appears in Columns++ could help me narrow the scope of what I could be missing.

As always, I understand if you don’t have the time for this sort of thing. Thank you for your observations so far, and many thanks in advance if you are willing to do this additional test.

guy038

Hi, @m-andre-z-eckenrode, @alan-kilborn, @coises, @mpheath, @thomas-knoefel and All,

@coises, personally, I confirm that the step by step replacement with the regex pattern :

FIND (\W)'(\w)
REPLACE \1’\2

Works correctly with both your two plugins Columns++ and Search++ and with the MultiReplace plugin as well, when using the N++ v8.9 release !

The bug seems to occur only with native N++ regex engine !

BR

guy038

M Andre Z Eckenrode

@Coises said:

Would you try and see if you can get the search in Columns++ to misbehave under the same circumstances as the one in Search++?

In installed NPP, using Columns++ search in regex mode with a rectangular selection of multiple copies of my previously shown example text, I find that only the instances of “ 'r” (preceded by a regular space, NOT by any EOL) are matched, and are all replaced correctly with no anomalous characters. To be clear, this, again, is the starting text:
this
'Cos I am
that

this
'Round and 'round
that

this
'Cos I am
that

this
'Round and 'round
that
And resulting text:
this
'Cos I am
that

this
'Round and ’round
that

this
'Cos I am
that

this
'Round and ’round
that

M Andre Z Eckenrode

@guy038 said:

The bug seems to occur only with native N++ regex engine !

I’m confused. You’re saying that a native N++ regex replacement, using my example text and regex strings, results in anomalous characters for you? I haven’t seen that at all.

guy038

Hello, @m-andre-z-eckenrode, @coises and All,

@m-andre-z-eckenrode, you said :

I’m confused. You’re saying that a native N++ regex replacement, using my example text and regex strings, results in anomalous characters for you? I haven’t seen that at all.

I didn’t say that anormalous characters appear. I just said that no replacement occurs at all !

Indeed, with the native regex N++ replacement, and the text below :

this
'Cos I am
that

this
'Round and 'round
that

and with the following REPLACEMENT :

FIND (\W)'(\w)
REPLACE \1’\2

The first two replacements do not occur ! Only the last one will change the normal quote ' into the ’ character ( \x{2019} RIGHT SINGLE QUOTATION MARK )

IMPORTANT : This test was done with N++ v8.9. May be, the last v8.9.7 release would produce a different result !

Best Regards,

guy038