A peculiar "bug" if persistent highlights is "enabled" in codeblock/frontmatter

[nuanjanP]

Just reporting on a small thing I found while playing around with the plugin.

At the moment (July 2024), persistent highlights in codeblocks and yaml frontmatter blocks are disabled (#17). While there are feature requests to add this back as an optional toggle (#33, #52), there's perhaps also an ad hoc way to "enable" this by directing editing the main.js file in the plugins folder of Obsidian. (You search for the string ["hmd-codeblock", "hmd-frontmatter"] and edit this to [])

Now assuming this is done, persistent highlights in codeblocks and yaml frontmatter blocks seems to normally function, except for at least one edge case I found: if a line in a codeblock or yaml frontmatter block is the second line in a file, some persistent highlights in that line can go wonky.

This may look like a strange condition, but it happens quite naturally, namely if the codeblock or yaml frontmatter is the first thing in the file, and that line is the first of the block.

A minimal example would be the following: if you import the following json settings for the plugin

{
  "test": {
    "class": "test",
    "color": "",
    "regex": true,
    "query": "@",
    "mark": [
      "match"
    ],
    "css": ""
  }
}

and add a bit of custom css to make the problem more visible

.test::before { content: "+"; background-color: #f00; color: #fff; }

Now with the following markdown file,

---
property: a@b@c
---

body text

this will happen in source mode:

• expected: property: a+@b+@c
• shown: a+@b@c (the last @ is not highlighted)

this problem also happens with this markdown file

property: a@b@c

body text

but does not happen with this

---

property: a@b@c
---

body text

nor does it happen with this

property: a@b@c

body text

Meanwhile, this problem doesn't happen at all when the text is not in a codeblock or a frontmatter block, even if when that line is the first line of the file.

Again, this is just a phenomenon I've found when modding the plugin outside of its current parameters, so it's not really a "bug" that currently needs fixing. I'm just reporting in case other people are finding the same "problem".