Has the Discourse footnote plugin been considered? I missed footnotes when editing Vendoring third party libraries in CPython
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.
1 Like
Thanks! I keep forgetting that some HTML markup is allowed 
1 Like
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 [1] [2] as footnote markers, and it would be really nice to use proper footnotes instead.
4 Likes
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.
2 Likes
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ā. (>.<)
Posting an example of a footnote [1] for illustration. As with other hyperlinks, the color is a bit dark in the Dark themeāat least in the editorās Preview Pane. 
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?
NOT SOLVED. Still getting nothing but inline notes. A post over at meta.discourse.org shows two locations for the caret:
- 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[^1]
Examples:
The caret in front of the brackets produces an inline note [2].
The caret inside with a label produces a standard footnote [3]. The label itself (at the footnote itself) is identical except has a colon after it, like so [^1]:
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>.
<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
display_footnotes_inline
Iām amongst the number who would prefer ānormalā footnotes[1], 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.
A
i.e. without inline expansion ā©ļø
1 Like
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] & [^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.
A
That excludes the notes from emails, contrary to the other forms.
1 Like
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
display_footnotes_inline
@admins, perhaps this switch immediately above can be turned off to restore standard footnote rendering at message bottomā¦?
From an Admin over at meta.discourse.org:
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:
plugin:discourse-footnote)
2 Likes
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[1] - 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. ā©ļø
3 Likes