[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Documentation nl, nonl possibly slightly wrong
From: |
Thomas Dickey |
Subject: |
Re: Documentation nl, nonl possibly slightly wrong |
Date: |
Sat, 19 Sep 2020 19:15:54 -0400 |
User-agent: |
NeoMutt/20170113 (1.7.2) |
On Wed, Sep 16, 2020 at 12:23:11PM +0200, Leon Winter wrote:
> Hi Thomas,
>
> the man page of nl, nonl says:
>
> The nl and nonl routines control whether the underlying display de-
> vice translates the return key into newline on input, and whether it
> translates newline into return and line-feed on output (in either
> case, the call addch('\n') does the equivalent of return and line
> feed on the virtual screen). Initially, these translations do occur.
> [*] If you disable them using nonl, curses will be able to make better
> use of the line-feed capability, resulting in faster cursor motion.
> Also, curses will then be able to detect the return key.
fwiw, that text dates from 1995/07/03 -
sometimes it takes a while for someone to see discrepancies :-)
> Reading the source code of function mvcur I see in
> ncurses/tty/lib_mvcur.c:1034:
>
> * If caller set nonl(), we cannot really use newlines to
>
> * position to the next row.
>
> */
>
> xold = -1;
>
> yold = -1;
>
> To me, it seems that, only when nl is set, ncurses can optimize so the
> documentation is missing the word "not".
>
> As another matter my understanding of nl/nonl in respect to the tty settings
> is
> somewhat lacking. Does the input conversion of \n and \r matter for the output
> direction?
see below - it seems to be because the original code was written for the
older Unix system which tied the two features together.
> I would think ICRNL is about the stuff the user enters into the tty and the
> way
> it is transmitted from tty to the application while ONLCR changes the other
> direction. In Ncurses the nl/nonl settings seems to apply to both directions:
> ncurses/base/lib_getch.c:610:
yes... it's been that way a long time.
offhand, it's not a feature mentioned in X/Open (not saying much):
https://pubs.opengroup.org/onlinepubs/7908799/xcurses/nl.html
but looking at the source-history for ncurses, it's been in the
code since the earliest snapshot that I have -- seen for
examply in December 1994 (in the file src/lib_raw.c),
but in ncurses 1.8.1 from October 1993 (which I didn't have
when I began my archive). I'm looking at this chunk of code:
int nonl()
{
T(("nonl() called"));
SP->_nl = SP->_nlmapping = FALSE;
#ifdef TERMIOS
cur_term->Nttyb.c_iflag &= ~ICRNL;
cur_term->Nttyb.c_oflag &= ~ONLCR;
if((tcsetattr(cur_term->Filedes, TCSANOW, &cur_term->Nttyb)) ==
-1)
return ERR;
else
return OK;
#else
cur_term->Nttyb.sg_flags &= ~CRMOD;
stty(cur_term->Filedes, &cur_term->Nttyb);
return OK;
#endif
}
The only earlier thing that I can cite would be pcurses, which doesn't
have the TERMIOS part. However, in a quick check, that CRMOD feature
applied to both input and output (which is what we're discussing).
Given all that, I suppose that Zeyd implemented the TERMIOS code, making
it match the sgttyb interface.
Comparing with the SVr4 code in illumos, I don't see this (output)
feature there. Of course, that source wasn't available in 1995, and the
only way we'd have noticed a difference like this would have been by
stumbling over some difference in testing.
Interestingly enough, in a change from 1996/09/07, I see that I removed
a few statements from lib_mvcur.c which had assumed that nl/nonl modify
ONLCR:
REV:1.20 lib_mvcur.c 1996/09/07 22:09:10 tom
tags: v1_9_9e_e313_960907
remove logic that assumes nl/nonl modify ONLCR
--- lib_mvcur.c 1996/08/18 01:21:26 1.19
+++ lib_mvcur.c 1996/09/07 22:09:10 1.20
which might be related to this item from the NEWS file
(I don't see anything closer):
960907 - snapshot
+ disable ONLCR during initialization, to match SVr4 (this is needed
for cursor optimization when the cursor-down is a newline).
> /*
> * Simulate ICRNL mode
> */
> if ((ch == '\r') && sp->_nl)
> ch = '\n';
>
> If I would like the RET key to be passed through without conversion to '\n' I
> must call nonl but this then also affects the output computation being of
> lower
> efficiency sadly.
well... since the optimization is "supposed to work" whether or not nl/nonl
are used, it might be safe to trim out that output-configurability aspect.
(I added a to-do item to investigate this -- not something I'd just do at
the end of a day -- I got to this item thinking it was just documentation...)
--
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net
signature.asc
Description: PGP signature