1 files changed, 46 insertions, 0 deletions
diff --git a/doc/ideas.txt b/doc/ideas.txt
new file mode 100644
index 0000000..55b5901
--- /dev/null
+++ b/doc/ideas.txt
@@ -0,0 +1,46 @@
+These are not really TODOs, they're "might do" or "hope to do".
+
+Features that should be implemented:
+
+- Support for (some of) the extra RAM in 64K machines. Can get an
+  extra 4K because we don't need the international font or the
+  floating point routines, and we can plop our custom font directly
+  into $E400. *Maybe* look into using the 800 OS, which would give
+  another 3K (the rest of the $C000 area besides the intl font).
+  This would be a separate executable (fnchatxl.xex).
+
+- Support for 130XE, 256K XL, etc extended RAM. Apparently a lot
+  of people have 1MB these days. *Lots* of screens, each with lots
+  of scrollback, would be the main (only?) use for the extra RAM.
+  Separate executable (fnchatxe.xex).
+
+- Custom cgetc() that doesn't block forever, and does its own
+  keyclick (using POKEY, not the console speaker), so we can
+  disable the click even on an 800. Also maybe we can set the
+  key repeat rate on an 800... and since the clicks are done
+  via POKEY, 800 users can *turn the volume down*. Also since
+  we won't be using WSYNC, it opens up the possibility of
+  using DLIs (if I can think of a useful use for them).
+
+- Keyboard buffer, if possible. Right now we miss the occasional
+  keystroke when typing fast & furious during network I/O. Not
+  sure how to accomplish this with FujiNet (the old FujiChat
+  key buffer actually hooked into the SLIP code).
+
+- Adaptive scrollback (dynamic screen size). Using fewer screens
+  would mean you get more scroll. Shorter screens steal lines from
+  the top of the tallest screen as needed. Requires a display list
+  that's all LMS, and each line needs to be 42 bytes (the extra
+  2 bytes are a pointer to the previous line, or 0 for the top line).
+  Some lines would have to be blacklisted because they'd cross a 4K
+  boundary. As a side effect, scrolling in new text would be *fast*,
+  no need to move memory around, just allocate a new line and change
+  the display list.
+
+- URL handling. Extract URLs from message text, send them to a
+  UDP port on a local machine that knows how to deal with them.
+
+- Some method of copy/paste, using the keyboard or maybe a joystick.
+
+- Cut buffer for ^U ^K ^W, like bash/emacs. LImited size (like,
+  240 bytes, same as the input box).