A formatter for the leptos view! macro
All notable changes are documented in: CHANGELOG.md
cargo install leptosfmt
or for trying out unreleased features:
cargo install --git https://github.com/bram209/leptosfmt.git
Usage: leptosfmt [OPTIONS] <INPUT_PATTERN>
Arguments:
<INPUT_PATTERN> A file, directory or glob
Options:
-m, --max-width <MAX_WIDTH>
-t, --tab-spaces <TAB_SPACES>
-c, --config_file <CONFIG_FILE>
-h, --help Print help
-V, --version Print version
You can configure all settings through a leptosfmt.toml
file.
max_width = 100
tab_spaces = 4
attr_value_brace_style = "WhenRequired" # "Always", "AlwaysUnlessLit", "WhenRequired" or "Preserve"
To see what each setting does, the see configuration docs
Single file
Format a specific file by name
leptosfmt ./examples/counter/src/lib.rs
Current directory
Format all .rs files within the current directory
leptosfmt .
Directory
Format all .rs files within the examples directory
leptosfmt ./examples
Glob
Format all .rs files ending with _test.rs
within the examples directory
leptosfmt ./examples/**/*_test.rs
Currently this formatter does not support non-doc comments in code blocks. It uses a fork of prettyplease for formatting rust code, and prettyplease
does not support this. I would like to not diverge this fork too much (so I can easily keep in sync with upstream), therefore I didn't add non-doc comment support in my prettyplease fork for now.
This means that you can use non-doc comments throughout your view macro, as long as they don't reside within code blocks.
The pretty-printer is based on Philip Karlton’s Mesa pretty-printer, as described in the appendix to Derek C. Oppen, “Pretty Printing” (1979), Stanford Computer Science Department STAN-CS-79-770, http://i.stanford.edu/pub/cstr/reports/cs/tr/79/770/CS-TR-79-770.pdf.
This algorithm's implementation is taken from prettyplease
which is adapted from rustc_ast_pretty
.
The algorithm takes from an input stream of length n
and an output device with margin width m
, the algorithm requires time O(n)
and space O(m)
.
The algorithm is described in terms of two parallel processes; the first scans the input stream to determine the space required to print logical blocks of tokens; the second uses this information to decide where to break lines of text; the two processes
communicate by means of a buffer of size o(m)
. The algorithm does not wait for the entire stream to be input, but begins printing as soon as it has received a linefull of input.