Add support for Literate Haskell

[infomiho]

I needed support for Literate Haskell for my lectures, so I first made a separate extension, but then I realize this can actually be used as part of the Haskell extension.

I've found an existing Literate Haskell tree-sitter grammar: https://github.com/LaurentRDC/tree-sitter-haskell-literate

I've employed Claude Code to analyze existing extensions and how it could embed Haskell syntax highlighting in lhs code blocks. It supports "bird" syntax, Latex code block and a Markdown style code block.

Tested it locally with my lectures - it works well:

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @infomiho on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[infomiho]

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[MrSubidubi]

Thanks for this! I think it is fine to have (although somewhat of a niece use case), left two comments and then we should be good 🙂

[MrSubidubi]

Are you sure this is a good idea? Did a quick check and https://discourse.haskell.org/t/hls-visual-studio-code-whats-so-great-about-it/4181/16 would suggest otherwise, but that is a bit older, so perhaps I am missing context?

[infomiho]

I checked and HLS does handle .lhs files - the official VS Code Haskell extension also registers HLS for literate haskell. In the HLS source, defaultPluginDescriptor includes LanguageKind_Custom "literate haskell" so all plugins declare support by default, and ghcide has an explicit isLiterate check that runs GHC's unlit preprocessor.

There are known issues with code actions (#2783, #3523) where refactorings break bird-track formatting, but core features like diagnostics, hover, completions, and go-to-definition work. I guess this is good enough? 🤷

[MrSubidubi]

Do we want to have injections for LaTeX / Mardown as well? Or would that not work/break other things?

[infomiho]

I looked into this and the blocker is the upstream grammar. It produces a single prose_line node type for all non-code text, regardless of whether the file uses Bird, LaTeX, or Markdown style. The source_file rule is a flat repeat(choice(...)) with no parent context to distinguish the mode. Maybe I misunderstood something, let me know.

So we can't conditionally inject LaTeX for LaTeX-style files and Markdown for Markdown-style files. Injecting one language unconditionally would break highlighting for the other styles, I believe.

[MrSubidubi]

Will close as stale, but happy to reopen with the comments adressed. Thanks!

[infomiho]

@MrSubidubi sorry for not responding promptly, I'll address them hopefully in the near future as time permits. Thanks you for the review 🙏