Components

I can think of a lot of potentially useful, pluggable components. The following is a brain dump of the types of components I can imagine. Some of them may not need their own types, but can share types with other components.

- Translator from raw input bytes to high level events. If we integrate with a specific terminal, we can receive high level events directly, allowing us to handle, for example, touchpad gestures.
- Dispatcher: Translate events into directives, I.E. what to do. This component can handle key bindings.
- Buffer: Translates directives that operate on text into new text.
- Compiler: Translates a text buffer into Ok(AST) or Err(Error).
- Stage: A -> Result (could implement lexing, parsing, or rest of the compiler)
- Executor: Executes an AST.
- Completor: Returns completions for a partial buffer
- Historian: Given an executed command, and a result, adds a history entry.
- Suggestor: Given a partial buffer, gives suggestions. (Like flags, as opposed to full completions of the buffer)
- Prompter: Draws the prompt.
- Optimizer: Given a program, produces a modified or better program.
- Analyzer: Given a program, catches errors with that program statically. Might also produce an output program which is better typed.
- Helper: Given a buffer, produce help about that buffer. (About command, args, probably)
- Multiplexer: Handle multiplexing input between multiple shells. (Like tmux.)
- Searcher: Handles finding binaries in your path.
- Renderer: Turns markup into styled text.

The issue is a brainstorm of possible shell components, including translators, dispatchers, buffers, compilers, executors, and renderers, but it names no files, tests, or entry points. First narrow the proposal to a specific component and define its interfaces and acceptance criteria; the work is done when that scoped component and its expected behavior are clearly specified.

Escrito por el modelo de indexación a partir del texto del issue.