fix(help): align columns + surface sort and screen-switch keys#4
Merged
Conversation
## Alignment
The previous help layout used '%-40s %s' to pad the combined "label +
keys" string for each two-column row. Since key strings vary in length
(e.g. "[s]" = 3 chars vs "[shift+p, P]" = 12), the padding eaten by
the keys segment shifted the right column by 9 characters between rows
— visible misalignment in the user's screenshot.
Rewrote the layout to:
1. Compute max label width and max keys width across all bindings,
2. Render each cell as `padRight(label, maxLabel) + " " + padRight(keys, maxKeys)`,
3. Join left + colSep + right cell per row, falling back to one
column when the terminal is too narrow.
All right-side `[` characters now sit at a stable column.
## Coverage of bindings
Two working bindings were never registered in keymap.Default(), so they
silently never appeared in the help overlay:
* Shift+S — opens the column sort picker (handled in app.go's Update,
bypasses keymap.Matches)
* 1-9, 0 — k9s-style screen quick-switch (handled by numberShortcut
in app.go)
Added both to keymap.Default() with informational keys arrays
("shift+s, S" and "1-9, 0") and short Help labels ("sort" and
"switch screen"). The functional dispatch is unchanged — these
entries are catalog-only so the help renders them.
## Tests
- TestHelpModel_TwoColumnAlignment is a regression test that strips
ANSI from the rendered help and asserts every right-side "[" sits at
the same column across all body rows.
- TestHelpModel_IncludesSortAndScreenSwitch asserts the new entries
appear with their key labels.
- Existing TestHelpListsAllBindings continues to pass.
Verified locally with make ci: gofumpt clean, go vet clean,
staticcheck clean, golangci-lint clean, race tests pass, total
coverage 70.3% (above 70% gate).
torosent
force-pushed
the
fix/help-alignment-and-coverage
branch
from
7f9cc30 to
4a1b576
Compare
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.
Re-opened from #3 (auto-closed when base branch was deleted on PR #2 merge).
Two issues from the user's screenshot
Misalignment
The 2-column help layout used
%-40s %sto pad the combined "label + keys" string. Since keys vary in length ([s]vs[shift+p, P]is 9 chars apart), every right-side cell ended at a different column.Rewrote to
padRight(label, maxLabel) + " " + padRight(keys, maxKeys)with a fixed column separator. Every right-side[now sits at the same column.Two undocumented bindings
Shift+S(sort picker) and1-9, 0(k9s-style screen quick-switch) were both wired up inapp.gobut never added tokeymap.Default(). Added both as catalog-only entries so they show up in?.Tests