Write some text with a footnote reference, and add a two-paragraph footnote. Apparently the needed indentation for the 2nd paragraph is 4 spaces which will show in edit mode as a red “code block”. In preview mode, it is shown correctly.
A restaurant is represented by the Unicode sequence U+1F374,U+FE0E[^1]
[^1]: U+FE0E is the Unicode variant selector for "text style" (so _not_ emoji style), but it is not recognized by all browsers. It is appended to the original character without any whitespace.
U+FE0F is the variant selector for "emoji style". It would change above "🅿" to a "🅿️".
Expected result
If “pseudo-WYSIWYG” must be, then this should also been shown as part of the footnote (i.e., indented and smaller font). Preview mode apparently handles it correctly:
For me, the sudden “jump” to a pseudo-WYSIWYG “footnote representation” in the editor is distracting enough, but having the 2nd paragraph suddenly shown in monospaced red totally confuses and leads to interruption of thought/writing flow. You start maximizing Obsidian, opening another window in preview mode, all just to check if it will be rendered okay …
Environment
Operating system: Linux Mint 20.1/Cinnamon
Obsidian version: 0.12.3, installer 0.12.3
Additional information
This issue is surely related to auto-formatting the “4-space-indent code blocks”.
There many editor parsing bugs which are due to the limitations of hypermd. A rework of the editor is due in the future (both the simple editor and the new WYSWYG editor). At that point, it’s possible we ditch/rework hypermd.
In the interim, you might consider replacing the newlines/spaces with a pair of HTML line breaks: Lorem upsum<br /><br />dolor sit amet. This approach will work across Markdown engines.
Needless context
Compared to HTML, Markdown trades clarity for convenience and drafting speed. HTML knows where the footnote ends because there is a closing tag. That takes extra typing, plus the mental overhead of making sure all the HTML elements nest correctly. (<p><i>lorem</p></i> is not strictly valid.)
Markdown does not specify where a footnote ends. That is where conflicting intuitions get us in trouble. Where you might see a pair of newlines and four leading spaces as an indication to continue the footnote, I might see that same set of symbols as an indication to leave the footnote and enter a code block—or to continue the footnote with a code block. In practice, the interpretation that appears most intuitive to us is probably the one that reflects our immediate intention. Today, on this note, I want those symbols to add up to continuation of the footnote. Tomorrow, I just want to put a code block in the main body of my text and the preceding footnote is weirdly getting in my way.
This is the kind of mess where the person designing the language leaves implementation up to the parsing engines, and those parsing engines do different things with the same symbols. I don’t want to be married to a particular Markdown engine for the rest of my days, so in these situations I jump to the HTML (even when there is a spec in the particular flavor of Markdown I am using).
