5 ms·
> xterm is bloated and unmaintainable (...) It has over 65K lines of code and emulates obscure and obsolete terminals you will never need. The way these things
by aartur 12y ago
> xterm is bloated and unmaintainable (...) It has over 65K lines of code and emulates obscure and obsolete terminals you will never need.
The way these things are usually implemented is that there is an interface of a "terminal" and implementations. As long as implementations do not break the abstraction and do not require modifications in the interface and other parts of code these implementations do not decrease internal software quality. They only cause bloatedness in terms of size of source code files which doesn't matter much.
I read something similar on Neovim's site, that they removed support of obsoleted architectures. And as an opposing example it seems that Linux kernel ships with drivers for very old devices and doesn't have plans for removing them.
Note that I don't know if in xterm's or vim's case implementations for obsolete subsystems cause real damage or only increase code size.
And when I was choosing a terminal implementation, I mostly benchmarked scrolling performance and looked at font rendering quality and xterm won. It is also actively maintained outside of Xorg [0].
[0] http://invisible-island.net/xterm/xterm.log.html http://invisible-island.net/xterm/xterm.log.html
- psibi 12y ago> Linux kernel ships with drivers for very old devices and doesn't have plans for removing them. I think as long as there is someone to maintain that driver, it doesn't get removed.
- aartur 12y agoBut if removing them would simplify other parts of code, I think they would do it, like they did for i386 recently.
- systems_glitch 12y agoIndeed, they do remove truly unused architectures and drivers from the kernel -- support for IBM MicroChannel is gone, as well as support for "it was uncommon back then" hardware. I have a bunch of Allied Telesis ISA 10baseFL Ethernet cards that were recently removed.
- not_with_retard 12y agoInteresting, as I too compared scrolling performance, and it was 6x slower than both st and urxvt (as did others in ##c). I suggest trying it again. But I also don't care about font rending, and having my code compile 6x slower is a non-starter, so take from that what you will.