Paragraph break weirdness

Hey All-

What’s the deal with how Inform decides where to put paragraph breaks after entering a command? Sometimes it puts one between your command and the response, and sometimes it doesn’t and it’s just a line break, and I can’t seem to figure out the logic behind it.

For instance, sometimes when I enter a direction, there’s a paragraph break between my command and the description of the new location, and other times there isn’t. It must be connected to checks or special rules I wrote about going in that direction, but not every check on going somewhere makes it happen, and I can’t figure out what’s going on. The same thing happens occasionally with new commands or “instead of” rules, but not with any pattern I can see.

5.8 says:

(b) pieces of text produced by different rules in Inform will be separated by paragraph breaks.

But I don’t understand what that means. Can someone clarify this for me?


The best reference on the subject is Nathanael’s Cookbook. (The details about when I7 thinks it should paragraph-break are documented in I6T/Printing.i6t under your I7 installation’s Internal directory, clear as pie.)


Clear as mud pie. I can’t find that at all.

But the cookbook page is extremely useful. I think it must be brackets and periods doing this. There’s the pattern. Thanks!

(On a Mac it’ll be something like “/Applications/Local Apps/Inform-7/”; on Windows at “Program Files/Inform 7/Internal”.)

I’ve had grandiose plans for doing this in a fancy way… but it was worth doing it plainly and quickly. The I6 Template Layer is now alongside my html-ification of the Standard Rules, so now it’s easy to link to Printing.i6t.

1 Like

Ok, I solved some of the problem by adding a space after a period and before a left bracket. But I STILL have some directional problems, where going some places generates a paragraph break between the command and the room header.

This looks promising:

(4) Every action rule (but not activities rules) generates an implicit paragraph break at the end. To suppress the implicit paragraph break, the action rule must say “[run paragraph on]”; as the very last say-statement in the rule.

So I added “say run paragraph on” to the end of rules about going, but no dice. I still get the paragraph break when going to that location.

It’s bugging me (and some testers), but I’ve spent hours trying to figure it out and I can’t. So it’s just going to have to be weird.

There’s a hacky solution floating around which I mentioned in this post: Window has pending line request error when asking yes or no - #7 by zarf

Inform likes to add a line break between text if it comes from different rulebooks, and this cannot be suppressed with “run paragraph on”. It can be suppressed by setting a flag when you invoke the new rule or rulebook. But if you’re just writing action rules, you’re not the one invoking rulebooks, so this isn’t helpful.

It’s hard to say more without looking at code samples.


What is an example of a different rulebook? I clearly made one of these and caused the problem, but how do I find it?


Since I don’t know where the problem is, I’d have to post the entire game code, which wouldn’t be good for comp rules, and which also would be like showing the world my dirty underwear full of holes.

It’s normal to get a blank line between the command prompt and the new location name when using a direction to move. You don’t get it when you look (or if an action teleports you to a new location). Is what you’re seeing consistent with that, or weirder?

I’m used to:





Some of my directional movements give the first; some give the second. I have been over the code with a fine-tooth comb trying to figure out why. All other commands behave like the former, as far as I can tell.

is the norm for successful directional movement, honest. Printing.i6t talks about it; the I6 routine GoingLookBreak there is responsible. It’s weird that there are cases where you’re not seeing it.

Huh. I guess I never paid attention before. I just looked over Fairest and I think it does this too. OK, so I’m looking for what’s wrong with the line break movements, not the paragraph break movements. That might help me find the problem.

Could it be “move the player to”? Would that cause a line break instead of a paragraph break? I think that might be it.

Yes, that’s what I meant to convey by an action teleporting you, above. It’s only the completely straightforward X is east of Y and the player goes EAST cases where you get it.

And… it’s all a classic case of knuckle-dragging, unobservant idiocy. Nothing to see here, folks. The village idiot is retiring to quietly reflect on how she can play IF for 40 years and not have noticed these basic things. Yes, it hurts.

I may have sounded all matter-of-fact, but the real sequence of events was:

  • read it in Printing.i6t
  • disbelieve it
  • quickly write a few lines af code in borogove to verify it
  • and only then say all matter-of-fact “this is how it behaves”

And it’s even the case that I know I read about it in Printing.i6t before!

1 Like

This caused me no end of pain at first. I didn’t understand line break rules at all, and I still don’t, but I think it’s under control.

I also find I do a lot of testing to verify what I’m reading, as @Zed did.

The code below also helps. Sometimes I don’t want an implicit line break. The code is Inform 6, but there’s not much of it, thankfully.

section avoid line breaks in consider/follow

[thanks to Climbingstars and Zarf ... note this link is expired now since we migrated to Discourse]

To process (RL - a rule): (- ProcessRulebook({RL}, 0, true); -)

To skip upcoming rulebook break: (- say__pc = say__pc | PARA_NORULEBOOKBREAKS; -). [this is when a weird line break pops up because Inform thinks it should after a rule, and you don't want it to. Often seen when writing a list of stuff after processing/considering/following rules and nothing gets printed out.]