[BUG] `{{CURSOR}}` silently not placed when capturing to a large open note

[pkelly102]

Describe the bug
A Capture with {{CURSOR}} in its format doesn't move the cursor when the destination note is large (~100KB+) and already open in the active editor. There's no error or notice. The cursor just stays where it was, or ends up at the start of the inserted line. Small notes work fine, so it looks intermittent.

To reproduce

1. Capture choice: "Capture to active file", Insert after # Encounters, format {{VALUE:Note}} {{CURSOR}}. "Run Templater on entire destination file" is off.
2. Open a note of ~130KB that has a # Encounters heading, and put the cursor somewhere below the heading.
3. Run the capture.
4. The text is inserted correctly, but the cursor doesn't move to the {{CURSOR}} position.

Results from running the same choice via quickAddApi.executeChoice (cursor on the captured line, out of 3–4 runs):

Note size	Cursor placed	editor.getValue() matches immediately after vault.modify
2 KB	3/3	yes
40 KB	3/3	yes
132 KB	0/3	no; matches after ~13–21 ms
250 KB	(only tested with the patch below)	no; matches after ~25 ms

Root cause (from reading 2.27.0 main.js)

• The capture writes with app.vault.modify(file, newContent), then the cursor helper (minified Vg(app, file, offsets, content)) is called right away.
• The helper compares editor.getValue() to content and returns false on mismatch (if(s!==n){if(s!==n.replace(/\r\n?/g,"\n"))return!1; …}).
• For small files, Obsidian applies an external vault.modify to an open editor synchronously, so the check passes.
• For larger files, the editor update lands a few ms later, so the check fails every time and placement is skipped silently.

Suggested fix
Either option works:

• When the destination is the active file, wait for the editor to reflect the write before placing the cursor. For example, retry the comparison for up to ~1s, or wait on the editor's next change/editor-change event.
• Or, for the active file, apply the capture through an editor transaction instead of vault.modify, so the offsets are always in sync.

I'm running a local patch that retries the comparison every 25 ms for up to 40 tries (returning true while a retry is pending so callers don't fall through to a second placement). It fixed the problem at every size above (4/4 each at 2 KB, 132 KB and 250 KB).

Related, possibly worth documenting
When "Run Templater on entire destination file after capture" is on, the {{CURSOR}} position is discarded on purpose (cursor = null when afterCapture === "wholeFile"), even if the file contains no <% %>. Users switching from <% tp.file.cursor() %> (which needed that setting) to {{CURSOR}} will hit this. A note in the {{CURSOR}} docs, or only discarding when Templater actually changed the file, would help.

Environment

• QuickAdd 2.27.0
• Obsidian 1.13.7, macOS
• Templater installed (auto-jump to cursor on; no tp.file.cursor markers in the note)

[chhoumann]

Thanks for this report. Your analysis was spot on, down to the timing table, and made this quick to pin down.

Fixed in #1801, which will ship in the next release.

What was going on: Obsidian only keeps a note's content cached after a write if it's 65,536 characters or less. An open editor showing a bigger note re-reads it from disk after QuickAdd's write has already finished. So QuickAdd compared the old editor text with what it wrote, saw a mismatch, and silently skipped the cursor. That's why 40 KB worked and 132 KB didn't.

It turned out to be a bit wider than big notes. If you typed something and ran a capture within Obsidian's ~2 second autosave window, QuickAdd read the note from disk without your latest typing. Obsidian then showed "modified externally, merging changes automatically" and the cursor got lost there too, at any note size.

The fix: instead of retrying the comparison, QuickAdd now writes through the open editor when the note is open (the second option you suggested). The editor already contains the capture when the run finishes, so there's no timing to wait on. It also means:

• {{CURSOR}} lands correctly at every size I tested, up to 5 MB.
• Typing you haven't saved yet is kept, and the "modified externally" notice no longer shows up.
• Folds, scroll position and undo history are kept, and Ctrl+Z undoes a capture in one step.
• The same fix covers Apply template (top/bottom/cursor), template overwrite, and "append link to file" when the target note is open.

About the "Related" part: with "Run Templater on entire destination file after capture" turned on, QuickAdd now only drops the {{CURSOR}} position if that Templater pass actually changed the note. A note with no <% %> tags keeps the cursor, so switching from tp.file.cursor() to {{CURSOR}} works with the setting on. The Capture docs mention this now.

I tested it with Templater installed and "auto jump to cursor" on, same as your setup. If anything still looks off after you update, please reopen this and let me know.

[chhoumann]

Hi @pkelly102 - the fix is out now in QuickAdd 2.28.0, so you can drop your local retry patch. I re-ran your setup on the released version: insert after # Encounters with {{VALUE:Note}} {{CURSOR}}, into a ~130 KB note that's open in the editor. The cursor lands at the marker right away.

Update under Settings → Community plugins → Check for updates. If anything still looks off after updating, please reopen this and let me know.

Thanks again for digging into this so thoroughly!