Missing newline characters in transcripts made while running in Inform IDE?

I recently discovered that there’s a weirdness in the transcripts generated while running my in-progress game from within the IDE: they’re missing the newline character between the player-entered command and the text generated in response. So transcripts look like this:

> x lennaAh, Lenna. Five years ago the two of you were inseparable. 

instead of

> x lenna
Ah, Lenna. Five years ago the two of you were inseparable. 

Needless to say, it makes transcripts hard to read!

This happens whether I configure Inform to use git or glulxe as the IDE’s 'terp. I don’t think I’m doing anything that interferes with reading or parsing the command in any bizarre way; my code doesn’t try to hook in to any of the parsing activities, for instance.

The problem disappears when I run a release version from within Gargoyle. Which I’m inclined to think means that it’s an IDE-based weirdness that I can live with, because it’s not as if someone’s going to be playing the eventually released game via the Inform 7 IDE, but I realize I’m not sure that that’s what’s going on, and I’m worried that it’s symptomatic of me doing something else dumb that’s going to come back and bite me later.

Is this a known IDE bug (Inform 7 with 6.33/6M62 under x64 Linux)? Is it something I should be concerned about? Will the problem reappear under other interpreters?

Hm, I can’t recall if I’ve ever actually made a transcript during an IDE game.

It certainly sounds like your IDE is creating line breaks at those points using different characters than the program you’re using to read the transcript expects.

I’m not sure if you’re aware of the different line break combos that exist in general? Some are linefeed only (LF), some are carriage-return only (CR), and some are both (CR+LF).

A common mismatch is Mac vs Windows, since Mac only uses CR, but Windows does CR+LF. So sometimes a text file made on a Mac and moved to a Windows text editor might open as one long line. This can be resolved by saving it as CR+LF back on the Mac, or redefining line breaks for that document on the Windows machine.

Linux’s native choice is LF-only, but I don’t know what the (Glulxe) IDE produces under Linux. Gargoyle is probably producing a transcript with CR+LF, which tends to be the safest version one as it will produce a newline on any machine. For instance, any generic read-mes I make on my Mac, I save as CR+LF.

The mismatch would be between what the Linux IDE is producing for line breaks in the transcript and the interpretation of them in the program you’re using to read it. You may be able to change settings in your program, formats for the opened transcript in that program, or try opening the transcript in a different program, to see if it suddenly appears as normal.

Whether or not it’s a bug in the IDE (producing line breaks a certain way it shouldn’t be?) I’d say odds are strong it’s a line break type mismatch rather than something you’re doing in your code.

-Wade

1 Like

At this point, MacOS has pretty well gone over to LF text files, same as Unix.

In any case, this problem doesn’t occur on Mac Inform. I’d say it’s a bug in the Linux IDE, but I’ve never tried the Linux IDE so I should let someone else check this.

1 Like

It’s a good theory, and when I read it, I thought “of course, that makes sense, it’s a line-endings problem.”

But using a Python REPL to open and re-save the file didn’t fix it, as I would have thought; and I opened up the original file with a hex editor and it looks like there really is no character at all where I would expect a line break to be:

hex

So it looks like the line breaks that do occur in the transcript are just \n (0x0A, linebreak) without a \r carriage return; they’re represented graphically by a dot in the character display there by the bless hex editor. There’s a few visible in that screenshot between listed extensions. But after the restart command the 'terps response is the very next character, with nothing at all between it and the 'terp’s response.