Return to Answer

In the hoarier days space-like characters (spaces, newlines, tabs) inside strings were interpreted on input in an odd way: for example single newlines followed by spaces or tabs were converted to a single space. The \<\> syntax was introduced as a way to avoid this: between \< and \> the space-like characters are interpreted literally with the only exception to line-ending backslash whish escapes the newline. This syntax was standardized in the modern Mathematica notebook format (introduced in 1996).

Starting from version 6 the behavior of strings on normal input was changed and the \<\> syntax is no longer needed for preserving space-like characters. But for direct editing of the low-level box representation of cells in the special cell editing mode of the FrontEnd (which is toggled by pressing Shift+Ctrl+E) it is still necessary as Vladimir showed. These delimiters aren't needed however when you programmatically work with the low-level representation (and the kernel simply removes them anyway!).

Despite this a Notebook exported as a "Package" can be correctly opened or imported as "NB" preserving space-like characters:

Now we got our newline but the backslash is absent (the next space is present). I think that the absence of the backslash can be related to the series of bugs I discuss in this answer. The code of the printed cell:

In the hoarier days space-like characters (spaces, newlines, tabs) inside strings were interpreted on input in an odd way: for example single newlines followed by spaces or tabs were converted to a single space. The \<\> syntax was introduced as a way to avoid this: between \< and \> the space-like characters are interpreted literally with the only exception to line-ending backslash whish escapes the newline. This syntax was standardized in the modern Mathematica notebook format (introduced in 1996).

Starting from version 6 the behavior of strings on normal input was changed and the \<\> syntax is no longer needed for preserving space-like characters. But for direct editing of the low-level box representation of cells in the special cell editing mode of the FrontEnd (which is toggled by pressing Shift+Ctrl+E) it is still necessary as Vladimir showed. These delimiters aren't needed however when you programmatically work with the low-level representation (and the kernel simply removes them anyway!).

Despite this a Notebook exported as a "Package" can be correctly opened or imported as "NB" preserving space-like characters:

Now we got our newline but the backslash is absent (the next space is present). I think that the absence of the backslash can be related to the series of bugs I discuss in this answer. The code of the printed cell:

In the hoarier days space-like characters (spaces, newlines, tabs) inside strings were interpreted on input in an odd way: for example single newlines followed by spaces or tabs were converted to a single space. The \<\> syntax was introduced as a way to avoid this: between \< and \> space-like characters are interpreted literally with the only exception to line-ending backslash whish escapes the newline. This syntax was standardized in the modern Mathematica notebook format (introduced in 1996).

Starting from version 6 the behavior of strings on normal input was changed and the \<\> syntax is no longer needed for preserving space-like characters. But for direct editing of the low-level box representation of cells in the special cell editing mode of the FrontEnd (which is toggled by pressing Shift+Ctrl+E) it is still necessary as Vladimir showed. It is not needed however when you programmatically work with the low-level representation (and the kernel simply removes these delimiters anyway).

Despite this a Notebook exported as a "Package" can be correctly opened or imported as "NB" preserving space-like characters:

###My experiments with Mathematica 11.0.0

It is easy to check that there are 9 spaces between abc and d in the printed cell (and so are before d in the code). But the new line and the backslash are absent because the backslash at the end of line simply escapes the newline.

Now we got our newline but the backslash is absent (the next whitespace is present). I think that the absence of the backslash can be related to the series of bugs I discuss in this answer. The code of the printed cell:

In the hoarier days space-like characters (spaces, newlines, tabs) inside strings were interpreted on input in an odd way: for example single newlines followed by spaces or tabs were converted to a single space. The \<\> syntax was introduced as a way to avoid this: between \< and \> the space-like characters are interpreted literally with the only exception to line-ending backslash whish escapes the newline. This syntax was standardized in the modern Mathematica notebook format (introduced in 1996).

Starting from version 6 the behavior of strings on normal input was changed and the \<\> syntax is no longer needed for preserving space-like characters. But for direct editing of the low-level box representation of cells in the special cell editing mode of the FrontEnd (which is toggled by pressing Shift+Ctrl+E) it is still necessary as Vladimir showed. These delimiters aren't needed however when you programmatically work with the low-level representation (and the kernel simply removes them anyway!).

Despite this a Notebook exported as a "Package" can be correctly opened or imported as "NB" preserving space-like characters:

###Further elaboration

It is easy to check that there are 9 spaces between abc and d in the printed cell (and so are before d in the code). But the newline and the backslash are absent because the backslash at the end of line simply escapes the newline.

Now we got our newline but the backslash is absent (the next space is present). I think that the absence of the backslash can be related to the series of bugs I discuss in this answer. The code of the printed cell:

It is easy to check that there are 9 spaces between abc and d in the printed cell (and so are before d in the code). But the new line and the backslash are absent because the backslash at the end of line simply escapes it.

It is easy to check that there are 9 spaces between abc and d in the printed cell (and so are before d in the code). But the new line and the backslash are absent because the backslash at the end of line simply escapes the newline.