Diagnostic issue: `MISSING_CLOSING_TAG_ERROR` on wrong elements

[D-system]

Line: 1
Diagnostic: Opening tag <div> at (1:1) doesn't have a matching closing tag </div>.
Severity: Error

File Content:
Please paste your HTML ERB file content below to help us reproduce the issue:

<div>
  <ul>
    <li><button><button></li>
  </ul>
</div>

Problematic Line:

 <li><button><button></li>

Environment:

• VS Code Extension Version: 0.7.0

• VS Code Version: 1.103.2

• Platform: darwin

• Node Version: v22.17.0

  Herb Settings:

{
"linter.enabled": true,
"trace.server": "verbose"
}

Additional Context:
The entire file has an issue with 2 opened button tags in the middle.
The file was vastly longer and didn't have an error on the buttons themselves.

With the proper closing tag

[marcoroth]

Thanks for reporting @D-system!

Parsing incorrect syntax is quite tricky. Sadly the algorithm for deciding where to put the parse errors is not the best it could be, and that's definitely something that could be improved!

[D-system]

@marcoroth Is it due to the decision algorithm or the parser itself? Can you point me to the part of the code that should be changed? (I don't guaranty I'd be able to do anything though)

[marcoroth]

@D-system I think it's mostly the algorithm in the parser itself. I feel like the make it more accurate you'd either need a (better) lookahead/lookback or you'd need a second pass to can figure out where within the document went wrong and how you could "touch it up".

Currently the algorithm is just trying to matching opening and closing tags in order. Which is also why you get this somewhat confusing error (Opening tag '<div>' at (1:1) closed with '</span>' at (1:7).) here: https://herb-tools.dev/playground?tab=diagnostics#DwEwlgbgfMD0DOAHAhgOykA

That is to say, I think it's definitely worth to implement this architecture to get better error messages and more accurate locations, but it's probably not just a "simple fix".

It's definitely a typical example of this "it's way easier to parse valid syntax than it is to parse invalid syntax" situation 😅

[marcoroth]

I just opened and merged #795 that should help with making the errors easier to understand and more actionable:

[marcoroth]

Going to close this, feel free to re-open if the error persists with v0.8.0.