This problem is a result of a change made in 2011 to fix problem report 100 in the old google code issues. The original problem report was the user could not insert a newline in the replacement text, it would always insert the string literal "\n". Now we have the opposite problem: the user wants to insert the string literal, but the code is converting it to an escape sequence. You could argue that no one would want to insert a backspace character, but that still leaves the new line, carriage return, and tab escape sequences.

I'm thinking that the best fix would be to treat the escape sequences as string literals: for example, the string C:\test\new\bin would be inserted as shown, without inserting a tab, newline, and backspace. Then, if the user wanted a tab, newline or other escape sequence, they would use a double backslash: \t \n \r, etc. (then, of course, this would mean you cannot insert a string literal of '\n').

We would add this to the tooltip on the "Replace with" field on the UI to help with the syntax.

Any comments on this?

I vote for literal strings. Regex mode already handles tab, newline, etc. If there's a big demand for non-regex special chars, we can cross that bridge when we get to it.

Oh, are we talking about regex mode? Maybe I read this too quickly.

The problem is in the replace, not in the search, and it affect both Regex and Text searches. To see the problem,

1. create a test file with any text, for example just "text text".
2. search for 'text' using either a regular expression or plain text.
3. replace with the string 'C:\test\new\bin'
   and you end up with a tab, a line feed, and a backspace in your file.
   Currently, I do not think there is any way to work around this behavior using a regex or otherwise.

Right, current plain-text replace behavior is wrong. I think it should not support escape characters. That's what regex is for.

Plain-text replace does already support newline (via multiline mode) and tab (have to paste it in, room for improvement).

Regex escape sequences mean you have to double the slashes in the example. That's good and correct. It's regex.

We could add a third option for "plain text but with escape chars", like Notepad++ does.

Also, I wrote that without trying it out (at work) 😉 If doubling the slashes doesn't work for regex, then I think it's a bug.