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).

- 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).

- Support for the XEP80 (and its modern clones). This really should be
  done as dual-head: Keep the regular Atari display for screen 1,
  the edit box, and the status bar. The rest of the screens can
  display on the XEP80. One problem with this is, scrollback memory.
  Each of screens 2-7 will be ~2000 bytes per 80x25 chunk, so each
  needs 4K to be able to scroll back 1 screens' worth. So XEP80
  support might end up being a 128K-and-up-only thing.
  reifsnyderb has some code that deals with the XEP, written for use
  with CP/M, that may be useful here.

- R: support. Compile-time switch, separate executable. Use with
  FujiNet, Lantronix, or anything else where we can go like
  ATDThostname:port.