Unexpected behavior with foot notes

When collapsing the last Item in a outline, the foot notes disappear from the view as well.

Yes, anything below the outline up to another outline of the same level is folded. Clicking the footnote in the body text will select the footnote, and unfold that section.

A wokaround could be to enter a heading as the last line and use an invisible separator (Unicode 2060) or a html space (  or   or  ). In reading mode, this outline will stop footnotes below from being folded, although it introduces extra blank space.

I don’t understand. Please repost this, follow the bug report template and troubleshooting guide and attach screen recording of this happening in the sandbox vault. Moved to help.

Given a document like this:

## First heading

Here we've got two [^1] footnotes [^2]

## Second heading

[^1]: Random phrase
[^2]: Just some more random stuff

If you collapse the Second heading the footnotes also disappears when in live preview or reading mode. This also happens in the Sandbox vault, and I’m thinking it’s kind of to be expected, but I do also see how it’s slightly confusing.

And the workaround, as suggested by vanadium, is to introduce another heading before the footnotes, so that when collapsing the Second heading it’s not the last heading in the document and thusly it’ll not collapse beyond it’s current section.

The question which remains to be answered is whether it’s considered a bug to include the footnote section in the last section or if it should somehow be excluded from that last section due to being footnotes related to the entire document.

1 Like

I’m using ## Footnotes (in my own language) to preface the footnote area. Also, I add:

  • A string ( Footnote) after each [^n]: to make sure the first and consequent lines in the footnotes are the same size.
  • An empty line between any footnotes to eliminate errors in reading mode where all footnotes were merged with the first one (this issue could have been solved in recent months, probably).

For the first to be automatic, I modified the main.js file (as well as the manifest.json) of the plugin ‘Obsidian Footnotes Shortcut’ that I use for adding footnotes like so:
let footnoteDetail = `\n[^${footNoteId}]: Footnote: `;

  • The manifest.json I modfiied to have a unique plugin name so future updates won’t change my modified js file.

Edit: I further modified 2-3 lines in the js. Can share if anybody shows interest.
Edit 2: I used a different solution below to finalize the js file – for my purpose of course.

1 Like

Since you can write footnotes everywhere in the doc (not just at the end), the current behavior is okay.

It’s easy to counter this (mis-)behaviour since you can just add another heading, but I’m still leaning towards that the footnote section isn’t really a part of the last section so it shouldn’t be hidden if the last section was hidden (as shown in my example).

I’m kind of thinking it should always be visible until I explicitly ask for the footnotes to be hidden. Part of why I think like this is exactly because footnotes can come from the entire document, so why should they disappear when the last section of text is collapsed?

But personally I’m not going to pursue this any further, I just wanted to clarify how I feel on the subject.

1 Like

I was not going to, either, but in the meantime I realized the plugin I mentioned above offers a setting for such solution:

As I said I modified the main.js file to 1) preface the footnotes area with Heading 2 (the plugin wants to do Heading 1) and further modified a few other lines to keep the footnote lines nicely separated in order that the reading mode and online versions of the notes look tip-top.

Because I don’t want to get back to this topic in a month’s time when I forget what I did for what purpose, I offer the changes I made in said js file after all:

function addFootnoteSectionHeader(plugin) {
    //check if 'Enable Footnote Section Heading' is true
    //if so, return the "Footnote Section Heading"
    // else, return ""
    if (plugin.settings.enableFootnoteSectionHeading == true) {
        let returnHeading = `\n\n## ${plugin.settings.FootnoteSectionHeading}`;
        return returnHeading;
    return "";
  • The code expects the user to set whatever heading name they like in the plugin settings, so I kept this dynamic.
    let footnoteDetail = `\n\n[^${footNoteId}]: Footnote:  \n`;
    let list = listExistingFootnoteDetails(doc);
    if (list === null && currentMax == 1) {
        footnoteDetail = footnoteDetail;

Search with enableFootnoteSectionHeading and listExistingFootnoteDetails to find the parts I modified.

EDIT. If anyone wants Heading 1 level preface, remove one hash mark (#) before ${plugin.settings.

I just feel like working around is rather time consuming and inelegant. Good UX should just work by itself. Disappearing all document footnotes when the last item in the outline is collapsed is anything but ideal behavior. The footnotes are a feature of the whole document, and can’t all belong to the last item in an outline.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.