Apply local settings to Tinymist

[alexanderkoller]

Summary

Fix Tinymist configuration propagation so project-local .zed/settings.json settings are applied reliably.

This makes the Typst extension pass lsp.tinymist.settings to Tinymist both:

• as initializationOptions, so settings such as exportPdf are available before Tinymist initializes its project/export state
• as workspace configuration, so runtime configuration updates no longer resolve to null

It also normalizes Tinymist settings so both flat keys and tinymist-namespaced keys are available.

Motivation

Project-local Tinymist settings were not applied reliably (cf. #56, #42, #21). In particular, settings such as:

{
  "lsp": {
    "tinymist": {
      "settings": {
        "exportPdf": "onSave",
        "outputPath": "$root/$name",
        "projectResolution": "lockDatabase",
        "typstExtraArgs": ["main.typ"]
      }
    }
  }
}

could fail to make Tinymist compile the intended root document on save.

With this change, Tinymist receives those settings during initialization and through workspace/didChangeConfiguration.

Validation

Tested with a dev extension in Zed using Tinymist LSP mirroring.

Confirmed that the LSP initialize request now contains:

• exportPdf: "onSave"
• outputPath: "$root/$name"
• projectResolution: "lockDatabase"
• typstExtraArgs: ["main.typ"]

Confirmed that workspace/didChangeConfiguration sends the same settings instead of null.

Confirmed that saving a project subfile updates main.pdf.

Also ran:

cargo fmt --check
cargo test
cargo check
cargo check --target wasm32-unknown-unknown

Issues

Should fix #56.
Should fix #42.

Likely addresses #21, since typstExtraArgs: ["main.typ"] is now propagated to Tinymist in the expected configuration shape.

Caveat

I used Codex to implement this fix and did not look at the code deeply. Someone with better knowledge of the extension should review it before accepting the PR. However, I tested the fix locally and it works for me.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @alexanderkoller 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'.

[alexanderkoller]

@cla-bot check

[cla-bot]

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

[MrSubidubi]

Thanks for this!

I am somewhat wondering whether this is not an issue with our documentation more if we suddenly need to merge the settings into the initialization options? Feels somewhat off to me and would like to know more about the root issue.

[alexanderkoller]

Well, if you look at the issues I referenced, they are all caused by the fact that the plugin currently ignores local Zed settings (in <project-dir>/.zed). It is true that, strictly speaking, the README only promises that settings under ~/.zed are being picked up, but (a) this is counterintuitive, one would expect the plugin to see project-local settings just like all the rest of Zed, and (b) it is really important for the Typst plugin to be able to define project-local settings. For instance, in multi-file projects, you have to define the main entry point for the compiler, and that doesn't make sense to define globally.

Lack of support for project-local settings just looked like an oversight to me, and judging from the issues, I'm not the only one. But if there's a better way to achieve this with respect to the internal logic of Zed or this plugin, I'm more than happy to withdraw the PR. My main concern was to get project-local settings working.