Skip to content

[Bug]: file editor carets and selections drift after the code font changes #35123

Closed

Description

@chreko

Before submitting

  • 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

  1. Open a source or Markdown file in the Files panel so the editable view is active.
  2. Change the code font size (for example 13 → 15) or the code font family in Settings.
  3. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions