Skip to content

fix(help): add context awareness to help-view width-based text truncation - #1032

Open
wolfwfr wants to merge 1 commit into
charmbracelet:mainfrom
wolfwfr:fix/help-truncation
Open

fix(help): add context awareness to help-view width-based text truncation#1032
wolfwfr wants to merge 1 commit into
charmbracelet:mainfrom
wolfwfr:fix/help-truncation

Conversation

@wolfwfr

@wolfwfr wolfwfr commented Aug 10, 2026

Copy link
Copy Markdown

Description

This change prevents the width of the output of help.FullHelpView() & help.ShortHelpView() from exceeding the configured 'help.width' when help.width > 0, even when help.width allows enough space for the first x items, but not enough for a tailing truncation-symbol (space+ellipsis).

Prior to this change, the functions would return an entirely untruncated response that would exceed the configured help.width, in the herein described scenario.

Technical Explanation

The pre-existing logic for assembling the string of help-items, would loop through the list of items, without awareness of whether another item would later be added too. When the configured help.width would be sufficient for the current item, the item would be added. When the configured help.width would not be sufficient, the logic would attempt to add a tail instead, consisting of a space & ellipsis (by default) with a total width of 2. If the remaining space was not sufficient for this tail, the logic would instead allow the addition of the item, and the next, and so forth.

In effect, when a subset of help items would fit within help.width with a margin of 0-2, the functions would never truncate, and instead return all items, thus exceeding the configured help.width.

Fix

In order to fix this, I adjusted the loop to be context-aware, i.e. it only appends a help-item when it knows whether or not the item is going to be succeeded by another or not. If it is, the logic ensures there is enough space for BOTH the item & the tail. If the item is not succeeded, it removes the requirement for space for the tail.

The tests were expanded to ensure that the correct response is returned for all edge-cases.

When help.width == 0, all items are returned. While this technically violates the configured help.width, I did not alter this behaviour, because it sat behind a dedicated check and could make sense in use-cases where width is not explicitly configured at all.

AI Notice

In case it matters, no form of AI was involved in the design, implementation, or any other facet of this change.

  • I have read CONTRIBUTING.md.
  • I have created a discussion that was approved by a maintainer (for new features).

DEMO

Short Help View

BUG
bubbles_bug_short_help_demo_compressed

FIX
bubbles_fix_short_help_demo_compressed

Full Help View

BUG
bubbles_bug_full_help_demo_compressed

FIX
bubbles_fix_full_help_demo_compressed

…tion

This change prevents the width of the output of 'help.FullHelpView()' &
'help.ShortHelpView()' from exceeding the configured 'help.width' when
'help.width > 0', even when 'm.width' allows enough space for the first
x items, but not enough for a tailing truncation-symbol
(space+ellipsis). Prior to this change, the functions would return an
entirely untruncated response that would exceed the configured
'help.width', in the herein described scenario.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant