If you open VSCode, create a new HTML file and type </span> (i.e. close a tag that was never opened), you won’t get any diagnostic error.
I wrote an HTML language server that reports diagnostics of that kind and offers autoformatting a-la-zig-fmt (e.g. you can make it align attributes vertically by adding a space between the last attribute and the >).
First release, autoformatting and diagnostics should work but lots of stuff missing and plenty of code still a bit untested :^)
Contributions to the LSP side of things very welcome as I’m first going to integrate my custom made HTML parser into Zine (static site generator) and will only return to actively polish the LSP later on.
Code & prebuilt exe downloads:
VSCode extension (you will also need to get manually the super executable from above):
Last but not least, the super fmt subcommand doesn’t require LSP support in your editor.
I wrote this because I needed to write an HTML parser from scratch for Zine
autocmd filetype html setlocal makeprg=path/to/superhtml\ check\ %
" if you want to add the formatter to use gq{motion}
autocmd filetype html setlocal formatprg=path/to/superhtml\ fmt\ --stdin
It’s not all that hard to believe that this is a first, because there’s almost no concept of a syntax error in HTML. Browsers are expected to limp along and make the best of it.
Notably, section 1.11.2, Syntax Errors, is non-normative! Meaning there’s not even a concept of a syntax error which conformant browsers need to implement. It’s just a bunch of guidance on the various bad consequences of doing ill-advised things with a byte stream and calling the result HTML.
That is what we want browsers to do, no one wants to visit a URL and see a syntax error instead of a page. But editors? No, from the perspective of writing HTML, there is very much such a thing as a syntax error. It’s very cool that you’ve written an LSP which recognizes that, and I expect it will be a popular choice.
I’m even slightly baffled that usable WASI support in VSCode was added like, yesterday. That’s great news for both the Zig and Rust communities, and now I’m going to go wander off and see if and how WASM binaries are supported in Neovim, because if they aren’t yet they’ll need to be.
I just merged a huge PR that introduces all kinds of validation and LSP goodies.
If any brave person wants to try it out, a bit of real world testing would be appreciated before I tag a release.
Unfortunately my AFL++ setup has bitrot completely so I couldn’t fuzz the new code for now, but I will once Zig’s native fuzzing is up and running.
