refactor(config): remove unused config knobs#326
Merged
barrettruth merged 1 commit intomainfrom Apr 19, 2026
Merged
Conversation
Drop seven config keys that were either redundant, conventional, or expressing preferences nobody actually has: - picker + client: fzf-lua is the only shipped backend; picker auto- detection and the one-registered-client indirection collapse to nothing. Delete lua/forge/client.lua, remove register_client from the public API, simplify lua/forge/picker/init.lua to always use fzf, inline the root-menu picker call in routes.lua, and drop the backend checks in layout.lua / picker/session.lua / health.lua. - keys.back: <c-o> is the vim jump-list convention; hardcode it in the fzf picker and drop the config key. - keys.log.browse: gx is the vim convention for URL opening; hardcode it in term.lua and the two log.lua keymap sites. - keys.log.next_error / prev_error: ]d / [d is the diagnostic convention, more common than the previous ]e / [e. Switch to the diagnostic defaults and hardcode them. - display.widths: the values are inputs to an elastic-width layout planner that is meant to be dynamic anyway; hardcode the current defaults (45/15/35/25) at the four format.lua call sites. Planned fully-dynamic widths land without this knob in the config surface. Tests: remove client_spec.lua and the registered-client extensibility test, prune widths / keys.back / keys.log.browse assertions, update picker_session_spec to drop the non-fzf branch, and fix the health spec's expected ok message. Docs: drop forge-config-picker and register_client sections, update the TOC anchor, and tighten the keys.log description to reflect the hardcoded set.
barrettruth
force-pushed
the
refactor/config-cleanup
branch
from
eee2e68 to
6e17f5d
Compare
barrettruth
added a commit
that referenced
this pull request
Apr 19, 2026
Removing display.widths from config in #326 did not change the elastic-width layout logic: the 45 hardcoded at the format.lua call sites is a soft cap on the column's INITIAL preferred width, and the actual column.max is data-driven (stats.max from layout.measure). layout.plan's grow_once phase then expands the column up to that data-driven max when budget allows. Add a regression test that hands format_prs a single pull request with a title longer than 45 chars and a wide (200-column) budget, asserts the rendered title is untruncated, and thus demonstrates dynamic growth. Complements the existing narrow-layout truncation test (format_prs 'drops secondary metadata before the primary title in narrow layouts') so both ends of the elastic range are covered. Closes #325
barrettruth
added a commit
that referenced
this pull request
Apr 19, 2026
#328) Removing display.widths from config in #326 did not change the elastic-width layout logic: the 45 hardcoded at the format.lua call sites is a soft cap on the column's INITIAL preferred width, and the actual column.max is data-driven (stats.max from layout.measure). layout.plan's grow_once phase then expands the column up to that data-driven max when budget allows. Add a regression test that hands format_prs a single pull request with a title longer than 45 chars and a wide (200-column) budget, asserts the rendered title is untruncated, and thus demonstrates dynamic growth. Complements the existing narrow-layout truncation test (format_prs 'drops secondary metadata before the primary title in narrow layouts') so both ends of the elastic range are covered. Closes #325
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Forge's config surface had accumulated knobs that either duplicated a layer below (`ci.split` vs top-level `split`), expressed a conventional vim binding as a user option (`keys.back`, `keys.log.browse`, `keys.log.next_error` / `prev_error`), represented an extension point with one implementation (`picker`, `client`), or fed inputs into a layout planner that's supposed to be dynamic (`display.widths`). Each one cost documentation, validation, type annotations, test coverage, and public-API surface without a real user ever reaching for it. With only fzf-lua shipped as a picker backend, the `picker` and `client` layers in particular collapsed to a single path with no real branching.
Solution
Remove seven config keys and the plumbing behind them:
Types, validation, defaults, tests, and vimdoc all updated in lockstep. Net change: -338 lines.