From fa9c7b244b646c214c2bbf9ab0c50499cc3858dd Mon Sep 17 00:00:00 2001 From: "B. Watson" Date: Sat, 21 Mar 2026 23:12:44 -0400 Subject: Update ideas.txt. --- TODO | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'TODO') diff --git a/TODO b/TODO index 57917d9..8ef14fc 100644 --- a/TODO +++ b/TODO @@ -12,6 +12,19 @@ FujiChat features, we're almost at parity! Other stuff: +- If an VBI-driven keyboard buffer turns out to be impossible or + too much of a PITA to contemplate, another idea to avoid dropping + keystrokes: after every keypress, wait something like 1/4 or 1/3 + second for another keypress, before checking for incoming net + traffic. As long as the user's typing 4 (or 3) keys per second, + he won't lose keystrokes. Probably have to put a limit on it, + a pathological case would be holding down a key long enough to + fill the edit box with 240 of the same character. That would + cause a 60 sec delay in net traffic, which might actually cause + us to time out... need some data on just how fast a fast typist + really types, and on average, how often they pause (to think or + read back what they just wrote, etc). Also look into detecting + key repeats (SRTIMER). - Write a cgetc() replacement that doesn't call the OS K: "get one byte" routine. I was avoiding it because it will need a 192-byte table (keycode -> atascii lookup)... but I'm spending more than 192 bytes -- cgit v1.2.3