what I need out of a unix terminal emulator
the unix terminal as it exists does two things and does them poorly.
- CLIs
- GUIs
the ideal terminal for the ideal operating system would only support CLIs. this can be seen in the plan 9 operating system; the rio terminal does CLIs only, and it does them fairly well. upon running a GUI program, it seamlessly takes over the window it was run from, able to render full bitmap graphics; the terminal is not involved.
I very much dislike most GUI programs, certainly not because GUIs are bad, but I find their implementation at large to be intolerable. some of this is just my preferences (for instance, I prefer frill-less keyboard-oriented software), but I also think that many GUIs objectively (in some sense) fail to be useful, implementing ineffective or even outright hostile design. and I definitely think that the toolkits widely used to make them are awful, bloated, and absolutely full of issues.
I use a few GUI programs that run in the terminal (TUI). I would prefer applications which would, instead of the terminal, use means of GUI that is good, but such a thing doesn’t seem to exist. so, although it is not ideal in many ways, I continue to use these applications as I personally find them to be the most tolerable available options.
the application of the terminal that I value the most is CLI programs. I find CLIs to be very powerful and prefer the CLI for many tasks. one could in theory use a non-ANSI plaintext terminal to run CLI programs, like the plan 9 terminal, which has in fact been ported to linux. but some of those programs do expect some ANSI features, and I often find them very useful. my shell uses them for advanced completion, history search, and even syntax highlighting. ideally, this responsibility would be handled in a different way, but the ideal does not exist.
all of this said, what this means is that I need to use a unix terminal. I presently use a terminal emulator that shall not be named, and I mostly use it for what it doesn’t have. it is utterly frill-less, which is what I desire. however, it is poorly designed, stubbornly lacks features that are actually useful, and apparently is made by nazis. all-in-all, I would not recommend it.
here is what I need out of a terminal emulator:
- no GTK, no Qt, no useless menu bars or GUI elements
- utterly low memory usage. no idle CPU usage. I should be able to open a hundred windows with no problem whatsoever.
- it should be almost scarily good at text rendering. text rendering is a very hard problem, and it’s not really fully solvable for the unix terminal, which requires everything to adhere to a grid (fundamentally incompatible with certain languages). that said, there are degrees to which you can do this well enough, and I would like it to be done as well as possible. for any unicode that it is thrown at it, it should render it as sensibly as it possibly could be rendered to a grid.
- it should be very good at being a terminal emulator. it should have scrolling, text rewrapping, etc.
- it should have no features beyond what is necessary to implement a good terminal emulator. it should be a very minimal piece of software.
the closest thing to meeting these requirements is probably foot. I don’t use wayland at this time, however, so foot is not an option for me. at some point, I’ll make the switch to wayland, and I’ll likely use it. I hope that someday there will be something practical to use that isn’t the unix terminal, but at this time, at least for me, nothing qualifies.
update 2024-04-08: I am now using sway (wayland compositor) and foot. foot is a vastly superior unix terminal emulator to the one I was using before. the text rewrapping is quite nice; I can resize a window without losing all of the text that was covered up. this is good, since I resize windows a lot. I toggle in/out of fullscreen frequently to direct my focus to things.