search

platers / obsidian-linter

An Obsidian plugin that formats and styles your notes with a focus on configurability and extensibility.
https://platers.github.io/obsidian-linter/
MIT License
1.21k stars 82 forks source link

Bug: "Footnotes after punctuation" and "Re-Index Footnotes" break tasks in footnotes #516

Closed Calorion closed 1 year ago

Calorion commented 1 year ago

Describe the Bug

So this is a weird edge case. Obsidian has an "accidental feature" where you can add tasks to footnotes using this format:

- [ ] [^1]: This is a footnote and a task.

and it works! There are a couple of minor cosmetic oddities, but they are recognized by Obsidian as both tasks and footnotes. However, unsurprisingly, Linter gets confused by them.

How to Reproduce

Steps to reproduce the behavior:

  1. Create a footnote (I use the Footnote Shortcut plugin)
  2. Make it a Task by executing the "Cycle bullet/checkbox" command twice, or inserting - [ ] before the footnote
  3. Lint

If "Footnotes after punctuation" is enabled,

- [ ] [^1]: This is a footnote and a task.

will change to

- [ ] :[^1] This is a footnote and a task.

If "Re-Index Footnotes" is enabled,

- [ ] [^1]: This is a footnote and a task.

will change to

- [ ] [^2]: This is a footnote and a task.

Expected Behavior

No changes should be made, unless re-indexing is actually necessary.

Device

Additional Context

Odd as this "feature" is, I use it often, so I'd love to see these issues fixed!

pjkaufman commented 1 year ago

Thanks for reporting this. Would it be an accurate assessment of this issue to say that the re-indexing is the only thing that needs changing or is there an issue with "Footnotes after punctuation" as well? The reason I am asking is because I am not familiar with footnotes as I don't personally use them and would like to make sure that I would be able to fix them all in one go when this gets worked on.

Calorion commented 1 year ago

Yes, there is definitely a problem with "Footnotes after punctuation": it changes - [ ] [^1]: to - [ ] :[^1]. The changed placement of the colon makes it no longer a footnote.

Note that this is only in the footnotes at the bottom of the page, which makes it tricky. I could easily write something like this:

I use footnotes, like this[^1]: blah blah blah

[^1]: Here's the footnote.

You want to move the first instance of [^1] to the right of the colon, but not the second.

But of course that's exactly what "Footnotes after punctuation" already does. It just doesn't work right when the footnote is also a task.

pjkaufman commented 1 year ago

Gotcha. I will see what can be done. Footnotes are a weak point in my understanding of markdown so it is a little rougher than other areas.

pjkaufman commented 1 year ago

I could be doing something wrong in try to test this out, but using the regexes found here and here, I am not seeing the changes you described to reindexing. Granted, I am not running the rule directly for this test as I am not able to do so right now. I will try when I get back, but, at least for now, I am not seeing the described behavior for re-indexing footnotes when solely using - [ ] [^1]: This is a footnote and a task.

Edit: to explain further, only the second set of regex matches anything and that should mean its value stays the same since it only increments the count of the index to use for the footnote when it has a regex match.

pjkaufman commented 1 year ago

The issue with the punctuation swap is with the regex. The way it is currently written it only does not swap the footnote indicator with the punctuation directly following the footnote key is if it shows up at the start of a line. I can try to update the regex, but I am hitting a couple of problems with that approach for some reason. Hopefully I can resolve them soon.

pjkaufman commented 1 year ago

I think I need to take a step back on this. It was my understanding that the format provided was a valid format for footnotes in github. I am not sure this is the case though as I am not able to get the parsers to recognize the format provided.

Am I mistaken or is that format something that is beyond the specs of what github footnotes are allowed to be, @Calorion?

Edit: I could be wrong, but isn't what you are describing in the post something that callouts somewhat tackle by being minimized or are those too large? I can see how tasks might be a little more inconspicuous, but you would still have the checkbox present on screen unless the theme you use does not.

