new line vs paragraph break, and the rationale behind

Hi!

While developing Tuuli I realized that the usage of the [paragraph break] vs [line break] produces an output that seems random at first. Interpreters put a lonely space where tabulation should be, and this is perceived by some readers as a bug, as an extra space that the author unconsciously have put there.

For more complication, usage of Inform 7 of paragraph breaks vs line breaks by it seems erratic. Sometimes it uses space, sometimes not, so… I’m quite not sure of the advantages of use [paragraph break] vs two [line breaks]. I’m not sure if there are good practices on this, and I’m not sure of what substitution use as a standard.

The chapter “§5.8. Line breaks and paragraph breaks” doesn’t help either, because, in the end, I7 games keep pouring a no homogenous output of it (or homogeneous but not for a simple human mind like mine), so…

What do you think?

1 Like

I’m not sure what your question is. Are you just asking for help understanding the rules? I don’t have a great answer for you, I’m afraid.

The general intent of the system is that you can just write “say” statements in your rules, and you’ll get automatic paragraph breaks between outputs, which is the traditional Inform style.

The confusing bit is that if you write several “say” statements in the same rule, they will get single line breaks between them, instead of paragraph breaks. I think this supports some semi-common case in the Inform library. (Although I’m not sure it was so common as to require a big confusion exception like this.) So, if you want to print several paragraphs at once, you need to use [paragraph break].

(I’m talking here about full-sentence output – a “say” statement that ends with a period or other closing punctuation. “Say” statements that end without closing punctuation) are one step lower: they get zero or one line breaks, depending on whether you’re looking at within-rule or cross-rule output. This is the other confusing bit.)

1 Like

What I mean by this is that you can write:

When play begins:
	say "One.";

When play begins:
	say "Two.";

When play begins:
	say "Three.";

And you get correctly paragraphed output without worrying about it.

Take a look at my game:

ifdb.tads.org/viewgame?id=ngcuiadqoqzy1yn0

Just in the first screen there almost none paragraph breaks. Just only one that was used by me in the description.

There’s no paragraph in the intro, non in the title of the room, no in the start of the description, no in my “type” help messages.

EDITED: I mean, the tabulation, that space that comes after a paragraph break.

So, because I used a paragraph by hand inside the description, this looks like an errata, instead of a feature.

The question is that I still don’t understand the system and how it behaves.

Could you post us a bit of source code that produces this problem for an example?

Are you asking about paragraph indentation? As in, an indented first line for each paragraph?

Inform’s standard style does not use paragraph indentation at all. The system isn’t really built to handle that style. The output model doesn’t distinguish between individual lines (as in room names or poetic lines) and paragraphs of text. You’d want to only apply indentation to the latter, and there’s no good way to make that distinction.

Hmm, ok, then I will use only [line break], and see what happens.

ah, no. No, Inform 7 still put paragraph indentation there, even if I use “line break”. Let’s compile some codes:

This is the original, it produces indentation:

You wake in your pallet, the scream still scratching at your throat.[paragraph break] You go to Mákke's bed to tell her about your dream. She isn't there, and you know she's dead even before you know where she is. The room is black as her eyes. Cold as her bones. Empty as her body.

Now, with line break that produces indentation too:

You wake in your pallet, the scream still scratching at your throat.[line break][line break] You go to Mákke's bed to tell her about your dream. She isn't there, and you know she's dead even before you know where she is. The room is black as her eyes. Cold as her bones. Empty as her body.

Now, this funny guy, don’t produce indentation:

You wake in your pallet, the scream still scratching at your throat.[paragraph break]You go to Mákke's bed to tell her about your dream. She isn't there, and you know she's dead even before you know where she is. The room is black as her eyes. Cold as her bones. Empty as her body.

So, the color here is that I guessed wrongly that indentation went with paragraph break hand in hand, and that is not true.

Ok, I think I got now my standard approximation to paragraphs to avoid automatic indentation:

[code]You wake in your pallet, the scream still scratching at your throat.

You go to Mákke’s bed to tell her about your dream. She isn’t there, and you know she’s dead even before you know where she is. The room is black as her eyes. Cold as her bones. Empty as her body.[/code]

SOLVED! Thanks!

But that is too busy for my project, I have more than 30 paragraphs breaks, so those are not safe to delete in bulk.

There’s any way to deactivate the indentation?

The problem seems to be having a new line in the code after a paragraph break or line break. Try putting the next line of code immediately following the paragraph break.

So instead of:

[something break]
New Text

Try:

[something break]New Text.

I have to say that this kind of indentation, an extra space at the beginning of a paragraph, just looks like a bug to me in an Inform game. But I suppose that is because I’m not used to it.

A period or sentence-ending punctuation triggers the parser to include a break of its own (often seemingly random) desire. You can muzzle this behavior and solve some problems by ending your quoted text with a space instead of the punctuation. It’s tedious to troubleshoot, but if you want this much control over phrases and breaks, it’s worth it.

[code]
Lab is a room.

Instead of jumping:
say “Here is a sentence.”;
say “Here is another sentence with no period”;
say “Here is a sentence with run paragraph on.[run paragraph on]”;
say “Here is the sentence after run paragraph on.”;
say “Here is a sentence.[line break]Here is a sentence after an inline line break.”;
say “Here is a sentence.[paragraph break]Here is a sentence after a paragraph break.”;
say “None”;
say " of “;
say “these”;
say " say statements have periods”;
say " except this one.";
say “Here’s the next sentence.”;
say "Here’s a sentence with a period and a space. ";
say “Here’s the next sentence.”;
say “Here’s period-space-line break. [line break]”;
say “Here’s period-space-paragraph break. [paragraph break]”;
say "The last word in this sentence is random after a space: ";
say “[randomword]”;
say “.”;

To say randomword:
say “[one of]foo[or]bar[or]xyzzy[or]plugh[at random]”;
[/code]

I would love to see a first class text management system within an IF platform. The “print” with no back or foreknowledge seems archaic at this point.