C# Класс kOS.Screen.TermWindow

Respond to one single input character in Unicode, using the pretend virtual Unicode terminal keycodes described in the UnicodeCommand enum. To keep things simple, all key input is coerced into single Unicode chars even if the actual keypress takes multiple characters to express in its native form (i.e. ESC [ A means left-arrow on a VT100 terminal. If a telnet is talking via VT100 codes, that ESC [ A will get converted into a single UnicdeCommand.LEFTCURSORONE character before being sent here.)
This method is public because it is also how other mods should send input to the terminal if they want some other source to send simulated keystrokes.

Draw a little status line at the bottom as a reminder that you are sharing the terminal with a telnet session:

Attempts to make Unity start a playthrough of the beep audio clip. The playthrough will continue on its own in the background while the rest of the code continues on. It will do nothing if the previous beep is still being played. (We only gave ourselves one audio beep source per GUI terminal so we can't play beeps simultaneously.)
Addendum: It will redirect into a visual beep if that is called for instead.

Get the newest copy of the screen buffer once, for use in all calculations for a while. This was added when telnet clients were added. The execution cost of obtaining a buffer snapshot from the ScreenBuffer class is non-trivial, and therefore shouldn't be done over and over for each telnet client that needs it within the span of a short time. This gets it once for all of them to borrow. All calls will re-use this copy for a while, until the next terminal refresh (1/20th of a second, at the moment).

Process the GUI event handler key events that are being seen the by GUI terminal, by translating them into values from the UnicodeCommand enum first if need be, and then passing them through to ProcessOneInputChar().

Read all pending input from all telnet clients attached and process it all. Hopefully this won't bog down anything, as we don't expect to get lots of chars at once from keyboard input in a single update. The amount of characters pending in the queues should be very small since this is flushing it out every update. It could potentially be large if someone does a big cut-n-paste into their terminal window and their telnet client therefore sends a wall of text within the span of one Update(). Premature optimization is bad, so we'll wait to see if that is a problem later.

When the input queue is not empty and the program or command is done such that the input cursor is now all the way back to the interpreter awaiting new input, send that queue out to the interpreter. This allows you to type the next command blindly while waiting for the previous one to finish. This is how people used to terminals would expect things to work.

Do the repaint of the telnet session.

Cover the case where the whole screen needs to be repainted from scratch.

Tell the telnet session to resize itself