Possible bug in the specification?

Authoring Dialog
1

I’ve run into a very odd crash, which I think qualifies as a bug. Specifically, if you (undo) or (restore) from within a span, the game crashes with code 7 (invalid I/O state).

Technically this is according to spec: (undo) doesn’t close any current spans or divs, and you can’t open a div inside a span, so if you jump out of a span then the game will crash the next time you open a div (probably immediately, for the room header). In fact, once this has happened, there’s no way to close that span: it’s just left open forever.

I think a better solution would be to have (undo) and (restore) close all active spans and divs, restoring the I/O to a known state where nothing is open. Does this seem reasonable?

1 Like
2

Interesting. I thought it already did reset/clear I/O states, with (undo) at least, since

(par) (save undo 1) (par)

does not collapse the two par breaks, this causes two empty lines.

Anyways, I think your suggestion is reasonable. Can you think of any scenario where saving and restoring I/O states would be a benefit?

3

Not really, because spans can’t be closed explicitly. If one gets “wedged open” by undoing like this, the game can’t interact with it again in any way.

4

I also vaguely remember Linus mentioning I/O states across restore and undo operations in the manual somewhere, but can’t recall where or what the remark entailed.

Edit: I found this in the manual

It is not possible to save the game state (to a file or undo buffer) from within a status area, or to enter a nested (status bar $) or (inline status bar $) from within a status area. Such operations will result in a runtime error.

but its scope is less than what you have discovered right?

5

Yeah, this was happening within a (span $). I’m using a style class for “meta” messages (from the game system instead of the game itself) and ended up calling (undo) inside one of those spans, which caused the error.