The terminal driver vane.

Keyboard events and the like from Unix are received by Dill as %belt tasks, and Dill sends %blit gifts containing $blits back to the runtime to be displayed in the Unix terminal. The manner of interacting with Dill differs depending on whether you're in userspace or kernelspace, as we'll explore below.

Kernelspace

For technical reasons, Dill performs a handful of system tasks related to booting a ship and some memory operations. Aside from those, other Vanes mostly just pass Dill tasks to print error messages and the like to the terminal.

Userspace

Unlike in kernelspace, userspace applications are unlikely to %pass Dill tasks directly. Instead, Dill looks at things in terms of sessions. A session is a pipeline between a client and a handler, where:

• The client is an external input source and output sink; a terminal with with dimensions and so forth.
• The handler is an application in Urbit that interprets input, maybe does something with it, maybe produces output to be displayed in the client, etc.

There are plans for Dill to support multiple independent sessions (i.e. independent terminal clients displaying and processing different information at the same time), but at this stage Dill only supports a single session. The client for this default session is just the Unix terminal via the Urbit runtime. The handler for the default session is the %hood app, whose drum module does the heavy lifting.

drum is the CLI app manager. By default you'll have a couple of CLI applications running—%dojo and %chat-cli—which you can switch between with ctrl+x. You may also have additional CLI apps which you have attached with the |link command. It's drum that keeps track of which one is active, which one input should be routed to, which one should be displayed, what each prompt should look like, and so forth. Dill itself is oblivious to the distinction between these CLI apps. It only sees the default session with drum, so it just passes all input to drum and display whatever drum gives it.

While drum talks with Dill in $dill-belts and $dill-blits, it talks to CLI apps with $sole-actions and $sole-events, which are defined in the sole library. For more information on the sole library and the related shoe library, and for information on how to build CLI apps, you can refer to the CLI app tutorial.

To give a basic idea of how keyboard events flow through these systems and produce terminal output, here's a diagram showing the messages in pseudo-Hoon:

You can use a move trace to get a hands-on feel for this data flow.

Sections

API Reference - The tasks Dill takes and the gifts it returns.

Scry Reference - The scry endpoints of Dill.

Data Types - Reference documentation of the data types used by Dill.