There are different schools of thought about what functionality should exist in what layer or what responsibilities should belong to which app. There's a lot of ideological back and forth about it, but for my purposes, fundamentally it comes down to usability and aesthetics. # Conclusion In general I think that a terminal emulator should manage talking to the windowing system and provide cool functionality for apps to hook into from ANSI to Sixels. Multiplexers are faster and cleaner to use and keeps a boatload of code out of the terminal emulator that it doesn't need. [[Terminal Emulator#Wezterm|Wezterm]] is interesting because it seems to ride the line. It is configured with plain text Lua. It uses unobtrusive and text-based UI elements in most cases, and builds in a lot of the navigation styles common to terminal multiplexers. It runs on Windows, Linux,BSD, and Mac. Rust is also available on Haiku and it may be possible to build Wezterm there with some tweaks. # Complaints About Terminal Emulators Managing Subshells In general terminal emulators require that most interaction with them be done via the mouse or obscure keyboard shortcuts. Navigating, arranging, and managing splits and tabs is very mouse-centric and not portable. The UI of most terminal emulators around these same features is unapealing, finicky, and are a poor use of space. More importantly, if you leave this management to a terminal emulator than you are destined to lose all of your tabs and splits and windows if you need to restart your terminal emulator or its windowing host. Some people undoubtable prefer the aesthetic of GUI spits and tabs rather than line drawing characters. I personally think that line drawing characters are timeless and they always match the other characters being displayed, while GUI versions pass through fads and always look out of place. Lastly, terminal emulators tend to have a lot of platform-dependant quirks. Even if the same codebase can run on multiple operating systems, they are going to look and behave differently. A multiplexer is always a multiplexer and if you sync the simple plain text config files, you'll get the exact same experience. Relatedly, terminal emulator configurations are sometimes elusive, hidden, or in binary or XML formats. This makes them less safe to move around from install to install. Whereas my tmux configuration - even with some of the deprecated or even removed features still left in my config - is still working fine after many years with minimal effort on my part. In a lot of situations you only need a single instance of your shell in a window. Why have all that other code?? Then drop in a multiplexer to opt into it. And if you're going to SSH into a remote server and want to manage multiple programs over there? Yeah, terminal emulators aren't able to do that. # The Case for Terminal Emulators Obviously terminal emulators are great for what I need of them: - rendering text, sometimes with multiple fallback fonts - rendering colors, with sometimes inaccurate but fun color palletes - clicking text URLs to open a browser - do fun things with images, sound, effects, and animation if desired But besides that, they can use keyboard shortcuts that terminal programs generally do not (terminal emulators usually do not send the meta/super/hyper or other extended modifiers to the console programs). They have the ability to natively interact with the windowing system and clipboard with no intermediaries. This also allows them to freely move tabs and panes between windows. They typically have the concept of profiles built in, while multiplexers do not and adding this kind of functionality is often a pain. Terminal emulators can.... emulate different terminals. Although this is not a feature I often use, it could be very useful to some.