fix(lsp): ignore diagnostic check within code blocks

[Rahlir]

resolves: #194.
resolves: zk-org/zk-nvim#161

I tried to be as thorough as possible, let me know if I missed any other markdown ways to denote code blocks. I am also including here two files I have used to test this fix:
empty-note.md
test-note.md

[tjex]

awesome! Thank you! I'll have a look at this tomorrow (or latest day after)

[tjex]

@Rahlir
Can confirm that links within code blocks are ignored, as are links within inline back ticks and indented code; with one exception:

16 |  `[[this is a link existing as the first string on a line]]`     ■ not found

These are getting missed for some reason. Will keep inspecting, but just wanted to chime in as I go.

Thanks again for this!

I do however think we can be clearer with the function and variable naming though.
linkWithinInlineCode does in fact apply to code within inline back ticks as well as code blocks.

I would suggest simply linkWithinBackticks / linkWithinCode instead. Thoughts?

[Rahlir]

Thanks for the feedback!

Hmm, weird that the first string is being missed, that's probably some oversight with 0 index, will fix that asap. Thanks for catching that.

Regarding the function names: I am not entirely sure what you mean. The function linkWithinInlineCode only checks whether the link is within backticks. The code block checks are separate checks done with regexes in the beginning of the for loop over lines. Or did I misunderstand what you meant?

[tjex]

Found it :) It's because when the link is the first string in the line, the backtick == 0.

So backtickId > 0 && backtickId < linkEnd needs to be backtickId >= 0 && backtickId < linkEnd

Regarding the naming, that was my confusion! I thought the function was being used for code blocks as well.
The comment perhaps (partially) threw me off (by my expertise had me already on a pretty diagonal course!)

Perhaps // Recursive function to check whether a link is within inline code block. could be changed to // Recursive function to check whether a link is within inline code.?

[tjex]

great! Thanks for getting these changes back so quickly.

I'm going to give it a second pass with a fresh mind this morning, just to double check myself.

[tjex]

@Rahlir I pushed the 'fixes' from my comments, so you can just pull to check them out if you like. If my comments/changes are misguided, let me know and I'll revert!

[Rahlir]

I think moving the check is fine and you are right that it might shave some execution time off.

Hardcoding insideInline = true is wrong though. The inversion is there because if you have three ticks on one line, the next line is still an inline comment, then if you have three backticks on next line, the third backtick ends the inline comment, it doesn't start it. That's why there is an inversion.

[tjex]

ahhh yep, awesome, thanks for taking the time to explain to me 👌

[Rahlir]

No problem 🙂. All looks good to me now.