thoughts.txt

   1 - A Key corresponds to a single keypress by the user:
   2   - A single ASCII byte, such as "a" (97)
   3   - A series of bytes corresponding to a single Unicode character, such
   4     as "æ" (195,166), "Ꮬ" (225,143,156), or "������" (240,144,144,166)
   5 - A Sequence is a specific series of Keys
   6   - An escape sequence in an editor, such as:
   7     M-æ (27, (195,166))
   8   - A cheat sequence in a game, such as:
   9     →↑→ (M[C-M[A-M[C) ((27,91,67), (27,91,65), (27,91,67))
  10
  11 - Not sure how to handle the fact that Unicode needs multiple bytes of input
  12   - Will I have to have some sort of global loop?
  13     - Time pauses 'tween bytes to form Key objects, synchronize `doupdate` calls
  14       for perceived speed
  15     - Pain in the ass
  16       - Ruby Threads? Seriously? >,>
  17   - What about a *single*, *central* global loop?
  18     - Something like Rack that handles "the Loop" for everything that needs it
  19       (EventMachine, XMPP4R, Rack, and Nfoiled?)
  20     - Any library can schedule things to work during the loop, all must be non-
  21       blocking etc
  22   - What about popping a thread everytime a non-ASCII byte is read?
  23     - Do all Unicode characters start with a non-ASCII byte? How are they
  24       sequential? (for #succ, etc)
  25     - I could pop a `Thread`, and instruct it to `gets` until it receives a
  26       nil, indicating the byte sequence is over.
  27       - Do Unicode characters of different byte-lengths pad with nils to a
  28         specific number of bytes? Try turning back on the display of `nil`s
  29         and let's see.
  30       - Do all terminals send the bytes of a unicode character fast enough to
  31         prevent intervening cyclings of `gets`? Must experiment on a really
  32         fast computer.
  33       - What if you were to provide input so fast as to prevent an successive
  34         nil? Is that possible? Must experiement with pasting Unicode
  35         characters/typing very fast.
  36       - If for some reason the user had turned back on `delay` mode or set a
  37         non-zero`wtimeout`, we'd have to retreive and save that value, then
  38         switch into `nodelay` mode; retreive the Unicode bytes; and re-set
  39         their preferred input mode.
  40       - If we're already in a `gets` loop ... we'd have to have an 'input
  41         lock' of some sort, to ensure that the `gets` from the original input
  42         loop doesn't accidentally 'steal' a byte from the middle of the
  43         Unicode series. (and recognize it as a Unicode byte, and start a new
  44         `Thread`, and ... so on)
  45       - Speed concerns involving popping a new thread for every Unicode
  46         character. Will have to benchmark a bit.
  47     - Would mean we couldn't handle `doupdate` calls in a sexy way ... have to
  48       leave that up to the user. Which is probably fine anyway, I guess, just
  49       doesn't feel as sexy.