On Fri, Aug 2, 2013, at 2:03, Andrew Barnert wrote:
I went with the idea of only allowing consoleio functions inside an enabling() context (or explicit enable() and disable() calls) instead of switching on the fly. It makes khbit easier to implement and to use, and it's generally simpler, cleaner, and more efficient, and I don't think anyone will complain too much.
Anyway, if something like were added to the stdlib, it definitely wouldn't allow us to deprecate tty or termios (especially since it uses them… but even if it didn't, sometimes you need more flexibility), but it would allow us to add a note at the top saying "If you're using looking for simple, more-portable raw I/O, see the consoleio module."
I don't think deprecating termios was ever on the table. As for "sometimes you need more flexibility" - as I understood it, the problem is that tty occupies an intermediate stage of flexibility/complexity - it's unlikely that you need more than consoleio without needing termios. (or curses, if we add screen manipulation functions) I really do think this should also include a clrscr/gotoxy (and attribute functions - you mentioned setbg/setfg in DOS versions, but conio.sourceforge.net has textcolor/textbackground/textattr instead), to provide a cross-platform way to do those things (and a foundation for an eventual windowing library). I can implement these for win32 this weekend. We might want a separate enable() call/context for cursor manipulation; you have to scroll to the top of the buffer for it to work properly (and this is what native fullscreen apps such as vim do).