obsidian-linter: Bug: New blank line around code fence rule does not respect callout/blockquote line prefixes for code fence

Describe the Bug

New rule for empty line around code fences does not respect when a code fence is inside a blockquote or callout.

How to Reproduce

> [!callout-name]
> ```language-name
> myCode
> more code
> ```
> ```language-name
> different code
> ```

Enable empty line around code fences rule and lint.

Observed Output

> [!callout-name]

```language-name
> myCode
> more code
> ```

```language-name
> different code
> ```

The first blank line breaks the callout because of the missing >. The > has also been removed from the front of the code fence.

Expected Behavior

Adds blank lines around the code fence that are at the same level of blockquote/callout nesting as the code block. Keeps the starting line of the codeblock at the same level of blockquote callout nesting.

> [!callout-name]
>
> ```language-name
> myCode
> more code
> ```
>
> ```language-name
> different code
> ```
>

OR ignore codefences inside callouts/blockquotes if needed but please do not arbitrarily remove > in front of code fences! OR if codefences inside blockquotes/callouts are fundamentally contrary to this lint rule, please document that so that users will know not to turn it on! I check the diff in the release notes when updating the plugin, before turning on new rules, and did not see anything about this.

Device

  • Desktop
  • Mobile

Additional Context

I have not tested with plain blockquotes or nested blockquotes/callouts but I expect it to be similarly broken there. Use case: I use codeblocks inside callouts to get multi-column features via the excellent https://efemkay.github.io/obsidian-modular-css-layout/multi-column/ If this use case is contrary to the lint rule and I should not be using this lint rule, please document that.

PS: Thanks for all your work and updates on this plugin!

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 24

Most upvoted comments

This bug should be fixed on master now. I plan on making a release either tonight or tomorrow, so it should be fixed in the release as well. Please let us know if the issue still exists.

It should also now ignore nested code blocks 🤞

I wanted to let you know that I have not forgotten about this. But I am trying to think through how to properly handle tables and code fences in blockquotes. I am guessing I will need to ignore them in blockquotes on the initial pass and pass in the new line value after that, but that may not work for double nesting. I could grab the content up until the start of the last new line character if the table does not start a line and that could be used to create the proper new line beginning, but I have not yet decided if this has any flaws.

All in all, I have not forgotten about this, but there are some technical difficulties surrounding making the updates at this time.

Thanks for reporting this issue. It will hopefully be addressed by the next release. In the meantime, you may want to refrain from using this rule or disable it in files with block quotes or callouts.

Seems they do get an empty line added around them. I will add an example for it.

I have to account for multiple blank lines before and after code blocks and blockquotes being cut down to one. But the overall logic seems to be present and working now.

I am currently trying to workout some issues upstream (in a dependency’s code). Once that change is made, it should be possible to move forward with work on this issue. It makes it a lot easier to let the dependency handle the parsing of tables instead of using regex to match tables as that can be iffy some times. I initially added the regex, but handling content in blockquotes will need to wait for tables until I have the ability to get them from the parser directly.

Here is the issue that holds a decent bit of discussion around this: https://github.com/micromark/micromark-extension-gfm-table/issues/5.

I guess the easiest solution for now is to ignore tables in blockquotes (add an example showing the limitation) and then add support for blockquotes once the issue upstream gets resolved allowing for a simplified check.