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