Add some words to docs

CONTRIBUTING.md

@@ -38,6 +38,8 @@ Commit messages form an important historical log for the repository. In your com
 You'll need the following tools to build and run Slumber locally:
 
 - [rustup](https://rustup.rs/)
+- [watchexec-cli](https://crates.io/crates/watchexec-cli)
+  - Not required, but useful for automatically re-running after changes
 - [oranda](https://opensource.axo.dev/oranda/artifacts/)
   - Only required if making documentation changes
 
@@ -48,8 +50,9 @@ That's it!
 - [Fork the repo](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/fork-a-repo)
 - Clone your fork
 - `cd slumber`
-- Run `cargo run`
+- Run `./run.sh`
   - This will install the appropriate Rust/Cargo toolchain if you don't have it already
+  - If you don't have `watchexec-cli` installed, you can just run `cargo run` instead
 
 ### Tests
 

docs/src/getting_started.md

@@ -6,7 +6,9 @@ Once you've [installed Slumber](/artifacts), setup is easy.
 
 ### 1. Create a Slumber collection file
 
-Create a file called `slumber.yml` and add the following contents:
+Slumber's core feature is that it's **source-based**. That means you write down your configuration in a file first, then run Slumber and it reads the file. This differs from other popular clients such as Postman and Insomnia. The goal of being source-based is to make it easy to save and share your configurations.
+
+To get started, create a file called `slumber.yml` and add the following contents:
 
 ```yaml
 requests:

docs/src/introduction.md

@@ -2,6 +2,6 @@
 
 Slumber is a terminal-based HTTP client, built for interacting with REST and other HTTP clients. It has two usage modes: Terminal User Interface (TUI) and Command Line Interface (CLI). The TUI is the most useful, and allows for interactively sending requests and viewing responses. The CLI is useful for sending quick requests and scripting.
 
-The goal of Slumber is to be **easy to use, configurable, and sharable**. To that end, configuration is defined in a YAML file called the **request collection**. Both usage modes share the same basic configuration, which is called the [request collection](./api/request_collection/index.md).
+The goal of Slumber is to be **easy to use, configurable, and sharable**. To that end, configuration is defined in a YAML file called the **request collection**. Both usage modes (TUI and CLI) share the same basic configuration, which is called the [request collection](./api/request_collection/index.md).
 
 Check out the [Getting Started guide](./getting_started.md) to try it out, or move onto [Key Concepts](./user_guide/key_concepts.md) to start learning in depth about Slumber.

src/tui/input.rs

@@ -32,8 +32,9 @@ pub struct InputEngine {
 
 impl InputEngine {
     /// Key code to string mappings
-    /// unstable: include ASCII chars https://github.com/rust-lang/rust/issues/110998
     const KEY_CODES: Mapping<'static, KeyCode> = Mapping(&[
+        // unstable: include ASCII chars
+        // https://github.com/rust-lang/rust/issues/110998
         // vvvvv If making changes, make sure to update the docs vvvvv
         (KeyCode::Esc, &["escape", "esc"]),
         (KeyCode::Enter, &["enter"]),

src/tui/view/event.rs

@@ -22,8 +22,8 @@ use tracing::trace;
 /// element has the opportunity to consume the event so it stops bubbling.
 pub trait EventHandler: Debug {
     /// Update the state of *just* this component according to the message.
-    /// Returned outcome indicates what to do afterwards. Use [UpdateContext]
-    /// to queue subsequent events.
+    /// Returned outcome indicates what to do afterwards. Use [EventQueue] to
+    /// queue subsequent events.
     fn update(&mut self, event: Event) -> Update {
         Update::Propagate(event)
     }
@@ -91,9 +91,9 @@ impl EventQueue {
 /// to propagate state changes, as well as side-effect messages to trigger
 /// app-wide changes (e.g. launch a request).
 ///
-/// This is conceptually different from [crate::tui::Message] in that view
-/// messages never queued, they are handled immediately. Maybe "message" is a
-/// misnomer here and we should rename this?
+/// This is conceptually different from [crate::tui::Message] in that events are
+/// restricted to the queue and handled in the main thread. Messages can be
+/// queued asyncronously and are used to interact *between* threads.
 #[derive(derive_more::Debug)]
 pub enum Event {
     /// Input from the user, which may or may not correspond to a bound action.
@@ -198,7 +198,7 @@ pub enum Update {
     /// The message was not consumed by this component, and should be passed to
     /// the parent component. While technically possible, this should *not* be
     /// used to trigger additional events. Instead, use
-    /// [UpdateContext::queue_event] for that. That will ensure the entire tree
+    /// [EventQueue::push] for that. That will ensure the entire tree
     /// has a chance to respond to the entire event.
     Propagate(Event),
 }