-
Notifications
You must be signed in to change notification settings - Fork 595
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
Multi-line matching with regular expression should be default #1588
Comments
Personally I agree, this trips me up too, I've never found a use for single-line matching. For a bit of the rationale, see the pull request that implemented this. |
|
Its not just a regex option, when the This is also a premature optimization since it can save having to coalesce the Scintilla buffer which can result in moving the entire document in memory if the cursor is near the start of a document. If thats really an issue requires benchmarking, but its likely to only apply to very large documents (and whats large depends on your machine). As to which should be the default, myeh. |
Hmm, ah, so the main purpose for single line matching is to save memory, since a 5-6 GB txt file might cause some serious trouble.. and is just not as optimized as searching line by line, no? But again especially regex like "(.+)\nfoobar" or anything with "\n" will fail without multi-line search. Anyway, I see why there are both options. But at least there should be something like a warning that "\n cannot be found in single-line mode" or something, unless someone has a better solution, which could also be optimized while being able to detect every symbol and regex correctly (one less option to care about). |
Remember Geany is intended to be fairly fast and lightweight, so its useful on old wimpy laptops, where much less than that is noticeably slow. And people insist on opening hundreds of megabyte log files, and search them.
See the tooltip when you hover over the option. |
@Johndeep, I don't think that's the (main) reason, just a side-effect. According to the PR I linked above, where it was implemented:
|
I see, I must have miss the line at that time, while I desperately wanted to match the newline without looking. But I didn't know that this behavior is normal for CLI tools like Because this post is quite old already, I even forgot this issue myself, so, since this seems to be rather a feature than an issue, I'll just close this issue for good then. But nevertheless, thank you for the insight of this option and sorry for triggering this as an issue. |
No need to apologize, it's a perfectly valid issue, it's just unlikely to be acted upon since changing the default was intentional, for better or worse. |
Story:
Besides searching for keywords like variables or unique words in codes, one also sometimes just want to search for special symbols like "\t" or "\n" for reasons. One would activate "regular expression" for this, but still, "\n" will not be found, unless "multi-line matching" is activated.
Suggesting:
To have an extra option for multi-line matching is somehow useless, this should obviously be the default if searching for regular expression. This also would simplify the search/replace dialog a bit, unless someone does have a use case for this extra option.
The text was updated successfully, but these errors were encountered: