In-editor Markdown Preview: caret jumps to top of document on every edit when the file uses CRLF (Windows, 3.25.9)

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

In the in-editor Markdown Preview (the Markdown | Preview toggle on a .md tab, not Ctrl+Shift+V), editing a file that uses CRLF line endings resets the caret to the very start of the document after a keystroke.

What happens:

  • I click in the middle of the document and type one character (or change a single digit).
  • The whole document appears to be re-rendered: the view scrolls back to the top and the caret jumps to the start of the document.
  • The next keystrokes land at the beginning of the first heading. For example, # My plan ends up as # aMy plan.

The same file converted to LF (status bar CRLF → LF, save, reopen Preview) works normally. Several LF test files with similar content never showed the problem; the CRLF file showed it on every edit.

My guess at the cause (not verified against the source): Preview serializes its document back to Markdown with \n. That never matches the \r\n buffer, so the editor replaces the whole model on each edit, and the selection resets to offset 0.

On Windows this is easy to hit, because many tools write CRLF by default: PowerShell Set-Content / Out-File, Python text mode, and Git with core.autocrlf=true, which is the default in Git for Windows.

Possibly related (closed): Plan editor is totally broken. A reply there mentions the caret jumping to the top of Markdown files while typing.

Steps to Reproduce

  1. On Windows, create a Markdown file with CRLF line endings. Mine was a ~150-line plan document with headings; I have not tried a minimal file yet. A CRLF file can be made in PowerShell like this:
    Set-Content test.md "# Title`r`n`r`nline 1`r`nline 2`r`n`r`n## Section`r`n`r`nsome text 123"
  2. Open it in Cursor. The status bar shows CRLF.
  3. Switch the tab to Preview mode.
  4. Click inside a paragraph near the end and type a character, or change a number.
  5. Observe: the view jumps to the top, the caret moves to the start of the document, and further typing goes into the first heading.
  6. Click CRLF in the status bar, choose LF, save, and repeat step 4: editing behaves normally.

Expected Behavior

  • The caret stays where I am typing, regardless of the file’s line endings.
  • Editing in Preview preserves the file’s existing line endings instead of fighting them.

Operating System

Windows 11

Version Information

Cursor: 3.25.9 (stable)
VSCode Version: 1.128.0
Commit: 5d4df965746c5d09740842fc0f1331ba1c157830
Date: 2026-10-15T21:52:24.891Z
OS: Windows 11 Pro for Workstations 10.0.26300

Reproduced on 3.25.9 (current stable at the time). Not yet tried on 3.26.13, and I could not find anything about this in the changelog.

Does this stop you from using Cursor

No. Cursor works, but Preview editing is unusable on CRLF files until I convert them to LF.

7

Hey @Andrew_Wang,

You’re close on the cause. Preview writes its edits back with LF line breaks while your file stays CRLF. When Preview refreshes from the file (for example after a save or auto-save), the two never match, so it treats the file as changed outside the editor and reloads the whole document, which puts the caret back at the start. I’ve flagged this to the team.

In the meantime:

  • Converting the file to LF (status bar CRLF → LF, then save) is the reliable fix, as you found.
  • To keep Markdown files LF going forward, add *.md text eol=lf to a .gitattributes file in the repo, or set Git’s core.autocrlf to input.
  • files.eol only sets the line ending for new files, so it won’t change files that are already CRLF.
  • If you have Auto Save on, turning it off while you edit in Preview may also help, since the reset happens when Preview reloads after the file is saved.
9

Thanks for the clear explanation — that matches what I saw. Converting to LF and enforcing it via .gitattributes (* text=auto eol=lf) plus core.autocrlf=input fixed it for me, so I’m unblocked.

One suggestion for the fix: Preview could preserve the file’s existing line endings when writing back, so CRLF files on Windows don’t get treated as externally modified.

Could you post an update in this thread when a fix ships? Happy to test on a pre-release build if that helps.