|
21 | 21 |
|
22 | 22 | Features:
|
23 | 23 | - **Customizable** output styles.
|
24 |
| -- Call your own module's code within the docstring, e.g., to **render examples**. |
| 24 | +- Automatically [**render code examples**](#example). |
25 | 25 | - **Annotate types** of parameters and return values.
|
26 | 26 | - Automatically read off default values for named parameters.
|
27 |
| -- **Help** feature for your package. |
28 |
| -- Docstring tests. |
| 27 | +- [**Help** feature](#generate-a-help-command-for-you-package) for your package. |
| 28 | +- [Docstring tests](#docstring-tests). |
29 | 29 |
|
30 | 30 |
|
31 | 31 | The [guide](./docs/tidy-guide.pdf) fully describes the usage of this module and defines the format for the docstrings.
|
@@ -81,6 +81,35 @@ The code in the docstrings is evaluated via `eval()`. In order to access user-de
|
81 | 81 | ```
|
82 | 82 | The docstrings in `my-module.typ` may now access the image with `#img` and can call any function or variable from `my-module` in the style of `#my-module.my-function()`. This makes rendering examples right in the docstrings as easy as a breeze!
|
83 | 83 |
|
| 84 | +## Generate a help command for you package |
| 85 | +With **tidy**, you can add a help command to you package that allows users to obtain the documentation of a specific definition or parameter right in the document. This is similar to CLI-style help commands. If you have already written docstrings for your package, it is quite low-effort to add this feature. Once set up, the end-user can use it like this: |
| 86 | + |
| 87 | +```typ |
| 88 | +// happily coding, but how do I use this one complex function again? |
| 89 | +
|
| 90 | +#mypackage.help("func") |
| 91 | +#mypackage.help("func(param1)") // print only parameter description of param1 |
| 92 | +``` |
| 93 | + |
| 94 | +This will print the documentation of `func` directly into the document — no need to look it up in a manual. Read up in the [guide](./docs/tidy-guide.pdf) for setup instructions. |
| 95 | + |
| 96 | +## Docstring tests |
| 97 | +It is possible to add simple docstring tests — assertions that will be run when the documentation is generated. This is useful if you want to keep small tests and documentation in one place. |
| 98 | +```typ |
| 99 | +/// #test( |
| 100 | +/// `num.my-square(2) == 4`, |
| 101 | +/// `num.my-square(4) == 16`, |
| 102 | +/// ) |
| 103 | +#let my-square(n) = n * n |
| 104 | +``` |
| 105 | +With the short-hand syntax, a unfulfilled assertion will even print the line number of the failed test: |
| 106 | +```typ |
| 107 | +/// >>> my-square(2) == 4 |
| 108 | +/// >>> my-square(4) == 16 |
| 109 | +#let my-square(n) = n * n |
| 110 | +``` |
| 111 | +A few test assertion functions are available to improve readability, simplicity, and error messages. Currently, these are `eq(a, b)` for equality tests, `ne(a, b)` for inequality tests and `approx(a, b, eps: 1e-10)` for floating point comparisons. These assertion helper functions are always available within docstring tests (with both `test()` and `>>>` syntax). |
| 112 | + |
84 | 113 |
|
85 | 114 | ## Changelog
|
86 | 115 |
|
|
0 commit comments