These are not really TODOs, they're "might do" or "hope to do".

Features that should be implemented:

- /r to reply to the last person/channel who msg'd you, /a to msg the
  last person/channel you msg'ed (server and private screens). Idea
  comes from phigan (thanks!)

- Support for (some of) the extra RAM in 64K machines. Can get an
  extra 4K (97 lines) because we don't need the regular or
  international font or the floating point routines. This can be done
  in the standard executable: most of the work happens in the config
  segment.

  It has to be possible to disable, in case the user's using
  e.g. Sparta 3.x (uses the under-OS RAM already) or the HSIO patch
  that uses the intl font area for code... though, we don't *do*
  disk I/O once the client starts, so maybe we can ignore the HSIO
  patch issue.

- *Maybe* look into using the 800 OS, which would give
  another 3K (the rest of the $C000 area besides the intl font).
  The issue here is "live-booting" the OS (switching from XL to
  OSB on a running system without a reboot or even a warmstart).
  The_Doctor__ says this is possible. I'm not sure I want to bother
  with this...

- Use any extra RAM in the code area, between the end of the code
  segment and the start of the stack, as extra screen memory.
  Currently that's 1.7K, or 42 extra lines.

- Use any extra RAM in the data area, between the end of the BSS and
  the start of the display list/etc (at $3360), as extra screen
  memory. Currently that's 1.4K, or 34 extra lines.

- 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, will be the only use for the extra RAM. Most of the
  work is done in the config segment (detecting banks and letting the
  user choose which ones to use) so it won't bloat the executable
  much. Already have the dynamic screen stuff, with support for
  multiple pools, so the groundwork is done at least.

- URL handling. Extract URLs from message text, send them to a
  UDP port on a local machine that knows how to deal with them.
  Or, show them as a QR code (FujiNet supports that).

- 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 the edit box,
  the status bar, and maybe some other info. The actual screens can
  display on the XEP80. Unfortunately to do this right, I'll have
  to use the XEP80's E: handler (so it'll work with modern XEP80
  replacements like the 1090XL 80-column board), and that means giving
  up 1.5KB of memory (the driver is bloated). 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.

These last two, xep80 and R:, will be compile-time options. I can't
afford the RAM it would take to keep all that code resident at once
and choose at runtime. So, 4 executables:

- fnchat.xex, 40 columns, FujiNet networking.
- fnchatx.xex, 80 columns, FujiNet networking.
- fnchatr.xex, 40 columns, R: networking.
- fnchatrx.xex, 80 columns, R: networking.