diff options
| author | B. Watson <urchlay@slackware.uk> | 2026-03-23 02:04:36 -0400 |
|---|---|---|
| committer | B. Watson <urchlay@slackware.uk> | 2026-03-23 02:04:36 -0400 |
| commit | db1343f2ec8d3b944e861fb40593d96be4ec5dda (patch) | |
| tree | 58d5913dc20b83201fbdac387254a017355ddc2f /TODO | |
| parent | 59bb76acede0fc72063485cdffe17acad5a3ac8c (diff) | |
| download | fujinet-chat-db1343f2ec8d3b944e861fb40593d96be4ec5dda.tar.gz | |
Error messages (numerics 400 to 599) go to the current screen, not [server].
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 15 |
1 files changed, 0 insertions, 15 deletions
@@ -20,21 +20,6 @@ Other stuff: - [*] When running /motd after connection, it works (even if 'hide MOTD' is enabled), but it jumps to screen #3 if there's a channel in that screen. -? Implemented, but not sure it was worth doing: - 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). - Remove this when/if I do a proper typeahead buffer. - [*] 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 |
