Re: RHS: libterm-ansicolor-ruby

[Adam Borowski <kilobyte@angband.pl>]

On Wed, Aug 15, 2007 at 04:02:57PM -0000, Thomas Dickey wrote:
> The Fungi <fungi@yuggoth.org> wrote:
> 
> > Of course, I can't imagine an ANSI library would be anything more
> > than a few dozen string constant definitions, unless you wanted
> 
> man tput
> 
> (no point in hardcoding "a few dozen string" definitions, unless one
> _likes_ the nasty comments that people make when they read the code ;-)

I'm afraid the very concept of termcap/terminfo is thoroughly broken. 
It makes the following assumptions:

* all TERM strings are known to all machines.  Mere ssh will break
  otherwise.  And even after all these years, Solaris still doesn't
  know what TERM="linux" means (the last time I checked it didn't, at
  least).

* TERM strings are unique.  Because of the above, no one who makes a
  terminal emulator will use a real string as it would make his
  terminal useless.  Thus, anything popular uses either:
    + "xterm":
        - xterms of all Unices -- no matter what differences between
          them are, often interpreting vt100+ codes in creative ways
          (compared to how I would read the docs),
        - libvt based stuff (totally incompatible with xterms),
        - konsole and derivatives (totally incompatible with the rest
          _and_ buggy)
        - PuTTY (one of the best nowadays, used to be terrible)
    + "rxvt":
        - aterm, wterm, etc.  None of them sync bugfixes with the
          others.
    + "linux":
        - real Linux text console.
    + "vt100":
        - physical terminals, even if they're rather vt19578394.
    + "screen":
        - reinterprets everything in its own dialect, usually for
          good results, sometimes for bad.

In other words, "TERM" is totally useless.  How is it supposed to
tell me that I have to write spaces to every position instead of
usual means of clearing the screen if bgcolor isn't transparent
(older putties) -- and even if it could, neither termcap nor terminfo
have means to convey this info.  Or, do I need to restore the \e[???m
attrs after moving the cursor (libvt in some cases)?  Or, what are
the effects of \n on the line right to the cursor?  Or, how to be
told if arrow keys pressed are Kpad ones or the new-style "gray"
ones?


>From my own experience, the only way to get decent portability is,
ironically, hard-coding a certain subset of vt100ish codes.  Querying
termcap/terminfo tends to lose rather fast in comparison.

So there's no point in using tstuff unless one _likes_ the nasty
comments that people make when they try to either use the program or
read the code ;-)

-- 
1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.