typst-lsp icon indicating copy to clipboard operation
typst-lsp copied to clipboard

Configuring the Output Directory

Open liamrosenfeld opened this issue 2 years ago • 12 comments

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.

liamrosenfeld avatar Mar 27 '23 04:03 liamrosenfeld

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.

liamrosenfeld avatar Mar 29 '23 05:03 liamrosenfeld

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.

beeb avatar Mar 29 '23 05:03 beeb

Just pushed the setting split

liamrosenfeld avatar Mar 29 '23 17:03 liamrosenfeld

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.

beeb avatar Mar 29 '23 17:03 beeb

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.

liamrosenfeld avatar Mar 29 '23 17:03 liamrosenfeld

I implemented the absolute option. I just need to fix the issues caused by the merge conflicts.

liamrosenfeld avatar Mar 29 '23 17:03 liamrosenfeld

I resolved the merge conflict issues

liamrosenfeld avatar Mar 29 '23 22:03 liamrosenfeld

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.

beeb avatar Mar 30 '23 04:03 beeb

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.

nvarner avatar Mar 30 '23 06:03 nvarner

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.

nvarner avatar Mar 30 '23 06:03 nvarner

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.

liamrosenfeld avatar Mar 30 '23 14:03 liamrosenfeld

I made the absolute path actually absolute (with tilde expansion)

liamrosenfeld avatar Mar 30 '23 18:03 liamrosenfeld