MantisBT - Core Inform
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000715||Core Inform||Spacing and printing||public||2011-08-08 18:08||2014-05-07 07:33|
|Target Version||Fixed in Version||6L02|
|Effect||(serious/mild) Game compiles but misbehaves|
|Summary||0000715: Quoted strings containing literal linebreaks are treated inconsistently|
|Description||There are several parts to this, some of which may be "works as intended", but (I think) not all. Consider the source code below and its output.|
Examples 1 and 2 demonstrate that a double linebreak (in a quoted string) is converted to a paragraph break in the output, *as long as* the following line of text is not indented. (That is, the "1b" and "2b" begin in column zero.) The indentation of the blank line does not matter -- that's the difference between example 1 and example 2 -- you get the same result.
Example 3 is what happens if the following line of text *is* indented. Two line breaks and a tab (in the I7 code) are converted to *one* line break and a tab (in the I6 code); the I6 compiler then converts this to one line break and a space character. This is surprising and almost certainly not what the author wants.
Note that if the author naively hits the Return key twice while typing this source code, he will wind up with example 3. That's because of the IDE's auto-indentation. You have to consciously delete tab characters to get back to the (probably desired) example 1.
Example 4 is what happens if you hit the Return key *once*. The literal line break (and tab character) are swallowed and converted to a space character. This may be the compiler's intended behavior, but I think it is surprising in light of examples 1/2.
Example 5 shows that for the single-line-break case, it *doesn't* matter whether the following line of text is indented or not. Examples 4 and 5 generate the same output. However, the generated I6 code reveals that this is sort of accidental -- the I7 compiler is generating different I6 string constants for these cases. They then get regularized by the I6 compiler.
(This is *not* what happens in ex 1/2; there the I7 compiler generates "^" characters, as expected for I6 source code.)
(Footnote: Printing a tab character is illegal in Glulx and questionable in Zcode. The I6 compiler takes a string of literal tabs and newlines in the I6 source and compiles it as a single space.)
- Should a single line break be swallowed, as in ex 4/5? If so, document it.
-- Either way, the generated I6 string constants should not contain literal tabs and newlines. It's not broken (because I6 handles these consistently) but it's ugly and confusing.
- The behavior of example 3 really should be changed. The indentation before "3b" should be ignored, and the double line break preserved, producing a result identical to ex 1/2. (And again, no literal tab or newline.)
|Minimal Source Text To Reproduce||"Test Case" by Andrew Plotkin.|
The Kitchen is a room.
When play begins:
[Five distinct examples follow!]
Constant SC_11 = "1a.^^1b.";
Constant SC_12 = "2a.^^2b.";
Constant SC_13 = "3a.^ 3b.";
Constant SC_14 = "4a. 4b.";
Constant SC_15 = "5a.
|Tags||No tags attached.|
|2011-08-08 18:08||zarf||New Issue|
|2011-09-01 09:31||EmacsUser||Status||new => confirmed|
|2014-02-01 03:28||graham||Note Added: 0002418|
|2014-02-01 03:28||graham||Status||confirmed => resolved|
|2014-02-01 03:28||graham||Resolution||open => fixed|
|2014-02-01 03:28||graham||Assigned To||=> graham|
|2014-05-07 07:32||jmcgrew||Fixed in Version||=> 6L02|
|2014-05-07 07:33||jmcgrew||Status||resolved => closed|