FFmpeg-SIXEL

any format whatsoever (sixel, kitty...) was supported by a console IDE; we could then argue about the ideal format. Arguing about the ideal format BEFORE letting the ecosystem grow using whatever solution there is only results in a negative loop. It's like if a startup was arguing about the ideal technological stack even before trying to find a product market fit!! Personally, I do not care much about sixels, kitty or iterm format - all I want is to see some kind of support for a format that's popular enough for tools using it to emerge. Yes, it would be better if that supported format was the option that had the greatest chance of succeeding, but right now, that is a very remote concern: first we need tools, then if in the worst case they are for a "bad" format, we can write transcoders to whatever format people prefer! Right now, there is rarely any "input" to transcode (how many console tools support say iTerm format?), so we have a much bigger bootstrapping problem. > an off the shelf ASCII plotting library probably involves less custom tooling With a terminal like msys2 or xterm, no custom tooling is required: just use the regular gnuplot after doing the export for the desired resolution, font, and font size. gnuplot is far more standard than plotting library that often require special Unicode fonts on top of requiring you to use their specific format.