Bug introduced in 7.0 or earlier and persists through 11.0.0
Bug isn't present in version 5.2

Update: Sjoerd pointed out that this happens with any string and it is not related to StringForm. Just evaluate "foo bar \\. daz.". Or type "\\. d directly, and watch the cursor jump after typing the d.

I found the weirdest problem with messages and StringForm.

This works fine:

enter image description here

But let's change that b to a d now:

enter image description here

What is going on? Where did that line break come from?

It turns out that the problem is actually in StringForm.

StringForm["foo bar \\. daz."]

enter image description here

It's a bug and it's there at least in 8.0.4-10.4.1. But can anyone offer an explanation about the cause? Removing either the backslash (remember that \\ denotes a single backslash) or the . or changing the d to something else prevents the problem. It doesn't matter if I use a capital or lowercase d.

  • 2
    $\begingroup$ It's even weirder: In an empty cell type "\. d" (including the double quote character) and the cursor moves to the next line the moment you press the 'd' button. $\endgroup$ Commented Jun 19, 2016 at 12:42
  • 1
    $\begingroup$ Note also that "\\." and "\." yield the same characters. Clearly a bug and perhaps related to the bug Alexey reported earlier this week. $\endgroup$ Commented Jun 19, 2016 at 12:47
  • 2
    $\begingroup$ Note BTW that "\." is used to initiate a hexadecimal character code. "\. d" doing something like the above may be related to the carriage return being ASCII 13 and d the hexadecimal notation for 13. Apparently, space+d are similar to 0d. $\endgroup$ Commented Jun 19, 2016 at 13:02
  • 2
    $\begingroup$ Yep, the bug is, I guess, that the first "\" doesn't escape the second one. $\endgroup$ Commented Jun 19, 2016 at 13:20
  • 2
    $\begingroup$ Also present in version 7. I guess probably introduced in 6. $\endgroup$ Commented Jun 19, 2016 at 14:59

1 Answer 1


This seems to be related to the notation "\.XX" being used to enter characters in hexadecimal notation, as explained in the documentation.

For instance, entering "\.09" will get you the tab character, which in ASCII has the value 9. Similarly "\.0d" codes for the Carriage Return (CR) character.

What appears to be the bug is twofold:

  1. "\. d" has the space acting as a zero, making it act like a CR and
  2. in "\\. d" the first backslash is supposed to escape the second one (according to this documentation, so that the string should consist of the literal characters "\", ".", " " and "d", but it doesn't work out that way.
  • 2
    $\begingroup$ This bug is also present in the 4-digit version as well. \:   d (with a colon and three spaces) also behaves the same way. $\endgroup$ Commented Jun 19, 2016 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.