FR: tidy footnotes

[calmwaves111]

trafficstars

for footnote, deliberately does not preserve the relation between key and footnote maybe this plugin is a good reference:https://github.com/charliecm/obsidian-tidy-footnotes

[pjkaufman]

I don't believe I follow what you mean by "deliberately does not preserve the relation between key and footnote". Do you mean you are requesting that functionality or that it currently has a bug where the key and value do not stay corresponding to each other?

Thanks for helping me better understand what is meant by your feature request!

[calmwaves111]

[calmwaves111]

before
aaaaaa[^1]
cccccc[^3]
ddddd[^4]
bbbbb[^2]
fffffff[^5]

[^1]: a-footnote
[^2]: b-footnote
[^3]: c-footnote
[^4]: d-footnote
[^5]: f-footnote

after
aaaaaa[^1]
cccccc[^2]
ddddd[^3]
bbbbb[^4]
fffffff[^5]

[^1]: a-footnote
[^2]: c-footnote
[^3]: d-footnote
[^4]: b-footnote
[^5]: f-footnote

[pjkaufman]

Thr scenario provided looks like it is working just fine. The order of the footnotes in the document dictates the key.

Do you mind pointing out what you expected to happen?

Do note that the part about the key and footnote not being correlated is that when you reindex it can change the key for the footnote especially when there are multiple of the same key or the values are out of order.

[calmwaves111]

before
aaaaaa[^1]
cccccc[^3]
ddddd[^4]
bbbbb[^2]
fffffff[^5]

[^1]: a-footnote
[^2]: b-footnote
[^3]: c-footnote
[^4]: d-footnote
[^5]: f-footnote

after
aaaaaa[^1]
cccccc[^2]
ddddd[^3]
bbbbb[^4]
fffffff[^5]

[^1]: a-footnote
[^2]: c-footnote
[^3]: d-footnote
[^4]: b-footnote
[^5]: f-footnote

in fact, linter's work is the following, cccccc[^2] but [^2]: b-footnote,and the above is the effect I want to happen

bfrore:
aaaaaa[^1]
cccccc[^3]
ddddd[^4]
bbbbb[^2]
fffffff[^5]

[^1]: a-footnote
[^2]: b-footnote
[^3]: c-footnote
[^4]: d-footnote
[^5]: f-footnote
after:
aaaaaa[^1]
cccccc[^2]
ddddd[^3]
bbbbb[^4]
fffffff[^5]

[^1]: a-footnote
[^2]: b-footnote
[^3]: c-footnote
[^4]: d-footnote
[^5]: f-footnote

[chrisgrieser]

@irrealizable Hi, a while ago, I was the one contributing that rule to the linter.

The purpose was to be able to fix footnotes when you merge two notes that each have footnotes, e.g. two times [1], something which could not be achieved with the tidy-footnotes plugin. The current re-index-footnote-rule and the tidy-footnote-linting do apply for two different scenarios (one for a single note, the other for when you merged two notes).

That being said, most of the time, I have that rule disable and do run the tidy-footnote plugin's command alongside the linter instead. Since the obsidian footnote plugin is essentially a set of linting rules, it would not be unreasonable to have its linting mechanism sherlocked into the obsidian linter in my view.

Since there basically already is a plugin for footnote-linting, I personally didn't find it worth the time investment to duplicate the feature (which only has the small benefit of "unifying" linting mechanisms in one plugin, which is desirable, but has no direct benefit to users who already have both plugins.) But if someone wants to integrate footnote-linting, I'd agree, that the rules are very much in the spirit of the obsidian-linter and fit in well.

[pjkaufman]

Sorry about the delay @irrealizable. I may have misunderstood this initially, but essentially, you do not want to re-index the footnotes. You just want them moved to the end of the document. Is that correct? If so, why not just use the rule for moving the footnotes to the end of the file or disable the reindexing of the footnotes on the file in question?

Reindexing which I have not looked at in a little while seems to reindex just by going in the order of footnotes found in the document. Is there a reason to index footnotes out of order (i.e. not based on the order they appear in the document)?

[pjkaufman]

I am thinking that I will do the following for this rule:

• Assume that when it runs all footnotes have had their actual values moved to the end of the file leaving only references to footnotes in the file before the footnote reference section
• Preserve key to value relationship on reindex (This will be the complicated part)
• The footnote indexes will be based on the order they are found in the file itself
• If two of the same footnote index are found, the linter will throw an error and require the user to manually update the duplicate footnote index to make it so that the Linter can properly distinguish which keys need to be matched with which footnotes

[pjkaufman]

This should now be on master and will go out with the next release. Please let us know if this is not fixed or if there is some other issue with footnotes.