intfiction.org

If there's a question mark, you have to go back to one of the cruftier solutions.



I want many things out of life. :/

It seems like the reason it's so complicated is so that you don't have to think about it in the majority of cases. Just like Microsoft, this strategy can backfire by making things even more complicated when "Do what I mean" doesn't.

The reason it's more complicated than TADS 3 is because T3 adds the abstraction layer of the transcript, where output can be tweaked and fixed up before being printed to the screen.

There are default rules in the adv3 library that weed out superfluous line breaks and paragraph tags, as well as removing or replacing HTML tags based on the capabilities of the interpreter at runtime.

To the best of my knowledge, Inform does not distinguish between queuing up output for eventual display and the actual VM level print operations. (Output may be buffered at the interpreter / library level but that is not guaranteed, and comes too late to assist the author in any case.)

You would need something like Eric Eve's Text Capture extension to make this work in Inform, running at a global level and with no length restrictions on captured output. Performance concerns and the lack of Z-Machine compatibility probably preclude this from becoming a standard feature.

Oh, it's z-machine compatible if your game is otherwise very tiny , but those performance concerns are nothing to sneeze at. I refer you to my short game, "Sugar" (Parchment and download links here), which is pretty much unplayable through Parchment.

The particular annoyance with the current line-break system is that the printing mechanism can keep track of *one* pending line break. That is, if you do



...then the system will print one line break, and then set a flag indicating that a second may be coming. (It depends on various factors, such whether the next print statement occurs in the same rule, or whether it starts with a special paragraph substitution.)

I wish it would instead print *no* line breaks, and set a flag indicating that *one or two* may be coming. That would be more flexible, obviously; an upcoming substitution could continue on the same line. (Which is not currently possible.) This would not require any additional I/O buffering; only an adjustment of how I7 generates I6 code.

However, I understand that the print mechanism is *already* a mare's nest, and any adjustment would probably break plenty of existing (working) code.

Had to get home from work to prove to myself that I didn't dream this. I am using the Windows IDE. (Line breaks in quoted text are ignored, paragraph breaks - double line breaks - produce the weird indentation. Unless you use the explicit tags [line break], [paragraph break])


Then we are practically life aim twins.

You're right, and my answer (about hitting return inside a quoted string) was wrong. This is both more complicated and buggier than I understood.

The case I was thinking of is this:



If you do this, you'll get a paragraph break (two line breaks) between "Alpha" and "Beta", with no indentation. This is probably what you want. However, it's not what the IDE editor naturally does -- it autoindents when you hit Enter, so you wind up with this:



This was your original complaint, and I misunderstood it. Sorry about that. I was thinking only about the behavior of the compiler, not of the editor. If you go back and delete the indentation before "Beta", you get back to the correct case.

The other reason I was confused was that I had never noticed the behavior of the compiler with a *single* line break. As you note, it collapses the line break *and* any associated indentation into a single space character. That's these cases:



I don't know why it converts the line break to a space -- I'd expect it to keep it. But given that it does, it certainly makes sense to drop the indentation, and it should be doing that for the double-line-break case too.

(In fact there's still something hinky going on under the covers. In these latter cases, the I7 compiler is generating I6 string constants which contain literal tab and newline characters -- though not both at the same time, which is even hinkier. These characters then get ironed out into spaces by the *I6* compiler. The result is valid, but the I7 compiler really should be handling it all and not passing the buck.)

I filed http://inform7.com/mantis/view.php?id=715 , which repeats this analysis in tedious detail.

I've gotten into the habit of doing things this way:

I just don't use literal line breaks inside strings at all, which is why I wasn't up to speed on how the compiler treats them.