Currently, the Style and Domain programs are hard-coded into the plugin itself. For this plugin to be at least usable, there should be a mechanism for the user to load their own files. This issues provides two possible designs for this.
Dynamic language ids
A penrose diagram block looks like this now:
```penrose
Vertex a, b, c, d
In this design, the user can set up identifiers for their Style-Domain pairs that will produce objects such as:
```js
{
simpleGraph: {
style: "penrose/simple-graph.style",
domain: "penrose/graph.domain",
},
euler: {
style: "penrose/euler.style",
domain: "penrose/setTheory.domain"
}
}
and use the key as the language id in the code block:
```simpleGraph
Vertex a, b, c, d
This will require the plugin to dynamically call the obsidian API to register new language ids (e.g. via `registerMarkdownCodeBlockProcessor`) when the user changes their configuration to add more files from their vault, which I haven't tested yet.
# Substance front-matter
Instead of relying on the obsidian api, we could also augument the substance language so the user to specify the files to use:
-- type: simpleGraph
Vertex a, b, c, d
...where how `simpleGraph` maps to vault files is also defined by the user configuration, or, even simpler:
-- style: penrose/simple-graph.style
-- domain penrose/graph.domain
Vertex a, b, c, d
Summary
Currently, the Style and Domain programs are hard-coded into the plugin itself. For this plugin to be at least usable, there should be a mechanism for the user to load their own files. This issues provides two possible designs for this.
Dynamic language ids
A penrose diagram block looks like this now:
and use the key as the language id in the code block: