bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: Problem when testing ncurses 5.2 on a LynxOS system...


From: Frédéric BOITEUX
Subject: Re: FW: Problem when testing ncurses 5.2 on a LynxOS system...
Date: Wed, 13 Feb 2002 16:24:14 +0100

Le Wed, 13 Feb 2002 09:52:06 -0500, Thomas Dickey <address@hidden> a écrit :

> On Wed, Feb 13, 2002 at 03:17:13PM +0100, Frédéric BOITEUX wrote:
> > I join the resulting `trace' file... It's very verbose, perhaps too much 
> > ... If you want, I can rerun
> > it with another trace level...
> 
> it does look large (but I've worked with larger ones).  Quoting the
> same chunk:
> 
> \E[J
> \E[35;44H/\r
> \n\b\b/
> \E[A/\r
> \E[J
> \E[34;45H-
> \E[A\b\b
> \E[35m
> \E[1m - \r
> \n\b\b\b-+-\r
>            ^^ I don't see this happening in the trace
> \n\b\b\b - 
> \E[39;49m
> \E[m^O
> \E[32;43H
> \E[36m --- \r
> \n
> \E[5D-+++-\r
> \n
> \E[5D-+#+-\r
> \n
> \E[5D-+++-\r
> \n
> \E[5D --- 
> \E[39;49m
> \E[m^O
> \E[32;43H
> \E[33m
> 
> An analogous section in the trace (won't always be the same since it's
> pseudo-random) follows.  The PutAttrChar calls note the literal characters
> that are written.  See that (from ncurses viewpoint) there's no intervening
> \r character.  While ncurses isn't tracing _everything_, it's looking as if
> something (balky termio) is emitting the \r.
> 
> PutAttrChar({'-' = 0x2d | {A_COLOR{1 = {COLOR_CYAN, default}}}}) at (18, 57)
> PutAttrChar({' ' = 0x20 | {A_COLOR{1 = {COLOR_CYAN, default}}}}) at (18, 58)
> TransformLine(19) called
> GoTo(19, 56) from (18, 59)
> + + + called {mvcur(18,59,19,56)
> + + + + called {tparm("\e[%i%p1%d;%p2%dH", 19, 56)
> + + + + return }"\e[20;57H"
> + + + + called {tparm("\e[%p1%dB", 1)
> + + + + return }"\e[1B"
> + + + + called {tparm("\e[%p1%dD", 3)
> + + + + return }"\e[3D"
> + + + + called {tparm("\e[%p1%dB", 1)
> + + + + return }"\e[1B"
> + + + + called {tparm("\e[%p1%dC", 56)
> + + + + return }"\e[56C"
> + + + + called {tparm("\e[%p1%dB", 19)
> + + + + return }"\e[19B"
> + + + + called {tparm("\e[%p1%dC", 56)
> + + + + return }"\e[56C"
> + + + + called {tparm("\e[%p1%dB", 1)
> + + + + return }"\e[1B"
> + + + + called {tparm("\e[%p1%dD", 3)
> + + + + return }"\e[3D"
> tputs(mvcur = "\n\b\b\b", 1, _nc_outch) called
> + + + return }0
> 
> In other chunks, you may see the terminal modes being set.  Perhaps LynxOS
> isn't doing the right thing there.
> 
> + + called {cbreak()
> cbreak before bits: iflags: {BRKINT, IGNPAR, ICRNL, IXON} oflags: {OPOST} 
> cflags: {CREAD} CS8 lflags: {ECHO, ECHOE, ECHOK, ICANON, ISIG, IEXTEN} 
> cbreak after bits: iflags: {BRKINT, IGNPAR, IXON} oflags: {OPOST} cflags: 
> {CREAD} CS8 lflags: {ECHO, ECHOE, ECHOK, ISIG, IEXTEN} 
> _nc_set_tty_mode: iflags: {BRKINT, IGNPAR, IXON} oflags: {OPOST} cflags: 
> {CREAD} CS8 lflags: {ECHO, ECHOE, ECHOK, ISIG, IEXTEN} 
> + + return }0
> 
> The trace _looks_ much the same on Linux.  But either there's some extra flag
> that I'm not putting in the trace, or something on LynxOS isn't working 
> properly.
> (I suggest you look for the corresponding documentation on termio or termios,
> to see).
> 
> + + called {cbreak()
> cbreak before bits: iflags: {ICRNL, IXON} oflags: {OPOST} cflags: {CREAD} CS8 
> lflags: {ECHO, ECHOE, ECHOK, ICANON, ISIG, IEXTEN} 
> cbreak after bits: iflags: {IXON} oflags: {OPOST} cflags: {CREAD} CS8 lflags: 
> {ECHO, ECHOE, ECHOK, ISIG, IEXTEN} 
> _nc_set_tty_mode: iflags: {IXON} oflags: {OPOST} cflags: {CREAD} CS8 lflags: 
> {ECHO, ECHOE, ECHOK, ISIG, IEXTEN} 
> + + return }0
> 
> ------------------------------------------------------------------------
> 
> Looking at the terminfo, the quick fix is to persuade ncurses to not do that.
> I see that cud1 is set to ^J.  If it were expressed as this:
>       cud=\E[B, 
> then ncurses would send that escape sequence rather than \n to move down one
> line.  Notwithstanding that there's a problem with LynxOS, I guess ncurses
> should look more closely to avoid sending a \n when nonl() has not been 
> called.
> (Will look at my notes later - I thought I'd addressed this some time ago).
> 
> -- 
> Thomas E. Dickey <address@hidden>
> http://invisible-island.net
> ftp://invisible-island.net


        Hi,

  Thanks a lot Thomas, with your suggestion mofifying the terminfo definition 
for rxvt,
it works nice now !!! 

        Fred.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]