Документ взят из кэша поисковой машины. Адрес оригинального документа : http://hea-www.harvard.edu/~fine/opinions/xterm-problems.html
Дата изменения: Unknown
Дата индексирования: Sun Apr 10 10:29:09 2016
Кодировка:
Поисковые слова: interferometry
xterm compatibility problems September, 2008

xterm compatibility problems

The root of the problem is that people are morons, more particularly, developers are morons, very particularly, xterm developers are morons. The ideal solution would be to round up the developers responsible for "enhancing" xterms in recent years, line them all up, bend them all over, and have at it.

Why so bitter? Because the fucking morons that "enhanced" xterm committed the cardinal sin of software development - they introduced incompatible changes into xterm while pretending like they're perfectly compatible. So people that have settings for years that have worked with xterms find that they no longer work with xterms.

In fairness, it's not really the xterm that's incompatible, it's the xterm descriptions that ship with modern operating systems that are incompatible with older xterms. But that's a ridiculous dodge. The developers had to know that people would actually USE the cool new features they put into xterms. And by so doing, create termcap/terminfo descriptions that are not compatible. Old xterm descriptions are compatible with new xterms but not vice-versa. In other words, these morons created a system that when put into use would be forward-compatible, not backward-compatible. It's insane.

Let me be clear - creating a new terminal is great, but it should never have been called an xterm. Now when I log in from an old system to a new system, and my TERM variable is forwarded, suddenly "xterm" is wrong, even though it was right on the original system, and I have to tell the new system that my terminal is actually an "xterm-r6" (even though there IS no such thing). But I can't automate that, because if I'm coming from a new system, I may want those new features, and there's no automated way to differentiate.

Assholes!

The new xterm shoulda been "xtermplus" or something. Die, die, die you idiots. Die and go to hell and spend all of eternity using incompatible xterms.

Symptom: command-line editing does not properly redraw the line.

The feature that was added is horizontal cursor positioning within a single line. Newer xterms have it, older xterms don't. Newer xterm descriptions in termcap and terminfo describe it, so when you tell the newer system that you have an xterm (which you DO!), it thinks you have a NEW xterm (which you don't), and command-line editing (among other things) goes to hell in a handbasket.

Symptom: reverse video stays reversed

It used to be that underlining, reverse video, and bold were all started with different control sequences, but they were all stopped with the same sequence. The cool new feature that new xterms have here is that there is a different control sequence to turn off each of these, so that you can more easily have a reverse-video line with bold and underline mixed in the middle. Big whoop.

So again, you log into the new system and tell it you have an xterm (because in fact, you DO have an xterm), and you read a man page or use "less" or "more", and it porks things all to hell and gone, because xterm developers are a bunch of moronic mother-fuckers that I'd recommend lobotomizing, if that hadn't apparently already been done.

How stupid are they really?

You know, I wouldn't be so fucking annoyed with these twat-faced idiots if they had at least given me an out. All they had to do was add a control-sequence to the xterms that allows you to interrogate the version (or better yet, the feature set), and this could be dealt with. I mean, it still woulda been inexcusably brain-dead to introduce these incompatible changes and keep the name "xterm", but at least I wouldn't want to drive a steam roller over the lot of them.

If they had at least done that, then the login process could check the xterm features or version, and set the TERM variable appropriately. It'd be an ugly hack over a really bad idea from a bunch of fucks that shoulda known better. But an ugly hack is better than no hack at all.

So that's how incredibly stupid, dumb, blind, moronic, incompetent, worthless, and crappy these so-called developers are. Am I making myself clear hear?

An award for the very depths of stupidity?

Sun may have won an award here. Solaris 10 ships with the new modern spiffy xterm descriptions in termcap and terminfo. Cool huh? But guess what the don't ship? A modern xterm! That's right, Solaris 10 xterms are the old xterms and are incompatible with the terminal descriptions provided.

Related Symptom: jumping cursor in vim

Ok, this one is partially vim developer's fault. Later versions of vim attempt to do a fancy version of vi's showmatch, by color-highlighting matching braces/brackets/parenthesis when you stand on one of them.

The problem is that on traditional two-color (foreground/backround) xterms, you have two color highlighting, a.k.a. reverse-video. And by conincidence traditional xterms makes a cursor using reverse-video highlighting. So the matching bracket or whatever gets reverse-video highlighted, and the cursor gets reverse-video highlighted TWICE, which means once to reverse video and once again back to normal, so apparently the real cursor simply disappears, meanwhile, something else that looks EXACTLY like a cursor, appears somewhere else entirely. The effect is that you're moving your cursor around, and the cursor acts like a drunk fucker, or to put it another way, almost as stupid as xterm and vim developers.

The solution? Line 'em up along with the xterm developers. At a more practical level, you'd think ":se nosm", or ":set noshowmatch". Well, these may work in some versions but not others. For me, ":NoMatch" did it.

Tom Fine's Home Send Me Email