chips-test VS termite

I tinkered a bit with sixel support for my "C64 emulator in the terminal" (https://github.com/floooh/docker-c64), but unfortunately it's way too slow to get anywhere near 'realtime' output (30fps or better).

Here's the (abandondend) sixel-version source code, only with two colors, more color planes would drastically reduce the performance.

https://github.com/floooh/chips-test/blob/master/examples/as...

I really wish there was a decent pixel-framebuffer standard for terminals (with at least the same performance as curses). This would allow a lot of fun "terminal applications" (e.g. everything that used to run in VGA Mode 13h).

- you can also rectangular select like in vim, and then press either p (includes LF) or which joins the multiline clipboard text into a single line (removing LF's), that payed off a lot for output like `git status` and wanting to operate on parts of the output (files e.g.)

Have a look at the still young website's documentation here: https://contour-terminal.org/input-modes/#supported-text-obj...

for a more complete look of what you can do with the keyboard (normal mode) :)

[1] https://github.com/thestinger/termite/

Also, regarding VTE, the author of termite (discontinued terminal emulator) expressed similar concerns about the GNOME devs. Apparently, they have little interest in making the library useful to people not working on GNOME apps: https://github.com/thestinger/termite

Termite is obsolete by Alacritty.

I simply do not want to use anything libvte based. And that's what sakura is and termite used to be.

History and experience tells a different story [1]. Never trust a library that is maintained by GNOME.

1.: https://github.com/thestinger/termite

This post by the Termite developer, with respect to VTE, is quite instructive

> https://github.com/thestinger/termite/blob/master/README.rst...

Wow, this confirms a lot of my impressions:

>> In 2012, we submitted a tiny patch exposing the APIs needed for the keyboard text selection, hints mode and other features. Despite support from multiple other projects, the patch was rejected. It's now almost a decade later and no progress has been made. There is no implementation of these kinds of features in VTE and it's unlikely they'll be provided either internally or as flexible APIs. This is the tip of the iceberg when it comes to their hostility towards other projects using VTE as a library. GTK and most of the GNOME project are much of the same. Avoid them and don't make the mistake of thinking their libraries are meant for others to use.

This is exactly why sixel-tmux exists as a separate entity!

> Yeah, I read the entire conversation and if sixel support lands in tmux upstream, it would indeed be good news.

I'll keep my fingers crossed, but right now, there seems to be a lot of good will. I will do everything I can.