<jo...@armadilloaerospace.com> wrote: > Related, I looked through the xterm code to see how hard it would > be to use some of it directly in the wscons system for accurate > emulation, and it looked pretty challenging to me. Fixing problems > piecemeal is probably easier than trying to reuse code.
It was obvious 25-30 years ago to choose vt220 as the what-to-emulate. In those days, there were still a lot of proprietary unix systems, and their termcaps were not being updated, so the "pccons" hackjob was highly inconvient when ssh'ing between machines. So vt220 was an easier choice. Highly compatible with the various termcap generations on those proprietary operating systems; most of their termcaps were quite restricted in what they said a vt220 was, so it worked well. Most of the architectures therefore got vt220 emulation, but since Torek's sparc code had early "sun" terminal emulation, the code also grew the option of servicing that emulation instead. It was convenient. Likewise, the "sun" termcap entry was high-quality on proprietary operating systems. Nowadays, if xterm emulation was the target (instead), it would be more suitable than either choice. Highly desireable in my mind. Imagine if /etc/ttys was "xterm" on all systems. I believe it only needs to be a fairly minimal emulation, with tty size issues are handled TIOCGWINSZ. After all, the vt220 emulation we have is already a hackjob. It has misbehaving features, the 24 vs 25 line issue, enhancements which are incompatible with a real vt220, gaps in emulating obscure features noone wants, and colour support which isn't really standard. >From a risk perspective, unless something is 100% compatible, and accepts nothing else as input, it isn't compatible and there are risks introduced because it behaves different from the real thing. We never seem to get close to perfect emulation. Just perfect enough to match termcap...
