Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!isgate!hafro!heimir
From: heimir@hafro.is (Heimir Sverrisson)
Newsgroups: comp.unix.programmer
Subject: Curses escape delay
Keywords: Esc, Curses, delay
Message-ID: <557@hafro.is>
Date: 3 Nov 90 18:13:44 GMT
Organization: Marine Research Institute, Reykjavik
Lines: 43

Hi,

I'm having trouble with sending escape sequences over a SL/IP connection
to a remote application running on a Sun 4 with SunOS 4.1.  The application
(I wrote) uses SYSV-curses (32-bit charcter size version) and works fine
on the machine it's running on.  The application uses keypad() and therefore
it should only get one token for a whole escape sequence.

When I'm connected remotely, my host tends to send the escape sequences as
separate packets for each character.  This causes delay on the other end
long enough for curses to time out and consider the Esc as a separate
entity. I've tried to ungetch() the Esc but that does not help!
Btw the connection is on 19200 baud and the network is not loaded.

Vi is working just fine over the same channel.  It's using the same
terminfo database, but is it intepreting the sequences by itself?

There are at least three solutions to this problem:

1) Let curses wait a bit longer until it writes off the esc-sequence algorithm.
   This would be a general solution to this problem and handle all delays in
   the channel i.e. from terminal servers or another machine on a heavily
   loaded network.  I know that IBM has an environment variable ESCDELAY on
   AIX 3.1 to do just this.  Is there any general way to fiddle with this
   internal timer.

2) Let my machine send the esc-sequence as one packet over the SL/IP line
   would probably fix this as well.  This would not fix the general curses
   problem, but could keep down network traffic.  Does anyone know if this
   is doable, preferably in rlogin/telnet or otherwise in SL/IP drivers?

3) Rewrite the application so that it will decode the sequences it self
   (from info read from the terminfo-database).  This is actually a big
   step backward and means throwing away curses code doing exactly the
   same thing - but not quite well enough :-(

Anyone out there given this a thought or even solved the problem in general :-)
?

-- 
---
Heimir Thor Sverrisson		Uucp: uunet!mcsun!sunic!isgate!hafro!heimir 
TF3ANT				Internet: heimir@hafro.is