18

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.

Szabolcs
  • 234,956
  • 30
  • 623
  • 1,263
  • The string "foo bar \. daz." itself, executed in its own cell, has the same problem. It does not seem to be related to StringForm or Message specifically. – Sjoerd C. de Vries Jun 19 '16 at 12:37
  • 2
    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. – Sjoerd C. de Vries Jun 19 '16 at 12:42
  • @Sjoerd Thanks! I didn't notice that! In a terminal it doesn't happen. This suggests that it may be related to the string representation of boxes. – Szabolcs Jun 19 '16 at 12:46
  • 1
    Note also that "\." and "." yield the same characters. Clearly a bug and perhaps related to the bug Alexey reported earlier this week. – Sjoerd C. de Vries Jun 19 '16 at 12:47
  • I can confirm this bug also exists in v8.04 – Sjoerd C. de Vries Jun 19 '16 at 12:52
  • 2
    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. – Sjoerd C. de Vries Jun 19 '16 at 13:02
  • 1
    @Sjoerd 13 (or 0D) is CR. 10 (or 0A) is LF. Using a instead of d also triggers the problem. b does not. This confirms your theory. – Szabolcs Jun 19 '16 at 13:18
  • 2
    Yep, the bug is, I guess, that the first "" doesn't escape the second one. – Sjoerd C. de Vries Jun 19 '16 at 13:20
  • ". c", also works (C=FormFeed). However ". 9" doesn't do a thing whereas you'd expect a tab there (".09" does that). – Sjoerd C. de Vries Jun 19 '16 at 13:24
  • @Sjoerd Maybe time to write an answer and to tag as bug? – Szabolcs Jun 19 '16 at 13:44
  • OK, something like the below? – Sjoerd C. de Vries Jun 19 '16 at 13:57
  • @SjoerdC.deVries Note that with versions 5.2 and 8.0.4 evaluation of "\." produces error message Syntax::sntoct2: 2 hexadecimal digits are required after \. to construct an 8-bit character. In version 10.4.1 this message is defined (evaluate Syntax::sntoct2) but isn't generated in this case... – Alexey Popkov Jun 19 '16 at 14:23
  • 1
    With version 5.2 evaluation of "foo bar \\. daz." produces the expected result but with versions 8.0.4 and 10.4.1 I observe the line break after d. – Alexey Popkov Jun 19 '16 at 14:29
  • I do not observe the cursor jump after typing d during typing "\\. d with versions 5.2, 8.0.4 and 10.4.1 on Windows 7 x64. But after evaluating "\\. d" I get additional empty line in the output with versions 8.0.4 and 10.4.1 (but not with version 5.2). – Alexey Popkov Jun 19 '16 at 14:36
  • I do observe cursor jump after typing d during typing "\\\. d with versions 8.0.4 and 10.4.1 on Windows 7 x64 (but not with version 5.2). Evaluation of "\\\. d" triggers the Syntax::sntoct2 message with versions 5.2 and 8.0.4 but not with version 10.4.1. – Alexey Popkov Jun 19 '16 at 14:50
  • It is interesting that evaluation of "\\\\. d" produces the expected output (i.e. \\. d) with the all versions tested. – Alexey Popkov Jun 19 '16 at 14:54
  • What is a bit surprising is that evaluation of CellPrint@Cell@"\\. d" in version 5.2 prints the cell Cell["\n", GeneratedCell->True, CellAutoOverwrite->True] but with versions 8.0.4 and 10.4.1 it prints Cell["\\. d", GeneratedCell->True, CellAutoOverwrite->True, CellChangeTimes->{3.6753369642877436`*^9}] which is displayed correctly. – Alexey Popkov Jun 19 '16 at 14:58
  • 2
    Also present in version 7. I guess probably introduced in 6. – Oleksandr R. Jun 19 '16 at 14:59
  • 1
    That's a lot of bugs persisting through 11.0. :-/ How many have you found that have been fixed in 11? – Mr.Wizard Aug 09 '16 at 00:29
  • Also would you check my list when you have time? – Mr.Wizard Aug 09 '16 at 00:43

1 Answers1

15

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.
Sjoerd C. de Vries
  • 65,815
  • 14
  • 188
  • 323
  • 2
    This bug is also present in the 4-digit version as well. \:   d (with a colon and three spaces) also behaves the same way. – JungHwan Min Jun 19 '16 at 15:40