For background to this issue, see jgm/skylighting#201

We now have the ability to format code blocks in typst using skylighting. Typst has its own built-in highlighting for code blocks, and so using skylighting will generate less idiomatic and readable typst (full of things like #KeywordTok("import");#NormalTok(" ");#DataTypeTok("Control.Monad");]), but it will have advantages for certain users, allowing the highlighting to be the same in different output formats.

So, ideally we'd like to be able to produce skylighting-enhanced typst on demand, but default to using typst's own idiomatic format for code blocks. The problem is how to achieve this. The writer option writerHighlightStyle defaults to Just pygments, which would use skylighting. And there is no option that says "use idiomatic highlighting."

Proposal

The default syntax highlighting used would by output-format dependent. So, default for HTML would by skylighting with pygments style, but for Typst it would be native typst format.

In T.P.Options, replace writerHighlightStyle :: Maybe Style with something like writerHighlighting :: HighlightOption, where

data HighlightOption =
    Skylighting Style
  | DefaultHighlighting
  | IdiomaticHighlighting
  | NoHighlighting

In command line options, we'd have

--highlighting=none|default|idiomatic|<stylename>|<themepath>.

(or perhaps it should be --syntax-highlighting).

The default value would be --highlighting=default.

--no-highlighting would become a deprecated synonym for --highlighting=none.
--highlight-style would become a deprecated synonym for --highlighting.
Perhaps: --listings would become a deprecated synonym for --highlighting=idiomatic.

DefaultHighlighting would be interpreted differently in different output formats. So, in typst it would be the same as IdiomaticHighlighting and would use marked typst code blocks and code spans. In latex and most other formats, it would be the same as Skylighting pygments (for backwards compatibility).

At the cli level, this would be a backwards-compatible solution; existing conversions would work as before. But at the Haskell library level, it would be a breaking API change, since WriterOptions would change. (There would also be breaking changes, potentially, for pandoc-server users.)

Comments?