Basic formatter for the Typst language with a future without a future 😄!
It's been a fun ride everyone but that's where I stop, feel free to fork etc.
last typst supported version is 0.10.
If I get the formatter fever again I'll probably try contributing to https://github.com/Enter-tainer/typstyle/ and you should check it out ;).
Config file: run typstfmt --make-default-config
to create a typstfmt.toml
file that you can customize!
The following lines show the contents of a simple typstfmt.toml
file:
indent_space = 2
max_line_length = 80
experimental_args_breaking_consecutive = false
line_wrap = true
// typstfmt::off
and // typstfmt::on
. (Experimental and broken)It's not always pretty, it sometimes break the code in math mode, but it should be safe for code and markup.
cargo install --git https://github.com/astrale-sharp/typstfmt.git
Optionally, you can setup a git hook to format your files at each commit:
echo "set -e
for f in \$(git ls-files --full-name -- '*.typ') ; do
typstfmt --check \$f --verbose
done" > .git/hooks/pre-commit
chmod +x .git/hooks/pre-commit
Now if you try to commit unformatted files, they will be caught and the commit will fail, telling you which file should be fixed.
Notes:
- You should probably avoid doing this at the moment, as typstfmt is not quite stable yet
- Be careful if you have another commit hook setup, as the command above will replace it entirely!
Since we're visiting a AST (which is a tree) we have a recursive function
visit(node: &LinkedNode, ctx: &mut Ctx)
that meets all the nodes in the tree.
It formats the children first (bottom up), then the parent decide what to do with their children.
Children have access to arbitrary context (they can know the kind of their parents, who are their siblings etc).
Once the test suite is large enough and the formatting is satisfying, create an abstraction to make the codebase easier to work with.
One person cannot come up with good formatting default. This will first be configurable and then with experience and opinions from the community, default will be tuned.
We use insta! If you don't have it installed take a look
here (hint: use cargo binstall
)
To see how it currently formats all the snippets:
cargo test
, a failing test indicates one of the snippets displayed in
the next step is not formatted like this anymore.show_all.sh
Of course not! We have tracing enabled during tests!
If you're contributing tests you should add a test case under src/tests
for
instance: make_test!(call_func_empty, "#f()");
then running your tests: cargo test && cargo insta review
If the info log isn't enough, run DEBUG=true cargo test
. If you wish to pipe
to a file run NO_COLOR=true cargo test
you may also set the NOLOG
env
variable if you wish to disable logging entirely.
On the fmttest branch, you can see the skeleton of a program that will automate finding which range, when formatted, was not valid anymore (broke the semantic of the code).