Skip to content

Count breakpoint characters in line length calculation#79

Open
sandrewh wants to merge 1 commit intomuesli:masterfrom
sandrewh:fix-breakpoint-linelen
Open

Count breakpoint characters in line length calculation#79
sandrewh wants to merge 1 commit intomuesli:masterfrom
sandrewh:fix-breakpoint-linelen

Conversation

@sandrewh
Copy link
Copy Markdown

Summary

Breakpoint characters (like hyphens -) were written to the buffer without incrementing lineLen. This caused incorrect line length calculations, leading to improper text wrapping when lines contained breakpoints near the wrap limit.

The Problem

When a breakpoint character is encountered in Write():

  1. Any pending space is flushed (addSpace())
  2. Any pending word is flushed (addWord())
  3. The breakpoint character is written directly to the buffer
  4. But lineLen was never incremented for this character

This causes lineLen to be under-counted by the number of breakpoint characters on the current line, affecting subsequent wrap decisions.

The Fix

Add w.lineLen += runewidth.RuneWidth(c) after writing the breakpoint character. This uses runewidth.RuneWidth() for proper handling of variable-width Unicode breakpoints, consistent with how other characters are measured.

Example

Input: "parties who may join xxx as a third-party defendant. \"Parties\" means Licensee and" with limit 76

Before (incorrect - 3 lines):

parties who may join xxx as a third-party defendant. "Parties" means
Licensee
and

After (correct - 2 lines):

parties who may join xxx as a third-party defendant. "Parties" means
Licensee and

Related

Breakpoint characters (like hyphens) were written to the buffer without
incrementing lineLen. This caused incorrect line length calculations,
leading to improper text wrapping when lines contained breakpoints near
the wrap limit.

Uses runewidth.RuneWidth() for proper handling of variable-width Unicode
breakpoints.
@sandrewh
Copy link
Copy Markdown
Author

This bug affects downstream users of charmbracelet/glow (22k+ stars).

When using glow --width N, the incorrect line length calculation causes words to wrap at unexpected positions, breaking the visual formatting of inline code blocks. See charmbracelet/glow#819 for a user report of this behavior.

I noticed PR #56 addresses the same issue and has been open since June 2023. Happy to close this in favor of that one if preferred, or help in any other way to get a fix merged.

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