MVP project-level configuration

[Myriad-Dreamin]

Rearranged from the cold issue #530

Motivation

Many clients other than VS Code provide bad experience on editing typst documents consisting multiple files.

Description

Possible MVP design. We will add tinymist.input section to typst.toml:

[tinymist]
# versioning the input (entry) resolver
resolver = "v0.0.0-beta"

[[tinymist.input]] # Some entry in this project
name = "Project 1"
entry = "main.typ"

[[tinymist.input]] # Some other entry in this project
name = "Project 2"
entry = "main2.typ"
sys.input = {
  x = "y"
}

Feature 1 (may change in future): The configuration in nearest typst.toml is used by inner documents. If the typst.toml files are nested, the configuration in outer typst.toml files are never used by inner documents. The distance "nearest", "outer", "inner" are determined by their file paths.
Feature 2: If some tinymist.input is used, tinymist will "pin" the entry as the main file to response lsp and preview requests.
Feature 3: If a file belongs to multiple tinymist.input, the first matched one is used in the typst.toml file.
Feature 4: If user switches between files and the files belongs to a same tinymist.input, tinymist will keep use the same tinymist.input and will not detect the entry file again.

Implementation

MVP can only support tinymist.input.name and tinymist.input.entry first. Users must restart the server to reload the configurations.

Questions

Question: It may cause slow start, as tinymist must know all file dependencies correctly, but we have already handle module dependencies resolution as much as possible by static code analysis, which won't trigger any typst compilation (typst::compile), and we can ignore file switches between non-source files.

tinymist/crates/tinymist-query/src/syntax/module.rs

Lines 17 to 22 in 3ed4323

	/// Construct the module dependencies of the given context.
	///
	/// It will scan all the files in the context, using
	/// [`AnalysisContext::source_files`], and find the dependencies and dependents
	/// of each file.
	pub fn construct_module_dependencies(

[Eric-Song-Nop]

This seems great! But why use the name "input" for the entry?

[Myriad-Dreamin]

This seems great! But why use the name "input" for the entry?

The name "entry" is already called the field specifying the entry path to the document. I'm also thinking of a better name, but I didn't get one.

For the reason why I use the name "input", we'll also have "export" or "output" section which will reference the input section. The "export" or "output" section is used for configuring the exporters.

[Myriad-Dreamin]

I've stopped the work on it as I find its behavior is hard to predict thus hard to use. It will be hard to

• have a model in mind why/whether tinymist switches main to/from some files.
• debug the reason why some document to be a main or not to be,

But I also find we can utilize typstExtraArgs to mitigate this problem. For example, when setting "typstExtraArgs": ["main.typ"], main.typ will be used for preview command if no entry argument is provided. With this temporary solution, all users from all editors can overcome editing in a mutliple-files project by setting this argument manually/programatically.