I thought it might be useful to have a separate thread to discuss some problems I’m having with Dialog that should maybe be fixed in the dgdebug or the standard library.
I’m having a problem with styling; the default (style class @meta) enables italics. The problem is that the way we read the output from dgdebug, the italic ANSI style is still “open” at the end of the output.
The end result is that, in the saved skein, knots that appear after (for example) the game over text are still in italics.
Ideally, there would be an SGR 0 m reset before the final carriage return, rather than after (before the >).
I’ll look into fixing this on the Skein side as part of post-processing the text captured from dgdebug.
Is it safe to assume that every new bit of command output will start from plain text and add new styles on top of that?
Theoretically, I don’t think that’s a safe assumption: it’s possible to (get input $) inside an arbitrary div. Practically, I don’t believe the standard library ever does that. If it happens, though, I could make dgdebug re-send the ANSI codes after every input.
For the specific case of the meta div not being closed before the final line break, I’m guessing it’s a problem because that line break and > are being stripped out by dgt? In the general case, styles have to be preserved until after the bottom margin is printed, in case of a background-color; but dgdebug doesn’t currently support that property.
I’ve only been following loosely, but it seems like it’s been a bit of a boondoggle trying to capture all the metadata from the terminal output, which is inherently encoded.
I wonder if it would make sense to use a z-machine that has remglk output? That has clearly delimited styles, and reading a newline would be explicit…
dgdebug can link with a Glk library, so that part wouldn’t be too hard; but Glk also has extremely limited support for styling, far less than even dumbfrotz.
Thinking on it a bit more, I think I’d propose the following:
After each input, dgdebug will reset all styles, then set the style it wants. This means you can safely assume the text after each input starts style-less, and don’t need to preserve style across inputs.
But, dgt should also not discard the last line of output before input is requested. Normally this is a simple >, but it could also be something like yes/no> or 1-20> or [press any key], and that would be good to keep in the Skein output. This line is also where dgdebug resets the style from a previous div, as a side benefit.
Implemented in #190, which I’ll merge later this week if nobody raises objections. I try to leave all PRs open for a week in case anyone wants to check them.
Color and background color support for dgdebug (named colors only: “green”, not “#00ff00”) is on the agenda, though it’s been a lower priority since I wasn’t sure if there was any real demand. But it sounds like it would be good for the unit testing framework.
Yeah, I abandoned a PR to update unit.dg to do exactly that because dgdebug didn’t support it yet, and I didn’t want to go down that rabbit hole.
On the subject of unit tests, having a way to run a suite of them when firing up the Skein would be a nice-to-have. I’ve been using <foo>-tests.dg as a convention for the tests I’ve been writing, with a command line specifying which files to include and in what order in a comment on line 1 of each test file, or the tool could look at the Makefile or run make.
It won’t be too hard to add; just tedious, which is why I’ve been putting it off. (Style class information gets passed through a half dozen layers of indirection before reaching stdout, and all those layers have to be adjusted to pass three values instead of one.) But if it’s a feature multiple people want, I’ll see about putting it in this weekend or thereabouts.
I’ve also considered making aamrun handle basic styling, but that might wait until aamrun has actually come out, and we can see how much people actually use it.
