Line / Paragraph Break control

After a lot of efforts, I decided to stop trying to control individual paragraph/line breaks; I find them too unpredictable to deal with!

I have read and read again §5.8, but there is no way that I can predict nor control getting line breaks where I actually want either no breaks or paragraph breaks. (The best solution so far is using [conditional paragraph break], but ideally I would need a [conditional run paragraph on] option, if it existed.)

So, I concluded that it is better if I make sure I end every sentence with a " " (thus NOT getting line/paragraph breaks at all) and then have a final paragraph break inserted at the very end of the rule (so the final text doesn’t stick to the “>” prompt of the following command).

For example:

[code]“Testing Paragraph/Line Breaks” by Giannis

The Attic is a room.

After examining a thing:
say "This line of text appears for all examined objects. ";
if the noun is a container:
say "This line appears because [the noun] is a container. ";
if the noun contains nothing:
say "This line appears because [the noun] is empty. ";
say paragraph break.

The closet is in the Attic. The skeleton is in the closet.

The bottle is in the Attic. The bottle is a container.[/code]

I am wondering: is this how most people work? Do people usually finish lines with a space?

A common approach is to leave the punctuation outside the conditions so that the text never ends in punctuation, especially when using inline conditions:

After examining a thing:
	say "This line of text appears for all examined objects[if the noun is a container]. This line appears because [the noun] is a container[end if][if the noun is a container and the noun contains nothing]. This line appears because [the noun] is empty[end if].";

That won’t work if the sentences end in different punctuation.

[Run paragraph on] can also be used. It’s most useful when the paragraph is built in multiple rules.

After examining a thing:
	say "This line of text appears for all examined objects.[run paragraph on]";
	if the noun is a container:
		say " This line appears because [the noun] is a container.[run paragraph on]";
		if the noun contains nothing:
			say " This line appears because [the noun] is empty.[run paragraph on]";
	say paragraph break.

Thank you.

Yes, with in-line conditions I have figured that one has to be aware of where the punctuation goes.

About the [run paragraph on], I see that we agree about using

say paragraph break

at the end!

Yes, this is a difficult area for Inform.

I can say that I was able to get through all of Hadean Lands without using the end-with-a-space trick. My usual tactic is leaving the punctuation outside the brackets. I used [run paragraph on] in a few places, and [conditional paragraph break] in two places (but only to backport an Inform bug fix from 6L38 to 6G60).

But I had to install one terrible low-level hack to the DivideParagraphPoint() routine. I only used it once (in the routine which executes high-level goals – that is of course fiercely complicated code). But it still makes the point that Inform’s line-break policy is an elephant that has to be maneuvered around.

Out of curiosity, what did the terrible low-level hack do?

I added a global flag which completely disabled Inform’s (inconsistent) tendency to turn line breaks into paragraph breaks.

Technical: I changed the “new_line” statement in DivideParagraphPoint() to “if (suppress_extra_newlines == 0) new_line”.

I don’t think this is a good solution for most people, because a global flag can easily become disarranged if you try to set-and-clear it in more than one spot in your code. I had to verify that the rule which set it could never ever be called recursively.