Embed editing fails for links without `.md` extension, while `Toggle Flow` adds multiple `!`
Environment:
-
Obsidian Version: [Version 1.8.10 (Installer 1.8.10)]
-
Make.md Version: v1.1.7
-
Operating System: macOS [Sequoia 15.4.1]
Problem Description
The core inline editing feature for embedded notes (![[...]]) does not work when the internal link does not contain the .md file extension. The issue persists even in a completely clean environment, indicating a bug within Make.md's link handling logic.
Expected Behavior
When an embedded note, such as ![[My Note]], is displayed, I should be able to click anywhere inside the embed's content to start editing it directly. The Toggle Flow button in the embed's header should also correctly activate the editing mode.
Actual Behavior
The behavior differs based on the link format:
-
For links WITHOUT
.mdextension (e.g.,![[My Note]]):-
Clicking inside the embed has no effect. The cursor does not appear, and editing is impossible.
-
The cursor focuses on the file name link in the header instead of the content.
-
Clicking the
Toggle Flowbutton in the embed's header does not activate editing. Instead, it incorrectly adds a!prefix to the embed link repeatedly with each click, changing it to!![[My Note]], then!!![[My Note]]and so on.
-
-
For links WITH
.mdextension (e.g.,![[My Note.md]]):-
This works correctly. Clicking inside the embed's content successfully activates the inline editing mode.
-
The
Toggle Flowbutton also works as expected.
-
-
For embeds inserted via the
/command:-
The command
/Embed note or spaceincorrectly generates a nested embed:![![My Note.md]]. -
While this malformed embed is surprisingly editable, it points to a related bug in the command's text generation logic.
-
Extensive Troubleshooting Steps Performed
To ensure this was not a local environment issue, I have performed an exhaustive series of troubleshooting steps, none of which resolved the core issue with extension-less links:
-
Restarted Obsidian: No effect.
-
Enabled Safe Mode: Disabled all other community plugins and tested with only Make.md active. The issue persisted.
-
Switched to Default Theme: Switched to the default Obsidian theme to rule out theme conflicts. The issue persisted.
-
Reset Vault Workspace: Deleted
workspace.jsonfrom the.obsidianfolder to reset all layout and navigation history. The issue persisted. -
Cleared Vault Cache: Deleted the
cache,GPUCache, andCode Cachefolders from the.obsidianfolder. The issue persisted. -
Full Vault Config Reset: Deleted all configuration files (
.json) from the.obsidianfolder, only keeping theplugins,themes, andsnippetsfolders. The issue persisted after re-enabling Make.md. -
Reset Global App Configuration: On macOS, renamed
~/Library/Application Support/obsidiantoobsidian.bakto force a complete application-level reset. The issue persisted in the original vault. -
Tested in a Brand New Vault: Created a completely new, empty vault. Installed only Make.md. The exact same behavior occurs: embeds with extension-less links (
![[note]]) are not editable, while embeds with extensions (![[note.md]]) are.
Conclusion
The bug is consistently reproducible in a clean environment and is directly tied to Make.md's inability to correctly handle internal links that do not have the .md extension, which is the default link format in Obsidian. The current workaround is to enable the "Use .md extension for internal links" setting in Obsidian's "Files & Links" options.
This appears to be a regression or a flaw in the file resolution logic within Make.md v1.1.7.
Additional Symptoms & Performance Issues:
In addition to the link handling issue, I've observed severe performance problems when a note contains multiple embedded blocks (especially with the extension-less link bug present).
Screen Flickering: The entire screen or the note pane sometimes flickers rapidly. This suggests a possible infinite render loop or rapid state updates caused by the plugin.
Loss of Interaction: After some time, the entire note view can become unresponsive. It becomes impossible to click, select, or edit any text in the main document, not just within the embeds.
While I haven't found a consistent pattern to reproduce this flickering and unresponsiveness, it seems to be triggered by having several problematic embeds in a single file and interacting with them. This points to a more critical stability issue beyond the initial link resolution bug.
I've also noticed that Toggle Flow adds multiple exclamation marks !