st VS termite

> you need to "edit your makefile". That isn't going to work for distributions

Is it not? [st] requires exactly that. And distros seem to have no issues shipping it.

[st] https://st.suckless.org/

I am fundamentally and ideologically opposed to using a terminal emulator implemented in electron.

If you feel similarly, then you might enjoy https://st.suckless.org/

You can use different forks of the ST. I, for example, use this one, already with the necessary patches https://github.com/mrdotx/st

kiss with kiss-xorg, nsxiv, st, dmenu with script, tewi, fet.sh

My journey of using terminal emulators began together with my introduction to Linux about 7 years ago. GNOME terminal was my first as it came pre-installed on Ubuntu, my first Linux distribution. Since then, I've had the opportunity to explore and utilize a range of terminal emulators, including Alacritty, Kitty, st, Konsole, xterm, and most recently iTerm2. It's been interesting to experiment with these different emulators, each offering its unique features (or similar however with each with personal touch), user interfaces, and performance benchmarks. Just the other day, a new terminal emulator caught my attention: Warp Terminal. My curiosity won, and Warp was downloaded, this short blog are my thoughts about Warp terminal. At the moment there is only support for macOS, however linux and windows builds are on the way.

Terminal : st

For those looking for a minimal VT100 terminal emulator without the legacy baggage of Xterm, I highly recommend checking out Suckless Software’s st: https://st.suckless.org/

That last reference builds off of the work of the other two. It also breaks down how NOT modern Xterm is, but, if I've read it correctly, it confirms that its input latency is low compared to all other tested terminal emulators, including Alacritty and ST, which humorously and justifiably thrashes Xterm on its homepage for being a bloated program. Its not a good choice for everyone: it has poor right-to-left text and Unicode support, making working with Chinese, Arabic, and other alphabets not great, I've read.

ST is a favorite of some fervent minimalists. I do not think you would like it.

- 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.