Hello!
I’m attempting to streamline an editing process, namely selecting multiple, discontiguous lines of un-tagged dialog, and Regex Replacing to place quotation marks around each individual selection.
However, it seems as if Replace only performs its operation on the most-recent selected text range. To test this:
Ctrl+select multiple lines of discontiguous text
Open the Find… tool
Set it to RegEx mode, “Selected Text”, and Ignore Case set to True
In Find: (.*)
In Replace, type TEST.
Now, when you press “Replace” or “Replace & Find,” only the most recent selected line will be replaced with TEST. If you press “Replace All”, nothing happens. I would expect “Replace All” to take each of my individual selections and perform the replacement.
Am I doing something wrong? Is this unsupported behavior? If it is, where could I make an official feature request? Having to make a selection, press Replace, make a new selection, press Replace again, etc takes a lot of time for a document of any length.
Thank you!
I don’t know what regex engine is used on Windows; but each engine may have subtly different rules. The period . character can mean any character, or any character except a newline depending on engine and setup. The asterisk * is usually greedy.
On macOS I confirm that (.*) does not select each paragraph in turn (only the first), whereas the same regex does select each paragraph (and newlines) when tested with the PCRE2 engine (a different regex engine, you can test that using https://regex101.com).
BUT (.+) does select each paragraph in turn, at least on macOS Scrivener. You could also try ([^\n]+) or similar variant. There is probably a technical reason why the greedy .* is not working where the .+ is.
Scrivener uses Qt, so the RegEx engine should be platform cross-compatible and Perl-compliant. However, after testing further, I don’t think the Find argument has anything to do with the Replace command when set to RegEx mode with Selected Text enabled. For instance, if I select a few words from one paragraphs, and Ctrl+select a few words from another to add to the selection, it doesn’t matter what I have in Find. Replace will do the replacement I would expect (only on the most-previously selected text though).
So I believe the issue is that Replace / Replace All with Selected Text and RegEx enabled only looks at the most recent selection range and doesn’t loop over each selection range in the entire current selection.
(As a curiosity, Microsoft Word ALSO doesn’t allow you to perform arbitrary replacements on discontinuous text selections, even using VBA.)
The macOS engine uses ICU (Regular Expressions | ICU Documentation) with is PCRE-ish but not identical, it is possible there may be some platform differences…
BUT, I missed that you are using a non-continuous selection. The pink text here is selected using ⌘-click (macOS equivalent):
While (.+) does work to replace each paragraph in the document, it does not respect the non-continuous selection…
So the fact find & replace doesn’t work with discontinuous selections is also true for macOS. I assume it is a bug, though it may just be a not-in-scope feature?
Just to clarify, the Mac version is MacOS-native and uses the text engine and APIs provided by Apple, hence also ICU RegEx. The Windows version is built with Qt—the Apple text engine and APIs not being available—hence PCRE RegEx.
There is not a single line of code shared between them.
On the matter of Find and Replace only hitting one of the selections, when attempting to run a Replace All with the “Selected Text” scope set, this is a known issue and likely a Qt limitation we will have to find a workaround for (Find and Replace in general has quite a number of workarounds and expansions already, such as making it work across multiple text editors, which Scrivenings view technically is, on Windows).
It doesn’t have anything to do with regular expressions specifically, this is a limitation with any of the search operator settings.
To clarify, please don’t waste your time on that, I looked up the existing ticket in the bug tracker to ensure we had this problem documented, before responding.
