I like how this bug report captures how much we've lost :-).
Basically the bug is that VT220's are not UTF-8 capable display devices. What is worse, when you send them UTF-8 sequences they interpret them as VT200 sequences and as a result oddness can and does occur. I haven't tried fuzzing one of my VTxxx terminals but I suspect there are likely cases where you can hang the terminal with the right character sequences.
Of course, most people, perhaps > 80%, working on open source maintenance have never actually touched a terminal. Many have lost any idea of what "TERMCAP" is, or the difference between "Smart" and "dumb" terminals, and what escape codes do what. For most, "terminal" is a program that runs and always responds in a way you would expect it to respond (which is typically a variant of ANSI terminal specs). Not that they have ever tried to get their shell to run on a Beehive or Hazeltine or Adds terminal either.
At one of the west coast vintage computer festivals I had a VT320 connected to a Linux box and the younger adults there who played around with it were appalled at both the lack of colors ("How do you know what files are directories?") and the pitiful number of lines and columns ("I feel like I am inside a coat closet!") It was funny, and sad. Sad because my memories of how great it was to have a terminal that could do line insert so when editing files over a 1200 baud modem it still felt fast, were now pitiable.
> Basically the bug is that VT220's are not UTF-8 capable display devices.
This was not the bug. I suspect that you didn't get the end, and I don't blame you. The bug was that the terminal reported zero rows and columns. A "simple" stty command made it work.
Thanks! So two years after it was filed, and a year after it was closed, another user figures out on a different bug that the Linux psuedo device initializes size to 0, 0? That is super odd.
What is more odd, is that the number of lines and columns are in both the termcap file and the terminfo database for the vt220, and in the bug the user said they had set TERM to be vt220, which if you do an infocmp after setting will show you it is a 24 line x 80 column terminal. And yet the user krader1961 has them going through a stty command to set the values to 24 x 80? That "fix" just raises more questions than it answers. Why doesn't stty respect termcap/terminfo? Why does fish see 0,0, and what is going on with terminal support in general?
`ls -F` helps with this on terminals without color.
> "I feel like I am inside a coat closet!"
Some terminals do offer higher character resolutions than 80-by-25.
> Sad because my memories of how great it was to have a terminal that could do line insert so when editing files over a 1200 baud modem it still felt fast, were now pitiable.
I use a terminal on a somewhat regular basis (an IBM 3151 emulating a VT100, connected to a Raspberry Pi running FreeBSD).
It can be a great tool for learning Unix command line fundamentals thoroughly (a prime example of blub studies [1]), and as you get comfortable with it, you might find it useful for deep work (George R.R. Martin's use of WordStar 4.0 on DOS [2] is a famous example of modern-day usage of text-mode computing, which isn't the same as using a hardware terminal on a Unix machine, but close enough in spirit).
The caveat is that it does require patience and commitment to the process, which is tough when more convenient and capable user interfaces exist. Oftentimes I'll look up documentation on my phone while using the terminal, since it's simply more convenient than trying to navigate through modern websites on a text-mode browser.
Yeah I remember those green phosphor ones that we had in one of our computing centers on the campus. Alongside them there were pure IBM X Windows terminals, connected to a DG/UX server.
On a similar note I find similar lack of experience understanding what is possible with something like ESP32, given the computing power we had at the early 80's, and the polyglot environments that were already available back then.
Basically the bug is that VT220's are not UTF-8 capable display devices. What is worse, when you send them UTF-8 sequences they interpret them as VT200 sequences and as a result oddness can and does occur. I haven't tried fuzzing one of my VTxxx terminals but I suspect there are likely cases where you can hang the terminal with the right character sequences.
Of course, most people, perhaps > 80%, working on open source maintenance have never actually touched a terminal. Many have lost any idea of what "TERMCAP" is, or the difference between "Smart" and "dumb" terminals, and what escape codes do what. For most, "terminal" is a program that runs and always responds in a way you would expect it to respond (which is typically a variant of ANSI terminal specs). Not that they have ever tried to get their shell to run on a Beehive or Hazeltine or Adds terminal either.
At one of the west coast vintage computer festivals I had a VT320 connected to a Linux box and the younger adults there who played around with it were appalled at both the lack of colors ("How do you know what files are directories?") and the pitiful number of lines and columns ("I feel like I am inside a coat closet!") It was funny, and sad. Sad because my memories of how great it was to have a terminal that could do line insert so when editing files over a 1200 baud modem it still felt fast, were now pitiable.