Looking for ANSI/VT100 code replacement.

[M. Warner Losh]

In message: <20050521015105.GA9063 at skatecity>
            alexander <arundel at h3c.de> writes:
: On Fri May 20 05, Dan Nelson wrote:
: > 
: > How often are you doing this?  I wrote a quick microbenchmark and my
: > pIII-900 box can do 80000 writes() per second of "\e[5D\e[Kabcde".  I
: > don't think that's your bottleneck.  If it is, the usual solution is to
: > not do a write on every iteration.  You've got a (maximum) 100hz screen
: > refresh rate anyhow, so doing more than 100 updates per second won't do
: > you any good.  Even 10 is probably more than you need.
: > 
: > -- 
: > 	Dan Nelson
: > 	dnelson at allantgroup.com
: 
: Ohh...sorry for not telling you this. Yes. The app works alright when
: executed from the console. But my problem is with xterm or Eterm. They don't
: handle VT100 very well. I've added a nanosleep after each VT100 output but
: that didn't solve the issue. In fact Eterm or xterm might not update the value
: for as long as 5-8 seconds. I tested burncd's code and it uses fprintf to
: update the bytes it sends. And that works perfectly under Eterm and xterm.

Actually, xterm handles VT100 very well.  The console does not.  The
console implements a variant of ANSI that's different from the variant
of ANSI that the vt100 did.  so if it works on the console, but acts
differently in an X term, that's likely due to the differences between
the terminal emulation both provide.  Maybe the problem isn't one of
performance, but one of emulation?

Warner