bug-ncurses
[Top][All Lists]
Advanced

[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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]