Anyway. Is there something better than just screen-shotting your terminal window and making PNGs or GIFs for stuff like this?
Anyway. Is there something better than just screen-shotting your terminal window and making PNGs or GIFs for stuff like this?
There are some long standing bugs against the aha tool pointing out that it does not even come close; including not coping with switching to and from the alternate display buffer. No-one seems to have yet noticed that it doesn't recognize ED or EL or any relative cursor motions, so will have serious problems with things like ZLE in the Z shell, or just plain clearing the screen; or that it doesn't handle 24-bit colour in the same ways as some popular terminal emulators do.
Screenshotting would involve reading a Linux KVT /dev/vcsa file, or a display file with my terminal emulator, or using a Kitty plug-in to get at its display buffer contents, or attaching to a screen/tmux server and reading out its display, or similar (if even possible) for other terminal emulators.
Ironically, BRLTTY can do some of the aforementioned. But it most certainly doesn't spit out HTML.
Still image: https://github.com/nbedos/termtosvg (dead, unknown if usable?)
This is why it was such a struggle for me to get through Godel, Escher, Bach as well. If I'm engaged on the topic, I want the author to get straight to the point, not to try to anticipate my questions or lead me with someone else's potted questions.
> Anyway. Is there something better than just screen-shotting your terminal window and making PNGs or GIFs for stuff like this?
I've done it manually in HTML/CSS for documentation, to preserve copy-pasteability. It's straightforward: body bgcolor, and font-family (something fixed width), then a bunch of spans with colors for syntax highlighting.
Would love to find something automatic though! E.g.:
command | ttyansi2htmlcss | pbcopyThanks for the link!
There is and it's been on my TODO list forever. In fact, the article you just read (congrats on getting through my narrative devices) was written /while tackling that/.
https://asciinema.org does it for "moving pictures", it shouldn't be too hard to do it for stills.
I’ve come to appreciate “dry”, technical guides void of overt personality. I’m not a fan of “Why_’s Poignant Guide to Ruby” in the least, but there is a visceral element in its whimsicalness (and other why_ materially) that similar efforts don’t compare to (I count the listed guide here among this). For me, why_’s work is an outlier in this “literary tech writing” genre. If I ever intended to learn the language, I would contemplate scrubbing out the comic strips if I couldn’t find a better alternative guide.
I think that style could work well when you're doing say a post-mortem of some failure, where you want to show the whole train of thought that lead to it or to finding a fix, but for this kind it just doesn't work very well
I guess I’m getting too old for this - I’m leaving this to the younger crowd !