New Line in Replace field in Compile

I am trying to find and replace text with a new line (or carriage return) upon compile.
I have successfully used RegEx to find all the text that I want replaced. (use RegEx is checked.)
But I have spent a long time trying to figure out how to insert a new line in the replace box.
/n seems to work in the find box. But it does not insert a new line if I put it in the replace box.
Finally, I found:
It does work if you type option+return in the replace box. However, you do not see invisibles in the replace box in compile, even if show invisibles has been turned on, so it is sort of mysterious.
I’m posting this:

  1. to make sure I’m not missing something (why doesn’t /n work?)
  2. to maybe help someone else if they are having the same problem
  3. to give a +1 to the feature request for having show invisibles function in the replacements section of compile.

Thanks, I hadn’t noticed that \n (it’s backslash not forward-slash, but backslash doesn’t work either) doesn’t work in the regex replacement field; neither does \r (though that generally wouldn’t be needed on a modern Mac, it uses the UNIX standard of 0x0A as the newline). Interestingly, it works with \t to insert a tab, I’m not sure why it doesn’t accept a newline control. Well, as you note, inserting literal carriage returns always works. It is a bit awkward in that small text field, but it works.

OK, thanks for the quick reply

I’m going out on a limb here, not really knowing much about the RTF spec, but I doubt that either the Unix or the DOS end-of-line characters are used as such inside an RTF file. \n is shorthand for the linefeed character and \r for the carriage return character. If RTF uses some other end-of-line ascii code, or anything that you can escape in a regex, you could search for that, but I don’t know what that might be.

Edit: What I mean by the ‘linefeed character’ and ‘carriage return character’ specifically are the ascii characters represented by hex codes 0A and 0D, respectively. They may be present in an RTF file, but I wonder if they represent the ends of paragraphs all on their own.

Edit the second: I was too curious to leave it at that… It appears that in an RTF file \para signals the beginning of a new paragraph. I don’t know if you can search for such RTF codes using REGEX, but \para is not going to be equivalent to either \n or \r, whereas \t is still a tab character in RTF. Source:

That’s true, RTF uses its own internal codes for paragraph breaks, but in theory this tool should be working at a level of abstraction above the RTF writer, and as such it would be expected that \n express itself in a meaningful way other than printing an ‘n’ in the output. I’m also not sure if the RegEx engine runs at a level where RTF exists yet. I think it runs purely in (or on top of) the NSTextView realm, where formatting isn’t RTF, but programming objects.

The telling problem here, I think, and one that indicates there is a problem in the regex engine, is that searching for\n will find true paragraph breaks in a rich text document and let you manipulate them. There is that abstraction, so why doesn’t it work for output?

The Option key was the trick I needed to get the Compile Regex/Replace to insert Tabs for me. Thanks for the post.