[Top][All Lists]

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

Documentation nl, nonl possibly slightly wrong

From: Leon Winter
Subject: Documentation nl, nonl possibly slightly wrong
Date: Wed, 16 Sep 2020 12:23:11 +0200

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.

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
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:

     * 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.


reply via email to

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