-
Notifications
You must be signed in to change notification settings - Fork 76
Configuring the Output Directory #39
base: master
Are you sure you want to change the base?
Conversation
%SOURCE_DIR% refers the the directory containing the current file. That is the default value to preserve the current behavior.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be a great change, but %SOURCE_DIR%
feels like a hack. How about using null
instead? See this example in the docs for what that might look like.
That is what I initially built, but I switched away from it because a 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 I agree that |
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. |
removes the `%SOURCE_DIR%` workaround
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. |
relative to user's home directory
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. |
addons/vscode/package.json
Outdated
"enumDescriptions": [ | ||
"The folder containing the source file", | ||
"The VSCode workspace", | ||
"Your home directory" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be "The root of the filesystem"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would make sense. I was designing it with a Unix filesystem in mind where VSCode would only have permission to save into the home directory anyway. I guess that is misleading when calling it "Absolute". I can change it to absolute and ensure it can handle ~/
.
src/main.rs
Outdated
file.to_file_path().unwrap().parent().unwrap().to_path_buf() | ||
} | ||
config::OutputRoot::Workspace => world.root().to_path_buf(), | ||
config::OutputRoot::Absolute => home::home_dir().unwrap(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would make the root path an Optional, and make it None
for Absolute
. When the root is OutputRoot::Absolute
, we should use the outputPath
only, which should include /
or C:\
(be an absolute path), and ignore the root.
The By default, it would be relative to the workspace root (or some other project-specific directory), so |
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 Basically, given enough time, I think this feature will be made redundant, so we can invest less in future-proofing it. |
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.
The primary problem with this solution is it would be unable to keep the existing behavior of saving to the source file directory. |
Uses tilde for home directory
I made the absolute path actually absolute (with tilde expansion) |
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.