Fix issue #1600, allow \\ to escape a backslash in replacement string

[mrducky4]

For search/replace in the proofing interface, allow \\ to escape \ in the replacement string.

Previously, any occurence of \n in the replacement string would become a newline. So \\n would become a backslash followed by newline. With this change, \\ means an escaped backslash, so \\n becomes a backslash followed by n. Also, any occurence of a single backslash followed by any character other than n just means that character. So to use a literal backslash in the replacement string, always escape it as \\.

Sandbox: https://www.pgdp.org/~mrducky/c.branch/replace_newline/

[mrducky4]

Related to this code change, I propose updating the Help page. Where it says "To replace matched text with a new line, \n may be used in the replace field." add this:
To include a literal backslash in the replace field, use \\.

[mrducky4]

Just an observation, I'm not saying this should influence how escaping characters in the PI should work. In Guiguts 2 search, if I search for text\n it searches for the text with a backslash and n, not a newline. Then if I enable the regex checkbox, it searches for the text followed by a newline. So if we go forward with this PR as is, it will be inconsistent with Guiguts 2 search.

[cpeel]

In Guiguts 2 search, if I search for text\n it searches for the text with a backslash and n, not a newline. Then if I enable the regex checkbox, it searches for the text followed by a newline. So if we go forward with this PR as is, it will be inconsistent with Guiguts 2 search.

@windymilla, can you please give us your thoughts on how you think we should address this search/replace issue in the current proofreading interface? See also the discussion in #1600

[windymilla]

tl;dr - remove \n to newline substitution when not in regex mode

Looking at the comments from users, it appears people previously assumed the \n to newline substitution would only happen with the regex option. I too would have thought that to be the case.

Perhaps the history is that there was no regex option originally, so the \n to newline substitution was added as a special case since that was frequently needed. After regex was introduced, there was no pressure to remove \n to newline substitution until the recent TeX stuff with \nu, \neq, etc.

Possible options seem to be:

1. Leave it as it is (and say "use the two-step process, and wait for the new PI"). Easy (for devs). Annoying for TeX proofers.
2. Remove the special case \n to newline substitution from non-regex mode. Brings it into line with most editors in "normal" mode (e.g. MS Word, Open Office, Notepad++, Guiguts, etc). Annoying to anyone who currently relies on it without checking the regex box (if that applies to anyone).
3. Add the \\ escape mechanism as in this PR. Easy to use \\nu for \nu. But adds complexity in code and documentation - still doesn't work like other editors.

My order of preference would be 2, 1, 3, but bear in mind that I've never used the feature. If I had something complicated to format with substitutions (regex/normal) I'd probably just copy the text into another editor, fix it there, then copy it back into the PI.

[mrducky4]

I am happy to change this PR to do windymilla's option 2, if cpeel agrees with that. Please let me know.

I think the \\ escape mechanism still ought to be there for regex mode, right?

[cpeel]

tl;dr - remove \n to newline substitution when not in regex mode

I am happy to change this PR to do windymilla's option 2, if cpeel agrees with that.

I'm fine with this. Having it map to other DP tools makes sense.

I think the \\ escape mechanism still ought to be there for regex mode, right?

Probably.

[windymilla]

tl;dr - remove \n to newline substitution when not in regex mode

I am happy to change this PR to do windymilla's option 2, if cpeel agrees with that.

I'm fine with this. Having it map to other DP tools makes sense.

I think the \\ escape mechanism still ought to be there for regex mode, right?

Probably.

I'm not entirely sure why \\ doesn't already work in regex mode. I haven't studied the code in detail though.
But, anyway, if there's something that works, the rest can probably wait for the new PI

[srjfoo]

Late comment, probably for future consideration. There are other common escaped characters -- \f for form feed, \t for tab -- that ought to map to a space in the PI, and \r that probably ought to map to the newline character, that, even in regex mode are pasted in as literals.

Edit: actually, \f would mean "end of page", so should maybe either be ignored entirely in regex mode except as \\f to paste in the literal -- I don't think we want to automatically map it to "save as done" without an "are you sure" (or am I over-thinking? 😁)

[mrducky4]

I updated the code as we discussed on Aug 31. Then I realized there was a unit test (I should have looked sooner) so I fixed that and added a new test. The sandbox is the same one: https://www.pgdp.org/~mrducky/c.branch/replace_newline/

[windymilla]

The behavior of the search/replace box seems to match what I expect:

• With regex on, \n is treated like a newline character, whether in the search string or replace string
• With regex on, \ escapes a backslash, so \\n, for example, means the character \ followed by n
• With regex off, \n is treated just like a normal string of characters - the backslash and n characters - no special meaning.

Clicking Regular Expression Help in the search/replace popup opens this page: https://www.pgdp.org/~mrducky/c.branch/replace_newline/faq/prooffacehelp.php#srchrep
On that page it says "To replace matched text with a new line, \n may be used in the replace field." (i.e. the text hasn't been changed). I think it should be made clearer that is now only in regex mode, perhaps by removing that sentence, and adding \n — the newline character to the short list of regex help notes above. I don't know if you want to specifically mention the escaping behavior of double backslash, but I don't think it's necessary - partly because that's standard for anyone who has used regexes, and partly because people who want to replace something with \nu can/should now use non-regex mode.

[mrducky4]

Thanks, yes, I will update the help page. I wasn't paying attention, and I thought that was a wiki page rather than a php page.

[windymilla]

LGTM!