feature: engine claim by language and class

[gordonwoodhull]

Apologies for filing a PR over holidays. We can discuss next week when everyone is back, but I wanted to put in a draft.

Marimo's preferred syntax for executable cells is

```{python.marimo}

This already works fine as long as the engine is directly specified in the metadata

engine: marimo

But the engine won't claim the language without this, because jupyter claims python.

I think it would be nice for us to support claiming by both language and first class, because it allows engine discovery to resolve in favor of an engine extension when the extension supports the same language as a built-in engine.

It can be done in a backward-compatible way:

  claimsLanguage: (language: string, firstClass?: string) => boolean | number;

Where old engines still return true, false, treated as 1 or 0, and new engines can return 2.

But this is a fundamental change to engine discovery, so I want to discuss as a group before merging.

@dmadisetti

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scanner	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[gordonwoodhull]

It needs to have a space in order to be compatible with the way we are going to handle this going forward.

```{python .marimo}

The situation in Quarto 1.9 is that we split execution cell blocks with regexes and everything after the language in executable is handled as raw text by the execution engine.

In the near future, we will have a proper parser for Quarto markdown, so these will need to follow Pandoc's conventions, allowing #tag and .class and attr=val explicitly but requiring spaces between them and between the execution language and the extra parameters.

I also need to change false to mean "do not consider" rather than 0 score, because the current logic would cause every language to be claimed even if no engine claimed it. 😛

Hope to get these fixes in and update my fork of quarto-marimo in the next week.

[gordonwoodhull]

Okay, it turned out that my comment above is wrong; our future parser pampa accepts

```{python.marimo}
```

It just doesn't parse .marimo as a class; it interprets the whole string as a language. So this will work along with the preferred syntax

```{python .marimo}
```

and legacy syntax

```python {.marimo}
```

The difference is that the legacy syntax can't claim the language, so it won't work without

engine: marimo

in the metadata. The other two syntax do work without explicit engine, because quarto-marimo claims both language python, class marimo, and also language python.marimo.

I have the PR ready for quarto-marimo and it will work when this is released in Quarto 1.9.19.