You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: file editor carets and selections drift after the code font changes #35123
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
Open a source or Markdown file in the Files panel so the editable view is active.
Change the code font size (for example 13 → 15) or the code font family in Settings.
Click near the end of a long line, or select text there.
It also happens without touching Settings: client settings hydrate asynchronously, so when the Files panel reopens a file before a non-default code font is applied, the editor is measured with the default font.
Expected behavior
The caret and the selection highlight sit on the characters under the pointer.
Actual behavior
The caret and selection are drawn at the old glyph width, so they drift from the text, and the error grows along the line. Measured after 13 → 15px: −1.1, −1.9, −2.7, −3.5 characters at increasing columns, and line wrap points went stale. With default settings and no change, 246 sampled caret positions matched the text within 1–3px.
Impact
Minor bug or occasional failure
Version or commit
main at d7454f7 (also on a Fedora desktop build merged from main on 2026-11-11)
Environment
Linux (Fedora), desktop and web dev build, @pierre/diffs 1.7.0-beta.3
Logs or stack traces
None. Cause: Pierre's Metrics (dist/editor/textMeasure.js) measures the width of "0" once per editor. init() returns early while the root element is unchanged, and remeasureCharacterWidth() reuses the cached font string, so a later change to --diffs-font-size or --font-mono is never measured.
Workaround
Reopen the file after changing the code font.
A local fix that works: key the <File> in EditableFileSurface on fontSizeCode:fontFamilyCode from client settings, so the editor remounts and measures the font in use. After that, the same 13 → 15px change left 0 of 81 sampled positions off by more than 3px (worst 1.1px). Its cost is that a font change clears that editor's undo history. Fixing the measurement in the vendored @pierre/diffs patch (re-measuring when the computed font changes) would avoid that cost. Happy to open a PR for whichever direction you prefer.
Reported with Claude Opus 5.5 in Claude Code, running in T3 Code.
Activity