Summary
The current-file format tokens embed the active file's basename into their output, and the format pipeline resolves them as a sequence of independent regex-replace passes. When a note is literally named like a token — e.g. {{filenamecurrent}}.md, {{title}}.md, {{linkcurrent}}.md, {{linksection}}.md — an earlier pass generates a link/text containing that token, and a later pass re-scans and rewrites it.
This is pre-existing (not introduced by #1356):
- A note named
{{filenamecurrent}}.md with a {{linkcurrent}} body: {{linkcurrent}} → [[{{filenamecurrent}}]], then replaceCurrentFileNameInString's while loop replaces {{filenamecurrent}} with the same basename forever → the formatter hangs.
{{title}}-named files can similarly corrupt a generated link.
What #1356 already did
PR #1356 ({{linksection}}) hardened the link tokens: {{linkcurrent}} + {{linksection}} are now resolved in a single non-rescanning pass (replaceCurrentFileLinksInString), so they no longer corrupt each other. But {{filenamecurrent}} / {{folder}} / {{title}} still run as separate later passes and can re-scan a generated link's basename.
Proposed fix
Resolve all file/note-derived tokens ({{linkcurrent}}, {{linksection}}, {{filenamecurrent}}, {{folder}}/{{folder|name}}, {{title}}) so that already-generated output is never re-scanned — either:
- one combined function-replacer pass over the alternation of those tokens, or
- a sentinel/placeholder approach (replace tokens with opaque sentinels, rehydrate at the very end).
Preserve each token's existing required/optional/empty/circular semantics. Add regression tests for each token-named-file direction (and assert no infinite loop).
Severity
Low real-world impact (no one names a note {{filenamecurrent}}.md), but it's a latent hang/corruption, so worth hardening. Found by Codex review on #1356.
Summary
The current-file format tokens embed the active file's basename into their output, and the format pipeline resolves them as a sequence of independent regex-replace passes. When a note is literally named like a token — e.g.
{{filenamecurrent}}.md,{{title}}.md,{{linkcurrent}}.md,{{linksection}}.md— an earlier pass generates a link/text containing that token, and a later pass re-scans and rewrites it.This is pre-existing (not introduced by #1356):
{{filenamecurrent}}.mdwith a{{linkcurrent}}body:{{linkcurrent}}→[[{{filenamecurrent}}]], thenreplaceCurrentFileNameInString'swhileloop replaces{{filenamecurrent}}with the same basename forever → the formatter hangs.{{title}}-named files can similarly corrupt a generated link.What #1356 already did
PR #1356 (
{{linksection}}) hardened the link tokens:{{linkcurrent}}+{{linksection}}are now resolved in a single non-rescanning pass (replaceCurrentFileLinksInString), so they no longer corrupt each other. But{{filenamecurrent}}/{{folder}}/{{title}}still run as separate later passes and can re-scan a generated link's basename.Proposed fix
Resolve all file/note-derived tokens (
{{linkcurrent}},{{linksection}},{{filenamecurrent}},{{folder}}/{{folder|name}},{{title}}) so that already-generated output is never re-scanned — either:Preserve each token's existing required/optional/empty/circular semantics. Add regression tests for each token-named-file direction (and assert no infinite loop).
Severity
Low real-world impact (no one names a note
{{filenamecurrent}}.md), but it's a latent hang/corruption, so worth hardening. Found by Codex review on #1356.