[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev peculiar behavior
From: |
T.E.Dickey |
Subject: |
Re: lynx-dev peculiar behavior |
Date: |
Sat, 10 Jul 1999 21:30:46 -0400 (EDT) |
> > It's not 100% ncurses (small relief). I tried lynx with Solaris curses and
> > vi,
> > and get some odd behavior (using a mail link):
>
> Can you try with just textarea editing (whatever it's bound to for you,
> ^Ve or ^Xe if using Bash-like Bindings)?
ok (though I would expect it to be the same - I'm just getting back to lynx
now).
> The easiest way to prevent Bad Things from happening here is to
> disable the SIGTSTP handler in this situation (use SIG_DFL).
>
> Should it be (n)curses' job to do this (probably always while in
> 'shell' mode)?
If Lynx establishes its own SIGTSTP handler before initscr, then
ncurses won't (isn't supposed to). It's simpler to just have one....
> Should lynx do this?
> (It could be put into LYSystem(). Or into stop_curses/start_curses.
> There would be differences between the two choices, especially if there
> are LYSystem() or system() calls that are not preceded by stop_curses().)
>
> Or both?
>
> ----
>
> Dos anyone have a different analysis or theory? Do curses standards
> say anything about how the SIGTSTP handler should behave after endwin()?
They're vague - just say that the library could have its own handlers.
>
> Klaus
--
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey
- Re: lynx-dev peculiar behavior, (continued)
- Re: lynx-dev peculiar behavior, T.E.Dickey, 1999/07/10
- Re: lynx-dev peculiar behavior, Larry W. Virden, 1999/07/10
- Re: lynx-dev peculiar behavior, Larry W. Virden, 1999/07/10
- Re: lynx-dev peculiar behavior, Larry W. Virden, 1999/07/10
- Re: lynx-dev peculiar behavior, Larry W. Virden, 1999/07/10
- Re: lynx-dev peculiar behavior, Larry W. Virden, 1999/07/10
- Re: lynx-dev peculiar behavior,
T.E.Dickey <=
- Re: lynx-dev peculiar behavior, T.E.Dickey, 1999/07/10