Calorion commented 1 year ago

Looking at the docs,^1 they seem to be the same. I wonder what happens when I put a task in a GitHub footnote, though?[^3]

pjkaufman commented 1 year ago

Gotcha. I am not entirely sure how to proceed because if this is accidental I am wondering how many other locations this kind of things is possible in Obsidian. The footnote parsing is somewhat neglected and fragile as it stands. While I am fine with updating it, I am not sure if making an exception for tasks opens a can of worms where it creates the expectation that the Linter will work for all special formats that Obsidian allows footnotes in. I am still thinking about this. But since the updates are made using regex in this case, adding an exception can be tedious and cause unexpected results in some cases.

For example, the change I am thinking of would also cause issues for 

- [ ] [^1]: here is some kind of explanation that is not a part of the footnote

[^1]: This is a footnote and a task.

Granted the above is a silly example. But it shows that making changes to how the regex identifies what to ignore, which is currently only footnote keys that start a line, can cause unintentional side-effects.

I will keep thinking about this, but I am not sure how to proceed at this time.

pjkaufman commented 1 year ago

I am thinking I can replace the regex here with ^(.*)(\[\^\w+\]) ?([,.;!:?])(.*)$ and then check if either the line starts with the footnote indicator or it starts with a task. Other exceptions would need to be requested down the road if they are desired for the punctuation change. But I think this would fix the issue here for the punctuation.

pjkaufman commented 1 year ago

I will have to see if I can even reproduce the other scenario and move forward from there.

pjkaufman commented 1 year ago

I am unable to reproduce the issue with re-index footnote. If you provide your data.json, I may be able to reproduce the issue in question for that. Otherwise, I don't think I will be able to do anything about that issue.

pjkaufman commented 1 year ago

I figured out a solution to the issue with the footnote after punctuation, but it is a bit hacky, so I am not the most fond of it, but it should work for this one off scenario for footnotes after a task. I do not plan to add any other exceptions to valid github footnote format though. So just bear that in mind when it comes to working with footnotes. I will see about pushing up the change with the header increment changes once I figure something out for it.

pjkaufman commented 1 year ago

@Calorion , are you still able to reproduce both issues? If so, could you provide your data.json, so I can troubleshoot the issue? I am not able to reproduce the issues on my end. One should have been fixed in the last release and the other I could not reproduce with the example provided.

pjkaufman commented 1 year ago

I haven't heard anything back in a week. If this is still an issue, please reopen this. I am going to close this until I can reproduce the issue with checklists incrementing the value of the footnote key erroneously.

Calorion commented 2 months ago

Thanks for addressing this, but at some point another problem got introduced: During reindexing, "task" footnotes get pulled out of the footnotes list and put above them, leading to this situation:

- [ ] [^4]: The task, formerly Footnote 4

[^1]: Footnote 1
[^2]: Footnote 2
[^3]: Footnote 3
[^4]: Footnote 4, formerly Footnote 5
[^5]: Footnote 5, formerly Footnote 6
pjkaufman commented 2 months ago

@Calorion , could you provide a sample file to work with? I am not sure I can do anything with just the information provided by your comment since I do not really use footnotes. The issue was likely caused by https://github.com/platers/obsidian-linter/pull/1113.

Calorion commented 2 months ago

Here is the file before it is linted: Footnote test before

and after it is linted: Footnote test after.

Calorion commented 2 months ago

Was that sufficient?

pjkaufman commented 2 months ago

Sorry, about the delay, I have been caught up on another feature, but this is on my todo list to get to.

pjkaufman commented 2 months ago

@Calorion, I am having trouble reproducing the scenario which you described above. I am seeing that the values get reindexed, and the numbers get shifted, but I am unable to get the same behavior where the task gets pulled out of the list of footnotes. I am guessing you have more rules than just reindex footnotes enabled. Could you provide your data.json?