- * If the output file descriptor is connected to a tty (the typical case) it
- * will probably be line-buffered. Keith Bostic pointed out that we don't want
- * this; it hoses people running over networks by forcing out a bunch of small
- * packets instead of one big one, so screen updates on ptys look jerky.
- * Restore block buffering to prevent this minor lossage.
- *
- * The buffer size is a compromise. Ideally we'd like a buffer that can hold
- * the maximum possible update size (the whole screen plus cup commands to
- * change lines as it's painted). On a 66-line xterm this can become
- * excessive. So we min it with the amount of data we think we can get through
- * two Ethernet packets (maximum packet size - 100 for TCP/IP overhead).
- *
- * Why two ethernet packets? It used to be one, on the theory that said
- * packets define the maximum size of atomic update. But that's less than the
- * 2000 chars on a 25 x 80 screen, and we don't want local updates to flicker
- * either. Two packet lengths will handle up to a 35 x 80 screen.
- *
- * The magic '6' is the estimated length of the end-of-line cup sequence to go
- * to the next line. It's generous. We used to mess with the buffering in
- * init_mvcur() after cost computation, but that lost the sequences emitted by
- * init_acs() in setupscreen().
- *
- * "The setvbuf function may be used only after the stream pointed to by stream
- * has been associated with an open file and before any other operation is
- * performed on the stream." (ISO 7.9.5.6.)
- *
- * Grrrr...
- *
- * On a lighter note, many implementations do in fact allow an application to
- * reset the buffering after it has been written to. We try to do this because
- * otherwise we leave stdout in buffered mode after endwin() is called. (This
- * also happens with SVr4 curses).
- *
- * There are pros/cons:
- *
- * con:
- * There is no guarantee that we can reestablish buffering once we've
- * dropped it.
- *
- * We _may_ lose data if the implementation does not coordinate this with
- * fflush.
- *
- * pro:
- * An implementation is more likely to refuse to change the buffering than
- * to do it in one of the ways mentioned above.
- *
- * The alternative is to have the application try to change buffering
- * itself, which is certainly no improvement.
- *
- * Just in case it does not work well on a particular system, the calls to
- * change buffering are all via the macro NC_BUFFERED. Some implementations
- * do indeed get confused by changing setbuf on/off, and will overrun the
- * buffer. So we disable this by default (there may yet be a workaround).