Merge branch 'master' of git@github.com:elliottcable/nfoiled
[nfoiled.git] / thoughts.txt
blobc409b7fbc943ed57df2138b7652b5a9d2bb7f462
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))
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.