#1

Steps to reproduce

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:

Schreiben - Obsidian v0.12.3_102
Schreiben - Obsidian v0.12.3_1021174×1035 115 KB

Actual result

Edit mode:

Schreiben - Obsidian v0.12.3_101
Schreiben - Obsidian v0.12.3_1011174×1035 129 KB

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”.

And yes, it’s reproducable in the Help Vault:

Auswahl_103
Auswahl_103759×259 22.6 KB

#3

There isn’t a formal spec for footnotes in commonmark. It seems that both markdown-it an remark interpret

Text[^1]

[^1]: Note1 

	Notes2

as a multi-paragraph footnote.

This is an upstream issue with hypermd.

#4

Any chance of making this an upstream issue? I guess Obsidian has more influence than a simple user …

And thanks for refining the thread title.

#5

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.

#6

Thanks for the info, so let’s see what the future brings …

#7

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).

1 Like