Repository navigation
fix: show the max width in Git Branch and Git Root Dir previews - #667
Open
eric-engberg wants to merge 3 commits into
Open
eric-engberg wants to merge 3 commits into
eric-engberg wants to merge 3 commits into
Conversation
(w) caps how wide the branch or repository name gets, but the TUI preview returned its sample before applying the cap, and the samples (`main`, `my-repo`) were too short to cut anyway. With a cap set, the previews now use a longer sample and cut it the way the status line cuts a real name, so the setting shows as you make it.
render() had grown a preview branch with its own sample, width and link handling; it reads more easily on its own.
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
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.
What
With a max width set (w), the TUI preview of Git Branch and Git Root Dir now shows the cut, e.g.
⎇ feature...at 12 columns. Before, the preview stayed⎇ main/my-repowhatever the setting.Why
w looked like it did nothing in the TUI. Both widgets returned their preview sample before applying the cap. Even if they had applied it, the samples (
main,my-repo) were too short for any useful width to cut. The cap only showed on the real status line, with a long branch or repository name.How
feature/long-branch-name,my-long-repository-name) and cuts it with the sameapplyMaxWidththe status line uses on a real name. That includes the glyph prefix and the raw value form, so the preview shows what the setting does.mainandmy-repo.Demo
w on Git Branch set to 12, then on Git Root Dir set to 10. The preview cuts each sample at its limit.
Powerline
Plain
Testing
⎇ feature...,feature/l...), and Git Root Dir's at 10 (my-long...). Both failed before the fix. The existing tests that expect⎇ mainandmy-repowith no cap still pass.render()had grown a preview branch with its own sample, width and link handling.compare-widgets.shrendersgit-branchthe same in all 14 cases on both commits.main(with docs: explain an empty status line in one folder (workspace trust) #606 and feat(git-is-fork): render forks as an editable glyph #617 merged in locally):bun testgives 2784 pass, 0 fail (Bun 1.4.2), andbun run lintis clean. Under Node 26 vitest, both widget test files pass (46).runtime-check.sh -c max-width-previewon the built CLI: Bun 1.4.2 and Node 26.10.0 agree byte-for-byte, the piped output is the same asmain(the change is preview-only), and the TUI opens and exits under both.⎇ maininto⎇ feature..., with(max:12)on the row.