0

Backstory (You can skip)

Awhile back I was developing a console toolkit for displaying debug messages and the like: enter image description here It gives me colour coding, blinking, underlines, bold, italic, etc.

While developing this library, I quickly learned that nesting with ANSI escape sequences was impossible, but assumed that good reasons existed why this was the case.

Of course working with other document types, nesting is more or less trivial:

<foo> the <bar> quick </bar> brown </foo>

or with JSON

{
        type=foo,
        text=[
                "the",
                {type=bar, text="quick",},
                "brown",
        ]
}

But with Ansi, its something like this:

\e[1m the \e[2m quick \e[1m brown

giving an output like this:

enter image description here

Basically meaning that you would need to manually track the formatting, and explicitly construct escape sequences to represent all output moving forward. You can obviously make due, but it complicates things. Before complaining about this, I'd like to clarify what reasons exist that would necessitate an escape sequence model over say, a structured document style.

Questions:

Is it purely due to legacy reasons why displaying text on our video terminals is done with ANSI escape sequences and not another framework such as JSON, Yaml, XML, or something else?

Is ANSI escape sequences in video terminal, simply an old technology similar to say, X11 that sticks around solely due to how embedded it is within the computing paradigm?

If not, why don't developers switch from an escape sequence style to something that would support nesting?

Are there any proposals to do away with ANSI escapes in terminals and replace it with something else?

  • 4
    In short: backwards compatibility. ANSI escape codes is a widely accepted standard, much older than JSON, XML or even HTML. If devs today wants to displaying fancy coloured text or tables using a hierarchical description language, they can utilize a web browser for this. – Doc Brown Jun 13 '19 at 13:33
  • 3
    I'm with Doc Brown. It's an old standard, and you follow it because it's the standard. If the standard doesn't meet your needs, you use something else like a web browser. We can cogitate over the relative merits of the standard, but it is what it is. – Robert Harvey Jun 13 '19 at 14:29
  • 4
    We did mention this is an old standard, right? The creators of the standard were not thinking about nesting when they created the standard; they merely needed a simple way to mark text for highlighting. – Robert Harvey Jun 13 '19 at 14:36
  • 4
    If your real question is "why is this ANSI escape style still so popular today," my answer is "it isn't." – Robert Harvey Jun 13 '19 at 15:37
  • 3
    @DavidArno: Time to take it to meta. – Robert Harvey Jun 13 '19 at 16:44
4

There is a simple reason. When you are typing you can only input a character at a time.

Something that is processing typed text has to deal with what in effect is invalid markup, half a json blob or half an xml document. You can't display "error" until the typing has finished and then display the result. You have to have a format where partial documents are valid and already input data wont change due to additions.

| improve this answer | |
  • So why not use a buffer then? Or conversely, have the interpreter make due with partial documents until a fuller representation is given? Given the partial information <foo> quick you can at the very least, assume, <foo> quick </foo> until you get <foo> quick <bar> brown </bar> </foo>. – Akiva Jun 13 '19 at 14:04
  • 1
    that would require you to reprocess the whole string when a character was added. Given that some escape sequences move the cursor that might be problematic. What it's doing is processing each character (or escape sequence) as a stand alone command. Much like a type writer, is the bold key down or up? I don't go back to the start of the document and work my way through counting open closures. I just look at the key – Ewan Jun 13 '19 at 14:32
  • Hmmm, that is an interesting way to look at terminals, effectively being a virtual bufferless typewriter, which of course would require this style. The only lingering question for me then is, what necessitates us today to have such a device today? What functionality do I gain from this? – Akiva Jun 13 '19 at 14:57
  • 2
    Well, you can't get away from the fact that its design comes from an age before the mouse. The way we use computers has drastically changed and perhaps it has no value anymore. However, an emacs or vi user would disagree.. perhaps violently! – Ewan Jun 13 '19 at 15:01
  • 1
    @Akiva, the main remaining "necessity" for consoles is embedded systems that cannot support the overhead of anything more, and also integration with legacy systems and tools. When I say legacy, I don't necessarily mean defunct, but I mean old systems that are widely available, whose workings are well understood, and whose simplicity and refinement is often still very adequate. For example, the Windows command line interpreter and batch files. – Steve Jun 14 '19 at 13:01
6

Your question is sort of like saying assembly is difficult to work with, so computers should use higher level languages instead. The ANSI format is the right level of abstraction for working with terminal hardware. You have to do the state tracking somewhere, and it's best to not do it in hardware that needs to be as cheap as possible. Even in modern hardware, some library at some point has to do the state tracking level of abstraction.

When you want something easier for a human to use, you use higher-level abstractions that have been around forever. Even something like nroff is a big improvement, and I'm sure you can find libraries and/or utilities for all the markup formats you described.

| improve this answer | |
  • Your question is sort of like saying assembly is difficult to work with, so computers should use higher level languages instead. Two issues with this statement: In one sense, we still all work with assembly, but rather our assembly is abstracted out of higher level code. We should rely on say, c++ generated assembly rather than writing straight assembly, for the sake of time, optimization, and stability. Also, computers don't use terminals, human's do, so it isn't obvious to me why ANSI means good for computers while JSON is bad for computers, when tracking happens regardless. – Akiva Jun 13 '19 at 14:17
  • 2
    @Akiva It's actually a brilliant metaphor. Are we using x86 compatible instruction sets because it is so awesome? No, it's an objectively awful assembler language/instruction set for modern computers. We just keep using the x86 architecture because it has a ginormous ecosystem of software that assumes it. Similarly, we keep using ANSI-compatible emulators because we keep using software that needs ANSI escape codes. But unlike with instruction sets, there's no strong reason to switch away from terminals. As Karl mentions, there already are abstraction layers for formatting like nroff. – amon Jun 13 '19 at 15:13
  • Salient point, but now you have me wondering whether the myth of the awful x86 instruction sets actually pasts muster. – Akiva Jun 13 '19 at 15:31
  • 2
    @Akiva: by googling a little bit around, I found this C#/.NET lib, which seems to support exactly what Karl Bielefeld suggested for your case: a XAML renderer for ANSI terminals. Since it is compatible to .Net standard, it should work on Linux terminals as well (but I did not try it out by myself). – Doc Brown Jun 15 '19 at 6:22
  • @DocBrown: That is very cool. – Robert Harvey Jun 15 '19 at 23:28

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