Honestly, I either just add the Unicode “superscript number” characters¹ directly, or I insert
<sup> HTML tags2. Either approach seems to work well enough for my purposes, and I don’t need to learn any new markup.
¹ like this…
2 or this.
Thanks! I keep forgetting that some HTML markup is allowed
So… GitHub added support for footnotes: Footnotes now supported in Markdown fields | GitHub Changelog
It ould be nice to get footnote support here as well – I’ve been using   as footnote markers, and it would be really nice to use proper footnotes instead.
Oooh, nice! Thanks for the link
The thing that frustrates me most about Markdown is the inconsistent support for extensions. Sticking to the “lowest common denominator” is too limiting, whereas having to remember what works where is a PITA.
I skimmed this document. Looks like tables work both here and in github, so do fenced code blocks (well, that one’s no surprise). Heading IDs work in neither. Nor do definition lists. Strikethrough works in both. As do task lists, emoji and automatic URL linking.
Supporting footnotes here would keep the supported syntax consistent with github, FWIW. So that’s a +1 from me just for that reason.
I hit this discrepency in Supporting sdists and source trees in PEP 665 - #63 by pradyunsg yesterday.
Exploring this further: PSF is on a hosted-by-Discourse setup/plan, wherein the hosting and plugins on the instance are provided by Discourse. The footnotes plugin is only available in their highest tier of “Enterprise plugins”. (>.<)
NOTE: The footnote is created with the Markdown code
^[This is a handy footnote...] and looks like a proper footnote while editing until you submit the footnoted post. Then it turns into an inline note as in @pradyunsg’s post. This is strange behavior. Does anyone know why Discourse does this?
- Before the square bracket with text inside:
^[A pithy inline note]
- Inside the first square bracket to make a ‘
goto’ or ‘
jump’ type label/reference
The caret in front of the brackets produces an inline note .
The caret inside with a label produces a standard footnote . The label itself (at the footnote itself) is identical except has a colon after it, like so
I always get inline (popup) footnotes. I don’t like them, and I wish I could get “standard” footnotes, but I assumed I was stuck with what Discourse gave me. There’s no “display footnotes inline” setting in the user preferences
I don’t like them, either.
I think I’m going to use folding dropdowns until we have proper footnotes <1>.
Because I can put them immediately after the paragraph that relates to the extra info–and they might, when collapsed, even take up fewer lines than a long footnote would. (Tried to use square brackets around the ‘1’ but couldn’t figure out how to escape the square brackets to keep them from confusing the markdown interpreter.)
Perhaps the word “inline” means you inline the text of the footnote when you write it; that is, it has nothing to do with the rendered output, it has to do with how you write the markdown.
From Discourse Footnote - plugin - Discourse Meta, it seems to be a site setting:
Additionally you can either enable or disable “inline” expansion with
I’m amongst the number who would prefer “normal” footnotes, but as it is a site-wide setting it would be up to the @admins to change it, and I’m not even sure they can – Pradyun mentioned we’re on a hosted plan, so we might not have access to every setting.
i.e. without inline expansion ↩︎
We’re supposed to have the option of either inline or footnote. That’s why there are two positions for the caret.
Discourse’s meta.discourse.org site is having the same problem. Evidently it’s supposed to work as advertised but got broken somewhere along the line. It was reported on 31 March and was acknowledged as WIP on 1 April by one of the Discourse founders.
@mlgtechuser – Erlend is correct here. The two ways of writing the note (
[^1]: spam spam ham eggs vs
^[spam spam ham eggs]) are divorced from the rendering of the footnotes into HTML – that is what is controlled by the site setting.
I believe the bug report you linked is about referencing the same footnote twice rather than the HTML display – a PR to fix that was merged in early April.
That excludes the notes from emails, contrary to the other forms.
I believe you’re correct, Adam. The topic name over there could use some clarification.
The GIF shows the mark-down pasted in from the footnote announcement with the
[^sartre] + [^sartre]: labels rendering in the topic as inline “tooltip”, but the second reference doesn’t trigger any popup text.
Yes, the Footnote Announcement Post makes a distinction between “single line and multi paragraph footnotes”.
Additionally you can either enable or disable “inline” expansion with
@admins, perhaps this switch immediately above can be turned off to restore standard footnote rendering at message bottom…?
From an Admin over at
If you type ‘footnote’ into your settings search bar it should pop up? The other good way to find the settings for an individual plugin is by going to the plugin page and clicking on the settings next to the specific one (which filters the settings with one of these:
Not that I doubt you all, but I’d be curious to hear the specifics about the disadvantages of the inline footnotes relative to displaying them all the way at the bottom of the post. It seemed like a lot of people mentioned they didn’t like them, but it wasn’t really clear to me their specific reasons.
Personally, I prefer having the note local to where it references, as opposed to having to disrupt my reading flow and jump all the way to the bottom of a long message and back to read the note, and it would discourage me from using them myself to add ancillary details.
However, there are a few practical issues with it. Besides the preview rendering inconsistency, the UX for copying them is very finicky (you have to hold down on the text, and then before letting go press Ctrl-C, since it will vanish once you release your mouse), and quoting them does not work correctly (see below), though hopefully those bugs could be fixed.
Test quote (to illustrate the bug quoting footnotes):
They are not visible without clicking on them (yes, I know that in a long post you have to scroll down, but not all posts are that long, and even if they are, you can scroll with the keyboard).
You can’t (easily) copy and paste from an inline footnote. You can’t quote an inline footnote. You say “those bugs could be fixed”, but the lack of an option to choose the rendering format could just as easily be fixed, surely?
Your “test quote” quotes some normal text with its footnote (and, by the way, it doesn’t render correctly for me). I’m talking about just quoting part of a footnote - and yes, I have wanted to do that in the past.
Having said this, I’m not trying to claim that inline footnotes are objectively bad, just that people have different preferences, and those preferences are apparently strong enough that having an option, so the user can choose for themselves, seems like a sensible approach.
For example, “just these four words” from this footnote. ↩︎