> See, certain terminal emulators lie about their TERM setting. Usually > it's things that aren't xterm pretending to be an xterm, although rxvt > sometimes crops up too. Examples of things pretending to be xterm > include Konsole, Gnome Terminal. > > The logic behind it goes like this: > > * We don't understand this 'terminfo' thing, but we want our terminal to > work with programs which use ncurses. > > * We've implemented xterm-style colour sequences and some basic cursor > movement. > > * Therefore, we shall set TERM=xterm. > > This is not a good idea. See, real xterm supports a hell of a lot of > fancy voodoo. It and rxvt-unicode are two of the most fully featured > terminal emulators (from a terminal capability point of view) out there. > None of these cheap knockoffs that claim to be xterm come anywhere near > close to supporting full xterm capabilities.
I fully agree with you, but ... did xterm support the full feature-set right from the start? So what happens if i've got a box running an old xterm and then do an ssh-session to a newer box where the application thinks that xterm support some fency new feature? After the all, the whole mess can IMHO only be cleared up, if there's something like a universal terminal-type, and the application could ask the terminal for it's feature-set. So i'm not aware if this is possible, but this seems to be the only _really_ reliable extensible way to do this. I don't see the point in define lots of all new terminal-types. Of course this isn't and a short-term sollution and would have to be implemented by all the terminal-emulators that lie about their terminal-type.
signature.asc
Description: OpenPGP digital signature
