Inform 7 line break inconsistency - Bug or oddity?

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].”


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:

  1. inside a thing’s description string (where no break occurs) vs.
  2. 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.