Current-Users archive

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

Re: Help with libcurses and lynx under NetBSD-9 and -current?



On Tue, Sep 21, 2021 at 07:43:28 +0930, Brett Lymn wrote:

> On Mon, Sep 20, 2021 at 02:44:21PM +0300, Valery Ushakov wrote:
> > > 
> > > Not always.  You are right it is ttys that is doing it.  The bug was
> > > that cursor down with onlcr on always moved the cursor to the first
> > > column of the next line.
> > 
> > Right, right, and my question is: why do we have onlcr on for curses
> > output?
> 
> That is a good question, onlcr is explicitly set/unset in a few places
> so it appears to be deliberate.
> 
> > > Window(1) doesn't use ^J for cursor down so the output was
> > > stair-stepping.
> > 
> > Do you mean curses code was running with onlcr and was compensating
> > for its own bug?
> 
> It would appear so and has been doing this since before NetBSD which is
> not a justification, just an observation.

nl/nonl are defined to affect *input* translation, turning off ICRNL,
so that apps can distinguish carriage return key.  I *guess* that the
code changes ONLCR in lockstep out of lazyness, so that for apps that
run with echo/nl the nl->cr+nl on output is done by tty(4).  Of course
that bites back by messing up cud1.  I would say this is saving a
penny losing a pound.

PS: From a quick look at xcurses - it seems to say that cbreak mode
implies ICRNL cleared:

  cbreak Mode - [...] This mode achieves the same effect as
      non-canonical-mode, Case B input processing (with MIN set to 1
      and ICRNL cleared) as specified in the XBD specification.

-uwe


Home | Main Index | Thread Index | Old Index