18
$\begingroup$

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.

|improve this question
$\endgroup$
  • 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$ – Sjoerd C. de Vries Jun 19 '16 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$ – Sjoerd C. de Vries Jun 19 '16 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$ – Sjoerd C. de Vries Jun 19 '16 at 13:02
  • 2
    $\begingroup$ Yep, the bug is, I guess, that the first "\" doesn't escape the second one. $\endgroup$ – Sjoerd C. de Vries Jun 19 '16 at 13:20
  • 2
    $\begingroup$ Also present in version 7. I guess probably introduced in 6. $\endgroup$ – Oleksandr R. Jun 19 '16 at 14:59
15
$\begingroup$

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.
|improve this answer
$\endgroup$
  • 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$ – JungHwan Min Jun 19 '16 at 15:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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