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