explore a fugitive-style buffer model for CI views #274

Closed
opened 2026-04-15 02:54:27 +00:00 by barrettruth · 0 comments
barrettruth commented 2026-04-15 02:54:27 +00:00

The recent GitHub CI work improved terminal-based run viewing, but it also highlights a broader design direction worth evaluating: whether CI should converge on a more fugitive-style buffer model instead of a mix of native terminal views and Forge-managed log buffers.

The idea is not to commit to a redesign immediately. It is to evaluate whether a buffer-centric model would make CI navigation, refresh, reuse of the current window, and contextual actions feel more coherent.

Why this is worth exploring:

  • moving from run view to job view currently raises questions about split-vs-reuse behavior
  • buffer reuse, refresh, and contextual gx / <cr> semantics are easier to reason about when the surface is Forge-managed
  • native CLI terminals still have advantages, but they can diverge from the surrounding editor UX

Questions:

  • should CI run and job views converge on a single buffer model?
  • when should Forge prefer native terminal rendering versus a Forge-managed buffer?
  • should watch/log become two modes of one surface instead of two distinct transports?
  • how much backend-specific behavior is acceptable before the model stops feeling coherent?

Related:

The recent GitHub CI work improved terminal-based run viewing, but it also highlights a broader design direction worth evaluating: whether CI should converge on a more fugitive-style buffer model instead of a mix of native terminal views and Forge-managed log buffers. The idea is not to commit to a redesign immediately. It is to evaluate whether a buffer-centric model would make CI navigation, refresh, reuse of the current window, and contextual actions feel more coherent. Why this is worth exploring: - moving from run view to job view currently raises questions about split-vs-reuse behavior - buffer reuse, refresh, and contextual `gx` / `<cr>` semantics are easier to reason about when the surface is Forge-managed - native CLI terminals still have advantages, but they can diverge from the surrounding editor UX Questions: - should CI run and job views converge on a single buffer model? - when should Forge prefer native terminal rendering versus a Forge-managed buffer? - should watch/log become two modes of one surface instead of two distinct transports? - how much backend-specific behavior is acceptable before the model stops feeling coherent? Related: - #260
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
barrettruth/forge.nvim#274
No description provided.