Why do people care so much about terminal emulators and their supposed "bloat" and "complexity"?
I really like VTE's behaviour; even if the performance is a bit worse than XTerm (though worlds ahead of what I've seen on OSX with iTerm2 and Terminal.app). I rely on using iBus input methods in the terminal on a daily basis, and VTE handles this wonderfully.
I just wish I could log the scrollback buffer so that I could open an actual editor on it, but I don't think libvte exposes anything to do this.
I can imagine there could be bugs in esoteric terminal emulation, but for the typical use case of "TERM=xterm-256color" (or screen-256color) it works perfectly for my use case.
We hack so much into a text interface it's really easy to accumulate bugs.
I rarely (never?) see any "terminal glitching" except for the cases where I've done something absurdly wrong, like running a bash inside emacs-shell with the wrong setting for TERM.
Terminal emulation is essentially a solved problem (state machines and control code sets are small and well defined, there are many reference implementations and compatibility tests). If you see glitching, it's probably from what you're doing inside the terminal, not from the terminal itself.
xterm is a de facto standard, in that you can sit down in front of a machine which appears to be running some flavour of Unix, it doesn't matter if it's Gnome, KDE, TWM, CDE, etc., GNU or BSD or Solaris or whatever, you'll probably be able to find xterm and work out the rest from there.
Many devs/hackers use xterm as their day-to-day terminal, and seem to approximate ANSI control code compliance with "works in xterm".
The problem with this situation, as mentioned on the st page, is that xterm is unmaintained and unmaintainable.
st is trying to be a maintainable replacement, making improvements like vector fonts, and not being shy about ignoring legacy/niche/solved-elsewhere features.
- xterm is for exactly the case you describe: when all you have is "base X11" and you need a terminal. No crazy multi-gigabyte toolkit requirements. Its essentially a fallback/recovery tool for these cases, although I prefer just working on console when things get that bad.
- xterm's codebase is 30+ years old. "unmaintainable" seems like an overstatement, by a longshot.
This appears to be true (from other comments on terminal performance in this thread) but other VTE-based terminals (gnome-terminal) have high performance and work great on sub-1GHz class machines.