intfiction.org

If there is one thing I do not get in Inform 7 right now, it is line breaks. Here is how I am working at the moment:

1. Write text.
2. Run it.
3. Note where line breaks appear.
4. Add [line break] or [no line break] as appropriate.

Take the following example:


This produces the following output:

Okay, noobishness, I don't know why that "Nothing obvious happens." is there, because I thought "rule succeeds" should stop that, but let's ignore that. I have two questions about this code:

1. How do I fix this? I have tried any combination of spacing, moving full stops, swearing - and I can't make the text output look right for both conditions. To clarify, I want the first and second sentences on the same line.

2. Why in the name of sweet flying kittens would I possibly want output like that? What is the utility of this feature? Why does Inform want to insert newlines all over the place - not even paragraph breaks, but newlines!

On a related note, why does the IDE indent text within indented blocks of code? It may make it look legible in the editor, but the text then line breaks and indents all oddly in the game.

In short, why does Inform want so much to make me look bad? I understand that some people will need fine control over line breaks and spacing. That's fine, give them the option. But why on Earth can't I7 just, by default, assume that I want block paragraph spacing, between paragraphs that I have specifically requested, and no crazy indentation.

Or, in other words, why can't it just be like TADS 3, where I never had to worry about any of this stuff, where you get paragraphs and newlines when you ask for them, where everything is single spaced by default, where even if your conditional text mistakenly spews out multiple new paragraph tags you still only get one. You know, an intuitive environment for outputting computer-generated text, where rather than getting a headache over complex logic puzzles (how do I make sure this sentence ends in a full stop? if this condition is false will that space trigger a newline? if the middle clause isn't displayed, will I have too many spaces?), I can just bloody write.

Having de-stressed a bit, I came up with:


I still challenge anyone to tell me that this is intuitive.

Ah man, that sort of thing drives me INSANE.. especially when working with a project that takes a long time to compile just to see if you got the break right.

This drives me nuts too. My code always ends up with a crazy mishmash of simple punctuated texts, [line break], [no line break], [run paragraph on], and [command clarification break] (this last one in contexts that have nothing to do with clarifying commands; it just seems like the only way to get the spacing I want sometimes.)

One thing that I picked up from Section 5.8 of the docs that helped a little is the fact that Inform adds an automatic paragraph break between two texts that are printed by different rules, but not if they are simply printed by different phrases. But I still don't understand the line break system fully, and like you, I end up doing a lot by trial and error.

Since this is something I've been meaning to figure out anyway, I'll run some sample code and try out all the permutations of different break types and where they appear (internal to a line of text, at the end of a line of text, as the last text produced by a phrase, as the last text produced by a rule, etc...) I'll see if I can boil the whole thing down to a logical set of rules, and let you know if I have any luck.

For this case, I always do:



This provides the correct result with the minimum of cruft.

The crucial observation is that I7 goes newline-happy if a period is immediately followed by an open-square-bracket. In your second example below, you got a space in between the period and the bracket, which is why it started behaving the way you wanted.



The IDE expects you to only hit Enter inside a quoted string if really want a line break there. (If you do this -- and don't add any *extra* indentation -- the string will print with no unexpected indentation.)

Forgot to add the other part of the answer: a "carry out" rule can't abort the action. That's why you get the "nothing obvious happens" message; it always moves on to the report phase. Either place your customized print message *in* the report phase, or divert everything in an instead rule.

The line break rules are specified pretty clearly:

I agree that it can be awfully freakin' persnickety, and I suspect that at least some of the reason for it is that Inform has always been this way and longtime users are used to it. It'd be helpful, at least, if (a) explicitly stated that a space after a full stop doesn't count.

That said, I think getting rid of (b) would cause far more work than it would remove; making it behave differently is fairly rare and can easily be dealt with by using [run paragraph on]. It does seem as if (a) could be handled better -- line breaks are really kind of crap in most cases -- but I'm sure that this discussion has happened a half-dozen times already.

So here's what I just found after some experimentation. This is just the results of some quick test code, and I could easily be missing something. Take everything that follows with a grain of salt:


There are six distinct ways to end a text block. From least likely to produce line feeds to most likely, they are:

If you don't use any of these instructions explicitly, then ending a text block with a period, exclamation mark, or question mark is equivalent to typing [line break]. Ending a text block with any other character (including a space after a punctuation mark) is the equivalent to typing [no line break].

Also note that the end of a text block can be either a close-quotes, or any bracketed instruction. Hence, is two text blocks, not one. (As the original poster discovered.)


The exact behavior of each of these block endings is:

Oddly, there's no command for "print a double line feed, regardless of whether the current rule produces more text". For this, you need to use two [command clarification break] commands in a row (or a [line break] followed by a [command clarification break]).

Finally, I could find no difference between the behavior of a [conditional paragraph break] and a regular [paragraph break]. (I was hoping the conditional version gave the missing "double line feed no matter what" behavior.) In all likelihood, there is a difference, just not one I was able to find.



I'm not arguing for getting rid of the present system, just for documenting it better (and maybe reworking a few of its quirkier aspects...)

Thanks very much -- that's very useful.



Example 113, "Don Pedro's Revenge," demonstrates the difference -- it uses a conditional paragraph break after reading a command, which prints one blank line after the command. If you substitute a paragraph break or line break, it prints two blank lines instead of one.

Why this happens, I cannot tell you.

Thank you all for your input and forbearance.


But trying to get sentences in that form gives me a massive headache. And what if one of them ended in a question mark?

Look, my point isn't that there is a bug, or that Inform 7 isn't consistent, it's just that I don't want to have to think about any of this.

In an environment supposedly aimed at writers, I don't want to have to bend my writing around programming conventions.