6cbb6b060d
This reverts commit 8e1e40d75b3ab15c194b6bf9570f3edc46e2de58. This reverts commit f073c490f9fd7c5abc033af4857df92229877de7. This reverts commit f187d2d7e01a54823f3e979af9bbd148b398e7e9. This reverts commit bc272862a73cfce1b118586ca39d3a377d841f1b. This reverts commit 30a397513f8890a3406dc7ab91c6e067e3bbfbbb. This reverts commit 4fc6856fb50d88c20a0f533392ca606641c5f38f. Conflicts: urb/urbit.pill urb/zod/base/lib/drum.hoon
1.1 KiB
%dill
Our terminal driver.
Unix sends keyboard events to %dill from either the console or telnet,
and %dill produces terminal output. The only app that should directly
talk to %dill is the terminal app. Command-line apps are run by,
receive input from, and produce output to, the %shell app, which is
controlled by %terminal, which talks to %dill, which talks to unix.
Clay also uses %dill directly to print out the filesystem change
events, but this is questionable behavior.
%dill has two main components. First, it controls the terminal on a
very basic, event-by-event level. This includes keeping track of things
like the dimensions of the terminal, the prompt type (plain text or
password), which duct to produce effects on, and so forth. Second, it
handles terminal events, keystroke by keystroke. Most characters are
simply pushed onto the buffer and blitted to the screen, but some
characters, including control-modified keys, arrow keys, etc. require
special handling. Most of the readline functionality is in %dill.