fix column black bars for file names with multibyte characters

[gmist]

Problem

When a folder contains files with non-ASCII names, the file panel breaks: black bars appear in the row of such files and the size and date columns shift out of place.

Cause

The code measured name length with len(s) and padded or cut strings by that value. len(s) returns the number of bytes, not the number of visible characters. Many characters take more than one byte in UTF-8 but occupy only one cell on the screen. So for a name like größe.txt:

len() reports 11
the terminal shows 9 cells

All column math was based on the wrong number. Cutting by byte index could also split one character in half which produced broken characters.

Fix

All helper functions now measure width in terminal cells, not bytes:
ansi.StringWidth for measure
ansi.Truncate, ansi.TruncateLeft for to cut safely

These functions from github.com/charmbracelet/x/ansi. This package is already in dependencies: lipgloss and bubbletea use it. It measures strings the same way bubbletea draws them, so the panel grid always matches what the renderer puts on screen.

[kongoncharuk]

Automated code review

Nice catch on the root cause — ansi.StringWidth / ansi.Truncate are the right primitives here, and the change also incidentally fixes a slice-bounds panic that main hits when rendering the panel at very narrow widths. A few things to address before this goes in.

1. The column shift is still reproducible (blocking)

ansi.Truncate(s, n, "") drops a grapheme that straddles cell n instead of clipping it, so for a 2-cell character it returns n-1 cells. The truncating branches in truncOrPad don't pad back up:

truncOrPad("日本語のファイル名前です.txt", 10) -> "日本語..."  width 9
truncOrPad("🎉🎉🎉🎉🎉report.pdf",      10) -> "🎉🎉🎉..."  width 9
padLeft   ("漢字漢字",                    5) -> "漢字"      width 4

renderRow concatenates the columns with no further padding, so the row comes out one cell short and lipgloss.JoinHorizontal in app.go pads the gap with unstyled spaces — an unthemed cell and a jagged right border, on roughly half of all panel widths. Smaller than before, but the same bar.

Affected: internal/ui/panel/panel_view.go:159 (truncOrPad) and :170 (padLeft), plus internal/ui/quickview/quickview.go:308, which is reached from both the content lines and the header.

Fix is to pad after truncating:

out := ansi.Truncate(s, width-3, "") + "..."
return out + strings.Repeat(" ", width-ansi.StringWidth(out))

The same shape is latent in padStr (bookmarks, fuzzy), padOrTrunc (menubar), PadOrTrim (completion) and padRight (dialog) — their truncate branches happen to be dead today because callers pre-clip, but they're one caller change away from the same bug. Worth fixing uniformly.

Side note: overlay.TruncateLeftEllipsis already anticipates exactly this hazard with its widening loop — that care just didn't reach the panel helpers.

2. New infinite loop in wrapText (blocking)

internal/ui/dialog/dialog.go:546 — ansi.Truncate(text, width, "") returns "" when width == 1 and the first grapheme is 2 cells (or when width <= 0). Then cut == 0 both times, text[:0] is appended, text never shrinks, and the loop appends empty strings forever.

wrapText("Delete 日本語.txt?", 1) -> hang
wrapText("plain ascii", 1)        -> terminates

Reachable via a dialog message starting with a wide character in a 9-column terminal (msg.Width has no floor). The old cut = width fallback always advanced by at least a byte. Suggested guard: clamp width to >= 1 at the top, and if cut == 0 { cut = len(head); if cut == 0 { cut = 1 } }.

3. Same bug class left unconverted elsewhere

• internal/ui/cmdexec/cmdexec.go:241 — dir = "..." + dir[len(dir)-innerW+5:] is byte-for-byte the pattern replaced in panel_view.go:42, on the same kind of user-supplied path. Mojibake for a non-ASCII cwd, and a slice-bounds panic when innerW < 5 — the exact panic this PR removes from the panel header.
• internal/ui/cmdexec/cmdexec.go:290 — line = line[:innerW] on command output.
• internal/ui/themepicker/themepicker.go:237 and internal/ui/help/help.go:172 — byte slicing; no live trigger today since those strings are ASCII, but same class.

4. Rename dialog corrupts multibyte names

internal/ui/dialog/dialog.go:204-227 and :337-372. inputPos is a byte index stepped one byte at a time, and cursorCh = string(m.input[m.inputPos]) reinterprets a single byte as a code point. Select 日本語.txt, press F6, backspace 5x:

bksp4  "日本語"            valid utf8
bksp5  "日本\xe8\xaa"      invalid utf8

Enter then submits that as the rename target. Same path for Go To and Copy/Move-as. Also labelW := len(label) on line 337 sizes the field in bytes. This feels in scope given the PR's goal, and it's in a file you already touched.

Smaller version of the same thing: internal/ui/copypath/copypath.go:107-109 still sizes the box with len() while the View it feeds now measures cells.

5. Two undocumented behavior changes

• The panel header's clip marker changed from "..." to "…" (via TruncateLeftEllipsis). panel_view.go now shows both glyphs in one view — … in the header, ... on the truncated filename right below it.
• wrapText changed the break scan from text[cut] to text[cut-1], which moves where lines wrap for plain ASCII too. That's an algorithm change rather than a width fix — worth calling out in the description or reverting.

6. Smaller notes

• overlay.go:122-125 — the comment says TruncateLeft "keeps the whole character and pads with a space." It doesn't; there's no padding path in ansi, it just emits the straddling cluster whole, which is why the tail can run one cell over. The loop is right, the stated reason isn't, and someone "simplifying" on that comment would reintroduce the overflow.
• Seven near-identical pad/truncate helpers now exist across packages (padStr x2, padRight, padOrTrunc, padLeft, truncOrPad x2, PadOrTrim). This PR shows the right move by pulling TruncateLeftEllipsis out into a shared helper — the rest could follow, especially since issue 1 above now needs the same fix applied in seven places.
• Mixed vocabulary: completion.go:53-60 measures with lipgloss.Width and truncates with ansi.Truncate in one 8-line function; copypath.go:158 uses ansi.StringWidth while its consumer padStr still uses lipgloss.Width. Equivalent, but grepping lipgloss.Width to audit width handling now misses half the sites.
• dialog.truncateLeft is now a pure one-line forwarder with two callers; they could call overlay.TruncateLeftEllipsis directly like the other four packages do. The original doc comment explaining why left-truncation matters for paths got dropped.
• No tests in the diff. TruncateLeftEllipsis is table-test-shaped, and a table covering CJK / emoji / width==1 would have caught issues 1 and 2 together. CI runs go test -race ./..., so it'd actually gate.