I’ve noticed the addition of a line break after a full stop in text works differently in a description to a say command. In the code below, the description behaves as I would expect but uncommenting the bottom line results in the text having a line break added, even though the text passed to the say command is identical to the text from the description.
Is this a bug? It seems like a bug, but I’m relatively new to Inform so maybe there is some reason I’m not aware of that this behaviour is correct.
Test number is a number that varies. Test number is 0.
Test room is a room. The description of test room is "This is a test room."
The Test thing is a thing in the test room. The description of test thing is "Test line 1.[if test number is 0] Line 1 continued."
[Instead of examining the thing: Say "Test line 1.[if test number is 0] Line 1 continued."]
Try different placement for the [if] relative to periods, exclamation marks, or question marks – the typical approach is:
[code]The Test thing is a thing in the test room. The description of test thing is “Test (carry out) line 1[if test number is 0]. Line 1 continued[end if].”
[or]
Instead of examining the thing when switch is at least 1: Say “Test (instead) line 1[if test number is 0]. Line 1 continued[end if].”[/code]
I’m not sure why the effect of doing it your way shouldn’t count as a bug. It’s at least an inconsistency.
It’s not a bug – everybody knows that Inform works like this and it’s not going to change.
If you want to assert it’s a design misfeature, I don’t think anybody would argue. The linebreak system evolved around making common cases work in early development; more complicated cases have had to fend for themselves.
I think everyone does understand (or at least quickly adjusts to) the default handling of text that ends with sentence-ending punctuation (./!/?) vs. that which doesn’t. But to be clear, I think what Sirwol was pointing to was the difference between the way that is handled at the start of an [if] block when it occurs:
inside a thing’s description string (where no break occurs) vs.
inside an instead rule’s say statement string (where a break does occur).
I may just be being dense, but I can’t think of the common uses this difference in behavior would be intended to support. Will you provide an example?
Ending punctuation is handled differently when printing a text value versus saying a literal string. I’m not saying that the example of this [if] block is intended to be specifically useful.
I get that. I’m just curious as to what the intended utility was. If nothing else, having some idea of what that intended utility was supposed to be would offer a better understanding of how to work “with the grain” of I7.
The specific difference you mentioned (handling of a text property vs. a literal string) isn’t elucidated in WWI 2.3 Punctuation, 5.2 How Inform read quoted text, or 5.8 Line breaks and paragraph breaks – though it is obviously very useful to know.
Sorry, I can’t cite you an example. It probably had to do with how object descriptions and room descriptions were printed – that’s the most common example of text properties.