Why do terminal emulators still need to emulate specific, old terminals?

Question

I more or less understand the distinction between what is called a "terminal" and a "terminal emulator". The former referring to an actual hardware peripheral connected to something like a mainframe computer to interface with it textually, and the latter being a piece of software that allows to do the same thing, but just in software and not with actual hardware.

I also gathered that nowadays, terminal emulators in fact emulate the way that these old terminals (like the popular VT100) sent keycodes to the computer, pretending to be them so-to-speak. But in the course of doing some troubleshooting and config on my Linux system, and encountering the odd and somewhat annoying quirks that made me ponder all this, I did some research and found that those devices almost exclusively used a keyboard to interact with the computer (I can't imagine that the mouse was created early enough for these sorts of terminals to support them), and because they belonged to the early era of computing, these keyboards were significantly different to the ones we usually encounter today, and have largely been standardized.

Why am I pointing this out? Well, things like function keys, or caps-lock and num-lock were not usually encountered on a lot of terminals back then (at least I know that function keys are a relatively recent features of keyboards). Because terminal emulators emulate these terminals, they have to use workarounds to be able to support these keys, like sending special escape sequences. In my experience, this makes dealing with the keyboard and the way that the terminal emulator handles it a lot more complicated than it should probably be (at least, that's how it seems to me).

In fact, I started pondering all of this when trying to figure out why trying to define keyboard shortcuts involving function keys above F4 didn't work on some terminal emulators, and why pressing such a function key inside a lot of terminal emulators (at least all the ones I've had any experience with) input a '~' on the command-line. (It's because these keys send escape sequences instead of dedicated keycodes since the terminals that are being emulated did not have function keys, and either they are not properly recognised or something, or the '~' that ends the escape sequence is interpreted as an actual character that the user typed.)

I mean, why do we have to emulate these ancient terminal devices that don't even exist anymore (at least that I know of) in the first place? I get that we need software to allow users to interface with the computer with a keyboard to input commands, and therefore to "emulate a terminal", but what benefit is there for a terminal emulator to still pretend to be one of these devices, whose capabilities were substantially different from that of modern keyboard interfaces, and lacking in some regards when compared to modern keyboards? Unless I am missing something, it seems to me inappropriate to do so given that modern devices have evolved in capabilities and features since these terminals.

It also seems like unnecessary complexity: why not consider the keyboard to just be something as simple as a panel of buttons which all send a specific standard keycode to the computer, instead of dealing with escape sequences to represent keys that didn't exist decades ago? If there was still a major need to support these old terminals I would probably understand, but I can't imagine that they are still so widely used that this is still a concern. Why is the combination of a computer's monitor and keyboard not considered a terminal in its own right, and why don't we define a way for a terminal emulator to send text to a computer that doesn't rely on how old terminals did it, and takes into account how computer interfaces have changed since then?

Answer 1

It's because these keys send escape sequences instead of dedicated keycodes since the terminals that are being emulated did not have function keys

No. It's because the "terminal" protocol uses in-band signalling, where every byte is considered to be text by default and anything that isn't text has to be indicated specially (i.e. escaped), which inherently means keycodes are "escape sequences". In other words, the escape sequences are dedicated keycodes.

It is not that modern terminal emulators have invented the concept of escape sequences to do things that original terminals could not. Rather, those terminals had already invented escape sequences to do things teletypes could not – e.g. VT100 did have PF1–PF4 function keys, and their "keycodes" were in fact the \e[P…\e[S escape sequences. And similarly, programs used "VT100 escape sequence" to control the physical terminal's behavior (cursor movement, text appearance, etc.)

Why is the combination of a computer's monitor and keyboard not considered a terminal in its own right, and why don't we define a way for a terminal emulator to send text to a computer that doesn't rely on how old terminals did it, and takes into account how computer interfaces have changed since then?

This already exists. That's how X11 works. It's also how Wayland works. As does the underlying Linux input and graphics API (evdev & drm), or the graphical applications in Windows, in macOS, in AmigaOS, in SunView, and so forth. All of those UI systems have APIs for creating applications that aren't relying on a single thing about "how old terminals did it".

Indeed there have been quite a few attempts to create command-shell interfaces that aren't bound to the character-cell format (on top of various APIs ranging from X11 to HTML5), but despite looking really fancy they just don't see much adoption.

The issue is that the purpose of a terminal emulator isn't just "to send text", its purpose is explicitly to send text the way VT100 and other such terminals did it, just like the purpose of a web browser is specifically to handle HTML. At this point, the VT100 terminal protocol is one of those universal cross-platform interfaces that remain widespread because of how widespread they are.

The "Console" in Windows NT was not based around VT-style terminal emulation at all – it used out-of-band Win32 API calls for things like changing colors, receiving mouse clicks, etc. And yet, in Windows 10 it eventually started behaving like a VT terminal. (In fact all the original Win32 Console API functions are now marked as "deprecated".)

The "Plan 9 from Bell Labs" OS also had a windowing system with console windows that didn't support any escape codes at all; if a program wanted to do something fancy, it would enter graphical mode directly within the same window. For example, its text editors Sam and acme had a mostly textual UI but without any of the constraints that a terminal-based UI normally has. (Plan 9 did ship a dedicated "VT emulator" app for interfacing with other operating systems.)

I get that we need software to allow users to interface with the computer with a keyboard to input commands, and therefore to "emulate a terminal", but what benefit is there for a terminal emulator to still pretend to be one of these devices, whose capabilities were substantially different from that of modern keyboard interfaces, and lacking in some regards when compared to modern keyboards?

As mentioned before – the terminal emulator acts as an interface to a massive existing ecosystem of software and hardware that speak the VT100-like terminal protocol.

The protocol is extensible; after all it did eventually gain color support (first 8-color then 256-color then 16M truecolor) and mouse support, neither of which were originally present in VT100 (now it's more often called the "Xterm" protocol rather than "VT100"), and programs like Terminology or Kitty even have extensions for displaying inline images, hyperlinks, interactive buttons, etc.