I'm accustomed to using codes like \n \t for newline, tab, etc in find & replace operations.Could have sworn I've used it that way on SublimeText back home on my WinXP machine.Now I'm traveling, with a Win7 laptop (and discovering the full horror of Win7. Grrrr! This machine gets a wipe and XP install when I get home.)I use ST (ver 1.4 still) for editing emails containing both English and UTF-8 Chinese text.Now tried to do a replace all: \n replaced with \n> (obvious, indent the old text) but it doesn't work.The code \n does not seem to be recognized. Copying a newline and pasting into the search field (the usualway to find out how an editor displays control codes in search/replace) shows nothing.What? That's... broken behavior. MUST display invisible characters in search/replace facility.

Am I just imagining that \n worked in ST before, on an XP machine?I do use it that way in another editor (which can't handle UTF-8, so no use here). Maybe I'm confusing the two.Or is Win7 somehow breaking what seems to be an internal feature of the text editor? (Would not surprise me at all.)

In any case, any suggestions for how to represent newline in the find/replace entry fields?

jbjornson wrote:On the find dialog there is a toggle to search with regular expressions or not (it is represented by a star). Make sure that toggle is selected for regular expression seach/replace to work...

Sorry, I should have mentioned - I had already tried that. It seemed the obvious first thing. But it doesn't matter whether the ".*" button is on or off, newlines still don't represent as "\n" in the find/replace entry fields.Simplest case: I create a new file containing only 5 newlines. Select all. Ctl-C to copy, ctl-V to paste to Find entry field. It just gets 5 invisible newlines pasted in. Both in regexp and normal modes. I'd have thought in regexp mode I should see \n\n\n\n\n\n

Is this the way it behaves for you? In Windows7 ? (so-called 'home premium' version, which is a classic MS marketting bullsh*t oxymoron.)

In Windows Vista it also shows invisible newlines (does not convert the newlines to \n's), but it *does* correctly find the one instance of the 5 empty lines in the view (i.e. although it doesn't change the search string, the functionality is correct).

Is your only problem that the search string isn't converted into a regular expression? I would imaging that, from a development perspective, it would be difficult to implement a converter from some random text into regular-expression-ified text...