Markdown uses ``` to start and end fenced code blocks. However code
blocks can themselves contain ``` sequences.
To deal with this, markdown allows code block fences to be of arbitrary
length; any sequence of fence-chars that is shorter than the opening
fence will not terminate the code block.
We can scan through the code block text to find the longest sequence of
`-chars to ensure the opening/closing fences are longer than the longest
in the code block.
Link: https://github.com/danth/stylix/pull/1218
Reviewed-by: awwpotato <awwpotato@voidq.com>
Co-authored-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Reviewed-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
This works around GitHub's limit on the number of matrix jobs (fixes
#947), by running all builds in a single job. To maintain some speed, we
use `nix-fast-build`, which uses multiple cores for evaluation, and skips
any builds for which the final derivation is already in a binary cache.
Although this makes the run for an individual pull request slower, the
amount of duplicated work is greatly reduced: previously, we often had
100 machines building the same derivation in parallel. This means that
more runners are available should there be multiple pull requests opened
in a short space of time, so there is less queuing. It's also more
energy efficient.
A potential downside is that the logs are all merged together, so it can
be hard to find what failed when lots of outputs were built.
`nix-fast-build` does report a list of failed attributes at the end of
the log, but this is currently broken:
https://github.com/Mic92/nix-fast-build/pull/98
The script used to launch `nix-fast-build` is also added to the
developer shell for local use. This replaces the old `nix-flake-check`
package (closes#898).
I also saw the opportunity to enable checks on `aarch64-linux` and
`aarch64-darwin` - as these are available as GitHub hosted runners.
Using too many "info" and "warning" boxes makes them less effective when
they're needed to draw attention to something genuinely important.
This commit adds important boxes to modules which require an external
module to be imported, similar to the box already used on the "Firefox and
derivatives" page.
It changes the warning when a module has no maintainers to a regular
paragraph.
The note about `stylix.enable` being new is removed, since this has been
around for a while now.
As promised at
https://github.com/danth/stylix/pull/977#pullrequestreview-2683388232,
this lists the maintainers for each module on its page in the docs.
This includes some fixes to `stylix/meta.nix`: swapped the order of
arguments to `mapAttrs`, and added an `import` to load the meta file
rather than returning its path.
Optionalize the stylix.image option when stylix.base16Scheme is set,
making the following Stylix configurations valid:
[
// Now it possible to set 'stylix.image = null', if
// stylix.base16Scheme is set.
{
base16Scheme = /* ... */;
}
// This configuration was already possible.
{
image = /* ... */;
}
// This configuration was already possible.
{
base16Scheme = /* ... */;
image = /* ... */;
}
]
Closes: https://github.com/danth/stylix/issues/200
Closes: https://github.com/danth/stylix/issues/442
Link: https://github.com/danth/stylix/pull/717
Co-authored-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Reviewed-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Tested-by: NAHO <90870942+trueNAHO@users.noreply.github.com>
Reviewed-by: Daniel Thwaites <danth@danth.me>
Parametrize and change the testbed field separator to the colon (':')
character to avoid ambiguity with module names containing hyphens ('-'),
and allow testbed names to contain hyphens.
Fixes: 211a8440e7 ("stylix: support multiple testbeds per module (#858)")
Collapsing is only possible for pages, not headings, so I had to
combine platforms and modules into a single section and nest them
under draft pages.
Later, we could migrate some content from the configuration page to
these draft pages to make the flow of the book more natural.
This has two benefits:
1. It will be displayed when browsing the module source code on
GitHub.
2. It prevents the documentation inadvertently disappearing if the
module directory is renamed.
