1

In wondering about math fonts in the terminal, I started to realize that you can't really have pixel-perfect graphics in the terminal:

The terminal also has weird features in that you have to use ansi escape sequences to change colors and move the cursor around and such (in the cells) in the terminal.

I am wondering why these decisions were made for the terminal. Why the terminals seem to have such limitations as everything being done with ansi escape sequences, divided into lines and cells for characters rather than pixels, limit to only a small color range, strange event handling with the mouse using ncurses, etc. I understand that early computers had limits of colors, so they might've been limited to 8 colors (or even just 2 colors black and white, or black and green or whatever). But that was because of the lack of technology at the time. Now modern terminals have at least 256 color support, with some having true color support (like 16 million colors). Some even allow you to have images in them now, so it's almost at the point of being pixel-perfect in some cases. This thing even allows you to display PDFs in the terminal (seems like this is because of sixels).

Wondering if these decisions were made because it would have been a problem in some way to make such a "terminal" application using pixel-level manipulation, and other things, like the browser. That is, wondering if there is a reason why the terminal application shouldn't just be the same capabilities like a browser, at least rendering and interaction wise.

Eventually terminals started to need to have complicated UIs more than just basically logs of text. So you get things like this or this (first two images below). Now you're getting terminals that have full graphics support, so they're basically like desktops or browsers (last image below). So I'm just wondering why these limitations are placed on the terminal essentially.

enter image description here enter image description here enter image description here

Improve this question
0

2 Answers 2

Reset to default
7

Because terminal emulators are provided to accommodate a simple style of human-computer communication, the command line, which remains extremely useful in some contexts.

Back when the command line and hardware terminals was all we had, it was clear that they were awfully limited for some contexts. Folks began to push their capabilities, giving us ANSI, ncurses, and eventually crude windowing and graphics systems as pictured in your first two examples. In parallel to that effort, actual pixel addressable, GUI systems began to slowly populate the world, because those terminal based windowing packages were clever, but still hopelessly inadequate for many needs. Eventually pixel addressable graphics systems took over the world.

However, the software API to manipulate GUI systems are far more complex then the API needed to display text messages in a fixed character set, on a fixed dimension screen, on a hardware terminal. Folks wanted their old software to keep running, and for their new software they didn't want to have to write a 300 line function, specifying window handles, font handles, bitblits, and manipulating overlapping rectangles, just to print a log message on the screen. So, one of the first things the GUI developers did was to write terminal emulators that allowed programs to pretend that they were still talking to 80x25, fixed character set, hardware terminals. All the old programs still work, and those of us writing new programs for the command line aren't burdened with learning a lot of new API that are irrelevant to our goals. Bells and whistles have been added, but that's still the essential role for terminal emulators.

If you need pixel level graphics and image support, you simply do that in an application written for the host windowing system or in Javascript in a browser. There is no need to add that capability to the terminal (other than perversity/curiosity).

Why the terminals seem to have such limitations as everything being done with ansi escape sequences, divided into lines and cells for characters

Most of the computers in wide use from the 60's through the early 80's communicated with their terminals via serial interfaces and many displayed their output on paper. Video terminals didn't become widespread until the late 70's, and those had very limited memory. Back in the day we used to distinguish between "dumb terminals" that essentially implemented the same interface as paper (print at the current position and scroll down were the only commands), and "smart terminals" that allowed things like line and column cursor positioning.

Improve this answer
2
  • 1
    Wow this makes a lot of sense. Thank you. I like the insight about how people perceived it when new technologies came out, makes sense. So basically, we still want old programs (like a unix command) which might rely on ansi escape sequences (for example) to run on modern terminals, which is why they are based on that technology.
    – Lance
    Jul 23, 2018 at 0:10
  • Thanks for expanding this into a great answer. It is worth noting that there's a kind of API known as "Rich Text" of which the API complexity is in between terminal (text-based interface) and fully enabled GUI (with interactive graphical manipulation). Rich Text can be used in "append-only" fashion, where old content are scrolled up into a buffer and new content appears at the bottom. This kind of API seems to match what Lance Pollard is looking for.
    – rwong
    Jul 23, 2018 at 8:24
1

It worth noting that the X Window system, which is still used as GUI for linux, was just designed as solution for letting programs show graphics remotely. So it is basically the graphical terminal you are looking for. It uses primitives like text as well as images.

This approach, however, starts being slow as there is a need for video and 3d graphics. So modern implementations use extensions to let local programs output without using the remote protocol. Also, it is lagging behind in term of features, so popular GUI frameworks have switched from using the X primitives to just drawing all their widgets to a single canvas which is sent to graphics as a bulk. This made remote usage prohibitively slow.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.