I’d like to revisit this; I’m finding that under heavy use, the pseudo-tty that the Skein is using is failing. If we could get dgdebug to output ANSI via an override command line argument, that would be great.
That seems like a good idea in general. I’m imagining something like --formatting 0 to force no formatting even on a TTY and --formatting 1 to force formatting even on a pipe.
The difficulties are mostly architectural (there’s not really a good way to pass information between the levels of abstraction this requires). I’ll take a crack at it next week probably.
Feels like a global variable in the deep layers. I imagine there’s a is_tty function somewhere. Yes, I’d love to ditch the psuedo-tty, I’m burning through LLM tokens now chasing down a solution and it’s not looking good.
That’s the easy way, but Linus avoided cross-module globals as much as possible, so I’m going to try to refactor a bunch of different configuration options into a struct instead. That way I can just pass the big config struct through the layers instead.
Give this PR a shot and see if it works. The option you’ll want is --formatting=ansi, or just -f ansi.
(Right now the only options for --formatting are default, ansi, and none, so it could also have been two options --formatting and --no-formatting. But this leaves the door open for outputting BBCode or the like, the same way dfrotz does.)
I believe the full suite of options dgt wants will now be dgdebug --no-header --height=-1 --seed=XXXX --dfquirks --tag-lines --transcripting --formatting=ansi. Which is a mouthful for any human to deal with! But I didn’t bother to give some of these options short names, because I don’t expect any human to need them.
If you also happen to use the --quit option, you can shorten this to dgdebug -uDT -s XXXX -f ansi --transcripting, since -u is equivalent to --no-header --height=-1 --quit.
Actually, one thing I should ask about use case.
Color isn’t the only thing affected by running in a terminal. If dgdebug isn’t run in a terminal, it also doesn’t print [more] prompts, doesn’t try to clear the screen with \033c, doesn’t watch for Ctrl-C, and doesn’t print certain messages (the initial header, “Program restarted”, “Press Ctrl-C to interrupt”, things like that).
Are any of these capabilities important to dgdebug?
No, those are all things we actively avoid. Any kind of pagination, or even word-wrapping, is less than ideal. For the Skein, the relevant parts are the text (including ANSI fonts and colors), but not the other evidence of dgdebug being run interactively.
I’ve been getting a lot done on this JFK->PDX flight. In-air wifi 
.
1 Like
Okay, give that PR a shot again. I believe you’ll now only want dgdebug -f ansi -w -1 -DT -s XXXX. No need to specify --no-header or --height=-1 any more.