Show HN: Tattoy – a text-based terminal compositor

> The idea of taking a screenshot of the terminal and then parsing that to determine the true colour support is definitely novel,

A better way to do this is to send `OSC 1 0 ; ? ST` (query foreground color), `OSC 1 1 ; ? ST` (background color), then `OSC 4 ; {n} ; ? ST` where {n} is the nth XTerm color.

See: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h4-O...

Thanks for trying it out. It looks like either your terminal or screenshotter isn't faithfully rendering the pure red marker column (it's needed for calibration in the parser). The red should be #ff0000, but the screenshot is using #ea3323. I've made a Github issue to keep track https://github.com/tattoy-org/tattoy/issues/98 If you can add more details it'd really useful, I'm sure there'll be more people like you.

Thank you.

Windows is supported, I've tested it in Windows Terminal and Powershell. I removed it that issue from the release plan because not all the subtasks are finished yet. And more broadly speaking I just haven't had much feedback from Windows users. For example I haven't managed to get GPU passthrough working in my Windows VM so haven't actually been able to test shaders yet.

Yes, every GUI terminal manages its own scrollback buffer. The reason that Tattoy and tmux have their own buffers is because they are essentially terminal emulators themselves. For instance a terminal emulator may have 10 tmux panes and it should of course be possible to view the history of each one. Tattoy manages its own scrollback because that's the only way to make the scrollback available programatically to other processes, like the minimap for example.

Interestingly Alacritty in the beginning didn't natively support scrollback because it wanted to hand-off that concern to multiplexers like tmux. So there's precedent for terminals emulators not having to support scrollback.

tmux should work fine in Tattoy, the only thing to be aware of is that Tattoy would then handle input, like for scrolling etc, so some events may not reach tmux, in which case you could make some custom tmux keybindings that Tattoy doesn't recognise. It's also worth noting that Tattoy recognises the so-called "alternate screen" state that tmux controls its host with. And in such cases Tattoy forwards scrolling events to the underlying process, like say the mouse scroll wheel.

I don't have any light theme examples yet. It should mostly just work though.

How do you mean? I'm actually not a fan of terminal image protocols like Sixel and Kitty's image protocol. I value the constraints of only being able to use text. I feel that in some ways when we venture into real graphics the soul of the terminal is lost.

Intenser flames the more you type, great idea!

Plugins can't currently get the shader pixels. But that's just because I haven't added them to the plugin protocol yet. But interestingly shaders actually have access to the terminal contents in the form of a pixelated version of the text. And the mouse and cursor position too. So maybe there's something you could do purely in a shader.

There is actually a Shadertoy for Doom! https://www.shadertoy.com/view/lldGDr So in theory Tattoy could run it, the only thing is that it doesn't currently support extra buffers and that Doom shader needs 5 of them.