Re: Terminal echo

[Thomas Dickey]

On Sat, Apr 05, 2003 at 06:56:39PM +0200, address@hidden wrote:
> Hi,
> 
> > I had in mind recently that someone once told me that readline had
> > enough hooks to allow ncurses to substitute for the display function
> > of readline, but on investigation found that was not so.  (Otherwise I
> > would have modified test/filter.c to do this, eliminating an faq). 
> 
> I'm not sure about your meaning... Is that to say it's not possible to
> use Readline directly in fullscreen curses mode? That would be actually
> very sad, as I intended to do exactly that in netrik at some point...

yes - I had recalled that the library provided a set of function-pointers
which could be overridden to allow one to supply a different set of functions.
Consulting my back-email, that was Bjorn Helgaas in 1999.  So I had in mind
that it was "doable", but did not fit well into the test-directory.  But
people do ask, and it occurred to me that modifying test/filter.c would
fit well enough, so I spent a couple of hours recently analyzing readline,
finding that without rewriting display.c it would be pointless to try this,
since it is too entangled with termcap, has a number of critcal pieces done
inside the overridable-functions, etc.

If it were done properly, there would be no I/O functions in display.c;
it would only be a framework.  Count the tputs, putc calls in that module,
to see.  Most of the logic in that module would remain.

> > > BTW, there is another (not new) problem with readline: Ncurses' default
> > > SIGWINCH handler doesn't work anymore after using readline, although
...
> I've now created a simplified test case for this also; see attachment.

will test (thanks)
> 
> > actually (on this machine I have 5.3 and 5.2 installed), I don't see a
> > difference in behavior: both turn on echoing after executing readline.
> > The debug trace shows that ncurses is doing the echoing (attaching copies
> > of the old/new traces).
> 
> My fault -- I messed up the test program. The call to echo() after
> readline() was actually to be noecho(), just to show that it has no
> effect... Well, maybe it's better this way, as the double echo more
> evidently shows something goes wrong...

my trace showed that tgetent() was being called in the middle (when readline
was started up), and that was probably related.  I'll probably make a fix for
that today (otherwise I was working on test-cases, to evaluate remaining work
for 5.4).
 
> > 2nd reply - long day.  I'm running Slackware, which does have termcap
> > library also, and in linking did
> >     -lncurses -lreadline -ltermcap
> > which works fine.  Changing to
> >     -lreadline -lncurses
> > yields a double echo.
> 
> What exactly does -ltermcap effect here?

it added a different copy of tgetent(), bypassing the re-initialization issue
that you are finding...

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net