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? 😁)