You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When dealing with some quite big SQL files recently, modifying them via regexps (regular expressions), several times I had the impression that NP3 didn't change the files in the way I expected. I can't remember all these constellations (I found a workaround for each), but I was able to reproduce at least one of them.
Affected version
Released version v5.19.108.1602 (RegEx: Onigmo v6.1.3)
Steps to reproduce
Create a document (extension .sql for the right lexer to kick in) with the following content:
ab
bc
--cd
de
ef
--fg
That's six lines, four with actual "code" (two chars long dummy commands) and two with "comments" (also meaningless).
Now try to replace all the lines with "code" with empty lines, only keeping the comments (with "Regular expression search" checkbox marked).
This is possible via the following regexp search expression:
The "replace with" text box was left empty (as this works in all other cases).
Expected result
The lines not starting with or containing "--" get replaced by empty ones.
All others are kept (this is equivalent to a filter, which was what I wanted to achieve).
Actual result
Only the first line gets removed (I even had cases where nothing was touched at all), the "ab" vanishes.
The other lines that should disappear ("bc", "de" and "ef) remain.
Further attempts to repeat the replace operation do not show any further effect.
Comments and other information
Weird: the highlighting for the matches of the regexp while the replace dialogue is open is correct. It indeed marks all non-comment lines. Just the actual replace operation does not work as expected (which makes be believe this is indeed a bug).
Also weird: using a different replacement term than 'nothing' (i.e. empty box), like a single "x" in the example above, works (with or without regexp search enabled)!
The non-comment lines are replaced by "x" in this case.
Another replacement step afterwards, replacing the "x" with 'nothing', finally yields the intended result (empty lines).
That last approach (with two replacement steps, first with "search term" → certain unique text/character which does not appear anywhere else, and then this unique text/character → 'nothing') was also my workaround for the issue.
For some long SQL statements (file with a few thousand lines, several dozens or even hundreds of kB big), the replacement operation sometimes only affected the first part.
The second half of the files was not considered at all and all lines there remained untouched.
I was not able to reliably reproduce this behavior, but it seemed as if the replacement operation simply aborted somewhere within the file.
As far as I remember, these hiccups were associated with the regexp search and replace operations as described, but I'm not sure. They could've appeared also under different circumstances and might represent a second and independent bug.
I just wanted to mention it here as well as long as I can't come up with a working example for this issue.
The text was updated successfully, but these errors were encountered:
When dealing with some quite big SQL files recently, modifying them via regexps (regular expressions), several times I had the impression that NP3 didn't change the files in the way I expected. I can't remember all these constellations (I found a workaround for each), but I was able to reproduce at least one of them.
Affected version
Released version v5.19.108.1602 (RegEx: Onigmo v6.1.3)
Steps to reproduce
Create a document (extension .sql for the right lexer to kick in) with the following content:
That's six lines, four with actual "code" (two chars long dummy commands) and two with "comments" (also meaningless).
Now try to replace all the lines with "code" with empty lines, only keeping the comments (with "Regular expression search" checkbox marked).
This is possible via the following regexp search expression:
See https://www.regular-expressions.info/completelines.html for an explanation.
The "replace with" text box was left empty (as this works in all other cases).
Expected result
The lines not starting with or containing "--" get replaced by empty ones.
All others are kept (this is equivalent to a filter, which was what I wanted to achieve).
Actual result
Only the first line gets removed (I even had cases where nothing was touched at all), the "ab" vanishes.
The other lines that should disappear ("bc", "de" and "ef) remain.
Further attempts to repeat the replace operation do not show any further effect.
Comments and other information
Weird: the highlighting for the matches of the regexp while the replace dialogue is open is correct. It indeed marks all non-comment lines. Just the actual replace operation does not work as expected (which makes be believe this is indeed a bug).
Also weird: using a different replacement term than 'nothing' (i.e. empty box), like a single "x" in the example above, works (with or without regexp search enabled)!
The non-comment lines are replaced by "x" in this case.
Another replacement step afterwards, replacing the "x" with 'nothing', finally yields the intended result (empty lines).
That last approach (with two replacement steps, first with "search term" → certain unique text/character which does not appear anywhere else, and then this unique text/character → 'nothing') was also my workaround for the issue.
For some long SQL statements (file with a few thousand lines, several dozens or even hundreds of kB big), the replacement operation sometimes only affected the first part.
The second half of the files was not considered at all and all lines there remained untouched.
I was not able to reliably reproduce this behavior, but it seemed as if the replacement operation simply aborted somewhere within the file.
As far as I remember, these hiccups were associated with the regexp search and replace operations as described, but I'm not sure. They could've appeared also under different circumstances and might represent a second and independent bug.
I just wanted to mention it here as well as long as I can't come up with a working example for this issue.
The text was updated successfully, but these errors were encountered: