Using a real VT220 as a terminal in the 21st century certainly violates the principle of least astonishment. Even backwards compatibility should have its limits.
Continually repeating something does not make it true.
The default terminal size is 80 columns by 24 rows. Making an assumption the rows/columns of a terminal are zero is certainly surprising and unreasonable.
Some questions;
Why is fish not determining the defaults from termcap/terminfo?
If you put hardware designed to do the job of a terminal on a serial line, you expect software that is supposed to be command line based to just work (according to the issue in the post it doesn't work with the Linux VT console either)
Furthermore according to a similar issue; a contributor shows their hubris of ignoring terminfo.
> Serial consoles basically date back to the days of hardware terminals, like a physical DEC VT220, when you could trust the information about columns and rows in the terminfo definition.
I can see your point and agree with it: you can connect hardware that speak serial and use it to connect software that speaks VT220. Looking from this point of view, the hardware and software protocols are correctly assigned, everything is perfectly predictable and normal, and therefore this setup should surprise or astonish no one.
At the same time, I have a different point: this approach is definitely NOT in my personal catalogue of ways in which modern shells are interfaced with nowadays. Using an antique VT220 over a breadboard serial adapter is a unique hack, rather than something used every day, and therefore this setup is perfectly capable of surprising and astonishing people.
For me, the above two points of view don't collide with one another.
It's much more common to have a VT220 on a wheeled stand that you can bring over to the rack, with a set of cables already made up. No breadboards! That's amateur hour.
Or, fairly frequently, one VT220 hooked to a serial terminal concentrator that lets you select which of the 32 or 48 machines you want to be connected to.
Or a VT220 emulator in that smart serial terminal concentrator, that's addressable by SSHing in.
Or a VT220 emulator in an IPMI access point directly in each server, that's extremely common. SSH in, then connect to the serial terminal.
Emitting UTF-8 when the settings clearly say "no UTF" is a bug, no matter if a real VT220 is on the other end, or something else that doesn't understand unicode (which is still quite possible, even today). It's even a bug if unicode actually works on the other end (but in that case, nobody notices).
Yes, that's another issue that luckily seems to have been fixed in the linked bugticket.
Still, using antique hardware for interfacing with modern systems is something that would surprise me if I found it used in the wild. I know that the standards are well-defined and that the software support is there - it just certainly isn't the norm.
