Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Search and replace operation with regular expressions faulty #1209

Closed
engelhro opened this issue May 14, 2019 · 2 comments
Closed

Search and replace operation with regular expressions faulty #1209

engelhro opened this issue May 14, 2019 · 2 comments

Comments

@engelhro
Copy link

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

  1. 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).

  2. 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.

  3. 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.

@RaiKoHoff
Copy link
Collaborator

Duplicate with #1151:
Has been fixed with one of the latest beta builds (beta channel access see: #1129).

Regarding the "long SQL statements" issue:
we definitely need an example file to reproduce the behavior for debugging purposes.

Nevertheless: Thank you for the precise and detailed error report.

@engelhro
Copy link
Author

Fixed in version v5.19.630.2381, I cannot reproduce the bug any longer. From my point of view this issue can be closed now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants