jjui

Revision Tree Operations

• Revset Auto-complete: Change revsets with real-time auto-complete and signature help.
• Rebase: Rebase a revision or a branch onto another revision in the tree.
• Squash: Combine revisions using the S key.
• Bookmarks: Move bookmarks to the currently selected revision.

Inspection and Preview

• Revision Details: Use l to inspect a revision, allowing for file restoration, splitting, and diff viewing.
• Op Log: Use o to view the operation log and r to restore operations.
• Preview Window: Use p to see the output of jj show (for revisions), jj diff (for files), or jj op show (for operations).

jjui uses a decoupled input architecture to ensure that models remain independent of specific key bindings. The flow of an input event is:

1. Key: The raw key press received from Bubble Tea.
2. Binding: A scoped runtime binding (configured via the dispatcher) that maps a key or sequence to an Action.
3. Action: A declarative identifier for a capability. Actions are bridged to intents via a generated catalog.
4. Intent: The application-level abstraction of what should happen (e.g., Undo, NextRevision). Models implement the logic for these intents.
5. Model Handler: The specific UI model that receives and executes the intent.

Key Rule: Models should never handle raw key bindings; they should only implement behavior for Intents.

Instead of models returning strings, jjui uses a shared DisplayContext (from internal/ui/render) to accumulate draw operations.

The Rendering Lifecycle:

1. The root UI model chooses the active layout.
2. Child models receive layout boxes.
3. Each child draws primitives (text, lists, effects like dim/highlight) directly into the DisplayContext using ViewRect(...) methods.
4. The root model renders the accumulated operations from the DisplayContext into an ultraviolet screen buffer, which is then converted into the final terminal string.

Mouse Interaction: During the rendering phase, components register clickable or scrollable regions with the DisplayContext. When a mouse event occurs, the root model resolves the event against the current frame's registered interactions.

To build jjui from the source code, clone the repository and use go install:

git clone https://github.com/idursun/jjui.git
cd jjui
go install ./...

Lua is integrated as a first-class way to invoke actions within the existing action/intent architecture. It is not a separate UI system.

Capabilities available via Lua:

• Builtin Actions: Any action generated via the //jjui:bind process is exposed under the jjui.builtin.* namespace.
• Configured Actions: Actions configured to resolve to Lua scripts can be executed through the standard action pipeline.

This ensures that Lua scripts follow the same resolution order as key bindings: active operation overrides $\rightarrow$ configured Lua action overrides $\rightarrow$ generated builtin action catalog.

jjui uses code generation to bridge declarative action identifiers with concrete intent values and Lua surfaces.

To define new capabilities:

1. Annotate intent types with //jjui:bind directives in the internal/ui/intents package.
2. Run the generator tool cmd/genactions.

This process automatically generates:

• The internal action-to-intent lookup in internal/ui/actions.
• Builtin action metadata in internal/ui/actionmeta.
• The builtin Lua action surface exposed under jjui.builtin.*.

To begin handling password prompts, you must follow a specific lifecycle:

1. Call StartListening() to initialize the Unix socket.
2. Call Serve(askpass func(...)) to enter the main loop that waits for subprocess connections.

The askpass function passed to Serve is the callback that will actually trigger your UI to prompt the user for a password. It receives the subprocess name, the prompt text, and a done channel that closes when the parent process no longer needs the password.

Note: StartListening must be called before Serve.