typst-lsp
typst-lsp copied to clipboard
Configuring the Output Directory
Allows saving files to other directories (relative to the workspace root) by setting a VSCode setting.
When started with %SOURCE_DIR%, it refers to the directory containing the current file. That is the default value, preserving the current behavior. That is the cleanest and most extensible method I've thought of so far. If anyone has a better system, I can update this.
That is what I initially built, but I switched away from it because a ["string", "null"] setting type does not have a graphical editor in VSCode (it just presents a button to edit it directly in the JSON file).
Another possible method I just thought of would be to have a separate setting that is a dropdown of 'source file directory' or 'workspace directory' to select what the output directory is relative to. That would also keep the functionality of saving in a subdirectory of the source file directory (which %SOURCE_DIR%/subdir allows for). The main downside of this method is that it has two settings to control one thing.
I agree that %SOURCE_DIR% is a hack, so I would be happy to switch to whichever of those you think is better.
Another possible method I just thought of would be to have a separate setting that is a dropdown of 'source file directory' or 'workspace directory' to select what the output directory is relative to.
I also think this would be preferrable. One setting called something like "output directory root" (dropdown, with maybe a third option being "absolute path", and the default being "source file directory") and another "output directory path" relative to the root selected above.
Just pushed the setting split
Should an absolute path be an option? Trying to think if people would actually want to output to a directory completely unrelated to their workspace or source dir.
I think that could be useful. They might want to have a single cache folder for all of their live previews to intermittently clear. I'll implement it.
I implemented the absolute option. I just need to fix the issues caused by the merge conflicts.
I resolved the merge conflict issues
Sorry to comment again on this... Should people be able to customize the name of the output file? Should it be then included in the path setting directly or be a separate setting? This could also be added as a later date, or not at all.
The ["string", "null"] editor is unfortunate, since that would a nice solution. To propose another alternative, we could keep one string for the output directory and treat it like a CLI tool would.
By default, it would be relative to the workspace root (or some other project-specific directory), so output/pdf/ would target a subdirectory of the workspace. Then, if the user enters an absolute path, like /home/username/typst_goes_here, output files to that directory unrelated to the workspace.
I don't like leaving in hacks, but I'm actually okay with small ones here. As Typst matures, I expect its offline users will need to manage growing projects, collaborators over Git repositories will need to share local configurations, the planned package manager will need a way to provide packages, and so on. We'll probably see some kind of build system tool, like cargo, that saves its configuration into a file that we can read. That should specify where to output files.
Basically, given enough time, I think this feature will be made redundant, so we can invest less in future-proofing it.
Sorry to comment again on this... Should people be able to customize the name of the output file? Should it be then included in the path setting directly or be a separate setting? This could also be added as a later date, or not at all.
I think that changing the name would be best suited for another PR. These changes are extensible to support it in the future, but that brings up a new collection of setting design questions that would probably be suited for another PR.
To propose another alternative, we could keep one string for the output directory and treat it like a CLI tool would.
The primary problem with this solution is it would be unable to keep the existing behavior of saving to the source file directory.
I made the absolute path actually absolute (with tilde expansion)