>> Here, we have software that's crippled by lacking support for >> producing its output in a generalized fashion - so, rather than >> fixing the limitation, we depend on a heavyweight OS feature to work >> around it? [...] > Or we have a library that is specifically designed and implemented to > talk to a tty and optimaise the output so that it outputs the minimum > amount of data to that tty and now someone complains that it doesn't > work on something that is not a tty?
Fair point. I'm actually complaining that it doesn't work connected to something that _is_ a tty...when the tty is nonblocking. Wanting the refresh guts to be separate is just one way to address that. Initially, it seemed to me that, given the usual intent of nonblocking, something like that was necessary to fix it without calling in heavyweight OS support like ptys and additional processes - or, for versions sufficiently recent that nonblocking is an open file table entry thing instead of a backing-object thing, depending on the output tty being reopenable. While writing this mail, it occurs to me that a mode wherein everything operates same as now, except that output, instead of being pushed to the tty with fwrite() or write() or writev() or whatever, is just passed to a callback. That would address my use cases with a much less intrusive change. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
